Final game · Milestone 2 of 7 · Peer evaluation

Digital Prototypes Rubric

Small, separate programs that each test one risky idea before it goes into the game.

1. Game Pitch 2. Digital Prototypes 3. Initial Game Demo 4. Alpha Playtest 5. Beta Playtest 6. Final Game 7. Final Game Video

About this milestone

RememberA prototype tests an idea, demonstrates or perfects a behavior, or builds a well-structured class. Each one should be an isolated, simple program with a precise purpose. Unless there's a specific reason, one prototype should not test several ideas at once.

Expect to see

Each prototype's purpose: the problem it tests
The prototype running
What the team learned, and how it will be used in the game

Not expected yet

The whole game
Final art or audio
Menus, levels or polish

How to score

Enter one whole number for each category, from 5 (best) to 1.
When a category has more than one criterion, weigh them together. If you're unsure, average them and round to the nearest whole number.
The descriptions are anchors, not checklists: pick the column that fits best.
Score what you saw today, not what the team says it will add later.
Most criteria are subjective. Apply your own judgment, but apply it the same way to every team.

Rubric

Criterion	5	4	3	2	1
1. Prototypes test the right problems
RelevanceDo they target the game's real risks?	Each prototype targets a clearly important risk for building this game.	Most prototypes target important risks.	Related to the game, but not clearly the risky parts.	Interesting, but it's unclear how they relate to the game.	Unrelated to the game.
FocusOne idea per prototype, with a stated purpose	Every prototype is a separate program testing one idea, with its purpose stated up front.	Separate and focused; most purposes stated.	Mostly separate; some prototypes mix several ideas.	Several ideas mixed together; purposes unclear.	Everything in one program; no stated purposes.
2. Prototypes show feasibility
The prototypes worked	All prototypes worked as demonstrated.	Most worked; minor glitches.	About half worked correctly.	Most did not work correctly.	Almost none worked.
Results are useful	Clear how every result (and its code) will be used in the game.	Clear for most results.	Most results should be useful, though how is not always clear.	Only some results seem useful.	No connection between the results and the game.
3. Confidence in meeting the deadline
Confidence in meeting the deadlineBased on what you saw today	Very confident the team will finish the game as proposed.	Fairly confident; a few parts still look risky.	Possible with steady work from here on.	Doubtful unless the team reduces its scope.	Not realistic without major changes to the plan.
4. Presentation
Problem and solution	Clear problem, solution demonstrated, and tied back to the game.	Clear problem and solution; link to the game less clear.	I understood the problem and solution, with some sense of how they relate to the game.	Problem, solution and relevance all somewhat unclear.	Unclear what was being tested or why.
OrganizationDemo flow	Well rehearsed and to the point; everything ready to run.	Organized, with minor hiccups.	Mostly organized; some time lost (e.g., searching for files).	Disorganized and hard to follow.	Could not show the work (e.g., builds missing or not running).
Team participationWho presented	Every member presented a substantial part and knew it well.	Every member presented; some parts were uneven.	Most members presented.	Only one or two members presented.	One member did everything; the others did not take part.

Hints on preparation

This is your “proof of concept”! You demo, we watch. You need to prove your game is doable: find and solve your own problems.

Examples (all the final games are here)

FourStick (final game: ByeByePillow: Crystal Realm)
- Like: an easy demo of all the prototypes
Other good examples:
- Escape (final game: Project Sloth: Epoch Escape)
- DualShot (final game: The Psychobots: Dual Shot)

Important

All the examples test very simple, yet important, technical points.
They use simple testing environments.
Keep it simple → encapsulate into separate classes for later use in the game.

The prototype zips are Windows builds (.exe).