|
4. Lack of Control Scheme Page
Our game is fairly different from
many other titles, so players really needed to be taught the role of the
interactive "props" in the game environment to enjoy the game.
Some
props were useful while others posed a potentially lethal hazard. We managed to
convey this message successfully via a tutorial system integrated across the
game levels, which explained new props when they first appeared.
This both
allowed the player to understand the multitude of game props in a simple manner
and allowed us to explain the multiple ways to use each prop in clear,
easy-to-follow steps so that the player didn't need to learn all the controls
at one go.

Fig 11: The in-game tutorial,
which introduces new techniques to players, was so important to the game that
we eventually expanded it into multiple frames.
Since we provided the tutorial
system, we became overconfident and felt that we did not need a control
scheme page. After all, the game only used two buttons and the analog stick.
When we submitted the game to the Xbox Live Community Games playtesters,
however, we were told that we needed a control scheme page that players
could reference if they forgot the controls.
It was only then that we realized
that, although we considered our game a platforming game, our control
scheme didn't follow the conventions of the genre (such as including a
"jump" button).
When we set about drafting such a control scheme
page, we realized that the game's many props (which all operated differently)
would have made such a page illegible. To meet the deadline, we had no choice
but to omit this feature.
5. Testing with a Niche Audience
While testing was one of the
things we did right, there were some blunders. At the beginning, we turned to
local schools and institutions for testers, which seemed to provide us with a
large pool of people to test our game.
However, it took us a while to realize
that most of the testers who showed up weren't familiar with console games,
which made it difficult for us to make sense of and interpret our test results.
In fact, we spent close to a month or two testing with this audience before we
realized our error.

Fig 12: Pinball was a big source
of inspiration for Showtime.
Due to inaccurate test data, many
of the early changes we made to the game were unnecessary. We needed
to completely restart testing, putting in much more effort to find
broader and more varied groups of testers.
We eventually succeeded,
but that didn't change the fact that we had lost so much time and effort
reacting to test results generated by a niche group of testers.
After
All is Said and Done...
During one of our testing
sessions we had three testers in our lab. All three were good friends and loved
gaming. Their testing session started early in the morning and we had them play
through the game from start to finish.
At noon we asked them
if they wanted to stop for lunch, but one of them said that he wanted to beat
the game first. He was on the final level, and was having some difficulty
beating it.
The other two testers were experiencing similar difficulties as
well. Before we knew it, the testers banded together and took turns at the
level together.
They cheered when one of them made a particularly tough leap,
and were collectively disappointed when Slinky narrowly missed a target. (Right -- Fig 13: Through much iteration,
the acrobatic trapeze evolved into a claw-like grabber.)
Watching them, we knew that we
had created something good. We had created something that three friends gave up
their lunch to play. It's times like that when we remember why we make games.
Now that the game is finished, we
are overjoyed to have been a part of the project. Although we suffered many
setbacks, it was a very good experience. We learned many things about ourselves
and how to manage a project. Now all we hope is that you will have as much fun
playing CarneyVale: Showtime as
we did making it!

Fig 14: Most of us aim to pursue
further studies in college.
Data
box
Full-time student developers: 7
Part-time
student interns: 2
Length
of development: 4 months
Xbox
Live Community Games release date: Dec 22, 2008
Platform:
Xbox 360
Development
Hardware: HP Desktop PC (Intel Core2 Duo 2, 2.33 GHz, 2 GB RAM), 19"
LCD screen, Wacom Intuos 3 tablet, Olympus LS-10 audio recorder
Development Software: Microsoft Visual Studio C# Express
2008, Microsoft XNA Game Studio
3.0, Microsoft XACT, Adobe Photoshop CS3, Steinberg Cubase 4
Resources: Farseer Physics Engine, XNA Creators Club, EastWest Symphonic
Orchestra Silver Edition, Fonts: Ligurino, Biondi, Ozone, Bell Gothic
|
You are not alone in making the mistake of failing to support lower-end displays as sadly it is all too common today even with more experienced developers. I have worked with developers on several projects and continually spoken to them about this yet in the end the standard def display was always vastly inferior and not just in resolution quality but also in usability. Then these same teams are shocked when they get knocked for that in reviews and user ratings. Good on you for recognizing the lesson and striving to do better.
The art issues with HD and localization were only recognized near the very end of development, several months after the Dream-Build-Play competition, when we were packaging the game for release on Xbox Live Community Games. The game was feature and asset complete by that time.
Of course, now we know that we should test our games on multiple regions and resolutions as early as possible. The XNA community can help out in this regard, since Microsoft has introduced a system for developers to submit time-limited demos for playtesting. It's not as rigorous as final review submissions, but it does give you access to a large pool of players from different countries with different screens.