Digital Game Physical Prototype - Writeup

This assignment is due on Friday 5/11.

In class we will be making physical prototypes of our digital games. This will include a few days for construction, time for testing and refinement, then playtesting each other’s prototypes.

Physical Prototype

The idea behind physical prototyping is to:

  1. Start reasoning about tangible aspects of your game. Instead of saying that you will have e.g. enemies that inhibit the player, you must come up with examples of enemies you will have and how they will inhibit the player.
  2. Create the cheapest possible model that can inform your development process. Even if your game’s genre and medium is well known, (e.g. if you have 2D side-scrolling game) you still need to make decisions about player controls and camera movement. You can use the prototype to consider these (and other!) aspects before you sink time into the software prototype.
  3. Rapidly iterate on game features and rules. Let’s say you plan to have many features in your game including mines that detonate and hurt the player. Without a physical prototype, your game must be mostly developed before you can start experiencing how these features affect gameplay. If you decide that the mines are more of a nuisance than a fun game feature after playing your software prototype, you have already paid the development time cost for this feature. The most important thing to do with your prototype is add and remove game features, even if they are essential to your vision, so that you can evaluate what they add to the experience.

I do want to see some iteration in your design. This means adding features, trying them out, then removing them and trying different features. If your game has levels, you can do this by making different levels that utilize different features.

Inexact Representation

Your physical prototype doesn’t have to perfectly represent all the aspects of your game. Many video games are played in real-time, but it can be difficult to simulate this physically when the game level becomes complex. Making a turn-based version of your real-time game makes it a lot easier to implement your game rules while still allowing you to reason about the mechanics of your real-time game.

The same rule applies to dimensionality - it can be hard to represent a 3D game using a physical prototype. It may be worthwhile to prototype a 2D version.

I want each team to submit a writeup describing their physical prototype and the construction process. I’m looking for at least a few pages here. Be descriptive!


Points Content

List of player experience goals for your digital game (see p. 10-11 in the book)


Description of prototype construction.

  • List of materials
  • Description of your construction - what pieces did you use to represent your game, and what did that representation look like.

Description of foundational rules

  • Turn-based or how does timing work?
  • How does movement work?
  • If dice or other random mechanics come into play, how are they used?

Features/rules and Iteration

  • For each rule: explain the rule, how it worked when you tried it, and whether you decided to keep it.
  • Examples of how iteration was applied
    • I really want to see a solid explanation of how you iterated on your design.

Playtesting results

  • Include thoughts on playtesting both in and outside of team
  • Anything that was confusing to players?
  • If your playtesters were confused about an aspect of your prototype that shouldn’t be an issue with the software prototype, still point it out.
  • Gameplay aspects that will transfer well to the final game
  • Gameplay aspects that are specific to the physical prototype

Formatting and spelling

  • No, or few, spelling, grammar, mistakes
  • Clear use of structure like section headings, lists, paragraphs
  • No walls of text


I recommend using Google Docs or a similar platform so that everyone on the team can contribute easily.

Please send your writeup to me via email, or give me read access (share it) if it’s on a platform like Google Docs. Plain text, an attachment, or a link to the document are all fine.