• If you are citizen of an European Union member nation, you may not use this service unless you are at least 16 years old.

  • You already know Dokkio is an AI-powered assistant to organize & manage your digital files & messages. Very soon, Dokkio will support Outlook as well as One Drive. Check it out today!



Page history last edited by Rafael Fajardo 8 years, 1 month ago

Rapid Physical Game Design & Prototyping (2016 03)



We will meet in conjunction with Programming for Play, and participants are expected to be enrolled in both experiences.
We will convene Tuesdays and Fridays from 9:00 am - 12:00 pm and 1:00 pm - 4:00 pm, inclusive of both class times.
Participants will engage in collaborative design and development for both experiences.



  • To explore the creation of games through rapid experimentation.
  • To prototype 5 games in 6 weeks. Players will make a new game each week for the first 6 weeks of the course. Each new game will be made in response to formal and conceptual parameters or challenges as detailed below.
  • To prototype a 6th game during the remaining 4 weeks of class. This game will be of greater ambition, depth, and complexity.
  • To combine and recombine in collaborations to create these game prototypes.
  • To explore and learn about how to be an effective and productive collaborator through experimentation and guidance by instructors.
  • To document and disseminate our observations and games through this wiki. Each player will document their games by uploading their rule sets and material specifications to pages that link off of their respective Participants pages. Each Player is charged with becoming a reflective player. Players should record their observations and comments on games they have played inside and outside of the lab and then share these observations verbally and online through the comments capability of the wiki. It is the responsibility of each respective Player to document the feedback they receive and include it on the page for their game(s).
  • a more granular list of Learning Objectives is being compiled.


Methods and Assessment

  1. Games are experiential in nature and can only be assessed by and through play.
    1. Players will gather in the lab for collaborative playtest and assessment twice a week.
    2. Designers are not allowed to play their own game for purposes of assessment.
  2. Game Designers agree to be listed on the Participants page.
    1. Game Designers agree to combine and recombine into productive collaborative groups with other participating designers.
    2. Together we are collaboratively co-creating the experience of this class, in effect playing the Lets Make Lots of Games game.
    3. We will engage in collaborative design & development
    4. We will combine and recombine collaborative groupings with each of the first five challenges/projects
  3. Game Designers agree to be open to constructive comments and critiques by the other participating designers.
  4. All participants agree that constructive comments and critiques are meant to:
    1. help improve the gameplay of a designer's game,
    2. share a player's reflections of gameplay and engagement,
    3. contribute to the building of critical vocabularies for game design.
  5. Game names and rules remain the property of the their respective participating designers who are the definitive arbiter of those rules.
  6. participating game designers agree to allow us to publish their games and rules on TakeTurns wiki and will receive proper credit for their creations.
  7. Players will play reflectively
  8. Players will be assumed to be playing to win, unless they proclaim their intention to do otherwise
  9. Non-players will actively observe games as they are played
  10. Players and non-players will offer observations and constructive critiques to the designers
  11. Role(s) of the player:
    1. play to win
    2. play to draw
    3. play to lose
    4. play to spoil
    5. play "against the text"
    6. all these imply an ethic of competition
  12. Players agree to document the composition of their collaborative groups and to credit their playtesters via the online Collaboration Matrix (read only version to be added)
  13. Players agree to document and assess the efforts of their collaborators anonymously via the online Collaboration Peer Review
  14. Players agree to collaborate with no fewer than five other Players by week six



  • there exist two primary levels of difficulty for a designer:
    1. is it fun for me?
    2. is it fun for someone else?
      • the latter is particularly hard for a designer to achieve, even within the industry
  • there are imperfect ways to measure "goodness" in game design:
    1. willingness of someone to play through to the end
    2. willingness of someone to play again
    3. willingness of someone to introduce the game to someone else
  • there exists room to improve on these



  1. Yourself
  2. game bits/tokens/props of sundry shapes and sizes (many will be provided)
  3. Your laptop equipped with appropriate game making software (most likely Unity 3D)



  1. on collaboration
    1. After years of intensive analysis, Google discovers the key to good teamwork is being nice (Quartz)
    2. What Google Learned From Its Quest to Build the Perfect Team:
      New research reveals surprising truths about why some work groups thrive and others falter (NY Times)
    3. Google's unwritten rule for successful teams (Medium, The Future of Work expands the circle of communication)
    4. Why Collaboration Is Hard And How We Used It To Make “Big Hero 6” (Medium)
    5. Together We Are Mega: The Collaborative Future of Indie Game Development (Gamasutra)
    6. No Dickheads: A Guide To Building Happy, Healthy, and Creative Teams (Medium)
    7. Group Projects and the Secretary Effect (The Atlantic)
  2. on rapid prototyping of games
    1. Ian Schreiber Talks Design, Rapid Prototyping, and Game Balance (Games & Meaningful Play)
    2. Herman Tulleken on Rapid Game Prototyping: Tips for Programmers (Gamasutra)
    3. Kyle Gabler et al on How to Prototype a Game in Under 7 Days (Gamasutra)
    4. Chaim Gingold on Catastrophic Prototyping (notes from working on Spore)
  3. on physical games (or big games)
    1. Oh Heck Yeah!
    2. Pac Manhattan
    3. IndieCade Big Games
    4. Oh Heck Yeah! on GitHub
  4. on mechanics
    1. Robin Hunicke, Marc LeBlanc, & Robert Zubek wrote an essay in which they propose a Framework based on Mechanics Dynamics & Aesthetics
    2. Dan Cook wrote an essay in 2013 on Game Mechanics at his blog Lost Garden
    3. Chris Crawford wrote that Mechanics are Verbs in his book The Art of Game Design
    4. Miguel Sicart wrote an essay Defining Game Mechanics
  5. on the cultures of rigor and of playfulness
    1. Bernie DeKoven on Sport versus Play
    2. Calvinball from Calvin and Hobbes by Bill Watterson
    3. George Carlin on Football and Baseball
    4. Bernie DeKoven on the Politics of Public Playfulness
  6. other important links
    1. Rafael's Bibliography for Rapid Physical Game Design & Prototyping 
    2. Various authors’ thoughts on the craft of writing rules for games
    3. Steamboat Willie 
    4. Don't Taunt the Happy Fun Ball (SNL parody commercial on YouTube), WikiPedia entry, SNL transcripts


Challenges for 2016 03 (these may evolve as we proceed)

Formal constraints are traction — Bill Depper

  1. Form a collaborative group of three (3) people.
    Create a game for two bodies in a single, non-aggressive and dynamic, mechanic,
    within a spatial envelope of 8 x 8 x 8 feet. All gameplay should be completed within 5 minutes.
  2. Form a six (6) or seven (7) person collaborative group. Create a game that involves four (4) humans interacting and moving through space and playing within an 8 x 8 x 8 foot bounding cube. Gameplay may involve no more than two (2) props of the same kind, but which cannot be the object or goal of the game. The goal should involve two or more players in a collaboration. The game should be self-evaluating, that is to say it should require no referee to judge end states. The temporal envelope should be carved into 30-second increments/events.TBA
  3. Form a two (2) or three (3) person collaborative  group. Create a game that involves five (5) bodies/players, all with equivalent roles, all interacting within a 16' long x 16' wide x 8' high maximum spatial envelope. Gameplay should be accessible by all body-types and all abilities. Gameplay may involve a number of props — limited only by practicality — of no more than two (2) kinds. The maximum temporal envelope will be 15 minutes for a game to play to completion. The game should be easy to learn but difficult to master. The time envelope for learning the game should be no longer than 5 minutes and can exist outside of the gameplay time envelope.
  4. Form a collaborative group of six (6) or seven (7). Design an eight player game that will take place in two non-contiguous spaces of 8' x 16' x 8' each. Line of sight between the two spaces is optional. Players must remain within the space where they begin the game for the entire run of play. Two (2) non-player runners can be enlisted to communicate between the spaces. Gameplay must be continuous, simultaneous (not turn-based). The activities in each space must affect or influence each other. Props may not be used as projectiles, nor as semaphores. The temporal envelope for setup, play, teardown, and reset of the space cannot exceed 45 minutes.
  5. Final Challenge:
    1. This is a combined challenge that spans
      Programming for Play and
      Rapid Physical Game Design & Prototyping.
    2. Team Formation: Collaborative groups of 4 will be formed through a silent draft process coordinated by the game masters, Depper and Fajardo. Three “pickers” will be chosen by the game masters, after which a private selection/drafting process will occur. A period of seven calendar days will be allowed for any trades of personnel, if necessary. Trades should be seen as an exception, and not as a given. All trades must be approved by the game masters. Teams should be balanced for the skills of programming, design, and art.
    3. The Conceptual Constraint: games created must engage either the theme of "unify/divide" or the theme of "tendril/tentacle". This engagement must be expressed overtly and palpably. Some prompts that might help us might be: how are the themes enacted or made real in the gameplay? is it possible that you are too literal? is it possible that you are not sufficiently literal? what verbs would reflect the theme? are there metaphors that are useful or related to the themes that you can employ? here is a test that could be used to measure the integration of the theme: if you altered or removed a portion or a piece of the mechanic would you severely impact -- in effect sever -- the connection between gameplay and the theme? if so, then you have managed to integrate well. if not, then you have not managed to integrate the theme.
    4. The Formal Constraints:
      1. Games must employ the Kinect sensor and a large-scale projection in ways that are responsive to bodies moving in space.
      2. Games must involve at least three (3) players.
      3. Gameplay must be simultaneous, but may have rhythmic intervals.
      4. Games must run without errors for the final presentation.
      5. Games must honor a 45 minute temporal envelope, inclusive of setup, gameplay, teardown, and reset of the play space.
      6. Games must have a minimum spatial envelope of 16’ on one side x 8’ tall to accommodate the projection screen. Additional spaces can be used, whether contiguous or non-contiguous.
      7. Games must be programmed for 2D, or 2.5D spatial projection.
      8. Games must be programmed to employ the Unity platform for gameplay. They may make use of supplemental libraries and environments.
      9. Games must employ at least 2 networked machines using OSC.
    5. Diversifiers (must use at least 2 from the following):
      1. Gone Orthogonal: Meaningfully making use of both themes
      2. Bit Shifter: Electronic wireless networking of non-contiguous spaces
      3. Untethered Control: Meaningfully makes use of wireless controllers, or portable wireless control surfaces such as Wiimotes, PS3 controllers, Wireless XBOX360 controllers, or tablet-based controls
      4. Flipping the bird: Use of Twitter Library, or other social libraries, for spectator participation for either judging or for altering the game experience (e.g. change level based on hash-tag)
      5. Studio54: Ambient lighting shift using the DMX protocols
      6. All For One & One For All: everyone together against a system
      7. Atlas Shrugs - every person for themselves: there can be no (NO) alliances, not even fleeting ones
    6. Penalities:
      1. A penalty will be assessed for disintegration of collaborative group. Play nice, share your toys.
      2. A penalty will be assessed for game mechanics that too closely mimic a known game.
      3. A penalty will be assessed for not meeting the formal constraints.
      4. A penalty will be assessed for not meeting the conceptual constraint. 
    7. Groups: the "pickers" are Hanna, Brock, and Jeremy
      1. team working title "red"
        1. Alex
        2. Brock
        3. Hannah T.
        4. Richard
      2. team working title "green"
        1. Ben
        2. Jeremy
        3. Quincie
        4. Tommy
      3. team working title "blue"
        1. Hanna P.
        2. Jeff
        3. Julia
        4. Kelia
        5. Stone
  6. TBA


Additional Challenge for Graduate Students

Graduate students enrolled are required to complete an additional challenge. They must read and lead a seminar session one or more of the following:

  1. TBA
  2. TBA

Comments (0)

You don't have permission to comment on this page.