Games that matter

Which topics carry a game

Not every subject survives being turned into a game. A topic carries a game when its central tension can become something a player does: a choice with a cost, a resource running out, a relationship that shifts depending on what you decide. A broad theme, such as 'the environment' or 'the past', doesn't do this by itself. It needs narrowing to one specific situation with a decision inside it before a mechanic has anything to attach to.

Difficult subjects, disasters, illness, war, displacement, are not off limits, and some of the most serious student work takes them on rather than avoiding them. What they demand is more design care than a lighter topic would. The question is not whether a topic is heavy, but whether the mechanic treats it honestly.

What a mechanic says, whether you meant it or not

This is the part of the module worth taking seriously. A mechanic is not neutral scaffolding around a topic. It makes a claim about that topic, whether the designer meant to make one or not. A timer says the subject is fundamentally about speed. A points tally says it is about winning and losing. A fail state that sends the player back to the start says failure is a private mistake rather than something that can happen to anyone.

Take a hypothetical example, easier to see worked through than described in the abstract. A student sets out to make a game about a family fleeing a warzone, and builds the fleeing itself as an obstacle course: jump the gap, dodge the checkpoint, collect enough supplies to reach the border before a timer runs out. Nothing about that design is malicious. But the obstacle-course mechanic says something specific about fleeing conflict: that it is a test of individual skill, that trying hard enough gets you through, that the people who don't make it failed the level rather than ran out of luck. That is not what fleeing a warzone is like, and a player who has never thought about it will absorb that claim from the mechanic, not from anything the game says out loud.

The fix is not to drop the topic. It is to ask, before building, what the mechanic itself teaches, separately from whatever the game's text or ending screen claims to be about. A resource that runs out regardless of skill, a route shaped by factors the player cannot control, an ending that is neither a clean win nor a clean loss: these say something closer to the truth. The mechanic is the argument. The text on screen is only commentary on it.

Questions worth asking before you build anything

Worth putting to the group before a single mechanic gets built, not after:

• What is this game actually about, in one sentence?
• If someone who lived through this saw your mechanic, would they recognise what it says about it?
• Does anyone earn points or a win state for something that shouldn't earn one?
• What does losing mean here, and does that match what losing means in the real situation?
• Who is this for, and will they understand what you meant without you standing next to them?

Showing the work

A game that stays inside the classroom only has to satisfy the person who made it and the teacher grading it, which is a low bar for a topic serious enough to justify this module. The point of the final step is to put the game in front of someone with no stake in the assignment, a relative, another class, a small public audience, and watch what they actually take from it.

That reaction is the real feedback. If a stranger comes away with a message the maker didn't intend, the mechanic said something the text didn't account for, and it is worth revising before calling the project finished. Publishing the work, even in a small way, is what turns this from an exercise into the kind of decision the rest of the module has been building towards.