5. Keeping the Code Modular

While making Showtime, we did a lot of playtesting to see what worked and what didn't. This meant that there were a lot of changes. Code that was written one day could be gone the next, and entire features could be taken out and replaced by something better at any time.

Understanding that modifications were inevitable in the process of making a game, we made sure that the code was modular and easy to change. This allowed us to make the necessary revisions quickly and see the results as soon as possible.

The faster changes can be implemented, the faster they can be tested to see if they indeed make the game more fun. As a result, even though there were a huge number of revisions made to the game during its development cycle, they still remained manageable, and the final game benefited immensely as a result.

Fig 7: Different ideas for the cannon prop, from the simple to the elaborate.

What Went Wrong

1. Not Enough Prototyping

Our team had lots of experienced game players, but did not have anyone trained in game design. This resulted in premature design decisions that eventually required us to do a lot of reworking.

Although we were unafraid of change, constantly having to overhaul the concept of the game throughout the four months was tiring and wasteful. (Left -- Fig 8: This sketch demonstrates how we intended to combine acrobatic performances with spectacular crashes.)

We started off well by creating one digital prototype and one paper prototype to test two ideas. The digital version was a circle that could jump around and swing on lines, and the paper prototype was a paper rag doll falling down pins we stuck on the wall.

That was all the prototyping we did before we decided that the paper rag doll falling down the wall was fun.

We proceeded straight into production, basing our entire game on this concept of "failing" and rewarding players if they failed a swing or mistimed a jump.

As it turned out, testers didn't understand the logic behind these design decisions, and we spent a lot of time making a game that was not well thought-out and was boring to play. When we eventually abandoned that design, we lost countless art assets and a lot of code.

We didn't spend enough time making prototypes and testing our early ideas. More importantly, we didn't allow anyone outside of the team to play with our prototypes before we cemented the idea.

Although this ended well for us, the magnitude of changes meant that we spent a significant amount of time and effort on reworking designs and changing mechanics instead of polishing and tuning the rest of the game. A smart designer can save your team a lot of time by zeroing in on the really good ideas with early prototyping and testing.

2. Over-Scoping and Feature Creep

Showtime was originally intended to include full-length cutscenes, sixty levels, multiplayer modes and much more. Essentially, we planned for functionality that we had no way of finishing in time.

Nearly a month was spent working and reworking the story for the scenes, and another was spent creating them. In the end, we realized that we had over-scoped, and we removed the cutscenes altogether. If we had not planned for the cutscenes in the first place, that time could have been spent on other, more productive portions of the game.

Fig 9: We originally planned to include cutscenes in which Slinky would have to convey a variety of moods.

Even though Showtime was intended to be a small-scale project, we started having lots of great ideas during production and we wanted to get them into the game. Not realizing that we were growing the scope of the game, we went about implementing all those features.

Before we knew it, we were building something much bigger than we'd intended. The crux of the issue came when we realized that, despite having more features to finish, we still had the same deadline bearing down on us. This resulted in more time spent in the office and more late nights. Even the effort of cutting out those features and assets drained our precious time.

3. HD and Localization

When we were building the game, we made sure that it looked great and ran properly on our development machines, not realizing how much influence that would have on our production. Not planning for wide distribution of our game made it much less accessible to other languages, regions and screen setups.

Our team had an HDTV in our lab that we used for most of our initial prototypes, and all of our computers were capable of rendering at high resolutions. This led us to work under the incorrect assumption that we were developing the game only for HD displays, and we lacked the foresight to support lower-resolution televisions.

In our zeal, we created so many assets that when we finally realized we should cater to lower resolutions, downsizing those assets was an insurmountable task.

For example, we had many lines of text that we'd rendered as image files with fancy effects. Although the Xbox Live Community Games reviewers did not reject our submission for this reason, many of them did complain that words were cut off and that some text was too small to read.

This was especially evident on CRT television screens that were less than 20" in size. However, due to time constraints and the need to ship, we had to push the title to Xbox Live Community Games without catering to lower-resolution television sets.

Fig 10: The text under the icons can't be read in 480i. The red color doesn't help.

In addition, three key errors we made in production now prevent us from localizing the game to multiple languages. First, as mentioned above, much of our text was rendered as bitmap images, blended with artwork designed around specific words. We didn't consider how changing the text would also require changing artwork.

Second, most of our in-game text was scattered all over our code. If they were kept in a single, separate text file, it would have been possible to swap different files for different language translations.

Third, although players could name their custom maps in our editor, our fonts only featured the basic English character set. Thus, players using different languages couldn't name their maps using letters from the full international character set.