Making video games (without an engine) in 2025

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?

I got sour on games for a while but I think there are good things awaiting them, because we're starting to get past the hurdle of "new technology usurps the old" actually being germane to the artistic processes that go into game design. Like, it still exists because the devices are so locked down, but it's stopped being a tech-driven business - there's little interest in AAA now, and the broader trends are shaken up too; there's more of a symbiotic pipeline of "make a game that helps people make video content" taking hold, one which has little relationship to recency or production values.

That said I have been pursuing the sustainable elements of gaming for years at this point, seeing the same issues - and for me what it comes down to is what I summarize as "the terrarium problem" - the bigger the software ecosystem you build the game over, the more of the jungle you have to port to the next platform du jour. When we approach gaming as a software problem it's just impossible, we can't support all the hardware and all the platforms.

But within that there are elements of "I can plan for this". Using tech that is already old is one way; Flash, for example, is emulated now. But if you go back to an earlier console generation or retro computers, you can find even more accuracy, better preservation. I took the compromise of "neo retro", since there are several SBCs around that mix old chips with new stuff - those have much more comfy specs to tinker with, while building on some old ideas. Tech that assumes less of a platform is another: I've taken up Forth, because Forth is the language that assumes you have to DIY everything, so it perpetuates ground-up honesty within your software, especially within a retro environment where there's no API layer to speak of and you have full control. And tech that has more of a standardized element is good: if something is "data structure portable", it's easier to recreate(this is why there are many homebrew ports of "Another World" - it's all bytecode).

The last piece of the puzzle in it is - okay, if I take things in that direction, how do I still make it fun to develop with? And that's the part I've been working on lately. I think the tools can be fun. Flash found some fun in it. But Flash as a model is too complex, too situated in just supplying every feature. PICO-8 is also fun, but very focused on a specific aesthetic. I think it's related to data models, conventions and defaults. Getting those things right clears the way.

This is basically what I did a couple years ago [1]. SDL2 and a bit of C++ to create a "sprite" class. Some collision code in the sprite class...

If you want to call what I added an "engine" it was more like a pedal-assist bike.

Too often I find "engines" end up driving the project/game. That is, you end up writing the game to the engine. It's why I've avoided Unity, etc. — high-level engines like that seem to guide you to writing the same game everyone else is writing — just with different assets.

Never mind you spend too much time, in my opinion, learning the engine and not getting the game written. To be sure there was a learning curve just pulling in SDL, but the curve was slight and it seemed more universally useful to know SDL as it can be employed in other cross-platform projects I might undertake — not just games.

[1] https://store.steampowered.com/app/2318420/Glypha_Vintage/

Games like Antichamber do non-euclidean space and rendering in Unreal (3). Enera (an upcoming action game) manages time rewinding (a la braid), in Unreal. Superhot is Unity, etc.

The best tool is the one you know, even if your vision is weird or niche. At the end of the day, you can always ignore all the bits and pieces unity gives to you and just write custom logic in your MonoBehaviour scripts and use it as a platform toolkit, input handler, content pipeline, scriptable editor, and renderer. There's a lot to be said for the features you get from that especially in the long term as you said.

> The real meat & potatoes is all the tooling and content and asset pipelines around the engine

This depends a lot on the type of game that you create. For example, if a lot of content is procedurally generated, for example the map editor can be simpler, and you need less kinds of data formats to import. Also, some genres require a lot more "external content" than other genres. Even if you keep the genre constant, you will find games where the "value proposition" lies more in the game engine vs those where the "value proposition" lies in the assets.

In particular for indie games, you can be much more flexible on how you structure your game compared to AAA titles.