Game Engines
The loop underneath every engine, the data layout that keeps it fast, and where Unity, Unreal and Godot actually differ.
What An Engine Is
Choosing an engine is mostly choosing a community, an asset pipeline and a set of defaults. All three major engines can render your game. They differ in what is easy, what is possible, and who you can hire.
Underneath the editor, every one of them is the same loop reading input, stepping simulation and drawing a frame. Learn the loop and the engine becomes a tool rather than a magic box.
The Game Loop
A game is a loop that never returns. Each pass: gather input, advance the world by some amount of time, draw the result, repeat — sixty or more times a second, forever.
while (running) {
input.poll();
accumulator += clock.deltaTime();
while (accumulator >= FIXED_STEP) { // simulation: fixed steps
physics.step(FIXED_STEP);
accumulator -= FIXED_STEP;
}
render(accumulator / FIXED_STEP); // rendering: whatever rate it gets
}The important structure is that simulation and rendering run at different rates. Physics wants equal-sized steps so results are deterministic and stable; rendering wants to draw as often as the display allows. The accumulator reconciles the two, and the leftover fraction is passed to the renderer so it can interpolate between the last two simulation states.
position += speed per frame means the game runs at double speed on a 120 Hz monitor. Multiply by delta time, always.Even with delta time, a variable step breaks physics. A frame hitch produces one enormous step, and a fast-moving object teleports through a wall because it was never on the collision side of it at any sampled moment. Fixed steps exist for that reason.
Entity-Component-System
Deep inheritance hierarchies collapse under their own weight once a design changes: a FlyingEnemy that also needs to swim has no correct parent. Composition solves it — an entity is an id, components are plain data attached to it, and systems are functions that run over every entity holding a given set of components.
| Piece | Is |
|---|---|
| Entity | An id. No behaviour, no data of its own |
| Component | Plain data — position, health, sprite |
| System | Logic that runs over everything with the components it needs |
The design win is that behaviour becomes a matter of which components an entity has, decided at runtime. The performance win is separate and larger: components of one type are stored contiguously, so a system walks memory in a straight line and the cache prefetcher keeps up.
Unity's DOTS, Unreal's Mass and Bevy's core are all this idea. It is not always the right shape — for a small game, plain objects are simpler and fast enough — but at thousands of entities the difference stops being theoretical.
Unity
C#, an enormous asset store, and by far the largest hiring pool. Unity dominates mobile and indie work because the iteration loop is quick and the answer to almost any question already exists in a forum post.
The default model is GameObjects with MonoBehaviour components — composition, but with per-object callbacks rather than systems. It is easy to start with, and the cost arrives later as thousands of tiny Update() calls with unpredictable ordering.
Unreal
C++ with Blueprints, a visual scripting layer that designers use without touching the codebase. Unreal ships with high-end rendering, a mature replication system for multiplayer, and a full-source licence, and it is the default for large 3D productions.
The cost is weight. The engine is large, the build times are long, the source is a substantial thing to learn, and the editor asks for a real workstation. For a small 2D game it is far more machinery than the problem needs.
Godot
Open source under MIT, small enough to download in seconds, and built on nodes in a scene tree — every scene is reusable inside another scene, which makes composition the natural way to build rather than a pattern you impose.
GDScript is Python-shaped and fast to write; C# is supported for those who want it. The 2D pipeline is genuinely first-class rather than 3D with the z-axis ignored. The 3D side is improving quickly but still behind Unreal at the high end, and the asset ecosystem is smaller.
Interview Questions
Why separate fixed simulation steps from rendering?
Physics needs equal-sized steps to stay stable and repeatable, while rendering should use whatever frame rate the display offers. An accumulator runs the simulation in fixed steps and hands the leftover fraction to the renderer to interpolate.
What breaks if game logic is not multiplied by delta time?
Speed becomes a function of frame rate — the game literally runs twice as fast on a 120 Hz monitor as on a 60 Hz one, and behaves differently on every machine.
Why does ECS help performance?
Components of the same type sit contiguously in memory, so a system iterates linearly and the cache prefetcher keeps ahead of it, instead of chasing pointers around the heap.
When is ECS the wrong choice?
When the entity count is small. Plain objects are simpler to read and debug, and the memory-layout win only matters once you are iterating thousands of things per frame.
Unity or Unreal for a high-end 3D multiplayer game?
Unreal — its renderer and its replication system are built for that scale, and Blueprints let designers work without engine programmers. Unity is the stronger pick for 2D, mobile and fast iteration.
Why do teams pick Godot?
MIT licence with no revenue share or royalty questions, a very small editor, a scene-tree model where any scene nests inside another, and 2D support that is genuinely first-class.