Noel Berry’s recent article “Making Video Games in 2025 (without an engine)” has been making rounds on Hacker News. Noel Berry is one of the developers of Celeste, a successful and technically excellent game.
The main point of the article is that he doesn’t use big commercial engines (Unreal and Unity) because he doesn’t need most of their functionality. It’s more fun to do things on your own and have full control over them. At the same time, not using an engine does not mean you have to implement everything yourself. There is a range of frameworks for every other language with good platform support (FNA, SDL, Raylib, etc.), so that you don’t have to do the plumbing but can start developing your game right away.
Another point he makes is that if you did need advanced 3D or just less effort, Godot is a great choice because it’s truly open source and now capable enough to achieve your vision. (Last year, I wrote “Godot quickstart” following my first steps with the engine.)
Compared to Noel, I’m a complete amateur who only dabbled in game development, but the path I took with Typingvania was motivated by the same reasons. I started out prototyping in Godot, but it made things that were important to me difficult. I wanted resolution-independent GPU text rendering and easier custom binary resource access, and writing my own engine for Typingvania allowed me to do it. Just as Noel says, I used SDL to handle all the system and low-level decisions for me. Using a framework, I still had to implement all the game systems, but they were not generic plumbing — they were specific to the game I was making and only did what I needed to do, nothing more.
Which brings me to the advice in the post’s title: make your game, not an engine. I have seen several experienced gamedevs say it. A trap many beginner game developers fall into, especially if (like me) they’re coming from a programming background, is to start implementing their own game engine that would power their game. It’s “cool” and fun and a great learning opportunity. Invariably it turns into a kitchen sink project and the new game dev gets overwhelmed. Some persevere and create fairly good general-purpose engines which doesn’t bring them any closer to releasing a game. The game engine becomes their project, instead of the game they’ve been making.
If you want to actually release a game, work on the game instead of its engine. Implement only the systems you need to support what you are making. You can keep the “engine” code separate from “game” code and potentially extract the engine later (it’s how many commercial engines were born). Making a complete game engine requires hundreds of small decisions on API design, and I found I was completely inequipped to make them because I simply didn’t have the experience. However, I knew exactly how I wanted a particular element in my game to behave, and I used that to guide the implementation on the “engine” side.
Looking back, I should have stayed with Godot because at times, I found the need to implement yet another system exhausting. Now that most of the features are in place, it’s not the most ergonomic experience and I’d rather use a language more expressive than plain C, but it works and I’m happy with the result.
My final point is: do whatever you want! There is no one true way, and you don’t know before your try it for yourself. Would I have made better progress if I stayed with Godot? Maybe. But would I have made that progress if I were not motivated by building the engine tech that tickled my fancy? There’s no way to know. So just try whatever you want and have fun and see where it takes you.