What is Game Loop?

The Heartbeat That Keeps Your Game Alive

Think of your heartbeat — it pumps steadily whether you're sleeping or sprinting, keeping you alive without you thinking about it. A game loop works the same way — it's a continuous cycle that checks for input, updates the game state, and draws everything on screen, running dozens of times per second to keep your game responsive and smooth.

6 min read Updated 2025-03-12 By Hasan

The Never-Ending Cycle

Your heart beats about 60-100 times per minute, keeping blood flowing without you thinking about it. A game loop does the same thing for your game — it runs continuously (often 60 times per second), checking if the player pressed any buttons, updating positions and scores, then drawing everything on screen. This cycle repeats forever until the player quits. Without it, your game would just be a frozen screenshot.
Without a proper game loop: Imagine a game where the character moves 10 pixels every frame. On a fast computer running at 120 FPS, the character zooms across the screen. On a slow computer at 30 FPS, the character crawls. Players with better hardware have an unfair advantage, and your physics behaves unpredictably — jumps are higher on fast machines, enemies move erratically.
Without Delta Time
💻Fast PC120 FPS
🏃Speed: 1200px/sToo fast!
🖥️Slow PC30 FPS
🐢Speed: 300px/sToo slow!
Same code = different speeds on different hardware
With a proper game loop using delta time: Instead of moving 10 pixels per frame, you move based on time passed. "Move 300 pixels per second" means on a fast computer with tiny time steps, you move a little each frame. On a slow computer with bigger time steps, you move more per frame. The result? Identical speed everywhere. Physics stays consistent. Every player gets the same experience.
With Delta Time
⏱️Delta Time
Game Loop
🎮Input
🔄Update
🖼️Render
300px/sAlways consistent!
Time-based movement = same speed everywhere
The good news? The game loop pattern is actually simple. It's just a while loop with three steps inside: handle input, update state, draw. Once you understand that every game — from Tetris to AAA titles — uses this same basic structure, you can build any real-time game. The key insight is using time (delta time) instead of frames to measure movement.
TL;DR

Game Loop = Repeat forever: process input → update game state → render graphics. Use delta time so movement speed stays consistent regardless of frame rate.

When to Use Game Loop

Game Loop isn't always the right call. Here's a quick mental model:

You're building any real-time game

Platformers, shooters, racing games, action RPGs — anything where things move continuously needs a game loop. Even simple games like Pong require constant updates and rendering.

You need consistent physics

Want jumps to always reach the same height? Gravity to always feel the same? Use a fixed timestep for physics calculations inside your game loop.

Your game should run the same on all hardware

When you multiply movement by delta time (time since last frame), a fast computer with small time steps and a slow computer with big time steps produce identical results.

You want smooth animations

The game loop's render phase draws every frame. Combined with delta time, animations interpolate smoothly even when frame rates vary.

You're building a turn-based game with no animations

Pure turn-based games like chess (no animated pieces) can use event-driven programming. Wait for player input, update state, redraw once. No continuous loop needed.

Your app is static or event-driven

Web forms, CRUD apps, and most business software don't need continuous loops. They respond to user events, update, done. Don't add complexity you don't need.

Interactive Game Loop Demo

Watch how delta time keeps movement consistent. Compare a ball moving with and without time-based movement at different simulated frame rates.

Game Loop Simulator

Simulated — no real calls
FPS
⛔ Without Delta Time
Movement
Actual Speed
x += 2.5
✓ With Delta Time
Movement
Actual Speed
x += 150 * deltaTime
Delta Time:
Frames:
At : The red ball (no delta time) moved at , while the green ball (with delta time) stayed consistent at 150 px/sec. This is why delta time matters!
What to notice:
  • Drag the FPS slider to simulate slow and fast computers
  • Watch the "Without Delta Time" ball speed up and slow down
  • Notice the "With Delta Time" ball stays consistent at any FPS

AI Prompts for Game Loop

Now that you understand game loop, use these prompts with your AI coding agent. Copy the one that matches what you're building — the agent will handle the implementation.

Tip: These prompts help you implement game loops in any language or engine. Copy, paste, and fill in the [brackets]. The AI will generate code and explain each part.

Create a basic game loop for my [language/framework, e.g., Python/Pygame, JavaScript/Canvas, C++/SDL]. I need the loop to: 1. Track time between frames (delta time) 2. Process player input 3. Update game state (positions, physics, AI) 4. Render everything to screen 5. Cap frame rate to [target FPS, e.g., 60] Include: - A simple moving object that uses delta time for consistent speed - Basic structure I can expand later - Comments explaining each section I'm learning game development, so explain why we need delta time and how it makes the game run the same on fast and slow computers.
starter Start here when building any new game
My game currently moves objects without delta time and runs at different speeds on different computers. Current movement code: [paste your movement code, e.g., "player.x += 5"] Help me: 1. Calculate delta time (time since last frame) 2. Convert my movement to be time-based instead of frame-based 3. Ensure physics and animations stay consistent at any frame rate My game uses: [language/framework] Current target FPS: [e.g., 60] Explain what delta time is and show before/after examples so I understand the change.
intermediate For fixing games that run too fast or slow on different computers
I need to implement a fixed timestep game loop for reliable physics simulation. My game has: [describe physics, e.g., "platformer with jumping and gravity" or "ball physics with collisions"] Create a game loop that: 1. Uses a fixed timestep for physics updates (e.g., 1/60th of a second) 2. Accumulates time and runs multiple physics steps if needed 3. Interpolates rendering between physics states for smooth visuals 4. Handles the "spiral of death" (when physics can't keep up) My framework: [language/framework] I'm learning about fixed vs variable timestep. Explain why physics needs fixed timestep but rendering can be variable, and what problems this solves.
advanced For games with precise physics requirements
Help me create a proper game loop for a browser-based game using requestAnimationFrame. I want to build: [describe your game, e.g., "a simple 2D platformer" or "a physics sandbox"] The loop should: 1. Use requestAnimationFrame for smooth rendering 2. Calculate delta time correctly (handling tab switching) 3. Cap maximum delta time to prevent physics explosions 4. Include a simple game state with update and render separation Also show me: - How to pause/resume the loop - How to handle the tab becoming inactive - Basic performance monitoring (FPS counter) I'm new to browser game development, so explain the differences from traditional game loops and why requestAnimationFrame is preferred over setInterval.
starter web For HTML5 Canvas or WebGL games

Game Loop in Real Applications

Unity's Update vs FixedUpdate Unity provides two loop hooks: Update() runs every frame (variable timestep for visuals) while FixedUpdate() runs at fixed intervals (for physics). This is the fixed/variable timestep pattern built into the engine.

Godot's _process vs _physics_process Godot has _process(delta) for frame-dependent updates and _physics_process(delta) for physics. Both receive delta time automatically — Godot handles the game loop for you.

Browser Games with requestAnimationFrame Every browser game (Canvas, WebGL, PixiJS, Phaser) uses requestAnimationFrame as its game loop. It syncs with the display refresh rate and provides timestamps for delta time calculation.

Pygame's Clock Pygame provides pygame.time.Clock() with tick(FPS) that caps frame rate and returns delta time in milliseconds. It's a simple way to implement the game loop pattern.

Common Game Loop Mistakes to Avoid

Moving by pixels-per-frame instead of pixels-per-second

Writing "x += 5" instead of "x += 300 * deltaTime" makes your game run faster on better hardware. Always multiply movement by delta time for consistent speed everywhere.

Running physics on variable timestep

Physics simulations need consistent time steps. Variable timestep makes jumps inconsistent — sometimes higher, sometimes lower. Use fixed timestep for physics, variable for rendering.

Doing heavy calculations in the render phase

The render phase should only draw. Put AI, physics, and game logic in the update phase. Heavy render code causes frame drops and stuttering.

Not capping delta time

If your game freezes momentarily (loading assets, garbage collection), delta time spikes. Objects teleport across the screen. Cap deltaTime to a maximum (e.g., 0.1 seconds) to prevent this.

Related Building Blocks

COURSE

Ready to Build Real Products?

Learn to ship MicroSaaS apps with AI in the Solo Builder course.

Start Building →