Classical game dev for AI developers: the game loop

25 Sep, 2026

So, you want to make a video game using AI? You prompted a one-shot generator and what came back certainly looks game shaped. It runs. You can play it, at least for a bit. Then you ask for a small change, watch the AI open six PRs and burn through your quota, and wish you understood what was going on.

I came at game dev from the other direction. I spent more than a decade on AI and engine work at Amazon and Blizzard before I ever prompted an agent, and I believe a little classical game dev knowledge can help you be better even at vibe gamedev. Unfortunately, most tutorials are designed either to walk you through making a game or to teach you enough engine architecture to build one the old-fashioned way. This article is the first in a series trying to do something else: give you a high-level lay of the land, just enough to understand what the AI is doing and where things are supposed to go.

I am going to gloss over a lot of complexity and shy away from details, for two reasons:

1. There are many, many books, tutorials, and series for anyone who wants to go deep.
2. You won't read massive detailed articles anyway. That is not the way of the vibe coder.

The only prerequisite is that you can read code. Not game code, and not any particular language, but you know what a loop is and what a condition does. This is for the programmer who has never done games. It may help if you are learning to program, but it will definitely not teach you coding, vibe or otherwise.

You may wonder whether any of this knowledge is still relevant. Maybe it won't be forever. AI-powered development is changing quickly. But what's changing is who does the work, not what the work is. Consider the role of a movie director. They don't operate the camera, light the set, or cut the film. But a director who knows what a lens does, how a cut works, and what a shooting day costs gets the film they imagined. One who doesn't gets whatever the crew gave them.

We are moving into a world where AI acts like a film crew. And the crew is skilled, fast, and will shoot anything you ask, including stuff that won't cut together. So this series is about learning just enough to be a better director.

I have three or four of these articles planned. The first, this one, is about what I think will probably help you most at this stage: the game loop. The second will talk about how game engines are structured. After that I will do a deep dive into one system, probably game AI. What comes after depends on whether anyone finds these useful.

With that out of the way:

The game loop

If there is one classical game dev concept worth knowing, it's this one.

A video game is a loop. Each turn of it does roughly the same four things: read what the player did, update every number in the world, throw away the screen, draw it again from scratch. That's it.

Every system you've heard of, physics, AI, animation, rendering, is just one step inside that loop, taking its turn. For example, the physics system is responsible for things with a velocity. A thing's position is a number, and each turn the physics system nudges that number by a small amount based on its velocity and how much time has passed. The renderer in turn redraws the screen so often that this looks like motion.

In the simplest terms, pretty much every game is:

while (true)
{
    Input.Read();
    AI.Update(frameTime);
    Physics.Update(frameTime);
    Animation.Update(frameTime);
    Render();
}

I'm obviously withholding a lot of complexity, but this is a good enough mental model to start from. In a real-time game this loop runs continuously. In a turn-based game it may spend most of its time waiting for the player, then run through much the same sequence when a turn advances. Either way, the basic idea is the same: take some input, update the world, and show the result.

At this level, you can think of the ends of the loop as more or less fixed: input comes first, because it's the thing the player contributes, and render comes last, because what you see should be the result of every system updating.

Let's talk quickly about frameTime. In a real-time game, this loop runs as fast as the machine allows, and the iterations are never evenly spaced. frameTime is how much time passed since the last iteration. It's how every system marks time, so a faster machine gets more updates, but less time has passed between each one and the systems update accordingly. A lot of older games didn't account for this very well, which is why running an old game on a much faster computer could sometimes make everything happen in turbo mode.

In traditional game dev you don't think about the loop much. You're on a big team and responsible for a sliver of one of those function calls.¹ But if you're making a game by yourself, or your agent is, you effectively own all of it. And that is where this model becomes useful.

Suppose your character starts sliding strangely down a slope. Maybe the physics is wrong. Maybe the character controller is wrong. Maybe the animation system is doing something it shouldn't. Maybe somebody fixed an earlier bug by pushing the character back into place every frame. From the outside, all of those can look like the same problem.

If you don't know that these systems are separate things with separate responsibilities, an AI can solve the visible symptom wherever it happens to find a convenient place to do so. The game works again, but the fix may now live somewhere it absolutely should not. Do this often enough and you end up with a project where every small change touches twelve files and nobody, not even the agent, is quite sure which system actually owns what.

Which raises the next question: what are these systems, where do they live, and who wrote them? When you build your own engine, you build everything from the physics and animation to the networking systems yourself, but most AI-powered developers are sitting on top of a pre-made engine that already has them.

All this and more in the next article: Engine architecture (on or before Oct 4, 2026).

- Nikhil

If you're already working on a game and want another pair of eyes on the code, architecture, or problems your agent has gotten you into, I can help: consult.seahorseemoji.co.

On AI assisted writing²

#ai #gamedev #vibe coding