I think the biggest mistake you can make is shifting your mindset from making a game to making a game engine. No, you still want to be dead set on making your game, you just don't have the ready-made building blocks from an off-the-shelf engine, so you have to make your own as you go, and only as needed. Personally, when I was working on my little game, I found it helpful to call the endeavour—just like Noel Berry in TFA—"making a game without an engine", rather than "making a custom game engine". I only really wrote the absolutely necessary plumbing that I needed for the game I was making, nothing more.

The same goes for software libraries in general, I think. Just make your program. Don't make an overly general library for something you won't need anyway. If the code proves useful for reuse, just factor it out after the fact and generalize as needed.

EDIT: Typos, wording

> 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.

I believe most of programmers who dive into game dev are actually interested in game engine and tools development.

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

"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.

AI may change the game here. Most games are slop coded by humans anyway as the industry prioritizes speed and dead lines over code quality.

So having AI build the slop instead of a human seems to make sense. I really wonder how AI is changing the gaming industry.

The articles author strangely left AI out of what he wrote. While I know a lot of HN readers are traditional and love the old way of doing things I don’t know how much longer that way will last.