Making video games (without an engine) in 2025

Graphics are anything from rendering 2d, 3d, shaders, scene graph, animation.

Physics and related interact with the scene graph.

The game part allows for dynamic behavior and of course the game logic/triggers.

Add some ui, and resource management, abs lastly of course ai.

Creating your own engine with different architectures is indeed the best way to learn how/why an engine works. But alll the details that come with it. That’s really a lot and probably way too much for one person. You’d be surprised how much is in there (in unreal engine)

The key difference is the code driven development workflow that makes it easy to keep different concerns like visual assets, collision boxes, navigation, etc separate.

If you do this in Godot, the standard editor features become meaningless, because they are optimized for throwaway workflows with extremely tight coupling (e.g. a player character IS a node containing subnodes, rather than the player character being a high level concept, whose nodes merely represent the player character).

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.

[1] https://github.com/ensisoft/detonator

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 :)