80/20 Of The Week … What Do Game Engines Actually Do?
Holy topic switch lol
We often hear things like “this game runs on Unreal Engine”, “this was made in Unity”, or “they built their own engine”, but what does that actually mean?
Because a game engine is not just “the thing that draws graphics”. That is part of it, sure, but the better way to think about it is as the foundation that gives developers many systems needed to build a game without starting from zero.
A game is not just a character moving on a screen. Underneath, you need rendering, physics, input, audio, animation, collision detection, asset loading, UI, scripting, networking, the game loop and a lot of glue between all of that.
They give you reusable infrastructure so you can focus more on building the actual game instead of rebuilding every low-level system first. Without an engine, even a “simple” game becomes bigger than it looks, because before you can say “let me move a character”, you first need to open a window, draw frames, load assets, read input, update objects every frame and connect everything together.
So without an engine, you are not just building the game. You are also building the environment where the game can even exist.
With something like Unity, Unreal, Godot or others, a lot of that already exists. You get an editor, rendering, physics, input handling, animation tools, asset management, debugging tools and a game loop that already knows how to update and render the world every frame.
It is kind of similar to using Spring Boot for backend apps. You could technically build HTTP handling, routing, configuration, dependency injection and database setup yourself. But usually you use a framework because it gives you a mature foundation, and then you build your actual product on top of it.
The biggest benefit of using an existing engine is speed. You can prototype faster, use tested tools, rely on documentation, use plugins/assets and deploy to different platforms more easily. For many games, using a mature engine is practical because the general-purpose hard problems are already solved well enough.
But building your own engine can still make sense.
If your game has very specific performance needs, unusual rendering requirements, custom simulation, special networking, unique tooling needs or a specific platform target, a custom engine can give you much more control.
The tradeoff is that now you are not just building a game. You are building and maintaining the thing that builds the game.
So the real question is not always:
“engine or no engine?”
It is more:
“how much of the foundation do we actually need to build ourselves?”
Existing engines give speed, tools and ecosystem. Custom engines give control, specialization and flexibility.
The real decision is not about what sounds cooler. It is about what your game actually needs.
#GameDev #GameEngines #UnrealEngine #Unity #Godot #SoftwareEngineering #SystemDesign
