Paper Prototyping Game Jam

Today (Wednesday) was the last day of orientation for the students at the GAMBIT Game Lab, and the first day of design work.

Students have had a brief presentation from their researcher / product owners about the project and were given a small set of constraints within which to create prototypes. Two 2-hour game jams were held followed up by play-testing.

A brief lecture on paper prototyping was delivered by Philip Tan, the executive director. I am reproducing a great deal of the slides here because I feel the presentation really outlined the purpose and a methodology for carrying out paper prototypes. The purpose in this case is less about working out issues with the as yet not understood game, and much more about working with each other and finding a useful model for expressing and testing ideas.

I have reproduced the text from Philip’s slides (with permission) and added some small editorial based on his descriptions:

Prototype a single small constraint and a single small mechanic. This will both be manageable in a quick game and permit you to actually play that aspect of the game with live people.

Make sure you have at least as many developers as players in a game. Use 2-3 people (or 3-4).

Include no more than 15 minutes of brainstorming, the activity is about doing more-so than thinking about doing.

Why do paper prototyping?
– to get feedback earlier, it’s cheaper
– to experiment with alternatives
– it is easier to change, throw away ideas and mechanisms

Be promiscuous with your ideas, these have to be remade to be included in final game. Get use to throwing away ideas – it is likely nothing from a quick game jam will make it into the final product, this is as much about working process as it is about testing and refining ideas as it is about working out a mechanism.

Play around with concepts – add, subtract, get ideas out, get ideas worked on.

Goal: find the fun for the player, by having players play the game, revise and refine on the fly to improve the fun.

You cannot do anything substantial, test a mechanic.

Focus on small handful of choices, create an actual thing you/others can play.

Prototyping gets the team on same page, nothing needs to remain in the game, this is based on teamwork, you create a framework / common ground / shared experience.

The prototype is a form of communication with product owner as well which shows your understanding and direction in the project. It brings in other people, not in team to consider ideas.

Paper prototyping is INTERACTIVE, your game is going to be interactive, so take advantage of this and play parts of the game.

A progression of prototypes shows the developments and thought processes so document each prototype.

Useful tools: big sheets of paper, index cards, dice, post-it glue, pencils, pens, markers, scissors, tape, game bits, small toys, kindergarten counters, photocopier, phone camera.

Keep it rough – keep people away from focusing on the quality of fabrication, keep focus on rules and playability.

– hand drawn
– sketchy
– big
– one dark ink

Keep iterating – try things, talk less about the choices, revise when you find an issue, remember things what are working, keep an eye out for emergent dynamics.

– rapid design
– play-test
– revise
– repeat

Keep track of Rules

– write on index cards
– rearrange flow control
– update cards as you change rules
– periodically take photos
– simplify,  simplify, simplify, – work on a small subset

Keep changing – large changes show more within the prototype (strategies)

– amend, replace, kill
– limit/unlimit
– player interference
– mess wit play order
– multiply / divide by 2
– strip and reconstruct
– throw away

Players, People play together
– cooperative/competitive
– symmetric/asymmetric

Very Loose
– open communication
– rule negotiation
Facilitator helps explain rules

Wizard of Oz
– someone plays “computer”
Very constrained
– communication
– rules
Don’t let the player know what the “computer” is thinking

There were some wonderfully diverse concepts and game styles that came out of this. Many of the games were hard to play all the way through, but I managed to participate in about 3 or 4 play-tests.

As a teacher it is hard to look at this and not think of the 50 or so students as members of a class and to imagine how this series of 2 hour game jams could be incorporated.  I was surprised to also find that this was the first time that the itinerary had been sequenced so that the participants learned a little about their research question, made a few prototype games, and then the next day learned more about the research in depth. I have to remember to find out what, if any, effect this had on the student understanding of the problem.  I had heard mixed comments from product owners, but even the one that I heard who was uncertain of the value of the exercise ended up with a group learning something just because they put a game under the nose of living, actual people.

I am rapidly falling behind in my note taking, so no polish for this post (my apologies).

Here are some links on rapid prototyping from a week to a day to a few hours, and some references for the presentation:

http://www.kloonigames.com/blog/general/articles-about-rapid-game-prototyping

http://www.kloonigames.com/blog/general/another-bunch-of-articles-about-rapid-game-prototyping

http://ocw.mit.edu/courses/electrical-engineering-and-computer-science/6-831-user-interface-design-and-implementation-fall-2004/

http://www.amazon.com/Game-Design-Workshop-Second-Edition/dp/0240809742/ref=sr_1_1?s=books&ie=UTF8&qid=1339703030&sr=1-1

http://www.amazon.com/Challenges-Game-Designers-Brenda-Brathwaite/dp/158450580X/ref=sr_1_1?ie=UTF8&qid=1339703001&sr=8-1

Advertisements