5 ms·
This applies so much do gamedev. I’ve tried Unity, Unreal, and Godot. But I’ve never been able to produce anything, because there’s just so much to learn. Rigg
by armchairhacker 5y ago
This applies so much do gamedev.
I’ve tried Unity, Unreal, and Godot. But I’ve never been able to produce anything, because there’s just so much to learn. Rigging, particle systems, AI pathing, etc. And so much weird bugs and workarounds. Unity in particular sometimes seems like it was hacked together, and there’s always multiple ways to do everything (DOTS, UI, animation), the broken “beta” way and the “legacy” way.
In contrast, I write my own engine, and even though I have to make everything it’s so much easier. All I need to know is graphics and code. My game engines are much more intuitive to me because I wrote them. And no workarounds, because if the engine has a bug, I can fix it at the source. Of course, this means I end up making smaller games and it’s harder to collaborate with others. But it’s better than no games at all.
With the like 20+ different game engines out there I know I’m not alone.
- reidjs 5y agoDo you actually finish the games? I’ve tried the DIY game engine approach before, but I never have finished a substantial game before because I get caught up in the weeds.
- andai 5y agoBeware the eternal enginedev... many a brave soul have fallen to this trap.
- matheusmoreira 5y agoDeveloping the engine is so much more fun though.
- fermentation 5y agoI think this is why developing emulators is fun. Once you’re done, the games have already been made for you!
- bitwize 5y agoThe way out is to focus on the game. Only build up the engine to the point the game needs it to be built. The bulk of your focus should be on game logic, even when you take writing the engine into account. Granted, I haven't finished my game this way, but the engine isn't really the bottleneck. It's deciding on, and implementing, appropriate behaviors, often for silly, fiddly corner cases.
- raghuveerdotnet 5y agoExactly this. After lots of trial and error I’ve found it easier to build better engines by extracting and abstracting the common elements from my game development process than focusing solely on engine development. Really can’t describe how much my productivity has gone up since I switched my focus by adding constraints to my development process and narrowing my focus to more parochial problems instead of always pondering the general/wider abstractions. It seems that abstractions are the natural consequence of focusing on a narrow and concrete problem, but people instead try to directly jump to the wider abstract space without any bounds or constraints set, and eventually overwhelming themselves.
- armchairhacker 5y agoSort of :). Most of the games are “technically” playable, but not quite ready for distribution (buggy, missing settings), and I’ve never published. The main issue is that I make most of the game, then realize that it’s really unbalanced and the controls are clunky and it isn’t that fun. So i lose interest. Probably related, I don’t really enjoy video games anymore because I get bored too easily.
- wly_cdgr 5y agoSounds like you've finished tons of games. The games just happen to be sandbox gamedev games - i.e., the engines themselves. Release the engines! Also, you could just go work as an engine programmer in AAA or for Unity/Unreal/etc....
- ekster 5y agoA good way to learn game engines is to build a series of games that only require you to learn a few new things with each iteration. The same way you wouldn’t roll your own game engine that has all the features of Godot on your first try.
- dllthomas 5y ago> if the engine has a bug, I can fix it at the source While this is probably going to be easier in something you wrote, note that it's possible in both Godot (F/LOSS) and Unreal (despite being proprietary they give you access to the source for free when you sign up).
- armchairhacker 5y agoYeah it’s definitely possible but a lot harder. Working on my own code is easier than someone else’s code. Of course they would say the same. Collaboration is a really important skill that i work hard to improve. Just not when making video games.
- dllthomas 5y agoYeah, I agree, although it's itself a good skill to practice. I just wanted to surface that of the three, Unity has an additional barrier.
- makeworld 5y agoYou might enjoy raylib, a library for videogame programming. https://www.raylib.com/ https://www.raylib.com/
- joeyjojo 5y agoThis looks look great, thanks for sharing.
- swiley 5y agoEveryone says not to write your own game engine but if you don't know another one it takes about the same amount of time to learn how to use it IMO. The main justification is when you're working in a team everyone can use the same tools.
- joeyjojo 5y agoYes! I coded many games with Flash/AS3, which is regarded as low level these days, but it actually had a lot of abstraction over the rendering. For years I would battle with the opinions of the framework, usually attempting to smooth over it with my own even higher level framework. It wasn't until I start coding directly with HTML canvas that I was finally able to produce code and workflows without the battle. I don't understand why pushing and popping to transformation stacks isn't the norm, when it is just sooo much cleaner. As soon as an underlying framework introduces an object hierarchy for rendering state, in the form of a display list or scene graph, it takes away so much of your ability to structure game state how it best makes sense. I would even say that ECS (entity, component, system) is often times an attempt to smooth over the opinionated framework problem, but it isn't all that great compared to plain and simple data structures for your game state. I wish more people were using rendering libraries such as Kha (http://kha.tech/ http://kha.tech/), building tooling on that sort of tech, and making those lower levels more robust and portable.