Pathway · Sample Problems
Game Programming
What real problems look like — and what separates a serious one from the easy way out
You have already read what game programming is and whether it might be for you. This page goes one level deeper. It shows what actual problems in this pathway look like, in enough detail that you can picture the real work involved — and see the difference between engaging with a problem seriously and doing the least you can get away with.
The problems below look simple on the surface: a text game, a grid you move around, a ball bouncing between two paddles. That is exactly right for this level — beginning game programmers build beginning games. The difficulty is never in the concept. It is in making the system actually work, and hold up when someone else plays it.
These are examples, not a menu
Every problem below is an illustration of the kind of work this pathway contains — not a list to choose from. You do not have to pick one of these. In fact, the strongest projects usually begin with a mechanic or system a student is genuinely curious about building. You are welcome to build on one of these examples or design something entirely your own. Either way, the standard is exactly the same.
What makes a problem serious
Across every pathway in this course, the difference between a strong project and a weak one is almost never the topic. It is whether the work shows these six things:
- A real question. You are answering something, not just making something.
- A genuine computational core. A real algorithm, model, or analysis does the work — not a few lines that print a result.
- A design decision you can justify. You considered more than one approach and can say why you chose yours.
- Evidence that you tested it. You checked your result against something you can trust, not just "it ran."
- The ability to explain it live. You can walk through your own code and answer questions about how and why it works.
- Honesty about its limits. You can say what your work does not do, and why that matters.
The easy way out is to take any problem — including the ones below — and build only the shallow version: the part that runs quickly and looks finished. That shortcut is visible almost immediately, and it is unmistakable in the oral defense, where you have to explain and modify your own code on the spot. A problem is only as serious as what you do with it.
The thing to understand before you start
You are not assessed on how impressive your game looks. You are assessed on the depth of your engagement with the system behind it. A simple game done seriously beats an ambitious one that only half-works, every time.
One standard this pathway is strict about
Your game has to work for someone who is not you. "It works when I play it" proves almost nothing — you know exactly what to type and what to avoid. A game is only real when someone who did not build it can pick it up, and when it survives them doing the unexpected. Testing your game on real players, watching where they get confused or break it, and fixing what you find is not an optional extra here. It is the core of the craft.
Sample problem 1 · Design a system of rules and consequences
A branching game — a text adventure where choices lead to different outcomes — looks simple, and a weak version is. But a real one is a system: choices that carry consequences, a world that remembers what you did, and a structure that can grow without collapsing into a tangle of special cases.
The computational core is state and structure. The interesting question is not "can I print three endings?" but "can I build this so that an earlier choice genuinely changes a later one, and so I can add a new branch without rewriting everything?"
The easy way out
- A handful of hardcoded
if/elsebranches with three endings - Choices that lead nowhere and never affect what comes later
- A game that only works if the player types exactly what you expected, and breaks on anything else
What a serious version demands
- The world represented as data, so it can grow without rewriting the logic
- State that carries forward — earlier choices actually change later outcomes
- Graceful handling of unexpected or invalid input
- Tested on someone who did not build it, and revised based on what confused them
Sample problem 2 · Build the loop that makes a game run
Every game is a loop: read what the player did, update the game state, show the result, repeat — until an exit condition is met. Building this event loop yourself, with genuine state inside it, is the single most important idea in the whole pathway. Everything else is built on top of it.
The core is state management. A loop that just prints a message is not a game. A loop that tracks a position, a score, or progress toward a goal — and enforces the rules of the world as it does — is where a game actually begins.
The easy way out
- A loop that prints a message until you type "exit," with no real state
- No boundaries, and no genuine win or lose condition
- A loop that falls apart the moment the player does something unplanned
What a serious version demands
- A genuine cycle: read input, update state, show the result, repeat
- Real game state that evolves — position, score, progress — with boundaries enforced
- A true win or lose condition, and robustness to bad input
- Code you can explain line by line, because the loop underlies everything else
Sample problem 3 · Make a game that runs in real time
A game like Pong stops waiting for the player and starts running on its own: a ball moves, bounces off walls and paddles, and a computer opponent reacts to it. This is where movement, collision, and a simple opponent AI all have to work together, in real time, without falling apart.
The core is correctness in the details. Games live or die on them — a ball that occasionally passes straight through a paddle is not a small bug, it is a broken game. Getting collision and timing exactly right is the whole challenge.
The easy way out
- A ball that moves but passes straight through the paddles
- Collision that "mostly" works — sometimes the ball tunnels through
- An opponent that does nothing, or one that cheats so it can never lose
What a serious version demands
- Collision detection that is correct and consistent, every time
- A ball that behaves predictably at speed and at the edges
- A computer opponent with real logic you can describe and defend
- A game that still holds together when a real person plays it for a while
Sample problem 4 · Generate a world that is different every time
Procedural generation uses a grid, randomness, and a set of rules to build a world — walls, treasure, a start point — that is never the same twice. It is how games create content without a designer placing every piece by hand. It sounds like it is mostly about randomness. It is actually mostly about rules.
The core is constrained randomness. Anyone can scatter random tiles. The hard part — and the real point — is making sure the random result is always playable: that the player is not boxed in, that the goal can actually be reached, that treasure is not stuck inside a wall.
The easy way out
- Scatter random tiles with no rules governing them
- Produce maps that are unplayable — the player boxed in, no path to the goal
- Never check whether a generated world can actually be completed
What a serious version demands
- Randomness governed by real rules — borders, a valid start point, a reachable goal
- Every generated world genuinely playable, not just different
- A test that proves the player can actually reach the goal
- An honest account of the cases your generator still gets wrong
Choosing your own problem
These four problems span a lot of the pathway: designing a system of rules, building the loop that runs a game, making real-time mechanics work, and generating playable worlds. From here the systems get deeper — smarter computer opponents, pathfinding, simple physics, performance, larger architectures — but the foundations are all here. They are meant to show you the shape of the space, not to fence you into it.
Whatever you build, the approach is the same: design the rules on paper, build a small playable version, put it in front of real players, and change it based on what they actually do. Bring your idea to your teacher, shape it into a real problem, and hold it to the same six standards above — plus the one that never bends in this pathway: it has to work for someone who is not you. A simple game that runs correctly and holds up when a real person plays it is worth far more than an ambitious one that only works when you demonstrate it yourself.