Your web app waits for the user. A game never does: it runs 60 times a second whether anyone touches it or not — and every frame has a 16.6 ms deadline.
← / → to navigate · EN/VI switch below
Strip away the graphics and a game is just code you already know: variables, if-statements, and a loop.
A handful of variables: player position, score, lives, what's on screen. The game IS its state.
If-statements that change the state: did the player jump? Did the ball hit the wall? +10 points.
It runs 60 times per second: read input → update state → draw. Forever, or until quit.
A framework that runs that loop FOR you and adds physics, sound, assets — pygame, Unity, Godot.
The same code skills, a totally different contract with time.
User clicks, the server thinks, a page comes back. Nothing happens until someone asks. Time works for you.
Seconds are fine — nobody is watching a blank screen.
The screen refreshes 60 times a second whether the player touches anything or not. Miss the 16.6 ms budget once and the player FEELS it: stutter.
The deadline is physical, not polite.
One while-true. Sixty times per second. That's the whole skeleton of every game ever made.
Four jobs, every frame, in order.
Poll the keyboard/touch: what did the player just do? Keys pressed, taps, mouse.
Apply the rules: move the player, roll the ball, check collisions, add score. The state changes.
Clear the screen and paint everything at its new position. This is the only thing the player sees.
Sleep until the next frame is due — this locks the loop to 60 fps instead of spinning as fast as possible.
1 second / frames = your budget. Spend it on input + update + draw.
| 60 fps | 30 fps | 144 fps | |
|---|---|---|---|
| Milliseconds per frame | 16.6 ms | 33.3 ms | 6.9 ms |
| Who plays at it | The standard — desktop, mobile, everything | Older phones, casual mobile | High-refresh monitors, esports |
| If you miss it | One janky frame out of sixty | Less visible, still noticed in fast scenes | You only have 6.9 ms — AAA games live here |
One frame = one painted picture. FPS = frames per second. 60 fps = a new picture 60 times a second.
One lap of the loop. 'Update every tick' = every frame.
A little image the game moves around: the player, the ball, the enemy. You don't draw pixels — you place sprites.
The 'did these two overlap this frame?' check — the if-statement that makes games feel physical.
All the game's variables at one instant. Save the state and you can pause, rewind, or respawn.
How long the last frame actually took. Multiply speeds by it so a slow laptop plays at the same speed as a fast one.
pygame runs the loop for you; you fill in input, update and draw. Arrow keys move the square.
import pygame, sys
pygame.init()
screen = pygame.display.set_mode((400, 300))
clock = pygame.time.Clock()
x = 200
while True: # THE loop — 60x per second
for e in pygame.event.get(): # 1. poll input
if e.type == pygame.QUIT: sys.exit()
k = pygame.key.get_pressed()
if k[pygame.K_LEFT]: x -= 5 # 2. update state
if k[pygame.K_RIGHT]: x += 5
screen.fill((15, 23, 42)) # 3. draw
pygame.draw.rect(screen, (110, 231, 160), (x, 120, 40, 40))
pygame.display.flip()
clock.tick(60) # 4. sleep — lock to 60 fpsThat's it: input polling, state update, redraw, and clock.tick(60) locking it to 60 fps.
Install, run, move with the arrow keys, close the window to quit.
Pick one and you can make almost anything.
The industry default for 2D and 3D. C#, a huge asset store, and most of the mobile hits you've played. Free to start.
Open-source and completely free. GDScript (Python-flavored), lightweight, and its 2D is genuinely great. The indie favorite.
The AAA monster: C++ plus Blueprints (visual scripting), the best real-time graphics anywhere. Big, heavy, overkill for small games.
| Unity | Godot | Unreal | |
|---|---|---|---|
| Language | C# | GDScript (+ C#) | C++ (+ Blueprints) |
| Cost | Free up to a revenue threshold, then a share | 100% free, open source (MIT) | Free, 5% after $1M gross |
| Weight | Heavy but batteries-included | Light — the editor opens in seconds | Very heavy — built for AAA |
| Best for | Indie → mid-size 2D/3D, mobile | 2D, quick prototypes, full control | AAA 3D, serious graphics |
Same loop, two ownership models.
You wrote the while-true, the input polling, the clock. You learn how every frame happens; nothing is for free — no physics, no editor, no asset store.
Use it to learn, or for tiny games.
The engine runs the loop; you write callbacks: 'when a frame ticks, move the player'. Physics, animation, editor, assets — included.
Use it for anything you'll actually ship.
Gravity, bounces, joints — engines ship a physics engine; you aim it, it solves the math.
Sprite sheets, skeletal animation, shaders — the reason games look like games.
Channels, mixing, spatial audio.
Netcode, latency, synchronization — a whole course on its own.
Tilemaps, level editors, world streaming.
Stores, reviews, monetization — the shipper half of game dev.
Strip a game to the bone and it's variables, if-statements, and a loop — the exact skills you're building in this course. Every engine, pygame to Unreal, is just a different answer to one question: who runs the loop?
Next: the same ship-it habits, on a phone — mobile dev.