|
4. Avoiding
the game design black hole.
The first version of the game sent to Microsoft was
purely a breakdancing game where you had to hit timed button combinations one
after the other as you traversed down a move tree.
The game
was brutally hard, and as the gameplay engineer I was the only one who
could play it properly. The only people to play the game were our development
team members and we never realized the flaws in our core gameplay mechanic. It
is only when Microsoft's portfolio team and our product manager decided to give
us feedback did we realize the state we were in.
While we
had complete creative control on the game, we really gave their comments a lot
of thought, as at that time it was the only way for us to break out of our
tunnel vision. We decided to improve the button combination part of the game to
be more like a rhythm game.

Figure 2: A Puzzling Move Tree?
Ivan
then one day decided that we needed a more compelling hook for the gameplay and he
had an epiphany to introduce a puzzle component to the game mechanic as opposed
to the incessant move-after-move mechanic. When we prototyped that out, we
realized that this would be the way forward. We sent another demo to Microsoft
and they were onboard then to bring our game to XBLA.
The rest
of the development cycle was spent trying to strengthen both the music and puzzle
genres of the game and figure out a balance to the dificulty. We decided to
take the game to Vancouver Film School,where
their entire game design class played the game for two days while we looked at
what worked and did not work for the game. This was the final breakthrough for
the game design, and served as our benchmark for the tuning.

Figure 3: The Puzzle Evolution
5. Going
online.
For the first half of our development cycle, we had
just one development kit shared between the two engineers. When we started
sending demos to Microsoft and they were more engaged with the game, we
realized that online gameplay would be a must have component since the multiplayer
component of the game was a lot of fun.
At that time, there were no
rhythm-based games that provided an online gameplay experience, so it was a big
challenge for a small
company like ourselves to find a solution that would work.
During
the initial months of development, our game-play seemed like in a constant
state of flux. It was not until halfway through the development cycle that we
decided to get a second development kit and figure out how to build the online
game modes.
The key thing then was that our gameplay code was more stable and
knowing that we would have to build online game modes later, the code was
architected such that we could fill in the online related gaps.
The
biggest breakthrough in this task happened when Microsoft released a light-weight
library for building online components for XBLA games. Although there were some
certification related quirks with this library, it greatly helped us by taking
away a lot of the low-level connection, packet ordering, and packet delivery
issues. We could then focus on building a compelling online gameplay experience
and knock out all the super tricky de-synchronization bugs in the game.
What Went Wrong
1. When
will this be done?
Self-funding the game, with no constant income, was
a real trial for us in this development cycle. Initially, we thought GGBS
would not take us longer than a year to make. But our ship deadline became more
of ship "guideline".
The
first thing we underestimated was the art effort required. As mentioned above,
art alone took us over a year to complete. Next came the certification process.
XBLA titles are subject to the same full certification requirements as AAA
titles with tens of engineers. As we kept changing our gameplay well past our
alpha and code complete milestones it took, us over six months to get the game
fully certified.
Although
we had a professional testing company put the game through its paces, we still
failed certification once, as a critical bug somehow slipped through. This
delayed our launch by a month and possibly hurt sales.
|