alt Hacker NewsMaking Video Games in 2025 (without an engine)
Comments
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!
I've been working on Metropolis 1998[1] for +4 years now. Custom C++ engine built with a modified version of SFML 2.5 and SQLite.
Creating my own engine was both a personal and strategic decision for me. I was really worried about running into performance issues with generalist engines, and I did not want the friction of working with someone else's mental model. Pretty sure that friction would have caused so much burnout for me. There's also the long payoff of operating in an environment that you understand top to bottom.
I ignored all the advice about making smaller games first, creating an engine first, etc. Metropolis 1998 is my first game and so far it's working out just fine. But your mileage will vary.. I started development with 10+ years of software experience and fond memories of Rollercoaster Tycoon and SimCity 2000/4.
I only add what I need. There's no level/scene editors (outside of the game being one itself :P ). No scene graphs. Shaders are coded by hand. Right now the entire game is about 45MB.
[1] https://store.steampowered.com/app/2287430/Metropolis_1998/
> 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
_____________
on that theme it reminds my of the Pico-8 community (although technically it is an engine but you dont need to do engine programming even for generating music!!)
compiled a personal webpage to play with mobile controls and a javascript engine to play the pico-8 games and i love the celeste port on that!
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’
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...
100% agree.
• There is overhead in learning how a specific game engine works.
• Often, due to a game engine API, it seems to herd you into writing the same game everyone else is writing with that engine.
I wanted just enough "game engine" to abstract away the pixel-buffer, windowing, user-events on the various target platforms and then do no more.
"I have been using SDL3 as it does everything I need as a cross-platform abstraction over the system - from windowing, to game controllers, to rendering."
And that is exactly where I landed as well. SDL3 [1] absolutely matched what I wanted. Then again, I enjoy writing sprite-based games. If you want to write a 1st-person shooter though I'm sure you will still want to go with one of the giant game engines.
(Actually it was SDL2 since it was two years ago I was exploring it: https://store.steampowered.com/app/2318420/Glypha_Vintage/)
If you're interested on a dive into building game engines, I've enjoyed some of Cherno's videos [1] on developing his game engine Hazel [2][3]. It's cool to see the amount of work that has to go into building an engine. I believe Noel when he says building games without a commercial engine is more fun - there's a lot of fascinating optimizations and tricks at the engine layer.
[1] https://www.youtube.com/playlist?list=PLlrATfBNZ98drHSOb-h2e...
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.
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.
been working on something in three.js and ended up building an editor inside it
its kinda insane how much i can get done with codex
half way through i realize i need a way to build levels and codex suggests you need a editor, here's the PRD following the safety harness and framework in your AGENTS.md and I come back to get coffee and its done....
also have a appreciation for how much game engines do for you, every step of the way I want to add a simple feature and realize we are not using a game engine so those have to built as well
I remember reading this article a while back. It may be partially responsible for me starting my own game project in a custom engine. Also the last 10 years of my professional life have been spent wrangling Unity and Unreal, and, well, I just didn't want to do it anymore.
So I narrowed my game concept to be more stylized, no photorealism, no human characters, etc, in order to make something both unique, and deliverable.
Its inspiring to see others doing the same thing for similar reasons. Maybe I'm not completely crazy after all :)
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?
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
There's a huge difference between "making a game" and "shipping a game".
If journey is more important to you than the destination then developing games without an engine can be a great adventure.
But if you bank on shipping your product within budget and scope then you'd better pick up one. Any one. And stick with it.
I’m in the middle of making a game now in C with raylib. Super small in scope. No level editor or tooling needed.
It’s easy for me. I just know C and raylib’s API is small. I got cross platform compilation going in an afternoon.
I’ve worked through some things with Godot. There’s just so much to learn that it’d take me longer to learn Godot than to get running with C.
Feel much the same as the author.
Inspired by this blog post by Noel Berry, I started playing with SDL3 and C# yesterday, experimenting with falling sand algorithms (implemented sand, stone, and water) https://github.com/alvivar/falling-sand
Discussed before: https://news.ycombinator.com/item?id=44038209
(246 comments)
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)
It's great to work in a constrained environment
A bit off topic. But I think that if the speed of today's LLMs would be a factor 1000 faster, we would need no general purpose engines or frameworks to build a game. One could prompt a complete custom game including all the parts that make the game. Engine. Physics, assets. Sounds, level design everything. Capabilities of for example opus is enough to achieve this. Its only slow.
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
A lot of modern games do feel like they blend together visually, similar lighting models, motion blur, depth of field, texture streaming pop in and I think part of that comes from so many titles relying on the same engines. When more studios were building or heavily customizing their own engines, games tended to have a more distinct identity.
Hey Noel! There is always Neovim :)
- A former VS Code enjoyer
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
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.
No MacOS version for Celeste 64. I would have thought building something from scratch would have meant that its easier to do multiplatform right?
What's the best place to get some cool graphics assets, sound etc when making a love2d or sdl or {yourfavoritetech} 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.
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.
Note that this is primarily about 2D indie games. For 3D, it's not much of a question, you probably need an engine.
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.
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.
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.
[dead]
3 anecdotes:
- For Talos Principle 2, Croteam switched from their own engine to UE5. The description was "It would be like attempting to sprint and catch up with a train that is already far down the track and accelerating even faster.". From a user's perspective, observe the graphics of Serious Sam Siberian Mayhem and Talos Principle 2: Same company, released at a similar time. Talos Principle (UE5) looks dramatically better than SS. (In-house engine)
- Jon Blow rolls his own engines (and lang), and releases games very slowly
- Expedition 33 recently released as a phenomenal game that leaned heavily on features in UE5 (Face/body, graphics, map/terrain gen etc.) They focused on the game itself, and let the engine do the heavy lifting... to a superb result.
From my own anecdotes in graphics programming: Producing a simple engine is easy. Producing something that's photorealistic etc is massively more difficult. Let along all the other things an engine provides for you. Modern games have so many complexities the engine abstracts out; we don't need to roll a new engine for each game or studio, each trying to have optimized netcode, human characters, photorealistic lighting, GUI map editors + terrain gen etc.
I use my own graphics engine for my scientific programs, but it has much simpler requirements than a game engine.