Games Pygame

Open the corner of almost any Indian school notebook and you will find someone's flipbook doodle — a stick figure that "runs" or a cricket ball that "flies" across the page when you flip the pages fast with your thumb. Each page has a picture that is only slightly different from the one before it. No single page shows motion. Motion is an illusion your eye builds when 15 or 20 slightly-different still pictures fly past every second. This is not a fun fact about notebooks — it is the exact engineering principle that every video game you have ever played is built on, from a mobile cricket game to a PS5 title. Pygame, the Python library this chapter teaches, is a tool for building that flipbook, one frame at a time, in code.

The Game Loop: One Idea That Explains Every Game

Before touching any code, understand the one idea that makes a game a game instead of a picture. A game program does the following four things, in order, over and over, dozens of times per second:

1. Check what happened — did the player press a key, click the mouse, or close the window?
2. Update — move the ball, move the paddle, check who won, based on what happened.
3. Draw — erase the old picture and draw the new positions of everything.
4. Wait a tiny, controlled amount of time — so the whole cycle repeats at a steady speed instead of running as fast as the processor can manage.

This repeating cycle is called the game loop. Everything in this chapter is really just learning to write these four steps correctly in Pygame. A common early mistake is to think a game program calculates the ball's final position with some formula and draws it once. It does not. It draws roughly 60 nearly-identical pictures every second, exactly like the flipbook, and lets your eye do the rest.

Setting Up: What Pygame Actually Is

Pygame is a Python library — a collection of ready-made functions — for drawing shapes, playing sound, and reading keyboard and mouse input, all inside a window that your program controls. It is not part of standard Python, so on a school or home computer it is installed once with pip install pygame in the terminal. After that, every Pygame program begins with the same short setup:

import pygame

pygame.init()                                  # starts all Pygame's internal systems

WIDTH, HEIGHT = 500, 400
screen = pygame.display.set_mode((WIDTH, HEIGHT))   # creates the window
pygame.display.set_caption("My First Game")

pygame.init() wakes up Pygame's internal modules (graphics, sound, input). pygame.display.set_mode((WIDTH, HEIGHT)) creates a surface — Pygame's word for a rectangular canvas of pixels you can draw on — and opens it as a visible window of that many pixels wide and tall. Everything you draw for the rest of the program goes onto this screen surface.

The Screen's Coordinate System — Not Your Math Graph

Here is a place where Pygame quietly breaks a habit from math class, and it trips up almost every beginner at least once. On a graph in your math notebook, the origin (0, 0) sits at the bottom-left, and y grows as you go up. On a computer screen, the origin (0, 0) is the top-left corner, x grows to the right exactly like a graph, but y grows downward. A point with a larger y value is lower on the screen, not higher.

Keep this picture in mind for the rest of the chapter: when a ball's y value decreases, it is rising toward the top of the window; when y increases, it is falling toward the bottom. Every "gravity" or "jump" effect in a 2D game is really just a small amount being added to or subtracted from y every frame.

Worked Example 1: A Ball That Moves and Bounces

Here is a complete, runnable Pygame program. Read it once fully, then we will trace it step by step.

import pygame

pygame.init()
WIDTH, HEIGHT = 500, 400
screen = pygame.display.set_mode((WIDTH, HEIGHT))
pygame.display.set_caption("Bouncing Ball")

WHITE = (255, 255, 255)
BLUE  = (30, 100, 240)

ball_x, ball_y = 100, 100
radius = 20
vx, vy = 3, 2

clock = pygame.time.Clock()
running = True

while running:
    for event in pygame.event.get():
        if event.type == pygame.QUIT:
            running = False

    ball_x += vx
    ball_y += vy

    if ball_x - radius <= 0 or ball_x + radius >= WIDTH:
        vx = -vx
    if ball_y - radius <= 0 or ball_y + radius >= HEIGHT:
        vy = -vy

    screen.fill(WHITE)
    pygame.draw.circle(screen, BLUE, (ball_x, ball_y), radius)
    pygame.display.flip()
    clock.tick(60)

pygame.quit()

Trace it carefully. ball_x, ball_y = 100, 100 and vx, vy = 3, 2 mean the ball starts 100 pixels from the left, 100 pixels from the top, and moves 3 pixels right and 2 pixels down every single frame. Colors in Pygame are RGB tuples of three numbers from 0 to 255 — (255, 255, 255) is pure white, and (30, 100, 240) is a strong blue (low red, medium green, high blue).

Now do the arithmetic a computer would do, frame by frame:

• Frame 1: ball_x = 100 + 3 = 103, ball_y = 100 + 2 = 102
• Frame 2: ball_x = 106, ball_y = 104
• Frame 3: ball_x = 109, ball_y = 106
• ...
• Frame 10: ball_x = 100 + 10×3 = 130, ball_y = 100 + 10×2 = 120

After 10 frames the ball has moved to (130, 120) — you can always find the position after n frames with start + n × velocity, exactly like simple-interest arithmetic in a maths textbook, just applied 60 times a second instead of once a year.

Now look at the bounce condition: if ball_x - radius <= 0 or ball_x + radius >= WIDTH: vx = -vx. ball_x - radius is the ball's left edge; ball_x + radius is its right edge. When the left edge reaches 0 (the window's left wall) or the right edge reaches 500 (the window's right wall, since WIDTH = 500), the horizontal velocity is negated — 3 becomes -3, so the ball now moves left instead of right. The same logic on ball_y against HEIGHT = 400 handles the top and bottom walls. This is the entire physics of a bouncing ball: check the edge, flip the sign of the velocity that would carry it through the wall.

The Misconception That Causes "Smearing"

A very common beginner mistake is to remove or forget the line screen.fill(WHITE), expecting the circle to still appear to move correctly. Try it and you will instead see a long blue streak — the ball's every previous position stays painted on the screen, because nothing ever erased it. This reveals an important truth about how Pygame (and most 2D game frameworks) actually work: the screen does not automatically clear itself between frames. The surface just remembers whatever pixels were last drawn on it. screen.fill(WHITE) is not decoration — it is the "erase the last flipbook page" step, and it must run before you draw the new frame, every single time through the loop. Likewise, pygame.display.flip() is not optional: everything drawn between fill() and flip() is invisible until flip() actually copies it to the visible window. Drawing without flip() is like flipping through blank pages — the pictures exist in memory but were never shown.

Reading the Keyboard: Player-Controlled Movement

So far the ball moves on its own. A game needs the player to control something. Pygame offers two different ways to check input, and it is worth knowing both because they answer different questions:

• pygame.event.get() tells you about things that just happened once — a key was pressed down, the window's close button was clicked. Good for "did the player just press Space to start."
• pygame.key.get_pressed() tells you which keys are currently held down right now, as a list of True/False values. Good for "is the player holding the Left arrow to keep moving the paddle."

For smooth movement — like sliding a paddle — you almost always want the second kind, checked fresh every frame:

paddle = pygame.Rect(210, 370, 80, 12)   # x, y, width, height

keys = pygame.key.get_pressed()
if keys[pygame.K_LEFT] and paddle.left > 0:
    paddle.x -= 6
if keys[pygame.K_RIGHT] and paddle.right < WIDTH:
    paddle.x += 6

pygame.Rect(210, 370, 80, 12) creates a rectangle 80 pixels wide, 12 pixels tall, whose top-left corner sits at (210, 370). A Rect is not just four stored numbers — it comes with convenient properties like .left, .right, .top, .bottom, .x, and .y that Pygame keeps in sync automatically when you change any one of them. The condition paddle.left > 0 stops the paddle from being dragged off the left edge of the window; paddle.right < WIDTH does the same on the right. Without these guard conditions, the player could hold the arrow key and push the paddle's rectangle to negative coordinates, off-screen and unreachable.

Rects and Collision Detection

Every non-trivial game needs to know when two things touch — a ball hitting a paddle, a player hitting a coin, a car hitting a wall. Pygame's Rect objects make this a one-line check with .colliderect(), but it helps to understand what that line is actually computing, because a wrong mental model here produces bugs that are hard to find later.

rect_a.colliderect(rect_b) returns True exactly when the two rectangles overlap on both the x-axis and the y-axis at the same time — overlapping on only one axis is not a collision. Work through a concrete case: suppose the paddle rectangle spans x from 210 to 290 and y from 370 to 382 (following the Rect(210, 370, 80, 12) above), and at some frame the ball's bounding box spans x from 238 to 262 and y from 352 to 376.

• x-overlap check: paddle covers [210, 290]; ball covers [238, 262]. Since 238 > 210 and 262 < 290, the ball's x-range sits entirely inside the paddle's — they overlap on x.
• y-overlap check: paddle covers [370, 382]; ball covers [352, 376]. These ranges share [370, 376] — they overlap on y too.

Both axes overlap, so colliderect returns True: a collision. If the ball's y-range had instead been [330, 354] (still above the paddle, not yet touching it), the y-check would fail even though the x-check passes, and there would be no collision — the ball simply hasn't fallen far enough yet. This two-axis logic is why collision detection with rectangles is reliable and fast: it is really just two ordinary "do these number ranges overlap" comparisons, one for x and one for y, combined with and.

Putting It Together: Paddle and Ball

Combining a moving ball, a player-controlled paddle, and collision detection produces the core of a Breakout- or Pong-style game:

import pygame

pygame.init()
WIDTH, HEIGHT = 500, 400
screen = pygame.display.set_mode((WIDTH, HEIGHT))
pygame.display.set_caption("Paddle and Ball")

WHITE = (255, 255, 255)
BLUE  = (30, 100, 240)
RED   = (220, 50, 50)

paddle = pygame.Rect(210, 370, 80, 12)
ball_x, ball_y = 250, 100
radius = 12
vx, vy = 4, 3

clock = pygame.time.Clock()
running = True

while running:
    for event in pygame.event.get():
        if event.type == pygame.QUIT:
            running = False

    keys = pygame.key.get_pressed()
    if keys[pygame.K_LEFT] and paddle.left > 0:
        paddle.x -= 6
    if keys[pygame.K_RIGHT] and paddle.right < WIDTH:
        paddle.x += 6

    ball_x += vx
    ball_y += vy
    ball_rect = pygame.Rect(ball_x - radius, ball_y - radius, radius * 2, radius * 2)

    if ball_x - radius <= 0 or ball_x + radius >= WIDTH:
        vx = -vx
    if ball_y - radius <= 0:
        vy = -vy
    if ball_rect.colliderect(paddle) and vy > 0:
        vy = -vy

    screen.fill(WHITE)
    pygame.draw.rect(screen, RED, paddle)
    pygame.draw.circle(screen, BLUE, (ball_x, ball_y), radius)
    pygame.display.flip()
    clock.tick(60)

pygame.quit()

Notice ball_rect is rebuilt fresh every frame, right after ball_x and ball_y change — a Rect built once before the loop would freeze at the ball's starting position forever, and colliderect would keep testing against a ball that, as far as the collision check is concerned, never moved. This is the same "must happen every frame" lesson as screen.fill(), applied to game logic instead of drawing.

Also notice the extra condition and vy > 0 on the paddle collision. vy > 0 means the ball is currently moving downward. Without this check, if the ball were resting against the paddle for two consecutive frames, the collision would be detected twice and vy = -vy would run twice, flipping the sign back to positive and letting the ball sink straight through the paddle. Requiring vy > 0 guarantees the bounce only triggers while the ball is heading toward the paddle, not while it is already bouncing away from it — a subtle but essential guard that separates a working game from one with an invisible, maddening bug.

Frame Rate and clock.tick(60): Why 60?

The line clock.tick(60) is doing more work than it looks like. Without any clock control, a while loop runs as fast as the processor physically allows — potentially thousands of iterations per second on a fast laptop and only a few hundred on an older school computer. If ball movement is written as "add 3 pixels every loop iteration," a game running at 3000 iterations per second would fling the ball across the screen instantly, while the same code on a slower machine would look sluggish. That is clearly wrong — a game's difficulty and feel should not depend on whose computer is running it.

clock.tick(60) fixes this by measuring how much real time has passed since it was last called and, if the loop finished early, deliberately pausing for the remaining time so that the loop executes at most 60 times per second — 60 frames per second, or "60 fps." With this in place, "3 pixels per frame" reliably means "3 × 60 = 180 pixels per second" on every machine, fast or slow, because the loop itself is held to the same steady 60-times-a-second pace everywhere. This is precisely why every serious Pygame program calls clock.tick() inside the loop: it turns "frames" into a dependable unit of time, the same way a metronome turns beats into a dependable unit of tempo for a musician, regardless of who is playing.

Check Yourself

• A ball starts at (50, 300) with velocity vx, vy = 5, -4. What is its position after 6 frames, and is it moving toward the top or bottom of the window?
• In the paddle-and-ball program above, what would happen on screen if the line screen.fill(WHITE) were deleted but everything else stayed the same? Explain why, using the idea of what a surface remembers between frames.
• Two rectangles: rect A spans x [100, 180], y [50, 90]. Rect B spans x [150, 220], y [95, 130]. Do they collide according to colliderect? Check the x-overlap and y-overlap separately before answering.
• Why does the paddle collision check in the worked example include and vy > 0 instead of just if ball_rect.colliderect(paddle): vy = -vy? What bug would reappear without it?
• If clock.tick(30) were used instead of clock.tick(60), and everything else in the bouncing-ball program stayed the same, would the ball appear to move faster, slower, or the same speed across the screen per second? (Hint: separate "pixels per frame" from "frames per second.")

Summary

A Pygame game is a loop, not a picture: handle events, update positions and check collisions, redraw the whole scene, then let clock.tick() pace the loop to a steady frame rate — usually 60 times a second, fast enough that redrawn still frames blur into motion the same way a hand-flipped notebook doodle does. The screen's coordinate system starts at the top-left with y increasing downward, the reverse of a maths-class graph, so moving something "up" means subtracting from its y value. Nothing on screen updates itself: forgetting screen.fill() smears old frames together, and forgetting pygame.display.flip() means nothing drawn that frame is ever shown. Rect objects package a shape's position and size together and make collision detection a matter of checking whether two rectangles' x-ranges and y-ranges both overlap at once — and that check must be rebuilt every frame from the object's current position, not calculated once before the loop starts. Master these five ideas — the loop, the coordinate system, redraw-every-frame, rect collisions, and frame-rate pacing — and you have the working foundation underneath every 2D game, from the simplest bouncing ball to a full Breakout clone.

Think About It

Think about this: How would you explain games pygame to a friend who has never seen a computer? What real-world analogy would you use? Imagine you had to build a system using these concepts — what would be your first step? Try this: before moving on, write down three things you learned and one question you still have.

Practice Exercises

Now it is time to practice! Complete these challenges to solidify your understanding:

• Exercise 1: Write a short program that demonstrates the core concept from this chapter. Test it with at least 3 different inputs.
• Exercise 2: Find a real-world example where games pygame is used in an Indian company (like TCS, Infosys, Flipkart, or ISRO). Write a paragraph explaining the connection.
• Exercise 3: Create a mind-map connecting games pygame to at least 3 other topics you have studied.