Today I finally had a chance to work closely with Jesse, the producer/game designer at the Johnson Simulation Center. We made a list of the game concepts we talked about and we each picked 3 or 4 designs. We then wrote a short one page design document about the purpose of the game itself, a short summary of how the game works, the learning objective implementation, difficulty/content complexity, how to engage the player and what challenges the game offers.

After writing about 7 documents we then exchanged designs and critiqued each other's ideas. We also did some testing with one of the design ideas. My idea was to create a clone of the notorious racing game Pole Position and post the issues related information on billboards on the side of the track. Jesse wanted to test if this was a good idea so he wrote a sentence like "cats have more dander than dogs" on a A4 white sheet of paper. Then we went out and he held the sheet while I was running towards him to simulate the effect of a car moving towards a billboard. I also limited my field of vision by putting my hands on my temples.

I had to slow down almost to walking pace to read the sign. But I think the sign should have been bigger and bold. The test was somewhat helpful but needs further testing. The next step is to decide which of the designs we want to actually put in a digital format. We already have a working Arkanoid-clone prototype.

For the kind of tool we want to produce we are struggling with creating a game whose mechanics teach effectively and is also general enough to allow a newsroom to adapt it to a great range of different topics and use the same tools. Feeding text and then throwing in a random game, any sort of game, is not the answer, and it is where a lot of educational games fail.

From my personal experience, a lot of games taught me several things, like rules in a sport and English among other things, but those games were made with the objective of entertaining and not teaching or educating. The challenge is how to combine both aspects. There is a game called Typing of The Dead. Instead of shooting to kill the zombies, you need to type as fast as you can. Isn't this a neat idea for how to teach people to type faster or better?! It has to be intrinsic to the game, and in order to do that the game design needs be tailored to a specific set of information or topic, otherwise it is not that effective or precise.

Now what we can do is create a few different tools to give to the newsroom: one could be mini-games with integrated information (what we are currently working on), and another idea is coming along. From now on I think we should keep our feet on the ground so we don't get too disappointed. It's a hard challenge, we are working on it..."

Fabio Berzaghi

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

For example, a news game might create an environment where the reader is exploring the different aspects of the use of ethanol fuel. The player moves from one NPC to another to talk about the pros and cons. But before the player can talk to each of the NPCs, he or she will have to successfully complete a mini-game as an incentive to move on.

Our top-notch graduate research assistant Fabio Berzaghi and Johnson Simulation Center game designer Jesse Crafts-Finch met recently to talk about their ideas and Fabio provided this update:

Thursday March 20th

Jesse from Johnson Simulation Center and I got together few days ago to figure out new ideas that could work for the mini-games plan. The basic idea is to have games that can have contents embedded into them in an easy way.

Generally we thought about text-based content, -- we haven't considered pictures or video because they can be inconsistent, since the newsroom has to deal with resolution, formats and re-sizing. We think that some game concepts like: Qix (an old arcade, ported to consoles, with the info hiding behind the uncovered parts of the screen), Pole Position (with the info on the billboards), Space Invaders (with the text behind the enemy's ships), checkers might work. Just to name a few.

The next step is actually trying to play through some of these games with just a paper and pen prototype and see which ones will make it to the electronic prototype. As we go along in the project I find it harder to find a game concept that can be challenging and interesting for the player and easy to build for the newsroom. In a generalized framework, in which it is easy to plug in information based on the theme/topic, it is hard to create a unique experience. We would either fall into redundancy or extreme complexity of the tools used by the newsroom, which doesn't want to spend too much time coding or building the game. So the main struggle is where to draw the line between possible customizations and ease of tailoring such a broad range of topics.

Another problem that we probably haven't considered until lately is how to deal with some serious issues that might be the topic of news coverage, for example the death penalty or abortion, in a game context. If the game is too frivolous, could it be used for such issues? Or would it be inappropriate? Or is there a game concept that could be used for such serious issues and be respectful and appropriate at the same time?

A thought I had is that maybe certain issues need a different game frame to educate people. But to me games are associated with entertainment, so if they don't do their job then it could just be a newspaper I am reading. Maybe games could be used to make something less dramatic.

Along with trying to envision how can mini-games can be used effectively in the news-game, we hope to get started soon with some testing with the prototype that is being built by the Johnson Simulation Center. Stay tuned.

Fabio Berzaghi

We are working with the Johnson Simulation Center at Pine Technical College in Pine City, MN to develop a tool that will allow journalists (read, non-techies) create engaging games built from news coverage of ongoing coverage in a community. After much to-ing and fro-ing, we think we've hit on a strategy for the type of utility that will work. But it has taken some "technical fortitude" to get to this point.

The JSC folks are working on what is sometimes called a "thin client" to make this happen. The "thin client" code sits on top of a widely accessible piece of software such as Flash but provides an interface that allows a user to bypass the creation technicalities as much as possible. What we are striving for is a tool that will allow journalists to call up a library of images and placeable, another library of characters and then simply input their own news content or other text and images into a "game" environment.

For instance, the topic being created by a newsroom might have to do with the issues surrounding the expansion of a light rail system in the community. The media organization has lots of copy, lots of reporters with additional materials that never made it into print or on the air, and lots of connections with experts and community members who have something to say about the issue.

The software being created by the JSC is supposed to allow the journalists to choose a set of locations and a cast of non-player characters that will interact with the "player" (news reader, viewer, etc.). Let's say the player starts the game in the home of a neighbor at a dinner party where the topic comes up. An "oracle" appears to lay out the parameters of the topic and to suggest some ideas about how to learn more.

The player then can choose a number of locations to visit to talk to NPCs who can provide more information from a variety of perspectives. It is the information from these NPCs that the journalists have to be able to create "on the fly" from their news organization's content. And they have to be able to do it without a lot of technical fortitude.

A company called Distil Interactive in Canada has a type of thin client product that is currently being tested. They say they are working on an "open content" model -- anyone can put their own content into the system. Right now, the company has some prototype games that deal with training compliance officers to meet workplace safety requirements, for instance. The company provides the "thin client" that allows the content provider to input his/her own information using something as simple as a Word file, and provides the placeables, the "world" in which the characters exist and some of the other back-room stuff. The "thin client" software is still in development, but it holds promise.

The JSC folks are creating a similar type of "thin client" system designed to work for journalists and news content. A preview of the work so far is encouraging. But it has taken months of effort and considerable programming power to get to this point.

Creating a tool that will allow non-techies to develop engaging, interactive and sophisticated games that can be created on the fly is not a trivial task. That is probably why it hasn't been done yet.

We hope our experience with the Knight project will provide some insight into this process as well as result in a tool that can actually be deployed in newsrooms.

"The very first idea for our project was to focus on a specific local issue and include real people and organizations in the game. The main idea of this concept had the player visiting different locations to learn about the different facets of the issue. We struggled in the process of creating a good game concept, avoiding reading a lot of text and dealing with problems related to using real people and the distinction between what was quoted and what was reported as "being said" by someone.

Subsequently we had a meeting with some journalists from the Star Tribune. It gave us some ideas. First of all the journalists don't want to use external sources or spend time gathering information from different places. They'd like to use what has already been written within the newspaper. That was a huge point to be taken into account in the process of designing the game.

We then had the idea of creating a more simple structure: the player would go through small, fast dialogues and collect tokens. We decided to use fictional NPCs who would provide the player with real events and facts. Then at the end of the phase of gathering information the player would enter a debate with the purpose of swaying an audience to one side or the other of the issue by playing the correct token when prompted with a question/statement. We decided though, that the debate would have been too complicated to implement on the journalist side, at least to make it challenging enough for the player.

The main problem we were facing was the broad range of issues a newsroom needs to address with the game. On the other side, adding complexity to the game means asking a journalist to perform complicated tasks when using the tools to create the story.

At last, we settled on the idea of offering mini-games embedded throughout the scenario, not necessarily related to the issue. The player would go through dialogs with NPCs to gather chunks of information and then have to play a mini-game to get to the next NPC. At the end of the game there would be a quiz on the issue or news topic, and players are rewarded with a dance scene. Based on the player score, more or less dance moves are available and also different faces to stick on the body. The faces and the moves can be collected and used afterwards. The journalists can plug-in whatever face they want. Also we thought of keeping an "issue master" ranking, that would be based on the level of knowledge of a particular issue. The dance will be the fun reward for the players and the "issue master" will be intellectual reward."

As Fabio describes, we are trying to combine the serious engagement of the audience with a news topic and the light-hearted culture of gaming -- not an easy task. We are also trying to create a tool that can be implemented easily by over-worked news staff members who would not have to spend more than a few hours to create the game.

We are quite sure we've hit on the best combination with the design we are now building. Fabio, Nora and I will continue to provide updates now that a lot of the behind-the-scenes brainstorming has been done.

After some serious brainstorming sessions with game designers, news professionals and people who actually play games, we have a good idea about the type of game environment we will be prototyping.

We have some questions and comments for the others in the group who are also working on games and news applications and I'm sure we will have much more to share now that we've got a good look at what we have to work with.

We are pushing the boundaries for what is and isn't a "game," and are thinking hard about how to engage "newsers" in a way that stays true to the news context but allows for that element of creativity and "play" that is so important to this experiment.

It has been fun, and it is just starting....