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:
- importing data from various sources and formats, textures, audio, model files such as gltf, fbx, animations etc etc.
- editor app with all the expected standard editing features, cut, copy, paste, undo, redo, save, delete etc.
- all the visualizations and operations that let the game developer use the editor to actually create and manipulate data, entities, animations, scenes, audio graphs, scripting support etc. etc.
- all the data packaging and baking such as baking static geometries, compiling shaders, resampling and packing textures, audio, creating game content asset packs etc
- etc etc.
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.
> Most people think of a “game engine” as code that is shipped with the game executable. However, that’s only half of it. The other half, which I’d argue is more significant, is the code that is not shipped with the game - level editors, content pipelines, debugging/profiling tools, development workflows, etc.
Writing tools is arguably more boring and tedious compared to writing an engine, and that's where lots of "making a game with custom engine" type of project grinds to a halt
[1] https://ruoyusun.com/2025/04/18/game-sequel-lessons.html
[1] https://ruoyusun.com/2023/10/12/one-game-six-platforms.html#...