Idea Lab

As we continue to develop the "Playing the News" game, we wanted to share the inside workings of the process. Our partners at the Johnson Simulation Center submitted this report on their production process.

An Overview of the JSC Production Process
This is a short description of the Johnson Simulation Center's production process; that is, how we go about designing and then producing a game. There are two stages to this process, pre-production and production.

Pre-production is a time during which everything about how the game will play and be built is written down on paper. We define the steps as documents that need to be created. These are:
 Gameplay One-Shots
 Gameplay Overview
 Technical Design Document
 Product Backlogs and Release Planning

Gameplay One-Shots
One-Shots are a series of one-page maximum length game designs that we create in order to explore completely different approaches to the current project. The best ideas we may explore in more depth. This is a much better way to approach initial game design than simply moving forward with the first idea to come around. Exploring several different designs allows you to later justify your choices - I.E. "We choose NOT to do this because we explored that idea, and we found that it would not work for X, Y, and Z reasons". These one-shots will often be accompanied by a visual. Once we have a decent pool of ideas the entire team reviews, discusses, and then updates them. A choice is then made on the best design to move forward with.

Gameplay Overview
After a suitable one-shot is picked a gameplay overview is written. The primary purpose of this document is to provide the reader with a clear understanding of how the end product might look and feel from the player's perspective. This is an important document, as it is the basis for the shared project vision between the client and our development team. It should be kept succinct as possible while remaining usefully descriptive. It is important to include graphical storyboards in the Gameplay Overview to provide the reader with visual references on how the game might look. Technical information such as specific programming systems or schedules for production are not included. Before proceeding to the next stage of production, this document must be reviewed and accepted by both the development team and the clients.

Technical Design Document
This is an internal document created for the benefit of the development team. It details all technical requirements for the gameplay systems outlined in the Gameplay Overview. These specific requirements are then separated into different stages of development. The first stage being the bare minimum needed to get a functioning game into a testable state, and then each additional stage bringing additional features and functions into the game until it is complete. Staging the game development like this is important, because it allows the developers to test individual aspects of the game as it is developed and make changes, sometimes drastic, as necessary. Compared to a more traditional development cycle where testing does not occur until the end of the game, when it is sometimes too late to change something that does not add value to the game, this system allows us to catch problems early on and address them while the material is still fresh to us.

Product Backlogs and Release Planning
These are the final stages of pre-production. A product backlog is simply a list of all the features that are present in the game, divided into chunks no larger than two weeks of estimated work. When all backlog items are completed, game development is finished.
The development cycle is broken into releases. These releases are major milestones where the project is turned into a deliverable to prove progress to the client and other stakeholders. Release planning involves deciding what theme each of the releases will be based on (movement, learning objectives, exploration, etc.) and then putting all the backlog listed features related to that theme into that release. Each feature is then given a ballpark estimate on development time, and then added up to provide a time estimate on each release. These estimates (which will change and evolve over the project life cycle) are the basis for planning the project time line.

By Jesse Crafts-Finch, JSC Producer