It’s 2025 and I am still making video games, which according to archive.org is 20 years since I started making games! That’s a pretty long time to be doing one thing…
When I share stuff I’m working on, people frequently ask how I make games and are often surprised (and sometimes concerned?) when I tell them I don’t use commercial game engines. There’s an assumption around making games without a big tool like Unity or Unreal that you’re out there hand writing your own assembly instruction by instruction.
I genuinely believe making games without a big “do everything” engine can be easier, more fun, and often less overhead. I am not making a “do everything” game and I do not need 90% of the features these engines provide. I am very particular about how my games feel and look, and how I interact with my tools. 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…
At which point, why am I using this engine? What is it providing me? Why am I letting a tool potentially destroy my ability to work when they suddenly make unethical and terrible business decisions? Or push out an update that they require to run my game on consoles, that also happens to break an entire system in my game, forcing me to rewrite it? Why am I fighting this thing daily for what essentially becomes a glorified asset loader and editor UI framework, by the time I’m done working around their default systems?
The obvious answer for me is to just not use big game engines, and write my own small tools for my specific use cases. It’s more fun, and I like controlling my development stack. I know when something goes wrong I can find the problem and address it, instead of submitting a bug report and 3 months later hearing back it “won’t be fixed”. I like knowing that in another two decades from now I will still be able to compile my game without needing to pirate an ancient version of a broken game engine.
Obviously this is my personal preference – and it’s one of someone who has been making indie games for a long time. I used engines like Game Maker for years before transitioning to more lightweight and custom workflows. I also work in very small teams, where it’s easy to make one-off tools for team members. But I want to push back that making games “from scratch” is some big impossible task – especially in 2025 with the state of open source frameworks and libraries. A lot of popular indie games are made in small frameworks like FNA, Love2D, or SDL. Making games “without an engine” doesn’t literally mean opening a plain text editor and writing system calls (unless you want to). Often, the overhead of learning how to implement these systems yourself is just as time consuming as learning the proprietary workflows of the engine itself.
With that all said, I think it’d be fun to talk about my workflow, and what I actually use to make games.
Programming Languages
Most of my career I’ve worked in C#, and aside from a short stint in C++ a few years ago, I’ve settled back into a modern C# workflow.
I think sometimes when I mention C# to non-indie game devs their minds jump to what it looked like circa 2003 – a closed source, interpreted, verbose, garbage collected language, and… the language has greatly improved since then. The C# of 2025 is vastly different from the C# of even 2015, and many of those changes are geared towards the performance and syntax of the langauge. You can allocate dynamically sized arrays on the stack! C++ can’t do that (although C99 can ;) …).
The dotnet developers have also implemented hot reload in C# (which works… most of the time), and it’s pretty fantastic for game development. You can launch your project with dotnet watch and it will live-update code changes, which is amazing when you want to change how something draws or the way an enemy updates.
C# also ends up being a great middle-ground between running things fast (which you need for video games) and easy to work with on a day-to-day basis. For example, I have been working on City of None with my brother Liam, who had done very little coding when we started the project. But over the last year he’s slowly picked up the language to the point where he’s programming entire boss fights by himself, because C# is just that accessible – and fairly foot-gun free. For small teams where everyone wears many hats, it’s a really nice language.
And finally, it has built in reflect
30 Comments
danielbarla
> I genuinely believe making games without a big "do everything" engine can be easier, more fun, and often less overhead. I am not making a "do everything" game and I do not need 90% of the features these engines provide.
At that point, of course, you don't need the engine. Having said that, every time I've really deep-dived into some particular feature of an engine – such as inverse kinematics and animation blending in Unreal – I've come away thinking "boy, am I glad I didn't spend several weeks trying to code that up from scratch".
There's definitely an argument to be made for minimalism and anti-bloat, but the reason engines are popular is that they really do some heavy lifting for you.
tosmatos
I really liked this post. I've recently been learning OpenGL and C++, and the libraries surrounding it, like ImGui, which I like using a lot !
But for my projects I think I'll keep using Godot. I really want to make a game, and not the tooling required to make a game. That said, I've dabbled in GDExtension, and if I really need to have something performant, I'll use that.
I've got huge amounts of respect for people doing it this way though. They have a level of control over their work that a Unity or even Godot developer cannot hope to have. It has, like any game dev approach, it's pros and cons
savory_pancake
It really feels like all the open-source projects are getting more and more capable. I recently went back to fedora linux on my desktop and the nvidia support is so much better on there than it was even a year or two ago. Hyprland is such a smooth wm that wasn't around even a few years ago. I've been using wgpu for cross-platform GPU rendering, but I've heard about SDL3's recent official release, and I really want to try out those GPU rendering capabilities. What a time to be alive.
atoav
One of my first bigger programming projects was a side-scroller in Processing. Processing.org was an amazing way to get into programming since you could draw onto the screen with minimal code.
So I essentially had to write my own physics, collisions, trigger functionality, ways of describing levels, enemies etc. The resulting game wasn't really fun, but I loved the process and the lessons learned.
Turns out writing your own game engine is a pretty good way of learning to understand existing ones.
oliverdzedou
Many people often say that making an engine from scratch takes too long. But how long does it take to properly learn Unreal or Unity such that you can have an idea and turn it into a game without friction? Presumably, once your engine is finished, you are at that level of expertise instantly, which is a huge time saver. In my opinion, the more experienced of an engineer you are, the more the scales tip in the favor of rolling your own, from a time-spent perspective.
The more unique and niche your game is, the more true this is. Stumbling around Unreal's horrid UI for 3 months just to realize that the thing you want to do is barely even possible due to how general and off-the-shelf the engine is, is not a good experience. On the other hand, if you want to make a hyper-realistic, open-world RPG, then rolling your own is probably not a good idea.
I also believe that even if it's not always the most efficient thing to do, placing limitations on yourself by using a custom-made specialized engine makes the creativity really flow, and your game, even if not the most advanced, will be a lot more unique as a result of that.
andreamonaco
Kudos to you! I'm writing a game (a little MMO) the same way, the technical and creative freedom is priceless.
buildj48
[flagged]
samiv
After having worked on my own (2D) game engine [1] for about 5 years now and having worked on related stuff for paid work I'd like to explain one thing that many people might not find so obvious.
Engines are the easy part.
The real meat & potatoes is all the tooling and content and asset pipelines around the engine.
If you think about it, you need to implement:
And this is just a small sample of all the features and things that need to be done in order to be able to leverage the engine part.
When all this is done you learn that the actual game engine (i.e. the runtime part that implements the game's main loop and the subsystems that go brrr) is actually a rather small part of the whole system.
This is why game studios typically have rather small teams (relatively speaking) working on the engine and hordes of "tools" programmers that can handle all the adjacent work that is super critical for the success of the whole thing.
[1]
https://github.com/ensisoft/detonator
Protostome
Since you've been making games for 20 years, I'm guessing you're at least in your thirties. Just curious – do you develop games purely as a hobby, or are you able to make a living from it?
If it's the latter, I'd love to hear your perspective on how to build a successful indie game-development business!
slowhadoken
I agree with making games from scratch. That being said I thought Celeste was wildly overrated. Keep up he hard work though.
HelloUsername
In the end of the post Noel mentions Aseprite, but he might be interested in Libresprite as well? https://libresprite.github.io/
interludead
It's refreshing to see someone advocate for small, custom tooling not from a "purist”"standpoint but because it's actually fun and practical for their workflow
zerr
I believe a majority of prospective game developers got into it because of interest in game engine development. For such people, Unreal/Unity/Godot take all the fun out of game dev.
sambeau
I recently wrote a game in Javascript (2D; Canvas). I was amazed at how simple it was and how performant plain-old-Javascript and Javascript objects were. Despite thousands of animating things moving on screen, and animated stereo audio, I couldn't get the frame rate to spill over an animation frame.
thorn
I am always super curious to read such posts. They make me happy for no reason. I do not make games these days, but I love to read about excited and happy people explaining the process they love to do. At the same time I learn new perspectives to understand what is going on in the world of indie games. I keep this (not so) secret wish in the back of my head because I have to work for some money to support my family and my country (Ukraine). Maybe some time later I will do more of games…
Thank you for writing this post, Noel!
selvan
For simpler games, libraries such as raylib or lightweight opensource game engines such as Amulet (https://www.amulet.xyz/) / Love 2D are good fit.
dakom
I've never delivered a game anyone's really paid for, so take with a grain of salt, but imho the big win when you are writing your own stuff is you get to decide what not to include.
That sounds obvious but it really isn't. One example: maybe you don't need any object culling at all. Nobody tells you this. Anything you look up will talk about octrees, portals, clusters, and so on – but you might be totally fine just throwing everything at the renderer and designing your game with transitions at certain points. When you know your constraints, you're not guessing, you can measure and know for a fact that it's fine.
Another example: shader programming is not like other programming. There's no subclassing or traits. You have to think carefully about what you parameterize. When you know the look you're going for, you can hardcode a bunch of values and, frankly, write a bunch of shit code that looks just right.
The list goes on and on… maybe you don't need fancy animation blending when you can just bake it in an external tool. Maybe you don't need 3d spatial audio because your game world isn't built that way.
Thing is – when you're writing an _engine_ you need all that. You don't get to tell people writing games that you don't really need shadows or that they need to limit the number of game objects to some number etc. But when you're writing a _game_ (and you can call part of that game the engine), suddenly you get to tweak things and exclude things in all these ways that are perfectly fine.
Same idea applies to anything of course.. maybe you don't need a whole SQL database when you know your data format, flat files can be fine. Maybe you don't need a whole web/dom framework when you're just spitting out simple html/css. etc. etc.
I think this headspace is pretty common among gamedevs (iiuc large projects often copy/paste dependencies and tweak between projects rather than import and support a generic api too)
noduerme
I really miss the days of Flash when I could write lots of mini-engines as needed (e.g. platformers or side scrollers or 2.5D, multiplayer, chat … all hand coded but reusable) and rely on being able to mix lots of different pipelines for vector art, bitmaps, 3D, audio and UI. There's nothing like that now. I tried to reinvent a few wheels. But at this point… a fairly low level (for script) rendering library like PixiJS is really the best we have. No frameworks, please.
That being said, games are kind of dead. The idea of spending another year or two on another indie game that barely cracks the top 50 for a couple days on an app store is… depressing. Going through the bureaucratic hoops to even get it there and maintain it seems like an exercise in self-torture. I'm kinda back to just making art in my spare time – screen savers, weird web experiences, one-off toys. I think having all my mini-engines in Flash suddenly deleted forever just made me realize how pointless it all was.
Maybe I just spent 20 years getting to be great at the wrong thing. I don't know of a historical parallel of someone spending their life perfecting an art that literally was burned down and blackholed overnight, in quite the same way. I imagine the scribes at Alexandria could at least have gone and scriven somewhere else the following year. So screw it, when I started learning code I was 8 and my brother was a CS major, he gave me his laptop to learn BASIC, and he said "we're just writing on sand." I finally learned that was true.
z3t4
I like to start all my software projects from scratch. Everyone who are used to working on large software projects know that it's very slow. But starting from scratch is fast! You just implement the bare minimum. But also on later stages of the development when you have abstractions going, then it becomes even faster to implement new features. Working on an enterprise software project and your own engine that you've written from scratch is nothing alike, you can work 1000x faster when you have written the thing yourself and can just cut out and refactor everything you want. This is why I advocate micro service architecture and small teams. Things are much smoother when you do it yourself and from scratch. There are however landmines you have to hit and it will take years of trail and error until you get a feeling for what architecture and abstractions work and which doesn't as well as learning the in and outs of the language and platform you are working on.
leonard-somero
I'm an indie game developer with over 10 years of experience. I'm not using Unity or Unreal, but I do have some frameworks that handle things like rendering graphics or playing audio. However, I write all the game logic, data manipulation, and entity management from scratch for each game I make. It seems to be the smoothest option for me, since I have full control over how my games actually operate, but I don't have to reinvent the wheel as far as the low-level architecture goes.
trollied
Just to note that the author wrote this game, >3 million copies sold: https://en.wikipedia.org/wiki/Celeste_(video_game)
pinoy420
[dead]
throwawayffffas
For anything I have ever tried to make, I always find myself fighting the engine. Whether it is Godot, Unity or Unreal.
They all feel like a ready made game that you add assets and mod. The problem for me is that I mostly don't want to make that game.
An analogy that comes to mind from the web dev world, it feels like the engines are like wordpress. Prebaked and ready to show content, but the moment your objective does not completely align with their preconfiguration you have to do a huge amount of hacking and workarounds.
russellbeattie
So, does everything he said about C# sound about right? I have no real desire to use it, but I'm curious if his opinion was more or less accurate.
Not looking for a flame war, just knowledge
varbhat
Isn't that a huge effort? I remember few games which developed their own game engines from scratch (factorio, limbo, bg3). But, wouldn't it be easier and better to use game engines like godot?
lucraft
Maybe a dumb question, but what is the C# compiler and runtime that you use?
I used to be up to date with .NET and Mono and stuff but I'm 10 years out of date
tiniuclx
That was a very fun read! While I’m using Godot for my hacking simulator game, Botnet of Ares [0] I think the native C# approach is very much justified in this case, and Noel clearly has had massive success with Celeste.
I like Godot because of the UI primitives built into the engine. For a UI heavy simulation game like mine, the game engine does a lot of the heavy lifting. Sure, I don’t use 90% of the 2D/3D features of the engine, but that’s okay.
[0] https://store.steampowered.com/app/3627290/Botnet_of_Ares/
kkukshtel
I agree with a lot of this, and am similarily working on my own code-only C# game framework meant as a spiritual successfor to XNA/Monogame:
https://zinc.graphics/
In OP's post as well he brings up some of the main factors that make modern C# incredible:
– Cross platform development (and runtime).
– NativeAOT Compiling (great for consoles, provided you have backend headers).
– Native Hot-reloading.
– Reflection
I'd also add:
– Source Generators
Modern C# is incredible. I think people still discount it due to its admittedly bad legacy, but the past five years of C# and CoreCLR development make me feel like it's truly a language that has everything necessary but isn't baroque or overburdened. My only major request, Union types, is also in proposal and will (hopefully) come in the next year or so:
https://github.com/dotnet/csharplang/blob/main/proposals/Typ…
OnACoffeeBreak
The author says that they tend to load all of the assets on init. This sidesteps the issue of the C#'s garbage collector (GC). I am not a C# developer, but seem to recall reading that GC can cause unexpected slow downs. Web search shows articles on tips and tricks for optimizing GC in C#, so it seems like a real issue.
Does anyone have any first hand experience they would like to share? Is it easy to avoid the GC slowing down your game unexpectedly? Is it only a problem for a certain class of games?
TacticalCoder
[dead]