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!

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

  0: https://cityofnone.com/

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/)

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.

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?

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

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.

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

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

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]