Abstract
A compact Pygame Snake implementation covering the full real-time game loop — keyboard input, grid-based movement, food spawning, collision detection, and score tracking in a single Python file. The one thing worth reporting on is how cleanly input, state update, and rendering separate once you commit to a fixed tick rate.
1. What This Is
I built this as a focused exercise in real-time game programming. The scope is deliberately small: one snake, one food item, grid-based movement, and boundary or self-collision rules. The value is in seeing how input polling, state mutation, and frame rendering interact inside a predictable loop without the noise of a full engine.
2. How It Works
The game runs a standard Pygame event loop. Each frame it polls keyboard events to update the current direction vector, advances the snake head one grid cell at the configured tick rate, checks for food consumption or collision, and redraws the window. The loop continues until a collision sets the game-over flag.
| # | Stage | Input | Tool | Output |
|---|---|---|---|---|
| 01 | Init | Window size, starting position | Pygame | Ready game state, first food |
| 02 | Input | Keyboard events | Pygame event queue | Updated direction vector |
| 03 | Move | Snake body, direction | Grid logic | New head position, shifted body |
| 04 | Check | Head, food, body cells | Collision logic | Grow / score / game-over flag |
| 05 | Render | Updated state | Pygame draw calls | New frame on screen |
3. Constraints
-
No input buffering
Rapid direction changes within a single frame can register as a 180-degree reversal, killing the snake instantly. A proper input queue would fix this but was out of scope.
-
Fixed tick rate
Movement speed is hardcoded. There is no difficulty scaling, no pause state, and no high-score persistence between sessions.
-
No automated tests
Collision and boundary logic are verified only by manual play. Edge cases like the snake filling the entire grid are untested.
-
Single-file scope
All logic, rendering, and state live in one script. No asset pipeline, no sound, no configuration file — fine for a learning exercise, not for anything beyond it.
4. Next
- a. Add an input queue so rapid key presses buffer instead of causing instant 180-degree deaths.
- b. Introduce a difficulty ramp: tick rate increases every N points, with a cap to keep it playable.
- c. Wrap game state in a class and add a high-score file plus a pause overlay so the loop can be extended to a second player or AI opponent.
— end of report —