I was really enjoying reading this piece until I read the above, then I realized I am reading for a big developer, the maker of, Celeste [1]. I am definitely adding this to my list of favorite articles about making games.
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!
"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.
> 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.
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.
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
After I read the title, I fully expected this to be about writing games using AI. But no, actually there is no mention of AI to be found in the text, not even in the "Miscellaneous Thoughts" section, which seems to be mostly answers to "why don't you use X?" questions. Refreshing...
Why would a game development pedigree correlate with rejecting AI? As Carmack said:
> AI tools will allow the best to reach even greater heights, while enabling smaller teams to accomplish more, and bring in some completely new creator demographics.
I don't use AI for the sake of it, I use it where and when it is useful. For example:
1. advanced autocomplete -- if you have or paste the structure of a JSON or other format, or a class fields, it is good at autocompleting things like serialization, case statements, or other repetitive/boilerplate code;
2. questions -- it can often be difficult to find an answer on Google/etc. (esp. if you don't know exactly what you are looking for, or if Google decides to ignore a key term such as the programming language), but can be better via an AI.
Like all tools, you need to read, check, and verify its output.
It's kinda sad SFML never get quoted, It was my framework ( after ALLEGRO ) where i learned c++ and I think it dosen't get much love nowdays even if it is very light and strong
The primary thing I'm going for in a commercial engine is platform targeting and stability. Some of the defaults are certainly "bland", but that ensures I can actually ship this thing to a meaningful % of the available market. Unity's coverage is so consistent that I've been debating using it for non gaming applications. There aren't many cross platform ecosystems that work this well.
Nice article, engines are bloated and introduce so many overheads. If you don't intend to ship any AAA games, consider investing your times to learn code-first game frameworks like libGDX, MonoGame, love2d,... or even lower level stuffs like SDL, bgfx, opengl which are good enough for almost any cases. A bit higher learning curve is expected but it won't hide anything from you, or bury you under tons of bloated abstractions.
Nobody seems to consider that doing it yourself, requires you implement it at least as efficiently as the commercial engine did, otherwise you're just creating a worse-performing implementation that seems to behave just like a bloated engine does.
The big difference is that the big game engines have to cover all sorts of genres and scenarios, which often results in bloated "jack of all trades master of none" code compared to engine-layer code that's highly specialized for exactly one, or few very similar games.
I’d highly recommend going with SDL if it’s 2D. IMO libraries like MonoGame, Love2D, LibGDX only offer small conveniences over SDL with big negative tradeoffs, sacrificing portability, quality of libraries, and conventions. The downsides of using C++ are now heavily mitigated with the use AI tools.
I could never jell with C++ until I had Cursor hold my hand (especially around the build system), and now I feel like I am developing games with a razor sharp knife that I could never before access. The patterns associated working directly with memory suddenly clicked and now it’s the only I want to build games.
I'm actually building my own mini-engine with SDL_GPU. It works ok so far. I'm quite confident that it's capable enough to replicate most of Unity's URP features (except the shader graph as I don't plan to expose such an interface for artists).
But I haven't reached to the more tedious parts, like doing skeleton animation on GPU and testing cross platform (SDL should be naturally cross platform, but I never tested it...), etc. The most tedious part, imo, is to build your own 3D scene editor.
At very least I can say SDL has reached a passable state for 3D. It doesn't support some modern features like bindless though.
And one doesn't need to stich with C++ if they don't want to. SDL is pure C and if your favorite language can call foreign function it's not that hard to make it work with SDL.
Similar, I also went back to mainly C++ and Raylib now that I can delegate the "boring" stuff to AI, never had any issues with programming in C++ it was mainly adding dependencies and builds I hated (configuration).
I still don't use it for the game programming as it sucks the joy out of it for me. Especially when AI usage is currently being pushed hard at work.
This was a great read. I'm in my 40's and have mostly done web dev/devops type stuff throughout my career. Making video games has always eluded me even though I've always been interested in it. I think it's that everything feels like a brand new language I have to learn. Perhaps creating an engine is the move.
For prototyping I usually use Kenney assets (from kenney.nl). Theres lots of assets for many types of games which lets you rapidly prototype and iterate without worrying about making assets first. For sounds you can use BFXR and just play around. Sometimes playing around with sounds can even lead to new feature ideas :)
>I often find the default feature implementations in large engines like Unity so lacking I end up writing my own anyway. Eventually, my projects end up being mostly my own tools and systems, and the engine becomes just a vehicle for a nice UI and some rendering...
I honestly don't see anything wrong with using the engine for its UI and "some rendering" kind of sweeps a lot of the complicated 3d light handling under the rug. I think the biggest mistake large engines have made is baking in features as first class citizens instead of those features being part of a standard plugin you could have written yourself from scratch once you reach that stage.
I've contemplated building my own editor UI, but after four weeks I realized that I'm just rebuilding the same UI structure you see in FreeCAD, Blender, Isaac Sim, Godot, etc. There's always a 3D viewport, there's a scene tree and there is an inspector panel for looking at the properties. So why not just use the Godot editor as a UI and provide my own custom nodes? By the time I've outgrown the training wheels, I've spent months working on the actually differentiating features.
> I honestly don't see anything wrong with using the engine for its UI and "some rendering" kind of sweeps a lot of the complicated 3d light handling under the rug. I think the biggest mistake large engines have made is baking in features as first class citizens instead of those features being part of a standard plugin you could have written yourself from scratch once you reach that stage.
Godot is more or less built that way. The entire node system is an abstraction over the various “servers” and you can even completely forgo it if you want, providing your own MainLoop implementation (instead of the included SceneTree implementation of MainLoop) and then just use the servers directly.
A lot of the editor features are also implemented as plugins. It’s been very easy turning the Godot editor into a custom editor for my game by writing some simple plugins
Creating a game with an engine is like designing a character with a pixel dollbase. You can get something out quickly, skipping a few steps because they're done for you, but you have to live with whatever choices were made by the creator of the engine/dollbase. Those choices can constrain your execution and to some extent, your imagination.
While true, people overestimate how limiting it actually is. It's like wanting to make your own kernel for your application instead of using an off the shelf one like Linux. Sure you might be able to eek out some extra performance but there are so many upsides in reusing Linux.
Has he dealt with some of the more challenging problems in game dev that engines help a lot with? Like... multiplayer netcode.
Seems like if you're doing this for a hobby or solo/small team then maybe it's reasonable.
For most people where they want to be a game dev but they probably will just work in industry, it seems like learning the major engines to competency cannot be ignored.
> that engines help a lot with? Like... multiplayer netcode.
Rust (the top 10 most downloaded game ever on Steam) is built with Unity. However they ended up to write their own netcode anyway. Of course Unity isn't known for the best netcode, but how much an engine helps is often overstated. Genshin even bought Unity's source code to customize it.
You should use tools that are appropriate to what you intend to achieve. If you want to make a 3D game then Unreal, Unity, or Godot are appropriate choices. If you want to make a 2D game then something like MonoGame might make more sense than Unreal. You don't need highly refined netcode if your game never needs to exchange data in realtime.
Heck, I've seen someone build a visual novel-type game with WinForms. That was actually a sensible choice for the game's presentation and interaction needs.
Of course if you want to become a game dev at a studio then you should be competent with whatever the studio uses (or something comparable so you can pivot to their stack). If you only want to make your hobby project and maybe publish it later it doesn't matter if your engine is Unreal, MonoGame, RPG Maker 2000, or vanilla JS/DOM.
I would say that one of the "Miscellaneous Thoughts" at the end of your article answers your question pretty well:
> I need only the best fancy tech to pull off my game idea
Then use Unreal! There's nothing wrong with that, but my projects don't require those kinds of features (and I would argue most of the things I do need can usually be learned fairly quickly).
> Our game, Celeste
I was really enjoying reading this piece until I read the above, then I realized I am reading for a big developer, the maker of, Celeste [1]. I am definitely adding this to my list of favorite articles about making games.
Also, you may want to check a previous discussion from nine months ago (573 points, 246 comments ): https://news.ycombinator.com/item?id=44038209
_____________
1. https://store.steampowered.com/app/504230/Celeste/
Just want to +1 this. It is a game so good I bought (and beat) it twice, once on Switch and once on Steam.
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!
"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.
> 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.
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
After I read the title, I fully expected this to be about writing games using AI. But no, actually there is no mention of AI to be found in the text, not even in the "Miscellaneous Thoughts" section, which seems to be mostly answers to "why don't you use X?" questions. Refreshing...
The author is Noel Berry, creator of Celeste. They don't shout about it, but with that pedigree, I'm confident they'll be staying well away from AI.
Why would a game development pedigree correlate with rejecting AI? As Carmack said:
> AI tools will allow the best to reach even greater heights, while enabling smaller teams to accomplish more, and bring in some completely new creator demographics.
Because they are clearly a talented and successful developer and don't need to rely on slop generators to program for them
Or they'll take a look at what, if anything at all,they can use in their workflow as a useful tool not a magic solution.
No need to brag about that.
They don’t seem to enthusiastic: https://bsky.app/profile/noelfb.bsky.social/post/3maa3m5x4vs...
> can use in their workflow as a useful tool not a magic solution.
Like what? If you can already program your game and create art for it, what is it going to be doing?
People are so obsessed with using AI stuff for the sake of it, it’s nuts
I don't use AI for the sake of it, I use it where and when it is useful. For example:
1. advanced autocomplete -- if you have or paste the structure of a JSON or other format, or a class fields, it is good at autocompleting things like serialization, case statements, or other repetitive/boilerplate code;
2. questions -- it can often be difficult to find an answer on Google/etc. (esp. if you don't know exactly what you are looking for, or if Google decides to ignore a key term such as the programming language), but can be better via an AI.
Like all tools, you need to read, check, and verify its output.
Genuine question re #1: does your text editor not already do that?
I can do long division manually but I still reach for a calculator.
Do you also spend a lot of time maximising calculator utilisation in other places? Maybe trying to write letters with it or composing music with it?
Very interesting article.
It's kinda sad SFML never get quoted, It was my framework ( after ALLEGRO ) where i learned c++ and I think it dosen't get much love nowdays even if it is very light and strong
SFML definitely needs more love than it's receiving.
The primary thing I'm going for in a commercial engine is platform targeting and stability. Some of the defaults are certainly "bland", but that ensures I can actually ship this thing to a meaningful % of the available market. Unity's coverage is so consistent that I've been debating using it for non gaming applications. There aren't many cross platform ecosystems that work this well.
What are some things that you'd build with Unity that aren't games?
Nice article, engines are bloated and introduce so many overheads. If you don't intend to ship any AAA games, consider investing your times to learn code-first game frameworks like libGDX, MonoGame, love2d,... or even lower level stuffs like SDL, bgfx, opengl which are good enough for almost any cases. A bit higher learning curve is expected but it won't hide anything from you, or bury you under tons of bloated abstractions.
Nobody seems to consider that doing it yourself, requires you implement it at least as efficiently as the commercial engine did, otherwise you're just creating a worse-performing implementation that seems to behave just like a bloated engine does.
The big difference is that the big game engines have to cover all sorts of genres and scenarios, which often results in bloated "jack of all trades master of none" code compared to engine-layer code that's highly specialized for exactly one, or few very similar games.
I’d highly recommend going with SDL if it’s 2D. IMO libraries like MonoGame, Love2D, LibGDX only offer small conveniences over SDL with big negative tradeoffs, sacrificing portability, quality of libraries, and conventions. The downsides of using C++ are now heavily mitigated with the use AI tools.
I could never jell with C++ until I had Cursor hold my hand (especially around the build system), and now I feel like I am developing games with a razor sharp knife that I could never before access. The patterns associated working directly with memory suddenly clicked and now it’s the only I want to build games.
I'm actually building my own mini-engine with SDL_GPU. It works ok so far. I'm quite confident that it's capable enough to replicate most of Unity's URP features (except the shader graph as I don't plan to expose such an interface for artists).
But I haven't reached to the more tedious parts, like doing skeleton animation on GPU and testing cross platform (SDL should be naturally cross platform, but I never tested it...), etc. The most tedious part, imo, is to build your own 3D scene editor.
At very least I can say SDL has reached a passable state for 3D. It doesn't support some modern features like bindless though.
And one doesn't need to stich with C++ if they don't want to. SDL is pure C and if your favorite language can call foreign function it's not that hard to make it work with SDL.
Similar, I also went back to mainly C++ and Raylib now that I can delegate the "boring" stuff to AI, never had any issues with programming in C++ it was mainly adding dependencies and builds I hated (configuration).
I still don't use it for the game programming as it sucks the joy out of it for me. Especially when AI usage is currently being pushed hard at work.
This was a great read. I'm in my 40's and have mostly done web dev/devops type stuff throughout my career. Making video games has always eluded me even though I've always been interested in it. I think it's that everything feels like a brand new language I have to learn. Perhaps creating an engine is the move.
Making video games in 2025, sans AI, sans an engine, is harder than some poeple could handle it, and very rewarding: it's like playing Celeste.
What's the best place to get some cool graphics assets, sound etc when making a love2d or sdl or {yourfavoritetech} game?
Don't know about "cool" but I always end up going back to opengameart.org
While most of the stuff is one off assets that do not fit together there are also some nice sets by some creators such as Kenney or Emcee Flesher
Also the Liberated Pixel Cup (LPC) stuff is pretty nice.
Mind you I mostly just look for 2D assets.
https://opengameart.org/users/kenney
https://opengameart.org/users/emcee-flesher
https://opengameart.org/content/lpc-collection
For prototyping I usually use Kenney assets (from kenney.nl). Theres lots of assets for many types of games which lets you rapidly prototype and iterate without worrying about making assets first. For sounds you can use BFXR and just play around. Sometimes playing around with sounds can even lead to new feature ideas :)
I've used itch.io before, it's great! I even made a game using some free assets and AI: https://github.com/acatovic/gothicvania-codex-demo
Putting as much love into it as you can.
itch.io is good for sprite assets and fonts I find.
Discussed before: https://news.ycombinator.com/item?id=44038209
(246 comments)
https://en.wikipedia.org/wiki/Celeste_(video_game)
>I often find the default feature implementations in large engines like Unity so lacking I end up writing my own anyway. Eventually, my projects end up being mostly my own tools and systems, and the engine becomes just a vehicle for a nice UI and some rendering...
I honestly don't see anything wrong with using the engine for its UI and "some rendering" kind of sweeps a lot of the complicated 3d light handling under the rug. I think the biggest mistake large engines have made is baking in features as first class citizens instead of those features being part of a standard plugin you could have written yourself from scratch once you reach that stage.
I've contemplated building my own editor UI, but after four weeks I realized that I'm just rebuilding the same UI structure you see in FreeCAD, Blender, Isaac Sim, Godot, etc. There's always a 3D viewport, there's a scene tree and there is an inspector panel for looking at the properties. So why not just use the Godot editor as a UI and provide my own custom nodes? By the time I've outgrown the training wheels, I've spent months working on the actually differentiating features.
> I honestly don't see anything wrong with using the engine for its UI and "some rendering" kind of sweeps a lot of the complicated 3d light handling under the rug. I think the biggest mistake large engines have made is baking in features as first class citizens instead of those features being part of a standard plugin you could have written yourself from scratch once you reach that stage.
Godot is more or less built that way. The entire node system is an abstraction over the various “servers” and you can even completely forgo it if you want, providing your own MainLoop implementation (instead of the included SceneTree implementation of MainLoop) and then just use the servers directly.
A lot of the editor features are also implemented as plugins. It’s been very easy turning the Godot editor into a custom editor for my game by writing some simple plugins
Creating a game with an engine is like designing a character with a pixel dollbase. You can get something out quickly, skipping a few steps because they're done for you, but you have to live with whatever choices were made by the creator of the engine/dollbase. Those choices can constrain your execution and to some extent, your imagination.
While true, people overestimate how limiting it actually is. It's like wanting to make your own kernel for your application instead of using an off the shelf one like Linux. Sure you might be able to eek out some extra performance but there are so many upsides in reusing Linux.
Has he dealt with some of the more challenging problems in game dev that engines help a lot with? Like... multiplayer netcode.
Seems like if you're doing this for a hobby or solo/small team then maybe it's reasonable.
For most people where they want to be a game dev but they probably will just work in industry, it seems like learning the major engines to competency cannot be ignored.
> that engines help a lot with? Like... multiplayer netcode.
Rust (the top 10 most downloaded game ever on Steam) is built with Unity. However they ended up to write their own netcode anyway. Of course Unity isn't known for the best netcode, but how much an engine helps is often overstated. Genshin even bought Unity's source code to customize it.
You should use tools that are appropriate to what you intend to achieve. If you want to make a 3D game then Unreal, Unity, or Godot are appropriate choices. If you want to make a 2D game then something like MonoGame might make more sense than Unreal. You don't need highly refined netcode if your game never needs to exchange data in realtime.
Heck, I've seen someone build a visual novel-type game with WinForms. That was actually a sensible choice for the game's presentation and interaction needs.
Of course if you want to become a game dev at a studio then you should be competent with whatever the studio uses (or something comparable so you can pivot to their stack). If you only want to make your hobby project and maybe publish it later it doesn't matter if your engine is Unreal, MonoGame, RPG Maker 2000, or vanilla JS/DOM.
Well yeah, he's working with a pretty small team, and quite successfully: https://en.wikipedia.org/wiki/Celeste_(video_game)
I would say that one of the "Miscellaneous Thoughts" at the end of your article answers your question pretty well:
> I need only the best fancy tech to pull off my game idea
Then use Unreal! There's nothing wrong with that, but my projects don't require those kinds of features (and I would argue most of the things I do need can usually be learned fairly quickly).
i am making a text editor/ide in Go and i too switched from raylib to sdl. it's likely one of the best graphics layers out there.