Comment by kgeist
9 months ago
>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
I once experimented with creating my own game engine. It took me about a year of building and learning along the way (through trial and error, with many dead ends initially). It featured lots of things you'd typically find in a game (3D rendering with all the bells and whistles, an adaptive UI framework inspired by flexbox, skeletal animation, a save file format, a smart object system, path finding, a scripting language, audio, physics, et cetera, et cetera)
Specifically, I tried to recreate Braid's system (without knowing it existed), where you can rewind your game to any point in time. It required support from all the engine's subsystems - to rewind scripts, physics, etc.
Knowing every little detail about your game engine was certainly a plus. After the engine was more-less complete, adding a feature, however ambitious it was, took about a couple of hours at most. When something didn't work, I knew exactly what was going on.
However, after a year of building, I was somewhat exhausted, and all my motivation to continue disappeared :)
> Specifically, I tried to recreate Braid's system (without knowing it existed), where you can rewind your game to any point in time. It required support from all the engine's subsystems - to rewind scripts, physics, etc.
Not necessarily. You can write your own "snapshotable allocator" that allows you to rewind back in time anything, even the state of unmodified 3rd party libraries and interpreters (as long as you can configure them to use your allocator).
I wrote about it in https://www.jfgeyelin.com/2021/02/a-general-state-rollback-t...
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"
> It featured lots of things you'd typically find in a game (3D rendering with all the bells and whistles, an adaptive UI framework inspired by flexbox, skeletal animation, a save file format, a smart object system, path finding, a scripting language, audio, physics, et cetera, et cetera)
But did you actually need all of those things?