Rubric Maker

Game Design Project Rubric Template

A ready-to-use, analytic game design project rubric for Game design project — designing, prototyping, and playtesting an original game (Grades 5–12). Score whether the game is actually playable by someone other than its designer and got better through playtesting — not whether the theme and artwork sound appealing on paper. Edit it for your own assignment, print it, download it as a Word file, or share a link with your students.

Edit this template in the maker →

The game design project rubric

CriterionExcellent (4)Proficient (3)Developing (2)Beginning (1)
Rules & objective clarityWritten rules state the objective, setup, turn order, legal moves, and end condition, and a group who has never seen the game can start playing from them without asking the designer a question.Written rules cover objective, setup, and turn order, but new players need one or two clarifying questions (usually an edge case or how the game ends) before play runs smoothly.Rules explain the general idea and how a turn works, but leave out the end condition or enough of the legal moves that players have to invent answers as they go.Rules are a list of components or a description of the theme; new players cannot determine what they are trying to do or how a turn works.
Core mechanics & meaningful choicesOn most turns a player picks between at least two options with different consequences, and the choice can be reasoned about (a trade-off between speed and safety, resources and position) rather than guessed.Players make real choices, but one option is usually the obvious best play, so decisions become routine after the first few turns.Choices exist only occasionally; most turns are determined by a die roll, card draw, or fixed sequence with no decision attached.The game has no player decisions — outcomes are entirely determined by chance or by following a set path from start to finish.
Balance & difficulty pacingNo single strategy or starting position reliably wins, trailing players still have a plausible path back, and the game reaches its end condition close to the intended playing time.The game is broadly fair, but one strategy or position is noticeably stronger, or the ending drags a few turns past the point where the winner is decided.One strategy or player position wins most of the time, or the game ends far too quickly or too slowly compared to the intended playing time.The game is unwinnable, unlosable, or ends at an arbitrary point — no working end condition or any sense of a fair contest.
Playtesting & iterationDocuments at least two playtests with other people, names specific problems observed (a stalled turn, a dominant strategy, a confusing rule), and shows the rule changes made in response to each.Documents playtesting with other people and names problems observed, but only some of them led to a rule change, or the changes are described without saying what problem they fixed.States that the game was playtested without describing what went wrong or what changed as a result.No evidence of playtesting with anyone else — the rules as submitted are the first and only version.
Components & presentationAll components needed for play are present, clearly labeled, and readable at arm's length; a player can tell at a glance whose pieces are whose and what each card or space does.Components are complete and usable, but one element needs a second look to interpret (small text, similar colors, an unlabeled space).Components are incomplete or hard to use during play — missing pieces are substituted on the fly, or labels have to be explained each time they come up.Components are missing or unusable, so the game cannot be played as designed without the designer supplying the missing parts verbally.

Four levels — Excellent (4) to Beginning (1). Print this page, or open it in the editor to change the wording, levels, or points.

How to use this rubric

The most common way a game design project gets graded wrong is by rewarding the pitch — a great theme, neat artwork, an ambitious concept — when the game itself has never been played by anyone but its designer. This rubric puts rules clarity and playtesting first, because those are what turn a concept into a game someone else can actually play, and a beautifully illustrated board with unplayable rules should not outscore a plain index-card prototype that works and got fixed twice.

Why these criteria

Each row targets something the assignment is really teaching, with descriptors written to be observable rather than vague:

Rules & objective clarity
A game only exists once someone else can play it — this row checks whether a stranger could sit down with the written rules and start playing without the designer in the room.
Core mechanics & meaningful choices
Separates a designed game from a race decided entirely by dice — this row asks whether the player's decisions actually change what happens.
Balance & difficulty pacing
A game that one player wins by turn three, or that drags long after the winner is obvious, fails as a game no matter how good the concept is.
Playtesting & iteration
Game design is a process of watching real people play and fixing what broke — this row checks that happened rather than the rules being written once and handed in.
Components & presentation
Board, cards, and tokens are the interface players use — this row grades whether they support play, not how decorative they are.

How to adapt it

Frequently asked questions

How is this different from a coding project rubric?
A coding project rubric grades the code — structure, correctness, whether the program does what it claims. This one grades the design: rules, choices, balance, and whether playtesting changed anything. If students are coding a game, use both — this rubric for the game as an experience, the coding project rubric for the implementation behind it.
Do students need finished artwork for a good grade?
No. 'Components & presentation' asks whether pieces are complete, labeled, and readable during play — hand-drawn cards on index cards can score at the top level. Polished art with unreadable labels or missing pieces scores lower, because the row is about usability at the table, not illustration quality.
How many playtests should be required?
Two with people outside the design team is a workable minimum, and that's the standard the top level of 'Playtesting & iteration' describes. The point is not the count but the loop: play, notice a specific problem, change a rule, play again. One thorough playtest that produced three documented fixes beats four sessions with nothing recorded.
Can this be used for a group game design project?
Yes — add a note requiring each member to name which rules or components they personally designed and which playtest problems they fixed. Keep 'Rules & objective clarity' scored on the team's single rulebook, since that's a shared artifact that either works for a new player or doesn't.

More rubric templates