alt Hacker NewsMy experience with making your own engine vs using an off the shelf solution - the former can be viable and even superior on the condition that you know what you're doing. That is if you've built entire games or engines before, or have enough experience with the internals of one.
Otherwise it can be a dangerous fool's errand on which many projects go to die. My younger naive self can attest to this, he loved trying to build his own overly-ambitious engines. But he never finished any games.
Another thought if you do roll your own - keep it simple stupid. When your brain tells you that some amazing nested scene graph with integrated occlusion culling would be the coolest thing in the world, but you lack evidence that you'll actually need all that functionality, tell your brain that it's being stupid and just implement some kind of basic flat scene structure. You can always retrofit it later.
Also - study the code of the likes of Carmack. Consider that he produced the likes of the quake engines in only a couple of years. Reflect long and hard on the raw simplicity of a lot of that code.
Do not worship complexity.
These are the words of someone who has walked both roads!
Replies
"Also - study the code of the likes of Carmack. Consider that he produced the likes of the quake engines in only a couple of years. Reflect long and hard on the raw simplicity of a lot of that code."
Also says something about the accumulation of complexity. At that time Carmack (and his team) were able to create a state of the art engine in a few years. Now consider the task today, if you were to create a state of the art engine today it'd take tremendously more work.
I see making a game engine as the illusion of progress on making a game. Making a game engine is fun and relatively easy. You have a check list of things to do. Each of them the solutions are relatively well known. so you do them and make tons of progress. You get a window open, then you get a triangle up, then you get a texture loaded, then you get some basic text for debugging, then you read the keyboard for input, etc etc. each day new stuff comes up and you think you’re making progress but really you haven’t even started making the game , you’re just reproducing what you could have already had if you’d started with an existing engine.
Then you start it hit the more tedious stuff. loading animated characters, blending animations on selective subtrees of a character hierarchy. Making a level editor. Adding quality of life feature to it like undo. Etc…
I’m not saying you shouldn’t do this. It’s fun to do. just don’t delude yourself that that’s making progress on your game. It’s instead making progress on a game engine. That’s a different thing.
I've shipped 18 games, 4 of them AAA. I wrote the engines for most fo them. I wouldn't do it again.
All that said, some nuance. If the game you are making is simple for some defintion of simple, Celeste, Dead Cells, Geometry Wars. Then making your own engine isn't much work and there maybe some benefits.
On the other hand, see all the tiles made with engines. Silksong is Unity. A Short Hike is Unity. Blue Prince is Unity. Valheim is Unity. Peak is Unity. Dredge is Unity. You don't need to make your own engine to make an indie game.
when Quake was being written, it was pushing the level of managable complexity at the time.
they used NeXT workstations to develop it, the programming tools on PCs were too weak for such a project
today it might look simple, but it's easy to say that when you open it in VS Code and have Intellisense, autocomplete, go to definition, ultra fast compilers, tons of RAM, and google for everything
> Consider that he produced the likes of the quake engines in only a couple of years. Reflect long and hard on the raw simplicity of a lot of that code
Things like the famous fast inverse square root are short, but I would hesitate to describe it as simple.
Ironically one of the things that the Quake engine relies on is clever culling. Like Doom, the level is stored in a pre-computed binary space partition tree so that the engine can uniquely determine from what volume you're in what the set of possibly visible quads is (if my memory is correct, oddly the engine uses quads rather than triangles) AND how to draw them in reverse order using painter's algorithm, because the software renderer doesn't have a z-buffer.
https://www.fabiensanglard.net/quakeSource/quakeSourceRendit...
The BSP partitioning used to take several minutes to run back in the day.
Anyway, the point I was trying to make was that Carmack used a few, clever, high-impact techniques to achieve effects, which were also "imperfect but good enough".
If you're not Carmack, don't over-optimize until you've run a profiler.