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 think the biggest mistake you can make is shifting your mindset from making a game to making a game engine. No, you still want to be dead set on making your game, you just don't have the ready-made building blocks from an off-the-shelf engine, so you have to make your own as you go, and only as needed. Personally, when I was working on my little game, I found it helpful to call the endeavour—just like Noel Berry in TFA—"making a game without an engine", rather than "making a custom game engine". I only really wrote the absolutely necessary plumbing that I needed for the game I was making, nothing more.
The same goes for software libraries in general, I think. Just make your program. Don't make an overly general library for something you won't need anyway. If the code proves useful for reuse, just factor it out after the fact and generalize as needed.
On the contrary, making the tool that makes the tool is what I live for! My personal tech stack has benefited incredibly from this practice and fuels my startup, though it did take me 20 years of slow iteration to get here.
Well I’m not anti ;) … I just mean if your goal is to make the thing and you’re sure you need a tool to do it, watch out for the temptation to make the tool that makes the tool, which is the LONG way around, as OP was saying
> 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.
> Things like the famous fast inverse square root are short, but I would hesitate to describe it as simple.
Not the best example. That snippet was in use at SGI for years and actually written by Gary Tarolli. Quake's optimization was mostly done by Michael Abrash.
The original id engines were also famously inflexible. They fit the mold of "developing an engine, not a game" to a T. What you saw them do was all they could do. Look at how much Half-Life needed to add to be viable. idtech3 also only broke out of its niche because Ritual and Infinity Ward heavily modified it and passed it around. There's a good reason the engine-based ecosystem is so prominent now.
> (if my memory is correct, oddly the engine uses quads rather than triangles)
I'm also working off a near 30-year-old memory but I recall quads not being unusual around this time. I remember a preview of Tomb Raider 3 in Official Playstation Magazine making a big deal out of the updated engine using triangles instead of quads to draw things. This was around 1998, so a couple of years after Quake came out.
I see making a game engine as the illusion of progress on making a game. Making a game engine is fun and relatively easy. You have a check list of things to do. Each of them the solutions are relatively well known. so you do them and make tons of progress. You get a window open, then you get a triangle up, then you get a texture loaded, then you get some basic text for debugging, then you read the keyboard for input, etc etc. each day new stuff comes up and you think you’re making progress but really you haven’t even started making the game , you’re just reproducing what you could have already had if you’d started with an existing engine.
Then you start it hit the more tedious stuff. loading animated characters, blending animations on selective subtrees of a character hierarchy. Making a level editor. Adding quality of life feature to it like undo. Etc…
I’m not saying you shouldn’t do this. It’s fun to do. just don’t delude yourself that that’s making progress on your game. It’s instead making progress on a game engine. That’s a different thing.
I've shipped 18 games, 4 of them AAA. I wrote the engines for most fo them. I wouldn't do it again.
All that said, some nuance. If the game you are making is simple for some defintion of simple, Celeste, Dead Cells, Geometry Wars. Then making your own engine isn't much work and there maybe some benefits.
On the other hand, see all the tiles made with engines. Silksong is Unity. A Short Hike is Unity. Blue Prince is Unity. Valheim is Unity. Peak is Unity. Dredge is Unity. You don't need to make your own engine to make an indie game.
Randy (funny gamedev guy from YouTube) said in a recent video that he realized he'd spent the last ten years making engines to avoid the creative terror of action making a game. I'm paraphrasing slightly, but that's what it came down to.
"I thought if I made a really good engine, making a game would be the easy part!" I had similar thoughts when I was younger. Surely if I just upgrade my tools, the hard part will become the easy part!
Jonathan Blow says making engines is easy, because enginedev only takes a relatively small part of development — the game itself takes way more time and energy.
So his argument is, in the grand scheme of things, the engine is not that much work. (Since you're gonna spend ten years working on the game anyway, of course ;)
And the thing usually is that what you want from your engine is the flexibility to be able to change things around easily so you can iterate and experiment on the game design itself. Sometimes a custom engine can give you that (especially if you're going off the beaten track) but often the tooling around the off-the-shelf engines is much better for it.
That’s also why 99% of people building games with Unity or Unreal never get anywhere by themselves or just produce asset-flip slop, and then complain on Reddit about marketing being hard.
Programming an engine requires dedication, but pretty much every other area in gamedev require similar dedication to get to an acceptable result.
Yeah don't end up like me with a folder full of library code, "tests", "prototypes" and a dozen implementations of the Tiled API but no game.
For certain personality types I think making an engine can make it very easy to get distracted and wind up in the weeds of something you don't actually need, overoptimizing, fence-painting etc. Using an engine can help with self-discipline and focus on the end rather than the means, although then you need to make sure you don't just wind up with a ton of mostly finished tutorial projects and no game.
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
"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.
An interesting thing is I think a lot of it's caused purely by the graphical fidelity. For instance an animated character back then was just a key framed polygon soup - compare that with the convincing humanoids games have now.
And yet often the actual gameplay code itself may only be 2x to 3x more complicated then the days of old.
I think of counterstrike for instance - it's still just guys shooting guns in a constrained arena.
AI may change the game here. Most games are slop coded by humans anyway as the industry prioritizes speed and dead lines over code quality.
So having AI build the slop instead of a human seems to make sense. I really wonder how AI is changing the gaming industry.
The articles author strangely left AI out of what he wrote. While I know a lot of HN readers are traditional and love the old way of doing things I don’t know how much longer that way will last.
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.
In the article they make that 2025 is a tipping point where open source frameworks and libraries "just work", making speedy, fun development possible without needing to fight the clunkiness of heavyweight engines.
And any new stuff regarding Celeste or from their devs will forever be relevant to me! Highly recommend to any who haven't played it.
I think Celeste was popular enough in the indie space to get "big developer". To put some words in OP's mouth, its not "Big Developer" as in a large studio. But "Big Developer" as in well known and acclaimed.
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.
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’
That's the Unity / Unreal look. I can see why that might be a problem, but I actually really like the Unreal 4 look and think fondly about many games using that engine that I like. The way it handles lighting, fog effects and color in general makes me feel "I'm home".
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.
Carmack isn't exactly a neutral observer here, his main gig since quitting VR has been as the founder of a VC-backed AI startup. He has a clear financial interest in joining the chorus of AI boosters.
A less cynical interpretation of his actions would be that he's never shown to be motivated by money and is working on technology that interests him and that he can make an important contribution to
I hate to say it but honestly, kinda, yeah... I do think that. Has he done anything significant since the early 1990s? All I've known him for since then is wasting a bunch of years spinning wheels at a virtual reality toy company and posting on Elon Musk's child pornography platform. I would not look to Carmack for tech inspiration in 2026, personally.
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.
Text editors/IDEs have simple autocomplete and the ability to do some expansion, e.g. a for loop with placeholders to fill in. Those work and are still useful.
JetBrains also has local line-based LLM models for various languages.
With the LLM-based autocomplete it a) generally autocompletes more code at once, and b) will often pick up on patterns in the existing code. E.g. if you have a similar method, list of print/string buffer write statements, or other repetitive code in the file it will often use that as a model for the generated code.
The JetBrains local autocomplete is hilarious but occasionally useful. I find it really hit and miss in terms of when it will decide to autocomplete and whether it will exhastively complete all elements, miss some out or get itself into a loop over several.
Customizable snipping is a feature editors support (which I mentioned as they are related/similar to what the AI is doing), but is different to the AI autocomplete behaviour.
If I have a JSON structure, I can paste that into the file as a comment, e.g.:
# {"foo": 1, "bar": "test", "baz"}
@dataclass
class FooBar:
foo:
and the AI will/can autocomplete/generate that to:
@dataclass
class FooBar:
foo: int
bar: str
baz: int
Sitting here on the sidelines having never configured snippets or macros or any of that in any of my editors, which I could have done like 30 years ago but never bothered in all this time, doing quizzical-dog look at all these people thrilled about LLMs.
I guess they might finally get me to use those things since they take the “configuring” and “remembering shortcuts” part out, but so much of this doesn’t look new at all. Super old, actually.
Won’t you get much better results trying to maximize utilization of some sort of LLM? For many people, you’d get faster and better results trying to optimize for LLMs than for any standard word processor or music composition tool.
Speaking for myself (who can program and all that), AI solves some of the tedium in my day job (building UI components). Most of that work nowadays is boilerplate.
But at the moment it's also helping me solve more complex issues with building applications - it's JS, so you can imagine how complex it can be.
I yearn for a simpler workflow to be honest, I don't want to rely on SO or LLMs to solve build issues. I want to work in Go but there's only a handful of companies using it in my country, plus my CV basically says I mainly did front-end in the past ~15 years.
• 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.
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.
SDL is used in Factorio, which IMO is the best showcase of what is possible if you go all-in on e.g. C++ when it comes to performance, both in terms of what is rendered on screen and the mind-blowing numbers of what your factories are doing.
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.
If building a custom commercial game engine these days... A team is 100% focused on the wrong problem, as the game-play content is what sells. Customers only care about game-engines when broken or cheating.
Godot, Unreal, CryEngine, and even Unity... all solve edge-cases most don't even know they will encounter. Trying something custom usually means teams simply run out of resources before a game ships, and is unlikely stable on most platforms/ports. =3
Many of those "edge cases" lurk in the platform abstraction layer (driver or OS bugs which needs to be worked around), and many of those problems are also taken care of in cross-platform wrappers like SDL (and for 2D games this is completely sufficient, you don't need UE5, Unity or Godot to render a couple thousand sprites and play music and audio effects).
But even more complex custom/inhouse engines are usually not written from scratch, those are often mostly glued together from specialized middleware libraries which solve the tricky problems (e.g. physics engines like Jolt, vegetation rendering like SpeedTree, audio engines and authoring tools like FMOD or WWise, LOD solutions like Simplygon, etc etc...)
>Customers only care about game-engines when broken or cheating
Most game engines are broken by default. Modern customers just aren't very discerning ("It's for the pigs. Pigs eat slop."). You can feel holes and rough edges in the vast majority of new releases, including AAA titles.
Unreal is the worst for this and Unreal-based games almost always have two things in common: a very particular, soft, sticky and unresponsive look & feel (often alleviated but never fully corrected by turning off some combination of motion blur, AA and VSync), as well as a UI that mishandles mouse pointers.
Unity devs seem to rely on a (more diverse but still quite) small pool of subsystems and renderers; possibly some mix of baseline and Asset Store components. This gives each Unity game a specific subset of flaws from a wider common pool. That is, you can tell that game A uses the same movement subsystem as games B and C (but not D), that game B uses the same UI subsystem as games C and D (but not A), and that game D uses the same rendering subsystem as games A and B (but not C).
In my humble opinion, the difference between good and great was often whether the Shaders and pre-Baked work was done well enough to go unnoticed.
Forcing devs to use a mid-grade GPU also tends to reduce chasing performance issues later. For example, high frame-generation artifacts users often perceive as "floats" or "wobbly". =3
For more context, I've developed over 200 games[0] using libGDX and threejs. I've learnt so much from working with code-oriented frameworks that are closer to the system APIs. I can never imagine if I could do all that in today full-blown game engines in term of effectiveness and development speed.
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.
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 (AI) 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.
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.
I've been building some stuff with love2D for a while now, more a hobby than anything else, and I've really enjoyed the process. Nothing really crazy, just a 2D platformer.
I think that if I were making something in 3D or I were more serious I'd use an engine, but I've found that I get more satisfaction from building tools than from learning how to use tools that other people have built.
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 personally use Skia, in combination with a very thin platform layer. I do use C++ so that might still be a bit too low level, but after having set up everything, the Skia API is really nice for just drawing some text / other primitives onto the screen.
React Native uses Skia under the hood as far as I recall.
I really like love2d and used prior but lua isn't compiled and network support is limited, although I see they now support https requests on the latest version
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.
Just a polite heads-up in case you weren't aware: for non-game usage of Unity, the licensing situation is... a little complicated. That goes for the engine as well as a lot of the stuff I've seen in the Asset Store. Just a thing to bear in mind, and potentially a reason to use a different engine.
Not OP, but at £JOB, I use Unity most of the time making demo and sales apps for clients to use at shows. The fact that it can build for basically every common platform and (most of the time) not need any special considerations for that makes it ideal for us. Sure, we could write web apps or something, but that's a different department.
I'm also not sure if it's still in the installer, but it used to ask you what you would be using unity for, and I don't remember most of the options, but one of them was "military simulations" or something like that, so they are aware of the possibility
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 quite like modern C++, so I really tried to make it work for gamedev, but I think you can't really do it. You can use all the modern C++ features that are not in the standard library though! I am working on a little game the last few months and after a while I just decided to not use any of the C++ standard library (I just use a few C headers) and make my own Vector, Array, Span, String, FlatMap. And using those the game compiles really fast. If I touch a header that is included almost everywhere (the big game state struct), I can compile and link (mold) in ~300ms. If I touch player.cpp I compile in 250ms. That is mostly good enough for me, but I am thinking about the "game code as dynamic library" thing myself.
I always thought CMake was good enough. I use FetchContent for all external dependencies and git submodules + add_directory for all internal dependencies. It took me a while to figure out that this was the simplest thing that works reliably though. I have used vcpkg and conan extensively and have completely given up on them.
I don't use C++ modules, because afaik they are still mostly broken. Without modules clangd works wonderfully and has been working wonderfully for a few years. I really, really like it. I think it can be done! I am missing reflection though, but if I would really want to use it, I'd probably just use clang -ast-dump instead of the new reflection functionality.
I think the standard library is good, but if you pull in ANY of it's headers you add a couple hundred milliseconds to every translation unit. So when making games (and only then), I avoid the standard library.
What I do like and use is overloading, references, templates, concepts, lambdas, enum classes, user defined literals, constexpr, operator overloading for math (!), little syntax stuff like structured binding declarations, "auto" and range based for. I also made my own little fmt (like https://riki.house/fmt). C++ is a much nicer language than C imo, even without the standard library.
C++ is really not very amenable to this because every change to the contents of a class messes up your entire memory layout. "game as DLL" is definitely a viable solution to that, but so is "game in scripting engine": many games delegate a lot of their mechanics to e.g. Lua precisely because it's so easy to tweak in-engine if you just want to change a bonus from 5% to 10% and so on.
> C++ is really not very amenable to this because every change to the contents of a class messes up your entire memory layout
I think even `dotnet watch` at some point nopes out when you change too much. I think they call it "rude edit" and ask you to completely restart the program in that case. So I don't expect every possible C++ edit to be manageable by hot reload. But changing a few if conditions or constants should be fine or not?
I'm more and more questioning scripting languages in games. What are the main reasons to use something like Lua? I think it's having not to rebuild the engine, no compile times, changing stuff while the game is running and being more accessible to non-programmers. But I think it's rather infuriating, all those points could be less relevant if the tooling for "real" programming languages was better. And with coding agents becoming more wide-spread I guess accessibility to non-programmers also becomes less of a point. I guess it's just my personal dislike for scripting languages in games, but really, it would be so much nicer imo if there was only need for one language that does it all. But seems like a difficult thing to achieve.
You could also offload potentially GC-heavy parts to C++ and write the rest in C#. Depends on the game, but usually most of the game logic that you'll be constantly tinkering with doesn't require all that much memory in the first place.
how to use? do self-contained publish (but not single file), replace 3 files in the folder with the one from Satori release
you can check if it's in use with GC.GetConfigurationVariables().ContainsKey("SatoriGC")
It is a far, far superior experience to touching anything C++.
Oh thanks, that looks very intriguing! The maintainer seems to be a Microsoft employee so there's that? I wonder though, is this a niche hidden gem or really something that more people should consider using? Also, what about compatibility with platforms like Android, iOS or consoles? That'd be very important for gamedev.
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.
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)
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 myself don't have much of a dotnet gamedev stack going on unfortunately. Although I've been dabbling with MonoGame and have been enjoying it so far. MonoGame matured quite a bit since I previously used it which was more than 5 years ago!
Unity indeed is still using Mono instead of CoreCLR and is kinda stuck in that sense. But to be fair, they are trying to migrate to CoreCLR which will let them profit from all the crazy optimizations that Microsoft has poured into the runtime and ecosystem.
Godot is kind of a hate love for me when it comes to C#. Godot gives me the most hope that there can be a free, community-driven but powerful game engine and it having C# support built-in seems great at first glance until you realize that GDScript, which is veeeeery dynamic language, pretty much nullifies a lot of the advantages you'd get from using C# because you find yourself doing weird type system stuff that GDScript imposes on all the other languages. The best you can do is doing as much as possible in C# and use Godot as kind of a input and rendering abstraction layer. But then you're missing out on a lot of the functionality that Godot offers which should raise the question why use a game engine in the first place. It's difficult, at least for me. Others might have figured it out much better.
For me when there is a library or framework or "engine". You are often having to learn the specifics of how this thing works, and ALSO map your mind to the way it works. When you write things yourself you are only in your own mindset. So you can write your 90% self implementation in less time than learning this new mindset. Then you can build everything together without special ways of piping things together. Adding more frameworks or libraries is an exponential explosion in complexity, and more and more of your time is spent with glue code. When you write everything yourself, you are in one design space and things flow more naturally.
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
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.
I'm no game developer, but I'd say don't create an engine if what you want to do is build a game. Do create an engine if you want to create an engine though.
But yeah, it is like learning a new language. But that's not a bad thing! I found messing around / following some tutorials for e.g. pico-8 to be both liberating (two characters are enough for a variable name) and educative (using functions like min/max to the fullest)
If you're familiar with web development, you can make games with HTML/JS, which is almost its own "engine." Think DOM elements for sprites, CSS animations for movement, requestAnimationFrame for an update loop, etc. This has the extra benefit of zero friction for players -- no native app installation necessary!
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.
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.
> 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.
Unity used to have a pretty good netcode implementation, but then they ripped it out in newer versions and still don't really have a good replacement for it
I mean, I dont hate netcode for gameobjects, but generally I prefer to have the application just set up some sockets for me and I'll handle the rest myself, which you can do in NfG, but I've not used it too much. There was a really long gap between having working netcode stuff, and I wrote what I felt was a really nice layer over the top of the old LLAPI for a project I was going to work on, and then they immediately deprecated it.
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).
multiplayer netcode isnt overly difficult to write unless you're at the highest lvl of complexity lol. it's not a black box, it's just transferring bytes around efficiently and keeping track of state, your "netcode" can literally just be bare tcp (+ssl), validation, and state, it's not that deep.
handling latency to keep a coherent experience in a real-time game is an unsolvable problem where every single mechanic requires a planned out scheme and companies go so far as buying data centers in optimized locations to help out with the illusion
that's probably what you mean by highest level of complexity
but even just a regular turn-based game there's a lot of questions you need to answer and decisions to make regarding latency, packet loss, and disconnects that all have to be solved in a coherent and consistent way
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!
The same goes for software libraries in general, I think. Just make your program. Don't make an overly general library for something you won't need anyway. If the code proves useful for reuse, just factor it out after the fact and generalize as needed.
EDIT: Typos, wording
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.
Not the best example. That snippet was in use at SGI for years and actually written by Gary Tarolli. Quake's optimization was mostly done by Michael Abrash.
The original id engines were also famously inflexible. They fit the mold of "developing an engine, not a game" to a T. What you saw them do was all they could do. Look at how much Half-Life needed to add to be viable. idtech3 also only broke out of its niche because Ritual and Infinity Ward heavily modified it and passed it around. There's a good reason the engine-based ecosystem is so prominent now.
I'm also working off a near 30-year-old memory but I recall quads not being unusual around this time. I remember a preview of Tomb Raider 3 in Official Playstation Magazine making a big deal out of the updated engine using triangles instead of quads to draw things. This was around 1998, so a couple of years after Quake came out.
Then you start it hit the more tedious stuff. loading animated characters, blending animations on selective subtrees of a character hierarchy. Making a level editor. Adding quality of life feature to it like undo. Etc…
I’m not saying you shouldn’t do this. It’s fun to do. just don’t delude yourself that that’s making progress on your game. It’s instead making progress on a game engine. That’s a different thing.
I've shipped 18 games, 4 of them AAA. I wrote the engines for most fo them. I wouldn't do it again.
All that said, some nuance. If the game you are making is simple for some defintion of simple, Celeste, Dead Cells, Geometry Wars. Then making your own engine isn't much work and there maybe some benefits.
On the other hand, see all the tiles made with engines. Silksong is Unity. A Short Hike is Unity. Blue Prince is Unity. Valheim is Unity. Peak is Unity. Dredge is Unity. You don't need to make your own engine to make an indie game.
"I thought if I made a really good engine, making a game would be the easy part!" I had similar thoughts when I was younger. Surely if I just upgrade my tools, the hard part will become the easy part!
Jonathan Blow says making engines is easy, because enginedev only takes a relatively small part of development — the game itself takes way more time and energy.
So his argument is, in the grand scheme of things, the engine is not that much work. (Since you're gonna spend ten years working on the game anyway, of course ;)
Programming an engine requires dedication, but pretty much every other area in gamedev require similar dedication to get to an acceptable result.
Solo? Or part of a team?
For certain personality types I think making an engine can make it very easy to get distracted and wind up in the weeds of something you don't actually need, overoptimizing, fence-painting etc. Using an engine can help with self-discipline and focus on the end rather than the means, although then you need to make sure you don't just wind up with a ton of mostly finished tutorial projects and no game.
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
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.
And yet often the actual gameplay code itself may only be 2x to 3x more complicated then the days of old.
I think of counterstrike for instance - it's still just guys shooting guns in a constrained arena.
So having AI build the slop instead of a human seems to make sense. I really wonder how AI is changing the gaming industry.
The articles author strangely left AI out of what he wrote. While I know a lot of HN readers are traditional and love the old way of doing things I don’t know how much longer that way will last.
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/
Also, pretty sure it was a small indie team rather than a “big developer”
And any new stuff regarding Celeste or from their devs will forever be relevant to me! Highly recommend to any who haven't played it.
--
If I remember correctly it was a team of 2.
0: https://maddymakesgames.com/
Fans of Celeste will almost certainly enjoy the local multiplayer game Towerfall by the same developers.
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/
I liked when games all felt very distinctly different and I feel like part of that was that they all varied on ‘engine’
> 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.
No need to brag about that.
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
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.
JetBrains also has local line-based LLM models for various languages.
With the LLM-based autocomplete it a) generally autocompletes more code at once, and b) will often pick up on patterns in the existing code. E.g. if you have a similar method, list of print/string buffer write statements, or other repetitive code in the file it will often use that as a model for the generated code.
If I have a JSON structure, I can paste that into the file as a comment, e.g.:
and the AI will/can autocomplete/generate that to: using the JSON example. Then if you type: the AI could then contextually generate, e.g.: Or if you have a SQLAlchemy model: typing `bar:` the AI can autocomplete: picking up that you have a `Bar` class in the file. Especially if you have other similar id/object definitions in the file.I guess they might finally get me to use those things since they take the “configuring” and “remembering shortcuts” part out, but so much of this doesn’t look new at all. Super old, actually.
With ai it add several lines of code at once as soon as it thinks it recognizes a common pattern.
It’s not perfect and it can get in the way but it’s amazing when it guesses right and spits out the next 3-4 lines I would have typed
But at the moment it's also helping me solve more complex issues with building applications - it's JS, so you can imagine how complex it can be.
I yearn for a simpler workflow to be honest, I don't want to rely on SO or LLMs to solve build issues. I want to work in Go but there's only a handful of companies using it in my country, plus my CV basically says I mainly did front-end in the past ~15 years.
This is a GREAT observation. Thank you!
• 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/)
Godot, Unreal, CryEngine, and even Unity... all solve edge-cases most don't even know they will encounter. Trying something custom usually means teams simply run out of resources before a game ships, and is unlikely stable on most platforms/ports. =3
But even more complex custom/inhouse engines are usually not written from scratch, those are often mostly glued together from specialized middleware libraries which solve the tricky problems (e.g. physics engines like Jolt, vegetation rendering like SpeedTree, audio engines and authoring tools like FMOD or WWise, LOD solutions like Simplygon, etc etc...)
Most game engines are broken by default. Modern customers just aren't very discerning ("It's for the pigs. Pigs eat slop."). You can feel holes and rough edges in the vast majority of new releases, including AAA titles.
Unreal is the worst for this and Unreal-based games almost always have two things in common: a very particular, soft, sticky and unresponsive look & feel (often alleviated but never fully corrected by turning off some combination of motion blur, AA and VSync), as well as a UI that mishandles mouse pointers.
Unity devs seem to rely on a (more diverse but still quite) small pool of subsystems and renderers; possibly some mix of baseline and Asset Store components. This gives each Unity game a specific subset of flaws from a wider common pool. That is, you can tell that game A uses the same movement subsystem as games B and C (but not D), that game B uses the same UI subsystem as games C and D (but not A), and that game D uses the same rendering subsystem as games A and B (but not C).
Forcing devs to use a mid-grade GPU also tends to reduce chasing performance issues later. For example, high frame-generation artifacts users often perceive as "floats" or "wobbly". =3
Besides not all games need performance, I have been working on a clone of the original elite game using SDL. It gets 6000 fps easily.
[0]: https://ookigame.com
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 still don't use it (AI) 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.
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.
I think that if I were making something in 3D or I were more serious I'd use an engine, but I've found that I get more satisfaction from building tools than from learning how to use tools that other people have built.
- Desktop: Windows, MacOS, Linux
- Mobile: Android, iOS, iPadOS
- Console: Playstation 4, Playstation 5, Xbox One, Nintendo Switch
It used to be XNA but then Microsoft discontinued and the community created the API compatible MonoGame.
Notable games: Terraria (when it was XNA), Stardew Valley, Celeste, Terraria and Fez.
React Native uses Skia under the hood as far as I recall.
[1] https://love2d.org/
I'm also not sure if it's still in the installer, but it used to ask you what you would be using unity for, and I don't remember most of the options, but one of them was "military simulations" or something like that, so they are aware of the possibility
https://en.wikipedia.org/wiki/Digital_twin
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 always thought CMake was good enough. I use FetchContent for all external dependencies and git submodules + add_directory for all internal dependencies. It took me a while to figure out that this was the simplest thing that works reliably though. I have used vcpkg and conan extensively and have completely given up on them.
I don't use C++ modules, because afaik they are still mostly broken. Without modules clangd works wonderfully and has been working wonderfully for a few years. I really, really like it. I think it can be done! I am missing reflection though, but if I would really want to use it, I'd probably just use clang -ast-dump instead of the new reflection functionality.
> I quite like modern C++, so I really tried to make it work for gamedev, but I think you can't really do it.
What exactly do you mean? What parts of modern C++ did not work for you?
> You can use all the modern C++ features that are not in the standard library though!
> I just decided to not use any of the C++ standard library (I just use a few C headers)
So what do you do with C++ that C alone couldn't do?
What I do like and use is overloading, references, templates, concepts, lambdas, enum classes, user defined literals, constexpr, operator overloading for math (!), little syntax stuff like structured binding declarations, "auto" and range based for. I also made my own little fmt (like https://riki.house/fmt). C++ is a much nicer language than C imo, even without the standard library.
I think even `dotnet watch` at some point nopes out when you change too much. I think they call it "rude edit" and ask you to completely restart the program in that case. So I don't expect every possible C++ edit to be manageable by hot reload. But changing a few if conditions or constants should be fine or not?
I'm more and more questioning scripting languages in games. What are the main reasons to use something like Lua? I think it's having not to rebuild the engine, no compile times, changing stuff while the game is running and being more accessible to non-programmers. But I think it's rather infuriating, all those points could be less relevant if the tooling for "real" programming languages was better. And with coding agents becoming more wide-spread I guess accessibility to non-programmers also becomes less of a point. I guess it's just my personal dislike for scripting languages in games, but really, it would be so much nicer imo if there was only need for one language that does it all. But seems like a difficult thing to achieve.
Builds: https://github.com/hez2010/Satori/releases
how to use? do self-contained publish (but not single file), replace 3 files in the folder with the one from Satori release you can check if it's in use with GC.GetConfigurationVariables().ContainsKey("SatoriGC")
It is a far, far superior experience to touching anything C++.
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 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'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?
Unity indeed is still using Mono instead of CoreCLR and is kinda stuck in that sense. But to be fair, they are trying to migrate to CoreCLR which will let them profit from all the crazy optimizations that Microsoft has poured into the runtime and ecosystem.
Godot is kind of a hate love for me when it comes to C#. Godot gives me the most hope that there can be a free, community-driven but powerful game engine and it having C# support built-in seems great at first glance until you realize that GDScript, which is veeeeery dynamic language, pretty much nullifies a lot of the advantages you'd get from using C# because you find yourself doing weird type system stuff that GDScript imposes on all the other languages. The best you can do is doing as much as possible in C# and use Godot as kind of a input and rendering abstraction layer. But then you're missing out on a lot of the functionality that Godot offers which should raise the question why use a game engine in the first place. It's difficult, at least for me. Others might have figured it out much better.
(246 comments)
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.
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
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
But yeah, it is like learning a new language. But that's not a bad thing! I found messing around / following some tutorials for e.g. pico-8 to be both liberating (two characters are enough for a variable name) and educative (using functions like min/max to the fullest)
[0] https://www.lexaloffle.com/pico-8.php
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
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.
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
In theory, yes. In practice 99.9% of the games developers want to make are feasible with an off the shelf engine.
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.
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.
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.
What's wrong with Netcode for GameObjects, and what are the odds I'll regret going with it?
Im sure NfG is fine
This is the mantra of the past decade of game dev.
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).
that's probably what you mean by highest level of complexity
but even just a regular turn-based game there's a lot of questions you need to answer and decisions to make regarding latency, packet loss, and disconnects that all have to be solved in a coherent and consistent way