When we have determined what each game in the series will be, we start to develop the graphics, stories, or puzzle content material that will be used by the games. This process may take a number of months depending on how much content is required by the game type. We have to have at least some content material for each game to code against.
Once we have some content for the game series and have done the initial layout, the actual coding process starts. First we look at the sketches we have made for each game in the series and try to ensure that the controls are as similar as we can make them. We also try to reduce the complexity as much as possible. When we have agreement on the user interface design, we start to lay out the architecture.
Design the Architecture
This is done by taking the game specifications and determining the objects we need during the game setup process. Then we review how the game is played and identify any objects that are needed during the playing process. This is usually where we discover we have left something important out of our specs – like perhaps what would constitute completion of the game!! Once all the design holes are filled, the architect hides away in his corner and lays out the overall design. He determines what processes and methods will be handled in the base program for the series, and what will be handled in the individual games. When the architecture is completed, the coding starts in earnest.
If the series is a story series, such as Inspector Cyndi, the data is handled by models specific to the game, while the code that runs the game is the same for each of the games. If it is a puzzle series, more of the processes and methods are used only by one game and are put into the design of the specific game. In a puzzle series, games are grouped by their similarity. We then lay out one game of a group of similar games, coding the layout and initial setup. The other games of the group are modified from the one that was coded. The methods unique to the game are then coded.
Our story games, like the twelve Inspector Cyndi in Newport games, were inspired by the Dungeons and Dragons campaign we played together for many years; and by many of the over one thousand books in our combined library. They interject little-known historic events into fictional stories that are the product of many long group meals and brainstorming sessions.
To make the games interesting and exciting, one has to be able to tune the game so that it is challenging but not impossible. To do this, such things as the number of tiles or letters, the time interval, time remaining and so forth are put into tunable arrays. This allows us to have a game that is exciting and playable even for young children, or specially challenged individuals or the hottest game player, depending on the settings used.
We try to tune the games so that the scoring is as fair and equitable as possible. If someone is driving the game using voice control, it will be slower than someone who can mouse a control. We try to equalize the scoring by increasing the time allowed when voice control is on so that both players are scored the same for successful play.
Once a game has been coded so that it is playable, we do the initial tuning. We have to first play test the game to see if it works, and if it is fun. Each game is rated as to who it is accessible to. If, for example, a game is rated BL, it has to work with our Game Voice and respond to JAWS. We play test our games with each of the rating groups they are intended for. Game testing is another subject, one we will discuss next time.
Eleanor Robinson Chief Operating Officer (and game developer) 7-128 Software