The Game Loop: When State Started Carrying Forward

Game Loop Added Continuously Evolving State

Games took the idea in another direction in the 90s. Games took the idea in another direction in the 90s. A game cannot simply wait for the next event because the world keeps moving even when the player does nothing. Physics advances, animation continues, timers expire, characters move, invaders shoot, mushrooms explode, and computer-controlled actors make decisions.

So the loop becomes continuous. A simple game loop might look like this:

while game_is_running:
process_input()
update_world()
render_frame()

A more explicit version might include physics, character updates, AI, collisions, and rendering:

while game_is_running:
read_player_input()
update_physics()
update_characters()
update_ai()
resolve_collisions()
render_world()

The important thing here is that the game maintains a model of the world, and each iteration transforms one version of that world into the next.

This introduces something that becomes particularly interesting when we get to discussing agents: State carries forward from one iteration to the next. The loop is not just responding to isolated events. It is maintaining continuity. What happens now depends on what happened before. Previous events affect future events.

Why this matters if you are building agents

Agent context is a world model. Every tool result, every observation, every revised plan is an update to it - and, exactly as in a game loop, the next iteration depends entirely on the accumulated one before it.

Which raises the obvious operational question for anyone doing AI agent state management: a game loses its world when the process exits, and everybody accepts that. Does your refund agent get the same deal, forty-five minutes into a customer dispute?