3. The Map Editor

The map editor in Showtime, which enables players to create their own performance venue and show it off to their friends, is probably one of the game's defining features.

It was powerful enough for us to use in creating the actual levels for the game, making it very easy for us to change a level if we felt it was unbalanced. Rather than having Desmond redraw an entire level, level designers could use the map editor on their own to move things around.

This saved us countless hours of time and streamlined our development process. By making it easy and fun to use, our tool also became a great added gameplay feature, thus killing two birds with one stone.

Fig 5: This early version of the map editor shows collision data for each prop.

However, if we could magically choose one more feature to add to the game, it would be map sharing. Many players of our game would also agree, judging from feedback.

We would have loved to include the ability to share user-created maps online but we had the choice of either shipping a stable product on time or putting in a completely new feature that would have required much more testing on multiple networked systems.

In addition, the networking capabilities of XNA are currently designed for multiplayer gameplay and not for sharing files between peers. This made the feature rather difficult to implement within a short period of time and we understood we had to make sacrifices to meet the Dream-Build-Play deadline.

We had an additional time constraint in that many of our teammates were scheduled to begin their mandatory military service soon after the development period!

4. Testing and Being Willing to Change

Testing was key to ensuring that our game provided the player with a good gameplay experience. We carried out two different types of testing: systematic QA testing, to ensure that the game was as stable and as bug-free as possible, and gameplay testing, to ensure that the game was fun to play.

The systematic QA testing helped us identify bugs after we made any changes to the game, as many bugs are easy to miss without a test plan to flush them out.

Gameplay testing was critically important; at the end of the day, it's not about making a game that the developers wanted to play, it's about making a game that the players wanted to play.

Understanding that important point, we constantly brought in people who had not seen the game at all. They would play through the game and we would collect their feedback. Using their observations, we could identify what players liked or disliked, address those issues and make the necessary revisions.

Once we made those changes, we would go through the testing process again to ensure that those changes did indeed have a positive impact on the overall experience.

Fig 6: Another GAMBIT team checks out our latest build as we get ready for a testing session.

Like many teams at the start of a project, we had what we thought was a fantastic idea, and we began churning out code and assets to get our game going. Halfway through production, tester feedback showed us that the game just wasn't fun.

We scrambled to save the concept by tuning certain mechanics and making drastic changes to the core gameplay, but unfortunately after still more testing we realized that our basic idea just wasn't cutting it.

Since a lot of work had already been put into the game, we were reluctant to change it. However, we gritted our teeth and decided to revamp the entire game. Fortunately, that decision made Showtime into what it is now. If we had stubbornly opted to iterate on the old idea in small steps, Showtime would have failed. It was a painful decision, but we were not afraid to listen to our testers' feedback and overhaul the game to make it fun.