The Game Loop, Simply
通俗讲游戏主循环
Updated October 3, 2026
01What this concept is really about
The game loop is the heartbeat of every game. It is the repeating cycle that keeps your game alive from the moment it starts until the moment it stops. At its core, the loop asks three simple questions over and over: What has changed since the last moment? What should the game look like right now? And has the player asked to quit? That is it. Everything else in your game, from jumping characters to scoring points, happens inside this cycle. When people say a game is "running," they mean this loop is turning.
The most important idea to grasp is that the loop separates thinking from showing. One part of the cycle updates the state of the world: positions, timers, health, scores, and any rules you have written. Another part draws that state to the screen so the player can see it. These two jobs are related but distinct. Updating changes the truth of your game world. Drawing only reports that truth visually. If you confuse them, your game will behave strangely, because you will be mixing what is true with what is seen.
A helpful mental model is a flipbook. Each page is a single pass through the loop. The update step decides what the next page should contain. The draw step actually paints that page. Flip the pages fast enough and the player experiences motion, challenge, and fun. The loop is not a feature you add later; it is the frame that holds every feature you will ever write.
02Why it matters for your game
Without a loop, your game is just a program that runs once and stops. A loop is what allows time to pass inside your game. Movement, animation, enemy behavior, and countdown timers all depend on the loop running again and again. If you skip building a clear loop, you will find yourself scattering logic in odd places, and your game will feel unpredictable. The loop gives every part of your game a predictable moment to do its job.
The loop also gives you a single place to control the pace of your game. You can decide how often updates happen, how smooth motion should feel, and how input is read. When something feels wrong, such as a character moving too fast or a menu responding slowly, the loop is often the first place to look. Beginners who understand the loop can debug timing problems far more easily than those who treat their game as a pile of unrelated scripts.
Finally, the loop is the foundation for everything you will learn next. Input handling, state machines, collision, and scoring all plug into the update step. Drawing, camera movement, and user interface all plug into the draw step. If the loop is clear in your mind, new topics have an obvious home. If it is fuzzy, every new topic feels disconnected. Learning the loop early saves you confusion later, and it makes your first small game feel like a real game rather than a demo.
03The mistake beginners often make
The most common mistake is skipping the loop entirely. Beginners often write code that reacts to a single event, such as a key press, and then stops. The game appears to work for one action, but nothing continues. Time does not advance, enemies do not move, and animations freeze. This happens because the program has no repeating cycle to keep the world alive. It is like clapping once and expecting applause to continue forever.
A related mistake is putting drawing logic inside the update step, or update logic inside the draw step. When you draw while updating, you may accidentally change the world based on how many times the screen refreshed, which varies between machines. When you update while drawing, you may move objects twice in one frame or not at all. These bugs are hard to see at first because the game still runs, just incorrectly. The fix is to keep the two jobs separate and honest.
Another frequent error is treating the loop as something you set up once and forget. In reality, the loop is the structure you return to constantly. Beginners sometimes add new features by creating separate timers or event handlers that bypass the loop. Soon the game has many competing rhythms, and behavior becomes chaotic. The healthier habit is to ask, every time you add something, which part of the loop it belongs to. Update or draw. That simple question prevents a lot of pain.
04A simple way to learn it
A concrete and repeatable approach is to build a tiny moving square before you build anything else. Start with a blank window and a square at a fixed position. Then write a loop that runs continuously. Inside the loop, do exactly two things in order: first update, then draw. In the update step, add a small amount to the square's horizontal position. In the draw step, clear the screen and draw the square at its current position. Run it. You should see the square glide across the screen. That is the entire concept working.
Once that works, repeat the exercise with small variations to deepen your understanding. Add a second square that moves in the opposite direction. Add a boundary so the square wraps around or bounces. Add a key that changes the square's direction, but only read that key inside the update step. Each variation should still follow the same pattern: update first, draw second, repeat. If something breaks, check whether you accidentally changed the world during the draw step or drew during the update step.
Finally, write down the loop in plain words in your own notes. Something like: while the game is running, read input, update the world, draw the world. Keep that note beside you as you build your first game. Whenever you feel lost, return to the note and ask which step you are in. This habit turns the loop from an abstract idea into a tool you can rely on. Repeat the moving square exercise until it feels boring, because boredom here means understanding.
05What to pair it with
The loop becomes far more useful when paired with input handling. Input is simply the player's intent, captured at the right moment. In most designs, you read input during the update step and store it, then act on it. If you read input during the draw step, you may miss presses or apply them inconsistently. Pairing the loop with clean input gives you responsive controls without chaos. Start with one or two keys, such as left and right, and expand later.
A state machine is another natural companion. A state machine describes what mode your game is in, such as a title screen, playing, paused, or game over. The loop can ask the state machine what should happen this frame, and the state machine decides which update logic to run. This keeps your loop small and your rules organized. Beginners often try to cram every possibility into one giant update function, which becomes unreadable quickly. A simple state machine prevents that.
Your first game is the best place to practice all three together. Build something tiny, like a square that moves, avoids a wall, and can be paused. Use the loop to drive time, input to steer, and a state machine to switch between playing and paused. Do not add scoring, menus, or levels yet. The goal is to feel how the loop, input, and state work as one system. Once that feels natural, adding features becomes a matter of plugging them into a structure you already trust.
06When to keep it simple
Keep the loop simple when you are still learning. A single update step and a single draw step are enough for a surprising number of small games. You do not need multiple loops, background threads, or complex scheduling. Those ideas exist for specific problems, and beginners rarely have those problems. If your game is small and your rules are few, one loop is almost always the right answer. Simplicity here is not a limitation; it is a way to see clearly.
Keep it simple also when your game is turn-based or menu-driven. In these games, the world does not need to change every frame. You can still use a loop, but the update step may do very little until the player acts. That is fine. The loop is still there to keep the program responsive and to draw the current screen. Do not force constant motion into a game that does not need it. Match the loop to the game, not the other way around.
Finally, keep it simple when you feel tempted to optimize too early. Beginners sometimes hear about frame rates and timing and try to build elaborate systems before their game works. Resist that. Get a square moving first. Get a key responding first. Get a pause working first. The loop will grow with your understanding. A simple loop you fully understand will beat a complex loop you copied and cannot explain. Clarity now pays off later.
07Questions beginners ask
Q: Do I need a loop if my game only reacts to clicks? A: Yes, but it can be very light. The loop still keeps the program alive and redraws the screen. Your update step may only check for clicks, and your draw step may only show the current state. The loop is the frame, even when little changes.
Q: What is the difference between update and draw? A: Update changes the truth of your game world, such as positions, timers, and scores. Draw shows that truth on the screen. Update decides what is real. Draw reports what is seen. Keeping them separate prevents timing bugs and makes your code easier to reason about.
Q: How fast should the loop run? A: Fast enough that motion looks smooth and input feels responsive, but you do not need to obsess over exact numbers as a beginner. Focus on the structure first. Once your loop is clean, you can learn about timing and frame rates with a solid foundation. Structure before speed.