You can see that I have plenty of experience as a biochemist, as a game developer and as an evaluator of learning (research page). It is important to work with a team that has experience. It took me several years to build the team I have now. It also took several years to design, build, test and iterate on Immune Defense. Iteration is the important part and it is also the time consuming part. So I want to share another important aspect of science game development that I have learned over these years: How to iterate in a way that gets maximal input from a wide range of participants.
Above is the Molecular Jig Games Iteration Cycle. This is our production schedule template. This is a really useful reference for creating a schedule. “Rapid Iteration” is important so that our game development always reflects what our audience enjoys. We need to show the game to our audience often. However, we have a second goal and that is to ensure that our game development also reflects what is real. So we need to be sure that scientists and teachers can participate in our iteration cycle. Getting scientists and teachers to be a part of development process lets us check each round of iteration before we spend any time developing it.
The first step of the process is at the top: Choosing a game mechanism that matches what we want to teach. As I discussed several years ago, Soren Johnson gave a great talk at GDC Serious Games Summit about how the Theme and the Meaning of your game are not the same. Meaning is what you learn… Meaning is “the moral of the story.” If you make a game in which players play checkers with water molecules instead of checkers, your players will learn checkers. But if you make a game in which your players can bind some of their checkers/molecules together if their binding sites match, then your player learns that molecules have binding sites that need to match. Gathering your whole team, scientists, game designer, game developer and producer together for this initial discussion is important. In person brainstorming, open and honest question asking from all parties, expertise sharing and mocking up paper prototypes/white board sketches are vital. Scientists can provide an immense amount of really great mechanics that a game developer would never come up with on their own: scientists live in a whole different world… a world of genetics or of biochemistry or of molecular ecology … The game developer can ask “what agency will the player have in this world?” Teachers remind us which standards they need to teach and which misconceptions they fight against. The producer is necessary to remind everyone we have a chosen audience and a budget.
After the initial brain storming sessions, each full cycle takes some time, and to estimate that time, we start estimate the time for each of the three sections Development, Testing and Discussion. Naturally, paper prototyping is faster, but testing and discussion can still take weeks. This method of estimation helps us stay on budget, of course. This also helps us keep a large number of people involved in the process. Letting our collaborators know when we expect to be ready and how soon we need their feedback is important. Most of our collaborators also do not have time to play the game. Rather, I need to schedule time to write an email with specific questions, record a game play video or chat on the phone with experts. Given how much communication must occur, and how disparate the expertise areas of the various parties are, facilitating communication is vital to making a rich science game experience.
This vital aspect of science game development, involving the scientists and teachers, and an audience that may not include ourselves can be difficult because it requires us to involve more people than a game studio usually involves. It requires us to involve non-developers, non-gamers and non-audience members in the development process. Some of the problems that exist are that our extended team does not have time to play the game, may not understand why we changed things, may not understand why this whole process takes so long. This schedule is my best answer to these issues. This schedule allows us to be predictable and to demonstrate our goals to our extended team in a clear way.
“Checking” our design for whether it is real is only part of the reason we want to show our under-development designs to scientists. Scientists also add detail, mechanic and strategy to our design. If you are making a game about the cell surface, then talking to an expert on lipids and their interactions with each other is invaluable. Imagine you are creating a game about Star Wars and you have a chance to talk to someone who grew up on Tattooine! Imagine the cool details you can add to your design after talking to someone who knows what a parsec is.
Our iterative development schedule is invaluable to maintaining a science game development studio. I hope you find it useful.
