Ana Lucia Reyes wrote a small platformer and tested it on a laptop that ran it at 60 frames a second. On a friend's newer machine, running at 144, the character crossed the screen in under half the time and every jump overshot the platform. Nothing was random and nothing was broken. She had written movement in pixels per frame, and the machine decided how many frames there were.
That bug is the doorway to this whole topic. A game is not a program that runs and finishes. It is a program that is asked, sixty or more times a second, what the world looks like now, and every subject below this page is a consequence of being on that clock.
The loop, and the budget it hands you
The loop is input, update, draw, and it runs whether anything happened or not. Read the controller, advance the world by one slice of time, put a picture on the screen, and go round again. A word processor waits for a key. A game does not wait for anything, and a frame in which the player did nothing still costs a full pass.
That pass has a hard ceiling. The frame budget at 60 frames a second is 16.7 milliseconds for everything: the physics, the enemies deciding what to do, the sound, the drawing. Miss it and the frame is late, which the player does not read as a number but as the game stuttering. This is the discipline that makes the code that runs sixty times a second a different subject from ordinary programming, where a function taking 30 milliseconds is fast.
The two lines that fixed Ana Lucia's jump
The repair is one of the most transferable ideas in games. Delta time: multiply every movement by the seconds since the last frame. Instead of moving the character 4 pixels each frame, move it 240 pixels per second and multiply by however long the last frame actually took. At 60 frames that is 4 pixels. At 144 it is about 1.7. The character now crosses the screen in the same time on both machines, and the code no longer contains a hidden assumption about hardware.
x = x + speed * dtwherespeedis 240 anddtis 0.0167 at 60 frames- the same line gives 4.0 on the old laptop and 1.67 on the fast machine
There is a second half to it that beginners meet later and painfully. Physics does not survive being fed uneven slices of time: a frame that takes an unusually long moment lets a fast object pass straight through a wall, because at no point in the calculation was it ever inside one. The answer is a fixed timestep for physics and a variable one for drawing, running the simulation in constant slices and letting the renderer draw between them. It is more machinery than it sounds and it is why engines do it for you.
What the engine is actually for
An engine is not a shortcut to making a game. It is the answer to everything in a game that is not the game: the window, the controller, the sound mixing, the asset pipeline, the physics, the export to five platforms. the frameworks that handle everything but your game is named precisely, and the naming is the point. What it does not supply is the reason anybody plays, which is the entire content of deciding what the player does, and why they keep doing it.
Ana Lucia's platformer would have been faster to build in an engine, and she would not have met delta time or the timestep problem, which for a first project is an argument on both sides. An engine also decides a great deal that never announces itself as a decision: how the world is organised in memory, what a scene is, and where the seam between her code and its code falls. Changing engines later is not a port. It is a rewrite of everything except the art and the idea.
One game
Four pieces, and a game missing any one of them is a demo
These are not stages and they are not departments. Removing one does not make a smaller game, it makes an unfinished one.
- The systemsThe rules, the loop, and the code that has 16.7 milliseconds to run them
- The reason to continueWhat the player is deciding, and why the next minute is worth having
- The assets, to budget8,000 triangles rather than 80,000, decided by arithmetic before taste
- The last ten percentMenus, saving, options and the store build, which is half the calendar
The pieces are not equal in hours. The fourth routinely takes as long as the other three and is the one that is missing from almost every abandoned project.
The budget nobody tells an artist about
The clock reaches the art as well. Every asset has a cost paid every frame, and the engine sets the budget rather than the artist. A character at 80,000 triangles and one at 8,000 look nearly identical at the size a player actually sees, and one of them costs ten times as much of the 16.7 milliseconds. This is why assets built to a budget the engine sets is filed under a programming topic rather than a visual one: the constraint is arithmetic and it arrives before any aesthetic decision.
Where people stall
The stall is scope, and it is close to universal. The first project is an idea that would take a studio four years, and it is abandoned at the point where the interesting part is finished and the rest of it is menus, saving, options, sound settings and the fourteen things that are not fun to build. The people who ship are the ones whose first project was small enough that the boring part was two weeks rather than two years.
The second stall is the last ten percent, which is genuinely half the work, and it has its own cluster in stores, builds, playtesting and the last ten percent because nothing about it is a surprise to anybody who has done it and all of it is a surprise the first time.
What to open, in 2026
Godot is the free option with no revenue condition attached, is open source, and has taken a large share of the two dimensional work since 2023, when its main commercial rival announced a per install fee and then withdrew it. Unity remains the widest option by job count and by platform support, and is free below a revenue threshold. Unreal is the answer for high end three dimensional work and takes a royalty above a threshold instead of a licence fee.
All three replaced writing an engine, which is what a game project meant before about 2010 and which is now a deliberate choice to learn the layer rather than a requirement. For a first game the correct choice is nearly always the one with the shortest path to something playable, and the argument for it is in programming, from the first variable to a deployed system: a finished small thing teaches more than an unfinished large one.
What none of this settles is whether the thing is any good, which cannot be reasoned about and can only be watched, in a room, over somebody's shoulder, while saying nothing.