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...
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.
How does one pick a tool/framework from these options when starting out with game development? I've seen the sentiment of "just pick anything" but the amount of choices is giving me some analysis paralysis.
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.
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.
>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.
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.
There's a tendency to ascribe the entirety of id's technology to Carmack. Michael Abrash, as one example, was a major factor.
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.
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.
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.
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.
I have wanted to make games my whole life but I got into web to make a living. Now it's been decades of game ideas and no implementations, just frustration. Something about unity, unreal, godot just never clicks with me
Maybe I'll try making my own engine too. Best of luck to you, maybe the both of us can make our dreams come true with a slightly different approaches
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
I read that article a while ago and highly enjoyed it. C# truly has become a very good language for game development and since NativeAOT has become a thing, we will less and less rely on hacks like IL2CPP or BRUTE which transpile the C# IL to C++ such that it can run on JIT restricted platforms like consoles or iOS.
I'd really love to go all-in with C# and SDL3 to make an engine-less cross-platform game but I still miss a good way to make complex game UIs without doing everything from scratch. Does anyone have a good suggestion for making non-trivial game UIs without using a full game engine? So far, I only found https://github.com/vchelaru/Gum and https://github.com/mikke89/RmlUi but I think there's not really something super mature and feature packed, or is there? I'm aware of https://github.com/ocornut/imgui, as the article also mentioned, but that's more for debug UIs, right?
I see `dotnet watch` being mentioned for code hot reload which is such a great feature for quickly iterating on a game. Not having to restart the whole game just because one has changed a few if statements and values really helps staying in the flow.
But I'm still not too enthusiastic about having GC in C# which is why ideally I'd like to start making a small 2D game just with SDL3 and C++ but how could I get this nice hot reload workflow there? I don't have the money to pay for expensive proprietary tools like https://liveplusplus.tech so what can I do? I guess there's the "game as dynamic library" trick from Handmade Hero (see https://www.youtube.com/shorts/seWAIURXxH0) so maybe that would work good enough? Maybe https://github.com/fungos/cr would do most of what's needed here?
Also, how does one even do modern C++ these days? Is it possible to have big C++ code bases that still compile fast these days? Is CMake 4 good™ now? Are modules really there yet? I rely on clangd as LSP for working with C++ but I read that clangd still fundamentally struggles with C++ modules https://chuanqixu9.github.io/c++/2025/12/03/Clangd-support-f... and it's so bad that there has even been some effort going into making a new C++ LSP https://github.com/clice-io/clice
If you implement the actual game logic in a scripting language like Lua, hot reloading becomes trivial. sol2 is a really awesome Lua binding library for C++: https://github.com/ThePhD/sol2
Reading this I realized even for someone who just wants to make games that are fun for him, I find engines very less rewarding to work with. I always loved game libraries that provided utilities to build things but hated do everything ones ( love2d supremacy ). It's great to see experienced and accomplished professionals validating my take :)
I saw this documentary on how celeste was made [1], which completely inspired me and got me into indie game dev community. Unfortunately I haven't made any games as of now that I would proudly showcase but the seed that your effort put is still there and one day I will get back to making games. Thanks a lot for making celeste I absolutely love it!
----
1. https://youtu.be/MSKOQr_YS-U?si=AGzl5ILzxkoIB-j9
I generally worked on AAA stuff but the few times I released stuff independently I ended up writing my own framework/engine.
I think the issue was when I used an engine the scope was too large and I never completed the work so I never released the game (or I released it for free because I felt it was incomplete and wasn't worth charging for)
A lot of modern games ‘feel’ the same to me now. Same sort of lighting, blur.. even the texture loading and pop in. They all sort of blend into one mess.
I liked when games all felt very distinctly different and I feel like part of that was that they all varied on ‘engine’
To anyone with experience on the matter: I'm looking for making a mobile app which resembles more of a game or "a graphical app" and was looking into tech I could use, all I need is a drawing API I could use cross platform for Android and iOS without much hassle, don't need any OS specific widget/component, I just want to draw stuff on the screen, handle touch input and do some network calls. Possibly with a statically typed language that gets compiled and has good performance. So far I excluded React Native because it's javascript and has too many dependencies(especially with expo) and SDL3 with plain C which seemed a little too much low level to dealing with on a mobile phone. Also tried go mobile but seems unmaintained and gives opengl context which is deprecated on iOS, and finally I'd really liked using Raylib but no iOS support :(. Any suggestion?
51 comments
[ 4.1 ms ] story [ 68.3 ms ] thread(246 comments)
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/
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.
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!
There's a tendency to ascribe the entirety of id's technology to Carmack. Michael Abrash, as one example, was a major factor.
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.
I have wanted to make games my whole life but I got into web to make a living. Now it's been decades of game ideas and no implementations, just frustration. Something about unity, unreal, godot just never clicks with me
Maybe I'll try making my own engine too. Best of luck to you, maybe the both of us can make our dreams come true with a slightly different approaches
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
I'd really love to go all-in with C# and SDL3 to make an engine-less cross-platform game but I still miss a good way to make complex game UIs without doing everything from scratch. Does anyone have a good suggestion for making non-trivial game UIs without using a full game engine? So far, I only found https://github.com/vchelaru/Gum and https://github.com/mikke89/RmlUi but I think there's not really something super mature and feature packed, or is there? I'm aware of https://github.com/ocornut/imgui, as the article also mentioned, but that's more for debug UIs, right?
But I'm still not too enthusiastic about having GC in C# which is why ideally I'd like to start making a small 2D game just with SDL3 and C++ but how could I get this nice hot reload workflow there? I don't have the money to pay for expensive proprietary tools like https://liveplusplus.tech so what can I do? I guess there's the "game as dynamic library" trick from Handmade Hero (see https://www.youtube.com/shorts/seWAIURXxH0) so maybe that would work good enough? Maybe https://github.com/fungos/cr would do most of what's needed here?
Also, how does one even do modern C++ these days? Is it possible to have big C++ code bases that still compile fast these days? Is CMake 4 good™ now? Are modules really there yet? I rely on clangd as LSP for working with C++ but I read that clangd still fundamentally struggles with C++ modules https://chuanqixu9.github.io/c++/2025/12/03/Clangd-support-f... and it's so bad that there has even been some effort going into making a new C++ LSP https://github.com/clice-io/clice
I saw this documentary on how celeste was made [1], which completely inspired me and got me into indie game dev community. Unfortunately I haven't made any games as of now that I would proudly showcase but the seed that your effort put is still there and one day I will get back to making games. Thanks a lot for making celeste I absolutely love it! ---- 1. https://youtu.be/MSKOQr_YS-U?si=AGzl5ILzxkoIB-j9
The best examples I can think of are Thumper, Devil Daggers, Hyper Demon, The Witness, and No Man's Sky. And of course, Minecraft!
I think the issue was when I used an engine the scope was too large and I never completed the work so I never released the game (or I released it for free because I felt it was incomplete and wasn't worth charging for)
It's great to work in a constrained environment
I liked when games all felt very distinctly different and I feel like part of that was that they all varied on ‘engine’