|
For those that have delved into UE4 recently, how effective would the tools and features be for a strictly 2D game? I'm debating if it would be worth utilizing for a future game project, but if I'm not going to be able to take advantage of 80%+ of the framework while paying 5% of my earnings, I'd probably just roll my own engine using the myriad of free frameworks and libraries. Totally sold on it for any future 3D/2.5D oriented games however.
|
#
?
Mar 29, 2014 22:11
|
|
|
|
| # ? May 11, 2024 17:48 |
|
|
space kobold posted:For those that have delved into UE4 recently, how effective would the tools and features be for a strictly 2D game? I'm debating if it would be worth utilizing for a future game project, but if I'm not going to be able to take advantage of 80%+ of the framework while paying 5% of my earnings, I'd probably just roll my own engine using the myriad of free frameworks and libraries. Yea I dunno. There is a whole lot of stuff. It is certainly capable of 2d no doubt. I guess it depends on your long and short term goals. If your long term goal is to learn the engine and use it for lots of projects then I would start now. You can easily add on to the engine and tools over time to make it even easier to make 2d stuff with it, if that is your focus. But short term there is one hell of a learning curve to even use it moderately well, let alone taking advantage of its full potential.
|
|
#
?
Mar 29, 2014 23:18
|
|
|
Have there ever been any strictly 2D games made with the Unreal engine? And I don't just mean 4, I can't think of any on any iteration.
|
|
#
?
Mar 30, 2014 01:23
|
|
|
Yodzilla posted:Have there ever been any strictly 2D games made with the Unreal engine? And I don't just mean 4, I can't think of any on any iteration. Does Unreal Engine even have an orthographic camera? If not, a pure 2D game would be pretty tough.
|
|
#
?
Mar 30, 2014 01:25
|
|
|
Obsurveyor posted:Does Unreal Engine even have an orthographic camera? If not, a pure 2D game would be pretty tough. They have a 2d game written in pure blueprint, provided as an example.
|
|
#
?
Mar 30, 2014 01:41
|
|
|
xgalaxy posted:They have a 2d game written in pure blueprint, provided as an example. But I bet it's still 3D models right? I believe Yodzilla was talking about using texture mapped quads as sprites. You need an orthographic camera for that or you get perspective distortion. With the source code available, it's probably not a big deal to edit the camera settings but I believe the old UDK didn't have one.
|
|
#
?
Mar 30, 2014 01:53
|
|
|
Obsurveyor posted:But I bet it's still 3D models right? I believe Yodzilla was talking about using texture mapped quads as sprites. You need an orthographic camera for that or you get perspective distortion. With the source code available, it's probably not a big deal to edit the camera settings but I believe the old UDK didn't have one. No its 2d sprites, yes they use an orthographic camera.
|
|
#
?
Mar 30, 2014 02:03
|
|
|
Obsurveyor posted:Does Unreal Engine even have an orthographic camera? If not, a pure 2D game would be pretty tough. I don't know of any 3d engines that don't support an orthographic camera. It's trivial to implement and the difference from projection is minuscule (literally changing a few values in the projection matrix). If you have access to the camera matrices it's easy to implement yourself too.
|
|
#
?
Mar 30, 2014 03:01
|
|
|
Replaced jewels with pinecones. Jewels just scream F2P IAP, and we're going to be a pay-for game with no significant IAP. Though eventually a f2p "demo" is probable, we really didn't like the way the game went when we tried to build it around IAP. We are going to be poor forever  (but at least we'll like the games we make instead of hate them!)
|
|
#
?
Mar 30, 2014 03:07
|
|
|
Goreld posted:I don't know of any 3d engines that don't support an orthographic camera. It's trivial to implement and the difference from projection is minuscule (literally changing a few values in the projection matrix). If you have access to the camera matrices it's easy to implement yourself too. I'm pretty sure, up until UE4, you couldn't get an orthographic camera out of the UDK that indies had access to: http://forums.epicgames.com/threads/940114-Orthographic-Camera-Q I did some more digging and still couldn't find anything about it in previous versions of Unreal, except that, no, you didn't have access to the camera matrix and even if you did, it would break a ton of other stuff in Unreal. Yodzilla's question included older versions of Unreal Engine as well. We've answered the question about UE4 to death now, thanks.
|
|
#
?
Mar 30, 2014 03:32
|
|
|
Unormal posted:Replaced jewels with pinecones. Way to take the high road in the face of potential IAP revenue. I'm definitely looking forward to your game so you can expect at least 1 sale.
|
|
#
?
Mar 30, 2014 03:33
|
|
|
poemdexter posted:Way to take the high road in the face of potential IAP revenue. I'm definitely looking forward to your game so you can expect at least 1 sale. Thanks. I dunno if it's the high road or not, but it's a game I'd personally play vs. a game I personally would not play, which is what it ultimately came down to for us.
|
|
#
?
Mar 30, 2014 03:48
|
|
|
Unormal posted:Thanks. I dunno if it's the high road or not, but it's a game I'd personally play vs. a game I personally would not play, which is what it ultimately came down to for us.
|
|
#
?
Mar 30, 2014 03:49
|
|
|
Can somebody recommend an online resource that hosts free .obj files with texture coordinates, if such a place exists? I've finally got my 3D engine to load .obj files and I just want something I can play around with (aside from the one .obj file the tutorial provides) without having to spend a lot of time learning 3D design.
|
|
#
?
Mar 30, 2014 06:39
|
|
|
I've been experimenting with PuzzleScript (site is currently down), a tiny language for making grid-based puzzle games. I did a "demake" of the LD28 game PUSH. Play it here.  PuzzleScript can be surprisingly concise. The core behavior only takes up 40 lines of code. source code | editor link
|
|
#
?
Mar 30, 2014 07:39
|
|
|
ROFLburger posted:Can somebody recommend an online resource that hosts free .obj files with texture coordinates TurboSquid is good for crap like that, if you don't mind crap being.. well, largely crap. Here's a turbosquid filter for free obj files Other options include Googling for ext:obj and seeing what gets thrown back.
|
|
#
?
Mar 31, 2014 10:58
|
|
|
Does anyone have any exciting subjects in computational geometry that would be useful in game development? I'm doing my master's thesis soon :-D
|
|
#
?
Mar 31, 2014 17:26
|
|
|
Boz0r posted:Does anyone have any exciting subjects in computational geometry that would be useful in game development? I'm doing my master's thesis soon :-D If you're willing to move to Stockholm, I'm sure we could figure something out. I work for Paradox Development Studio if it could interest you.
|
|
#
?
Mar 31, 2014 21:12
|
|
|
I'm balls deep in my first major RPG project, and I can't believe how long it takes to do UI stuff. It's like, the fun parts -- coding combat, quests, "achievements", generating monsters -- takes no time at all. But writing a method that displays a dialogue window with the NPC's portrait and text, and will also be able to handle dialogue options when appropriate and communicate with other parts of the game to, for example, open up a shop interface or update a quest variable.  Every time I try to pick a bite-sized project, I end up expanding it like crazy with quality of life standards that generate an insane amount of overhead code. Really makes you appreciate modern indie games with smooth interfaces.
|
|
#
?
Apr 1, 2014 01:01
|
|
|
With all the complaining you guys do about UI programming here and in the other thread, I'm starting to think I need to become a UI programmer-for-hire...
|
|
#
?
Apr 1, 2014 03:44
|
|
|
UI programming can be one of the most fun programming jobs, as long as you have: A) Good tools B) A good UI library, or C) Enough time to make some good tools and a good library. Only problem is that a lot of people leave it until the last minute and didn't even consider how everything was going to tie together with it. It's a lot like supporting multithreading or networking; It's not bad if you plan for it from the start, but if you don't you're going to be in for a world of hurt.
|
|
#
?
Apr 1, 2014 05:23
|
|
|
Zerf posted:If you're willing to move to Stockholm, I'm sure we could figure something out. I work for Paradox Development Studio if it could interest you. That's a fine offer, but for now I'm just looking for a subject to write my thesis on 
|
|
#
?
Apr 1, 2014 13:16
|
|
|
Boz0r posted:Does anyone have any exciting subjects in computational geometry that would be useful in game development? I'm doing my master's thesis soon :-D Have ball trees/cone trees/etc percolated across to game development yet?
|
|
#
?
Apr 1, 2014 14:35
|
|
|
dupersaurus posted:With all the complaining you guys do about UI programming here and in the other thread, I'm starting to think I need to become a UI programmer-for-hire... 
|
|
#
?
Apr 2, 2014 04:53
|
|
|
SupSuper posted:Nothing grows hair on your chest like reinventing every standard UI control. This is a lot of fun but not in the middle of trying to get a real app made, for obvious reasons.
|
|
#
?
Apr 2, 2014 05:33
|
|
|
SupSuper posted:Nothing grows hair on your chest like reinventing every standard UI control. I haven't yet had a moment when I wished I had at home some of the widgets I've made at work, but I know the moment is going to come and it's going to be really annoying.
|
|
#
?
Apr 2, 2014 13:29
|
|
|
I just finally learned about unit/integration testing in Unity, and I'm wondering if a TDD is good for making games. I figured I'd make a new mechanic in an integration test (let's say, walking over a tile) then putting it in the game. I'd also figure I'd unit test everything I can, so I know the exact second my terrible programming fails hilariously. Does this sound like a good idea to you people, or does it sound like a giant pain in the rear end?
|
|
#
?
Apr 2, 2014 13:50
|
|
|
TwoQuestions posted:I just finally learned about unit/integration testing in Unity, and I'm wondering if a TDD is good for making games. I figured I'd make a new mechanic in an integration test (let's say, walking over a tile) then putting it in the game. I'd also figure I'd unit test everything I can, so I know the exact second my terrible programming fails hilariously. Yes. Lots of game programmers don't like to do it because ~~my productivity~~ but coming back and adding functionality to code you don't have under test is utter misery. With Unity in particular, try to partition off code that actually has to interact with the engine, and minimize the amount of logic you put in there. While there is unit testing support for engine interactions, it's much easier to work with code that's isolated from it.
|
|
#
?
Apr 2, 2014 14:06
|
|
|
TwoQuestions posted:Does this sound like a good idea to you people, or does it sound like a giant pain in the rear end? TDD always sounds like a pain in the rear end, but would be amazing for some of the more basic development early in the life cycle. It's almost always better to have unit tests then not but like everything else moderation is the key. Make sure to only unit tests things that matter and that you can keep your unit tests up to date. Also don't try for more than about 50-70% code coverage as it becomes massively diminishing returns.
|
|
#
?
Apr 2, 2014 15:25
|
|
|
Stick100 posted:TDD always sounds like a pain in the rear end, but would be amazing for some of the more basic development early in the life cycle. It's almost always better to have unit tests then not but like everything else moderation is the key. I've seen TDD work, but I'm not convinced it scales down well. It seems to work great when you have a large engineering team that can absorb the (slight at that scale) productivity drop, and that specifically has the time to maintain the framework throughout the lifetime of the codebase. On the other hand, when you bung in TDD and then walk away and count on it working forever... that's less useful.
|
|
#
?
Apr 2, 2014 15:31
|
|
|
So I've been avoiding Unity for a couple of years now, solely because of its complete lack of modding support for games made in it. But after doing some research into it, I've found what I think to be a good solution, albeit one that many people don't seem to make use of. User scripting can be handled by making use of Jurassic or one of the Lua bindings found on the asset store (or by C# plugins, the method used by Kerbal), but options for importing new content at runtime looked bleak. But then I came across the serialization assets/libs; namely Unity Serializer and the stripped down (to just the actual serialization functionality, none of the save game stuff) subset Unity Serializer Basic. Both are MIT licensed and freely distributable, and both make the claim that they are capable of fully [de]serializing any custom or Unity class, object, component, etc., including textures, meshes, animations, whatever. The ability to import custom content at runtime is even cited as one of their features. The only catch is that instead of the end-user exporting a .fbx or .dae and then loading it at runtime, they instead need to load it into a Unity (free) project, that has a basic editor script setup, to serialize and save their custom content into external files, which are then easily loaded by the game. So I suppose my question is if I can drop lack of modding support as a reason to avoid Unity, given what I've found regarding scripting support and runtime content loading? I've been using Ogre3D and a collection of various open-source libs (with half-assed custom bindings to tie it all together) for a couple of years now, and I'm frankly tired of the trial and error work-flow that's so prevalent when you lack any form of IDE outside Visual Studio/CodeLite/whatever, and your game creation tools consist of a couple utilities you've written here and there to do various menial tasks. So a little over a week ago now, I decided that grass must be greener on the other side and started looking at game engines where I could just focus on the actual game creation and let the engine handle all the foundational stuff. If there's anything I've learned since I started looking, it's that there's a ton of options right now for potential game engines; unfortunately very few of them are particularly any good. There's a ton of options that really have nothing wrong with them, but they never really got traction and didn't develop the communities necessary to drive development of and with them, so they're essentially dead projects. Eventually I worked the list down to just a few options.
|
|
#
?
Apr 2, 2014 18:57
|
|
|
The King of Swag posted:So I've been avoiding Unity for a couple of years now, solely because of its complete lack of modding support for games made in it. But after doing some research into it, I've found what I think to be a good solution, albeit one that many people don't seem to make use of. I'm not sure if there's a way to use StreamingAssets AND make use of Unity's handy Resource.Load() stuff, but I've never investigated it heavily. Even without Resource.Load(), though, it's a perfectly workable approach. You just need to orient your code toward that from the word go, put a few asset loading classes in early, and the difference will be all but transparent. The gist of how you'd do it is: put most of your assets into the Resource directory, and load EVERYTHING that way. Any time you load a Resource, first check if the file exists in StreamingAssets, using a mirrored directory structure such that you can override files in Resources on a per-asset basis. If you're loading from StreamingAssets, use your custom loader, otherwise, use Resources.Load. Everything "above" that in your code can't tell where the asset came from, and boom, you have a moddable framework. You could also just put everything into StreamingAssets, really, and have your data files floating in the wind for anyone to play with. Even if you do that, though, you still want the concept of mirrored directory structure with overriding files. This will NOT work with Web export, though, whereas if you did the Resources/StreamingAssets combo, you could still export a Web build (and it just wouldn't support modding). Shalinor fucked around with this message at 20:21 on Apr 2, 2014 |
|
#
?
Apr 2, 2014 20:18
|
|
|
Is there a downside to just doing that with every project? At a glance it seems like a smart move so you are always ready to have mod support if you so wish. You never know how a project will turn out and you might find yourself wanting to add it later.
|
|
#
?
Apr 2, 2014 20:41
|
|
|
BUGS OF SPRING posted:Is there a downside to just doing that with every project?  thing. I'm way too far into my current project to retrofit that stuff in, and I didn't want to fiddle with it at the start. It'll be at the core of our next project, and anything else we do with Unity most likely.
|
|
#
?
Apr 2, 2014 23:11
|
|
|
Maybe I'm misunderstanding, but wouldn't that method mean that you can't use the scene view at all? Components use asset references instead of resource paths, so deferring the actual asset (mesh/material/texture/whatever) selection entirely until runtime means you won't have a visible GameObject in your scene when developing; it'll all have to be handled programmatically. I would imagine it would be much easier to attach a script to any game object with moddable assets, that just stores an asset location. On awake (or start), the object checks to see if those assets exist at that location. If they do, the custom asset loader loads the file and replaces the currently referenced mesh/material/texture with the newly loaded one, otherwise it does nothing. An alternative that does much the same is to create a "user-content manager" that does the same, just from a centralized source (that eliminates the overhead of attaching it to every object that needs it). Of course, in this situation I'm pretty sure I'm misunderstanding exactly what needs to be done, because it sounds insane to simply drop the Scene view entirely in favor of designing the game 100% in scripts.
|
|
#
?
Apr 2, 2014 23:46
|
|
|
Shalinor posted:None whatsoever. It's just an Would that cause problems with 3rd party plugins expecting to use the standard resource loading mechanisms?
|
|
#
?
Apr 3, 2014 00:08
|
|
|
Subjunctive posted:Would that cause problems with 3rd party plugins expecting to use the standard resource loading mechanisms? It's not either-or though; you can use the streamingassets folder right alongside normal resources, for the things you want to be exposed to modders/your own whatever. StreamingAssets is just yet another special folder (YASF) in Unity.
|
|
#
?
Apr 3, 2014 00:22
|
|
|
The King of Swag posted:Maybe I'm misunderstanding, but wouldn't that method mean that you can't use the scene view at all? Components use asset references instead of resource paths, so deferring the actual asset (mesh/material/texture/whatever) selection entirely until runtime means you won't have a visible GameObject in your scene when developing; it'll all have to be handled programmatically. Personally, our next few projects aren't the kind of thing that you build in Unity editor anyways (heavy procedural / open-world stuff), so we're going to need our own tools anyways. Doubly so since we're focused on modding. On the other hand, my current project (Hot Tin Roof) is VERY reliant on the editor, since it's content-driven, which is also why it isn't mod focused. Just kinda depends what game you've got in mind. I think that most "large" projects are going to shift toward the Resources/StreamingAssets + custom toolsets approach, though. The Unity toolset just has a lot of... weirdness, to it, that can't be fixed. It tries to do too many things at one, and isn't especially good at any of them. Purpose-built toolets for your game would almost invariably be better, you just need the engineering time to build them.
|
|
#
?
Apr 3, 2014 04:10
|
|
|
I feel embarrassed to admit it, but I honestly have no idea how to go about doing TDD (The problems with being self-taught is you miss a lot of stuff like this), and one of my projects seems like it could really benefit from it. Anyone know of a good introduction article or anything?
|
|
#
?
Apr 3, 2014 04:57
|
|
|
|
| # ? May 11, 2024 17:48 |
|
|
AntiPseudonym posted:I feel embarrassed to admit it, but I honestly have no idea how to go about doing TDD Don't be, true TDD is almost never appropriate for game development. The short version of TDD is when you decide you want a new feature (like say, space will cause you to jump) you first go build positive and negative tests. TDD means you first determine and code the unit tests before attempting to code the implementation. Ex. you would make a test that when space is pressed you users should be 2 units higher 1/10th of a second later, and if any other key was pressed then you should be the same high 1/10th of a second later. The problem with TDD for game development is you often have no idea how you are going to solve the problem before you attempt to solve it, and even if you did your intended implementation might not have good game feel and immediately be changed. In short TDD is NOT recommended for game development for these exact reasons. Instead when you have an issue you want to implement, go implement it and afterwards consider if a covering unit test might be worthwhile. In some cases it will but in many it won't, unit tests can be great for code logic, but be very careful to not use too many as it can kill your ability to adapt (which is the essence of early game development). Again, don't do pure TDD, but this seems like a pretty good resource: http://www.agiledata.org/essays/tdd.html Also once you have done TDD make sure to bring it up in every technical interview you ever do and explain exactly why it is and is not appropriate for the application your interview for. Hiring managers love hearing that stuff. Stick100 fucked around with this message at 08:01 on Apr 3, 2014 |
|
#
?
Apr 3, 2014 07:59
|
|