Making video games (without an engine) in 2025

Feels like fiddling with snapshotting raw C++ memory is a can of worms (you listed some of the pitfalls yourself). Most of my snapshotting happened at the scripting runtime level, where everything is well-defined and well-understood: I manually snapshotted the VM's heap memory, the green threads' stack memory, the current instruction pointer of every green thread etc. I could safely validate those snapshots without segfaulting on a corrupted savefile, because it was a well-defined file format. The same code worked both as a time-travel snapshotter and as a general savefile format.

I think this is dangerous and can lead to remote execution attacks:

>The snapshot could even be exchanged over the network, assuming the receiving side has the same endianness, the same pointer size, is running the same binary, and can mmap the same memory location.

For physics, I needed to restore all those remembered motion vectors; for audio - current playback time, etc. Same as yours:

>The rest of the memory (the textures, the 3D models, the audio, the UI, etc...) should be allocated by your usual non-snapshotting allocator"

Except that I wouldn't, because most of that stuff would be a shader nowdays, and depending on the API version, not the same kind of shader.

This kind of stuff is fun, if the end goal is to become a game engine or tools engineer, if the goal is to make a game, it is mostly yak shaving.

I agree with almost everything except:

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

When you're making an engine it's perfectly fine to bake in constraints. Probably most famously PICO-8 does that very intentionally and is written by just one person. Similarly RPGMaker and a bunch of other 'genre specific' game engines also do this. It's just that everyone tries to make something super general purpose which is really a Sisyphean task.

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 (using Sokol instead of SDL):

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

Yes, C# has had low-level primitives since 1.0 and it has only gotten better in this regard. This means that it's worse than Java at things like devirtualizing calls, but you can write allocation-free hot loops in C# these days.

It's also cross-platform and has multiple deployment modes: you can ship the runtime and the program separately (good when you control the end-user machines, like in an enterprise settings), you can tree-shake the runtime and ship it with the program, or you can tree-shake the runtime and use the AOT compiler to ship a go-like native binary.

The JIT compiler is still better for long-running processes like servers, but for one-shot programs where the startup time is critical, like CLI tools and FaaS, the AOT compiler is really great.