Experiments in Rapid Prototyping, part 1

Experiments in Rapid Prototyping, part 1

This summer, we’re experimenting with rapid prototyping. Every other week, we’re making something: a game, a tool, a website, an object. These might be physical, digital, software, or hardware. For our purposes, what we make is not as important as how we make it: we’re investigating the processes we use when discussing, selecting, planning, and producing these short projects.

There are constraints and limits to committing to a continuous prototyping cycle in parallel with our normal work days. Every other week, we are devoting 3-4 hours/day of time to a small project. Our goal is for each project to always be usable/playable in some fashion at the end of a workday. This summer, because we want to work on a lot of projects to put our processes through their paces, we’re limiting our scope to projects that can be completable within these time limits. We’ll be doing a project every other week through August.


Our Process

Our current process starts the Thursday before a scheduled project week. We meet for a short (1-hour), timeboxed meeting where we first figure out our working schedule for the next week, recap our last project, spend about 30 minutes brainstorming new ideas for our next project, and then decide as a group what we’re working on the next week. With each brainstorm session, we add new ideas to an increasing list of previous ideas. Keeping old ideas has kickstarted our brainstorming process – if we can’t think of anything completely new, we can always riff on an old idea. The old weird or incomplete ideas are mutating into more concrete and understandable ones (but still delightfully weird!)

IMG_1381We’re still developing better methods for deciding which project is worth working on. This summer, our decisions are based on who is available to work on the project that week and the fact that the project must be scoped to just one week. We’ve had a number of ideas so far that really need 3-4 weeks of work in order to fit our vision, so we keep those to the side and try to mine them for simpler, more concrete ideas that are doable in 1 week of development. In the Fall and during the IAP (January) month we’ll likely be increasing the number of weeks we’ll devote to a single project. So far, this has kept up levels of excitement within the lab – there are a number of great ideas that our staff can look forward to working on in the future, but in the meantime, teams can work on smaller projects that will help prepare us for the larger ones.

The development week generally breaks down into 15-20 hours of work, with at least a 1-hour team working session each day. Because of the “always playable/always usable” constraint, the project team is constantly playtesting it. Every change is immediately put into place and tested by the project team. Because not all of our lab staff are working on every project, teams have access to a couple of people in-house who can test the project with fresh eyes. The goal of the team is to have something shippable by Friday, but to not crunch or operate too far outside the allotted hours to work on it (we still have our regular jobs to do!).

The week after the project is spent on reflection and publishing. On Monday, after a weekend’s soak time, the project team meets to postmortem the project and confirm what needs to be created for publishing the project on our website. (Hopefully, we scoped this out the week prior!). That includes writing a blog post, shooting a short demo video, and any kind of marketing materials we might want (photos, screen captures, a logo design, final layout/grammar check for print materials, etc…). Generally only 1 or 2 people are creating these assets, and usually not spending more than 4 hours over the entire week creating it. We then meet again as an entire lab on Thursday, reporting out the highlights of the postmortem. After the meeting, the team demonstrates the prior week’s project to the lab, recording it for the blog post. Publication happens on the Monday of the next project week. For now, that means a simple blog post on our website with links to download or play the project.

As Studio Manager for the MIT Game Lab, Rik Eberhardt spends his days playing Tetris: with people, boxes, tasklists, equipment, and time. When not staring at a spreadsheet trying to fit in another computer purchase, a last minute event budget, or placing undergraduate researchers on a Game Lab project, he's chipping away at spreadsheets on his DS, reproducing pixel-art in Picross and Picross 3D. His favorite moments on the job are working on projects with student workers and having fun social interactions forced on him despite his busy schedule. Contact him about research projects at the MIT Game Lab at gamelab-request@mit.edu