Pac-Man is a milestone M4 Python project, done in pairs. You build a playable Pac-Man game: a player eating pac-gums in a maze, four ghosts chasing them, super pac-gums that make ghosts edible, lives, levels, a timer and a persistent high score table. The twist is that the mazes are not yours: each level is generated by another team's A-Maze-ing package, installed as a dependency, so you learn what it means to depend on someone else's library. Details below come from student repositories (Reported by students); check them against your subject.
What you will learn
- Structuring a real-time game: game loop, input, update, render, fixed time step
- Separating game logic from rendering so each can be tested and changed alone
- Ghost behaviour with BFS chasing, fleeing and respawn timers
- Consuming a third-party package: installing a wheel, reading its API, validating its output
- Reading a JSON configuration with safe defaults
- Persisting data (high scores) safely to a file
- Working in a pair on a codebase with clear ownership
Before you start
- Previous nodes: A-Maze-ing (yours is the reference for the maze format) and Fly-in or Call Me Maybe from M3.
- Tools: Python 3.10+,
flake8, mypy, and a graphics library. MiniLibX bindings are reported; some teams use Pygame while keeping to drawing calls that exist in MiniLibX. Check what your subject allows.
- Get another team's
mazegen wheel early, and agree with them on how to report bugs.
- Reported configuration keys include the high score file, number of levels, lives (default 3), points per pac-gum (10), per super pac-gum (50), per ghost (200), maximum level time and seed.
Plan of attack
- Day 1: split the work. One partner owns the core (state, rules, ghosts, scoring), the other the front (window, input, drawing, menus, high scores).
- Day 1: load the configuration with defaults for every key; invalid values fall back to defaults with a warning instead of crashing.
- Day 2: install the foreign maze package, generate a level, and convert it to your own grid model. Check connectivity and regenerate if some cells are unreachable.
- Day 2: player movement with buffered input (the next direction is applied when the corridor allows it).
- Day 3: ghosts: BFS towards the player, a frightened mode after a super pac-gum, a respawn delay after being eaten.
- Day 3: lives, level timer, level progression and game over.
- Day 4: high scores (top ten, names sanitised, stored as JSON), pause and menus.
- Day 4: an evaluation or cheat mode (invincibility, skip level) so the evaluator can reach every feature quickly.
- Day 5: lint, README with the AI usage section, and a full play session by each partner on the other's code.
An illustrative configuration (check the exact keys against your subject):
{
"levels": 10,
"lives": 3,
"points_per_pacgum": 10,
"points_per_super_pacgum": 50,
"points_per_ghost": 200,
"level_max_time": 90,
"seed": 42
}
Common pitfalls
- Game logic mixed into drawing code, which makes mypy errors and bugs spread everywhere.
- Speed that depends on the frame rate of the machine.
- Trusting the foreign maze blindly: closed areas, entry inside the "42" pattern, unexpected sizes.
- Losing the score or the timer when a life is lost.
- A high score file that crashes the game if it is missing or corrupted.
- Imports of your own A-Maze-ing code instead of the other team's package.
How it is evaluated
- Peer evaluation of the pair. The evaluator runs the linters and installs the dependencies from scratch.
- Then plays: movement, ghosts, super pac-gums, lives, timer, level change, high score saving.
- The evaluator checks that the maze comes from another team's package and asks how you integrated it.
- Both partners must be able to explain the core and the front.
- Extra features (ghost modes such as scatter and chase, sound, animations) are reported as bonus.
Resources