[abcde666777]

My 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!

[spiffyk]

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

[pibaker]

> shifting your mindset from making a game to making a game engine

This reminds me of when someone makes his own static site generator, write one blog post about how he started a blog with his own static site generator, and then post nothing afterwards.

I suspect the reason for this genre of behavior is there is just a tremendous amount of creativity required to come up with anything original enough to justify putting into a game, or a blog, but game engines and static site generators have relatively straightforward feature requirements that you can just implement like any software feature. Building your own game engine or static site generator is just a good way to procrastinate doing the hard part of game making or blogging while still keeping yourself in the game making or blogging zone so that you can tell yourself, yes, I am a game developer or blogger.

[doctorhandshake]

The way I phrase this to myself is ‘make the tool, don’t make the tool that makes the tool.’

[herpdyderp]

On the contrary, making the tool that makes the tool is what I live for! My personal tech stack has benefited incredibly from this practice and fuels my startup, though it did take me 20 years of slow iteration to get here.

[doctorhandshake]

Well I’m not anti ;) … I just mean if your goal is to make the thing and you’re sure you need a tool to do it, watch out for the temptation to make the tool that makes the tool, which is the LONG way around, as OP was saying

[performative]

that's really dope, but i'm not sure if it'll work out the same way nowadays. i think we're in a weird stage where momentum REALLY matters in a way that it didn't 10 years ago or 5 years down the line (probably)

[__xor_eax_eax]

YAGNI still undefeated in 2026

[pjc50]

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

[BearOso]

> Things like the famous fast inverse square root are short, but I would hesitate to describe it as simple.

Not the best example. That snippet was in use at SGI for years and actually written by Gary Tarolli. Quake's optimization was mostly done by Michael Abrash.

The original id engines were also famously inflexible. They fit the mold of "developing an engine, not a game" to a T. What you saw them do was all they could do. Look at how much Half-Life needed to add to be viable. idtech3 also only broke out of its niche because Ritual and Infinity Ward heavily modified it and passed it around. There's a good reason the engine-based ecosystem is so prominent now.

[jamesfinlayson]

What changes were needed in Half-Life? Quake seemed okay enough to modify though it was rushed and getting close to what was possible with the hardware at the time.

[scott_w]

> (if my memory is correct, oddly the engine uses quads rather than triangles)

I'm also working off a near 30-year-old memory but I recall quads not being unusual around this time. I remember a preview of Tomb Raider 3 in Official Playstation Magazine making a big deal out of the updated engine using triangles instead of quads to draw things. This was around 1998, so a couple of years after Quake came out.

[spppedury]

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

[socalgal2]

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.

[andai]

Randy (funny gamedev guy from YouTube) said in a recent video that he realized he'd spent the last ten years making engines to avoid the creative terror of action making a game. I'm paraphrasing slightly, but that's what it came down to.

"I thought if I made a really good engine, making a game would be the easy part!" I had similar thoughts when I was younger. Surely if I just upgrade my tools, the hard part will become the easy part!

Jonathan Blow says making engines is easy, because enginedev only takes a relatively small part of development — the game itself takes way more time and energy.

So his argument is, in the grand scheme of things, the engine is not that much work. (Since you're gonna spend ten years working on the game anyway, of course ;)

[jz391]

And, of course, the next level of procrastination is to develop your own programming language, which you will use to write the engine to use in creating the game :-) Definitely hats off to Jon for pulling it off - he had a lot of focus and some previous experience - and it also helps to have re$ource$ from past successful games. For many of us, the lure of developing better tools, rather than the end product, proves to be too strong to resist. At least Jon stopped short of developing own OS :-)

[the__alchemist]

Jonathan Blow also makes games at a very slow pace; e.g. his Sokoban games. There are other factors at play, but his pace is consistent with the speed drawback of rolling your own engine.

[rcxdude]

And the thing usually is that what you want from your engine is the flexibility to be able to change things around easily so you can iterate and experiment on the game design itself. Sometimes a custom engine can give you that (especially if you're going off the beaten track) but often the tooling around the off-the-shelf engines is much better for it.

[kleiba]

That's also why the Handmade Hero series took more than 600 episodes to eventually go nowhere.

[whstl]

That’s also why 99% of people building games with Unity or Unreal never get anywhere by themselves or just produce asset-flip slop, and then complain on Reddit about marketing being hard.

Programming an engine requires dedication, but pretty much every other area in gamedev require similar dedication to get to an acceptable result.

[krapp]

Yeah don't end up like me with a folder full of library code, "tests", "prototypes" and a dozen implementations of the Tiled API but no game.

For certain personality types I think making an engine can make it very easy to get distracted and wind up in the weeds of something you don't actually need, overoptimizing, fence-painting etc. Using an engine can help with self-discipline and focus on the end rather than the means, although then you need to make sure you don't just wind up with a ton of mostly finished tutorial projects and no game.

[andsoitis]

> I've shipped 18 games, 4 of them AAA. I wrote the engines for most fo them.

Solo? Or part of a team?

[ses1984]

Can you name one solo dev AAA game let alone four?

[zerr]

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

[diath]

There's also a middle ground - using a framework that already abstracts away things like graphics, window, audio and input handling but acts as a "bring your own engine" base. This is probably the best if you have a specific type of game in mind where generic solutions wouldn't really work. Things like Raylib, SFML, Love2D and so on are a great compromise.

[vor_]

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

There's a tendency to ascribe the entirety of id's technology to Carmack. Michael Abrash, as one example, was a major factor.

[samiv]

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

[abcde666777]

An interesting thing is I think a lot of it's caused purely by the graphical fidelity. For instance an animated character back then was just a key framed polygon soup - compare that with the convincing humanoids games have now.

And yet often the actual gameplay code itself may only be 2x to 3x more complicated then the days of old.

I think of counterstrike for instance - it's still just guys shooting guns in a constrained arena.

[direwolf20]

But you could create Quake.

[andai]

Quake is peak graphics anyway. We hit diminishing returns after that ;)

[threethirtytwo]

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.

[agentultra]

It’ll last as long as there are humans who like making things themselves.

[threethirtytwo]

That’s what they said about assembly coders.

[agentultra]

Guess what, there are still people who write code in assembler.

For plenty of reasons there are lots of programmers who still need to know how to code in assembly, read assembly, etc.

[spiffyk]

The indie gamedev scene is full of people for whom games are an art form. These people don't give two hoots about what "the industry" prioritizes, they just want to make their games their way.

Calling their creations slop and suggesting using AI to make them is honestly quite the insult.