designed our user interface and dance choreography, we uncovered gestures
and poses that were difficult for the early tracking to reliably detect. It was
impossible for us to predict exactly how robust tracking would be by launch,
and there was some anxiety as to whether we would need to simplify or
remove moves and gestures that were undetectable.
Rather than putting development off while the tracking improved, we
accepted the situation and tried, whenever possible, to handle noisy skeletal
data and cases of skeleton “crumpling” gracefully. We also began investing
in sophisticated in-game detection technology that could better handle the
possibility of imperfect tracking. The payoff was a more consistently playable
and fun game throughout development. Even as the Kinect skeletal tracking
was refined to its more robust shipping state, we realized that this wasn’t
wasted work. Every Kinect game needs to handle cases where skeletal data
isn’t reliable (e.g. if the player drifts out of the sensor’s field of view). Dealing
with the design ramifications of noisy and unreliable data early on helped us
better understand the capabilities of the technology and mitigate risk.
Early on, Microsoft provided us with detailed resource costs for using
Kinect, including the CPU, GPU, and memory costs for skeletal tracking and
other features of the platform. These costs are non-trivial, but because we
had plenty of advance warning, we were able to plan and budget accordingly.
The Kinect platform team also provided great resources for tackling some of
the technical challenges unique to Kinect, such as smoothing algorithms,
image processing, and latency reduction.
5} THE RIGH T SCOPE, THE RIGHT MOVES. Creating new IP isn’t easy, especially
when your studio is well known for one type of genre-defining game. We knew
that the Dance central team would need the drive to do something completely
new while also quickly reaching consensus on feature scope. We looked back
to the work our studio had done developing the original Guitar Hero as a
reference point. At that time, Harmonix was a much smaller developer. We had
to be prudent about our ambitions while remaining flexible and innovative.
Our imperative for GH was first and foremost to completely nail the core fun
experience. Naturally, it felt like Dance central should share that approach.
We made the decision to keep the team small, composed of key
members who had proven themselves on other Harmonix titles over
the years. This was no easy task, given that we were simultaneously
developing rock BanD 3! This core Dance central group was able to break
into agile sub-teams that rapidly iterated on gameplay prototypes. There
was a conscious effort to focus the design on strengthening the core dance
experience rather than adding breadth and complexity. Adding a character
creator, in-depth single player campaign, or other ancillary feature would
have detracted from achieving our core goals. Instead, we spent most of
our time perfecting the dance gameplay – learning how to best handle
difficulty, building a teaching mode, and making sure our flashcard and
spotlight HUD were conveying the right information at the right time, all
in the service of keeping the dancing as fun and entertaining as possible.
Our strike teams consisted of a designer, coder, artists, sound designer, QA
tester, and a producer, each empowered to scope, design, and prototype the
main gameplay modes.
As noted earlier, we also made sure the team had a genuine interest in
dancing and dance culture. That dedication shows in the final product. Having
a common background, knowledge of club music, and passion for dancing
meant we were able to approach all design choices knowing that they were
grounded in the world of dance. By “speaking the same language,” we moved
rapidly through iteration, since we didn’t suffer from off-the-mark decisions.
We felt validated in our approach when we showed the game to professional
dancers who were impressed with the authenticity of both the dancing and
approach to teaching.
The combination of a small, powerful team, tasked with the goal of
implementing a core feature set unhindered by feature bloat enabled us
to execute a sophisticated game based on Microsoft’s brand new motion
tracking tech in just 12 months.
/// When developing a Kinect title,
you also need to create a way to
navigate menus using gestural input.
Microsoft hadn’t yet released any UI
libraries or guidelines, so despite the
fact that none of our team members
had any expertise in this field, we set
out to design a solution from scratch.
Our approach to working in
this unfamiliar and evolving field
was to iterate quickly through rapid
prototyping. This allowed us to fail
quickly, identify what didn’t work,
and eventually whittle down to what
did. We formed a team to focus on
the UI that met twice a week. The
principal workers in this team were
a programmer and a UI artist; the
remainder of this team included
the project director, producer,
lead programmer, lead designer,
and other senior members of the
project. Generally these meetings
had about 8 attendees total.
Here’s how we structured
the team meetings: We’d begin
by taking a look at the latest
prototype, noting its deficiencies
and limitations, and brainstorming
ways to improve it. If someone had
an idea, they would have to sell it
to the rest of the team. Eventually,
we’d reach a consensus and leave
with a list of action items. Those
action items alone determined
the subsequent work for the
programmer and UI artist. With
this method we were able to allow
a large group of individuals to
have creative input while removing
dependencies or changes in
direction for the principal workers in
between meetings.
As we ran through many
prototypes, we learned some
important lessons about full-body gestural input. One major
hurdle that separated this type of
input from, say, a touchscreen, was
the lack of an obvious way to signal
engagement/disengagement. With
an iPhone, if you want to press
a button, flick between pages, or
scroll a list, you can just touch
your finger to the screen. When
navigating a UI with Kinect, it’s
essentially like your finger is always
on the screen. Kinect doesn’t detect
whether your hands are open or
closed, so we couldn’t determine
engagement that way. We tried
using the player’s hand position in
the depth axis and arm extension
to determine engagement, and
while it seemed like it would be
an intuitive way to interact with
this sort of UI, in practice it was
unsatisfying and strange.
We decided to ditch using the
depth axis, electing to use only
the hand’s horizontal and vertical
position to navigate. We prototyped
a UI using this concept: a vertical list
of buttons where a specific button
was highlighted based on your
hand height, and that highlighted
button could be slid across the
screen in order to select it. After
the prototype concept was initially
dismissed because it didn’t feel
right, our UI artist had an idea for
a treatment and created a video in
Maya to mock up how he envisioned
us using this navigation paradigm.
He altered the look and animation
of these buttons, while still
retaining the same underlying user
interaction. This added aesthetic
polish elucidated the concept to the
team, and the shipping version of
our UI matches that mockup video
very closely.
Ryan Challinor on UI/Nav
www.gdmag.com 27
