Under the Hood: Rapid Gameplay Prototyping

Paper prototyping is great for designing games. But what do you do when you want to try out a multiplayer game idea too fast paced for a human game master? Recently we used HTML5 + Firebase and Google spreadsheets to develop play-testable mockups of the UI and mechanics of a multiplayer game—all in a few short days.

Our new Learning Everywhere initiative is developing exhibits and mobile learning experiences that provide trackable, coordinated learning opportunities around the topic of energy, including renewable energy, energy efficiency and the use of natural resources. The goal is to create activities and exhibits that adapt flexibly to different learning settings—from school to home, after school and museum—for extended learning opportunities. We are currently prototyping and testing a variety of hands-on and virtual activities.

One quick way to try out different ideas is to develop paper prototypes, so we created a variety of games using cards and tokens. We settled on the idea of a fast-paced cooperative game in which communication is key—players talk to each other to send and receive electrical power from their cities. (We were inspired by Spaceteam.) Each player’s power demand as well as their wind, solar and fossil fuel-based power supplies fluctuate over the course of the game.

With real players we could test our ideas about how to make sharing energy not only challenging but fun. However, we quickly reached the limits of paper prototyping. When we had to manually change everybody’s paper “screen” to simulate game play, it was impossible to tell when we got the pace and flow right. We needed computer-based mockups that could be modified quickly and easily—and support multiple players.

One approach was to mock up the user experience in a mobile webapp deployed to GitHub Pages, a simple (and free) static hosting service. Each player’s client pushed data to the others by using Firebase, a real-time database service. This meant we could create a multiplayer game in HTML5 without needing to write and deploy a server, allowing us to focus on the game experience alone.

A complementary approach exploited Google spreadsheets’ inherent multi-user capabilities to model the game mechanic. Players were each given access to one sheet, which was connected to master sheets and the other players’ sheets by formulas. These accounted for the supply, demand and power sharing between players at any moment in game time. To make the game automatically advance at a steady clip we wrote a small Google Apps Script, which runs on Google servers and is able to read and write to spreadsheet cells.

Teachers in a KidWind Senators workshop play-tested this version, and although they could only type numbers into a grid, we could tell from their laughter that they enjoyed the challenge of keeping their cities from blacking out. We knew we were on the right track, and have merged the spreadsheet game mechanic into the web-based game. We’re now working with FableVision to add some fun artwork. An alpha version should be available soon.

Sam Fentress (sfentress@concord.org) is a software developer.
Richard Klancer (rklancer@concord.org) is a software developer.

This material is based upon work supported by the William K. Bowes, Jr. Foundation.