Dance Central GDC Talk

Last week at GDC, Matt Boch and I gave a talk on the design process of Dance Central. We covered everything from the very early beginnings of the project (rough prototyping with FireHose Games creators of the excellent SLAM BOLT SCRAPPERS!) all the way through to the end of production.


We used Prezi to put together our presentation. It was super fun to use and made for a much more interesting talk!


Here is our Prezi. You can toggle through each step of the Prezi while reading along with our notes below!


You can also follow Matt and I on Twitter:


@iamdeantate
@mattboch


TALK NOTES


FIRST SLIDE

Welcome to our talk! First we’re going to introduce ourselves.


NEXT SLIDE

I’m Dean Tate. Dance Central was my first project with Harmonix; I brought to bear 10 whole years of experience in the First Person Shooter genre onto Dance Central. In particular the experiences and lessons that I learned on the seminal, innovative, and critically acclaimed...

NEXT SLIDE

...Tactical Ops: Assault on Terror! (ho ho! Ha ha!)

NEXT SLIDE

I’m Matt Boch. I was the prototyping lead for Dance Central. I’ve been working at Harmonix for four years. I began working in the hardware department designing the instruments for the Rock Band franchise.

NEXT SLIDE

This talk will cover the design process of Dance Central, from conception and early prototyping, through to ship.

• How we used prototyping to whittle down a massive possibility space
• How in Full Production we answered the largest design question that faced us: How will the game teach people to dance?
• The process used in developing the game’s tutorial mode, “Break it Down”
• Why focus on this mode?
• It represented our largest design challenge, and took the most time to develop
• All of the processes used in developing it were applied to every other core system in the game.

NEXT SLIDE

Project Scope notes

• 17 months, start to finish
• 5 months of prototyping and pre-production, with a small team at Firehose Games
• 12 months of Full Production, where development moved in-house to Harmonix and the team grew to 60 members (every one of them awesome)

NEXT SLIDE

Dance Central prototyping began in March 2009 and ended in August 2009.

NEXT SLIDE

At the beginning of the project our possibility space was rather undefined. We had a couple knowns, and quite a number of unknowns.

NEXT SLIDE

We knew we wanted to make a dance game, and we knew what kind of music we wanted.

NEXT SLIDE

In the years leading up to DC prototyping, we’d seen an explosion of dance in culture. TV shows, as well as dance crazes, were springing up every year.

NEXT SLIDE

In terms of music, we knew we wanted to focus on:

• Pop
• Hip-Hop
• RnB

In addition to some deeper cuts, and a spattering of classic 70s and 80s hits.

NEXT SLIDE

Our unknowns were far more numerous.

NEXT SLIDE

For our interface tech, would we use depth cameras or body-mounted sensors?

NEXT SLIDE

How would our detection work?

NEXT SLIDE

What was our intended audience? Were we targeting novices, experienced dancers, or everybody in between?

NEXT SLIDE

How complex would our choreography be? Would our moves be more like #1 or more like #3?

NEXT SLIDE

What type of language would we use to represent the dance moves? Would we use move names? Footprint diagrams? Silhouettes?

NEXT SLIDE

How would we communicate to the player that they had correctly performed the moves?

NEXT SLIDE

How would we teach the player the moves?

Who was on our prototyping team?

NEXT SLIDE

Myself...

NEXT SLIDE

...and a small external studio called Firehose Games.

NEXT SLIDE

Firehouse is working on an awesome game called Slam Bolt Scrappers.

NEXT SLIDE

It comes out March 15th 2011 on Playstation Network.

NEXT SLIDE

We were joined by Eran Egozy, CTO and founder of Harmonix. Kasson Crooker joined towards the tail end of the process as he transitioned off of Rock Band 3 and onto the Dance Central team.

NEXT SLIDE

So with our knowns, our unknowns, and our team assembled, we set out to prototype Dance Central.

NEXT SLIDE

For the purposes of prototyping, we decided to table the questions of tech and detection. For prototyping tech, we settled on a proprietary sensor solution. For detection, we were open to implementing some actual logic when possible, but, given that detection wasn’t the focus of our investigation, we agreed to cheat and use a man-behind-the-curtain solution if all else failed.

We definitely ran playtests where designers were driving the game’s detection with a handheld remote. Our playtesters were all Harmonix employees, and we were confident they would be able to see past any fakery and perceive the game’s potential.

NEXT SLIDE

Our prototyping process vacillated between two extremes: a traditional dance game, and real choreographed dance.

NEXT SLIDE

Let’s take a look at the possibility space of a traditional dance game.

NEXT SLIDE

The tech is commonly dance mats, floor mounted sensors, or handheld sensors.

NEXT SLIDE

Detection can be as simple as looking for a button press on a mat, or as complicated as reading gestures from accelerometer data.

NEXT SLIDE

The audience is very broad; almost any one can play these games.

NEXT SLIDE

Move complexity is generally limited to very simple movements...

NEXT SLIDE

...and the language mirrors that simplicity. Dance games commonly have a limited set of icons, each matched to a specific step or movement.

NEXT SLIDE

Feedback is generally loaded on to those icons.

NEXT SLIDE

Tutorials are rare in dance games. They’re pick-up-and-play experiences!

NEXT SLIDE

Now lets take a look at the possibility space of traditional choreographed dance.

NEXT SLIDE

The primary technology is a mirror, used by dancers to ensure a tight match between proprioception, what the body thinks its doing, and visual perception, what the eyes perceive the body to be doing.

NEXT SLIDE

Detection is the job of the dance instructor. It’s up to the instructor to see if their students are performing adequately.

NEXT SLIDE

The audience is limited to people who are serious about dance.

NEXT SLIDE

Move complexity runs the gamut from simple to extremely complex.

NEXT SLIDE

The language of dance isn’t widely agreed upon. In the past dancers and choreographers have tried to develop visual languages that communicate movement, but its a very difficult problem and no language has been broadly adopted. It’s easy to see why: Here, the image on the left represents the movement on the right, but it’s near impossible to decipher, never mind in real time.

NEXT SLIDE

It’s also up to instructors to let dancers know whether they are looking great, or botching the dance.

NEXT SLIDE

Tutorial is at the very heart of the experience. Serious go to dance class to learn new styles and expand their repertoire.

NEXT SLIDE

We began our prototyping way over on the dance game end of the spectrum with a prototype to the song “Please Don’t Stop the Music”

NEXT SLIDE

As you can see in this video, players are expected to perform a given move when its icon passes over the green bar. This was a very simple prototype that only took a week or so, but it got our minds focused on the problem space and laid some groundwork for our investigation.

NEXT SLIDE

Taking a look at the possibility space defined by this prototype:

NEXT SLIDE

The move complexity is very low. Only a few moves are included in this system and it won’t scale well to extremely complex movement.

NEXT SLIDE

The language is very much that of a traditional dance game. 6 icons, each representing a very specific movement.

NEXT SLIDE

We didn’t implement a feedback system.

NEXT SLIDE

Our tutorial took place in person, outside of the game.

NEXT SLIDE

Having completed this prototype, we knew this strategy was far too restrictive. We needed a system that was capable communicating a broader variety of dance moves.

NEXT SLIDE

So we began work on our second prototype, using the song and dance to a popular dance craze at the time, the “Cupid Shuffle”.

NEXT SLIDE

This prototype was quite similar to an instructional dance DVD. The player watches the dancer on the right and copies their moves. A move-name-based cuing system tells the player the next dance move, and counts them in.

NEXT SLIDE

Taking a look at the possibility space defined by this prototype:

NEXT SLIDE

While the actual “Cupid Shuffle” dance is relatively simple, the system is hugely flexible in terms of move complexity. As long as it can be captured by video and given a name, it will work in the system.

NEXT SLIDE

The language was that of move names, something we’d seen in tons of videos...

NEXT SLIDE

...including Hannah Montana’s “Hoedown Throwdown” and Dancin’ Kim.

NEXT SLIDE

Our feedback was text cues, superimposed atop a representation of the player’s hands and feet that served as a sort of mirror for the player.

NEXT SLIDE

Our tutorial was again in person.

NEXT SLIDE

Having completed this prototype, we were convinced we’d found a potential basis for our game, but we had a ways to go. We weren’t happy with the limited feedback we were giving the player and the cuing system left much to be desired.

NEXT SLIDE

So we set out to refine our approach with our 3rd prototype using the song “Sexy Back” and some custom choreography.

NEXT SLIDE

Like the previous prototype, the player watches a dancer on screen and mimics their moves. A “tumbler” cuing system tells the player what’s coming up next.

NEXT SLIDE

Taking a look at the possibility space defined by this prototype:

NEXT SLIDE

Much like the previous prototype, the system is flexible in terms of move complexity.

NEXT SLIDE

Our move name based language was refined. We latched on to funny iconic names that would help the player make an association between the movement and the name, hopefully improving retention.  At this point, moves were still of a flexible length: some moves would last for 4 beats, others 8 or 12. We found that inconsistent movement of the tumbler really threw players off, and resolved to make all moves 4 beats long.

NEXT SLIDE

We kept our representation of the player’s hands and feet...

NEXT SLIDE

...and added a circle that fills up and color shifts as they player successfully performs a given move. This feedback added a lot to the experience and pushed us in a more game-like direction.

NEXT SLIDE

Having avoided it for weeks, we finally tackled an in-game tutorial. The structure was very simple: we’d introduce a new move, and then give the player few chances to repeat it, before attempting in context. This first attempt at a tutorial laid the groundwork for Break it Down’s eventual learning-followed-by-recap structure.

NEXT SLIDE

Having completed this prototype, we knew we were on a path towards a flexible and fun system based around real dance, but we were a bit disheartened by the experiences of some our playtesters. While we had succeeded in creating a fun experience for playtesters who were excited about dancing, we had failed to enfranchise those less comfortable with dance.

NEXT SLIDE

This observation helped us refine our concept of our audience. We had:

• Dancers- People are totally comfortable with dance and seek it out recreation-ally or professionally
• Willing Non-Dancers - People who are not proficient at dance, but are interested in trying. They dance at weddings and similar social events, but don’t seek explicitly seek it out.
• Non-Winning Non-Dancers - Wallflowers. People who are uncomfortable dancing and won’t dance even if pressed.

We knew our prototyped worked well with the first two groups, but we were alienating the last group.

We were also frustrated with the role tutorials occupied in our present prototype and wondered whether a tutorial-free experience was possible.

NEXT SLIDE

So with the goal of enfranchising non-willing non-dancers with a tutorial free, game-focused dance experience, we made our 4th prototype, using the song “Low”.

NEXT SLIDE

This game took a Rock Band gem-style approach to a dance game. The dancer would perform a move, sending gems down a tunnel to the front of the screen. The player was instructed to match the move 4 beats later, hitting the gems with their arms and legs as they went. The dancer would then begin stringing together multiple moves as the player followed. Scoring was focused on successful gem popping rather than successful dance performance, but a competent dance performance would pop all the gems.

NEXT SLIDE

Taking a look at the possibility space:

NEXT SLIDE

Move complexity was extremely limited in this system. The gem based mechanic limited dance to 2 dimensional movement of the arms and legs away from the body. Any movement towards the camera or in front of the body would be completely lost.

NEXT SLIDE

We kept our move names, but the real focus of the game was on the arm and leg gems.

NEXT SLIDE

Feedback was messaged entirely on the gems.

NEXT SLIDE

And the game was tutorial-free.

NEXT SLIDE

We’d succeeded at our goal. Our non-willing non-dancers happily popped the gems while ignoring the dance moves. Everyone else had plenty of fun trying to dance and gem-pop simultaneously. But we’d lost something important: the flow of dance. In previous prototypes, when a player had mastered a given dance, they fell into a state of flow. That unparalleled feeling was completely absent, and we felt the game suffered for it. This is when we arrived at a core tenet that would define much of Dance Central’s development: “The fun of dance is mastery”.

NEXT SLIDE

We revisited our intended audience and determined we weren’t interested in pleasing the non-willing non-dancers. We wanted to make a real dance game, not a game that tricked people into dancing.

NEXT SLIDE

With that in mind, we tackled the biggest choreographic challenge of our prototype phase: “Crank Dat” by Soulja Boy. The song and its choreography had already become ubiquitous. We saw it performed on football fields and college quads across the country and knew that any dance game we were going to ship had to include this iconic choreography. We went back to our 3rd prototype, borrowed its cuing system, and went about investigating what improvements were possible.

NEXT SLIDE

First we dug into the language. Various artists and designers around Harmonix had been forwarding the concept of trails and footprints that would cue the player, showing them the basic path of the movement in advance.

While many on the prototyping team were suspicious of this approach, we’d heard it suggested often enough that we knew we had to try it.

NEXT SLIDE

Upon implementing trails, a number of issues became obvious. For the majority of moves, the trails were pretty abstract and difficult to read. Further, in order to show the trails as clearly as possible, we would often have to move the camera to an extreme angle every few beats. While a few moves, like Supahman, were totally readable, the vast majority didn’t work, and we abandoned the approach.

NEXT SLIDE

We regrouped, had a long design conversation, and eventually settled on investigating the potential of pairing move names with per-beat dancer icons to create flashcards for each move.

NEXT SLIDE

The player was given feedback on a per beat basis. Icons would turn gold per beat if the player’s performance was adequate. If they failed to meet the detection criteria, the icon would turn gray.

NEXT SLIDE

We also expanded our tutorial, introducing the concept of verb barks.

NEXT SLIDE

Verb barks are short percussive commands often spoken by dance instructors as they teach a move or routine to their class. Each major action in a given move is assigned a word, and these words are repeated as the dancers learn the moves. They serve both as a means of explicating the actions and as a memory device.

NEXT SLIDE

Here you can see the verb barks in action in our tutorial.

NEXT SLIDE

When we had completed this prototype our possibility space looked something like this:

NEXT SLIDE

The system could deal with a broad spectrum of moves, from simple to complex.

NEXT SLIDE

The language was visual, verbal, and textual, as it included iconographic, auditory, and written representations of each move. This broad approach appealed to a variety of learning styles.

NEXT SLIDE

We removed our mirror-like visual feedback, which was present in almost all the previous prototypes, and replaced it with simple icon-based feedback. We found that giving positive feedback without showcasing exact movement on screen allowed the players to imagine that they were performing the dance with the grace and poise of the dancer on screen. Any mirror-like representation broke that illusion of high performance.

NEXT SLIDE

Our tutorial was becoming more and more reminiscent of a dance class.

NEXT SLIDE

We had arrived at a system that our team was truly excited about. At this point we decided we were ready for full production, but wanted to create a polished demo to bring to the production team that reflected all the lessons we had learned during prototyping.

NEXT SLIDE

So we created our last prototype using custom created choreography for “Crazy in Love”.

NEXT SLIDE

This prototype was a lot like the previous prototype: move names paired with icons that changed state based on the player’s performance.

NEXT SLIDE

Looking at the possibility space:

NEXT SLIDE

This system was able to adapt to almost any move we could throw at it.

NEXT SLIDE

We refined our flashcard language to better represent the dancer’s movements, adding details like hands, arrows, and dots for beats devoid of specific movement.

NEXT SLIDE

We added a Rock Band style crowd meter to represent the player’s overall performance, and upped the ante on the per beat feedback, adding a huge gold flourish that engulfed the whole flashcard if the player was successful.

NEXT SLIDE

We polished our tutorial, including elements like an explicit “Watch First” section that allowed the player to see the move and try it before they were explicitly graded.

NEXT SLIDE

It was nearly August and we were ready to show the production team what we’d made.

NEXT SLIDE

Our process had brought us to both extremes, but we settled somewhere in the middle. What we’d made combined all the positive feedback of a dance game, with the core elements of a real dance experience. By trying out concepts at either end of the spectrum, we were able to define the benefits of both experiences and, through iteration, work the best of both into a compelling game interaction.

NEXT SLIDE

Prototyping was done!

NEXT SLIDE

Time to move on to full production.

NEXT SLIDE

Now that we’re ready to start making the game, let’s take another look at our knowns and unknowns.

NEXT SLIDE

Our focus on dance and our music selection hasn’t changed.

NEXT SLIDE

In terms of tech, we had a Deus Ex Machina moment. Towards the end of prototyping, Microsoft gave us a demo of the Kinect. When we saw what it could do, we knew we’d found the perfect technology for our game.

NEXT SLIDE

Through prototyping we’d discovered that our intended audience included just about everyone who was willing to dance.

NEXT SLIDE

We’d discovered that our game should include simple, approachable moves for beginners, as well as scale to incredibly complex moves, to add depth and reward repeated play sessions.

NEXT SLIDE

Our move language was significantly revised as we moved into full production. We replaced the per-beat icons on each flashcard with per-bar icons. We found that the primary role of the icon-based flashcards was that of a memorization tool. By reducing the number of poses on each flashcard from 4 per-beat icons to 1 or 2 icons, the flashcards became more glance-able, which meant less time staring at the icons, more time watching the dancer.

NEXT SLIDE

We took the per-move feedback and loaded it on to the dancer, the primary visual interface for the game. The longer-term feedback that we had placed in a crowd meter was incorporated into the game world: as the player strung together move after move, the locale would transform from a real-world location into a psychedelic dance club.

NEXT SLIDE

The net effect of these changes was that the player no longer had to take their eyes off the dancer to understand how well they had done on a given move or how well they were doing on the song as a whole.

NEXT SLIDE

While we staked out the majority of our possibility space, two particularly difficult unknowns remained: detection and tutorial. We worked on detection throughout the entirety of our production cycle and only solved it adequately at the 11th hour, but that’s a talk in and of itself. We’ll focus on the other major design challenge: the tutorial.

Knowing now that the game would be all about mastering complex and authentic dance moves and full routines, we knew that the game would need to be able to teach people to dance. So, moving into Full Production, the largest design question we faced was “How will the game teach people to dance?”.  

NEXT SLIDE

A small Strike Team was tasked with answering this question.

NEXT SLIDE

We were also responsible for all other core gameplay systems and modes:

• “Perform It!” mode, which is our core game mode. In it, players dance routines linearly, and receive a grade
• “Dance Battle”, which is our 2-player multiplayer mode
• A small subset of the Strike Team was also responsible for our move detection system (the system that speaks to Kinect and grades players on their ability to accurately mimic dance moves)

NEXT SLIDE

The labors of this team and other Strike Teams was so successful that all Harmonix projects are now developed using our own take on Scrum methodology.

NEXT SLIDE

In much the same way that prototyping lead a small team to vacillate between the ends of a spectrum (at one end real dance, at the other end dance games) we spent out time developing Break it Down bouncing back and forth along a new spectrum. At one end, experiences purely about learning. At the other, experiences purely about play. Not that we knew this would be the case when we first set out!

NEXT SLIDE

So when you think about gameplay experiences that our purely about learning, you tend to notice a few things:

• They place higher priority on function rather than form. Usually not a lot of attention is lavished on snazzy presentational flare.
• They tend to give players tons of direct control over the experience.Think of fighting game practice modes; players can choose which character to practice with, which moves to try out, etc. They control everything about the structure of the lesson.
• The only incentive for playing tends to be the gaining of knowledge that can then be employed in the actual game.

And most of all, these experiences tend to unfortunately have a negative stigma associated with them. Players prefer to avoid tutorials if at all possible, and just jump in and play (and learn on the run). Designers prefer to avoid implementing tutorials if at all possible too, but we didn’t have that luxury on Dance Central. We knew that every single routine in our game would essentially require its own custom-tailored tutorial.

NEXT SLIDE

So knowing these things, we dove into development! The goal we stated to ourselves in the beginning was “Let’s make an effective teaching tool!”

NEXT SLIDE

A few things to note about the project’s situation at this point in development:

• Natal/Kinect was still quite early in development, and would be developed in parallel with our game throughout the next 12 months. Within a short time it started to make huge leaps and bounds, but at this early stage in the project we were not yet making full use of it in the game.
• Break it Down’s design was more or less a blank slate. We knew a few things about how to teach people to dance from early prototyping (repetition of moves + pairing of icons/names to moves can aid in retention!) but outside of this, we didn’t have a great idea of what direction to start heading in, and as designers we were definitely not experts at teaching people to dance.

NEXT SLIDE

Luckily for us, at this point a bunch of choreographers joined the team! Frenchy and Marcos joined full time, and immediately began entrenching the entire team in the world of dance.

NEXT SLIDE

“The Dance Complex” is just down the road from Harmonix. Marcos and Frenchy started running twice weekly dance lessons that were open to the entire team. We all started to learn how to dance, and about the world of dance!

NEXT SLIDE

At this point we said to ourselves “Hey, these guys are experts at teaching people how to dance...maybe they can teach us how to teach people to dance?”. So we started to observe how Marcos and Frenchy would teach us to dance, and started to gather together elements that would eventually make their way into the game.

NEXT SLIDE

We started to notice specific teaching techniques that we could borrow from and convert into gameplay. As an example, “verb barks” made a return to the game. We’d dropped them after prototyping, but seeing that Marcos and Frenchy both made use of them during lessons made us realize we had to bring them back

NEXT SLIDE

Watch the video. Listen to Marcos! Note that these are developers dancing, at the Dance Complex, in one of our actual lessons. Don’t they look like naturals?

NEXT SLIDE

Marcos and Frenchy had different ways of structuring and pacing their lessons.

NEXT SLIDE

So we started to collect a bunch of options for different ways of structuring and pacing gameplay. This diagram is overwhelming at a glance, but these were all potential ways for us to structure Break it Down.

NEXT SLIDE

In this example, the player watches a move once (A) and then has a chance to try it a couple of times  (AA) before moving on to a new move (B).

NEXT SLIDE

So after watching Frenchy and Marcos teach us to dance for a while, we had a bunch of options for gameplay elements that we were eager to try out.

NEXT SLIDE

But two major constraints were preventing us from trying out all of our ideas.

• We were on a tight schedule. We knew that we wanted to be a launch title for Kinect, which meant that we didn’t have unlimited time to experiment.
• We were still limited by the technology we had at our disposal. As mentioned earlier, Kinect was still in its early days. And the game itself was still not presenting a strong base on which we could start layering more complexity.

So, we had to find a way to work around these constraints!

NEXT SLIDE

The solution we came up with was to use dance class to start proving out ideas. We would get Marcos and Frenchy to run special dance lessons where they would impose game-like rules and structures onto the class. This allowed us to start trying out ideas and gather data that would allow us to better understand what would work and what wouldn’t.

NEXT SLIDE

The obvious downside to this technique was that there are some major differences between a dance class and a dance game. The formats are completely different:

• A dance class has one instructor and ~15 students.
• A dance game has a single student, and the instructor is Kinect (which is judging the player and giving feedback)

So it almost goes without saying that a number of things get lost in the translation!

NEXT SLIDE

However, this technique still proved useful, and allowed us to sidestep our constraints. We were able to prove out ideas really quickly and start to have a better idea of what to implement in the game!

NEXT SLIDE

We joked that this was our example of a paper test (but we dubbed it a “meat test”). Paper tests are useful to designers as they allow them to prove out design ideas before anything is implemented in the game.

NEXT SLIDE

And so the lesson here is that designers and their teams should always be on the lookout for non-obvious ways to sidestep constraints. There’s always going to be something that has the potential to stop you from moving forward and find answers to your design questions - but don’t just sit around and wait for those things to disappear! Get creative and find ways to work around them!

NEXT SLIDE

As another fun example of this; it took a long time for us to get new dance routines implemented and working in the game. And by that time, it would be too late to react to feedback and make changes to the routine. So we found a way to get the feedback we needed before a routine was ever added to the game. We’d shoot video footage of new routines, and then have playtesters dance along to the video and pretend they were playing the game, and then give us feedback (which moves they liked and disliked, what was too easy/too hard, etc).

NEXT SLIDE

Video. Marcos in action!

NEXT SLIDE

So after a few months of watching Marcos and Frenchy run dance lessons and pulling together the basic design for Break it Down mode, we were ready to start implementing. Our first pass of the mode looked something like this!

NEXT SLIDE

(watch video)

So now you could start to see:

• Break it Down was still called “Skills” at this point.
• Players had a lot of direct control over the experience. As an example, they could choose which part of the song to practice before heading into the game.
• Now into the game; we had a basic play structure in place. Watch a new move, and then nail it a few times to go on to the next move.
• Basic move detection was working. Players received grades for their ability to dance.
• Two modes of learning: players would learn individual moves + their names and flashcard icons, and would then hit the real test, where they’d “Put it all together!” in what we called “recaps”. Here players are tasked with acting on their memorization of individual moves, and start to learn how they are sequenced into a routine.

NEXT SLIDE

We were pretty happy with where the mode was at! We were finding that people who practiced in Break it Down tended to get higher scores in Perform It mode, which for us meant that we’d created an effective teaching mode...

NEXT SLIDE

...but unfortunately we realized that the mode was actually completely ineffective. People still held that negative stigma; why not just go into Perform It mode and practice songs “on the run”?

NEXT SLIDE

So we took a step back and thought to ourselves “how do we make people want to play Break it Down?”. It was now that we started to think about making the mode more fun and playful.

NEXT SLIDE

So when you think about gameplay experiences that are purely about play vs. pure learning experiences, you notice some key differences. Pure play experiences tend to:

• Prioritize form and function equally. Lots of pizazz and flare!
• Give players indirect control over the experience. Players master skills and systems, and use their mastery to manipulate the experience and influence things like structure and pacing.
• Game-like incentives are employed to encourage the player to engage more fully. Scoring systems and content rewards, etc!

NEXT SLIDE

So we thought “We should start to bring some of these elements into Break it Down!”

Our design goal changed from “Let’s make an effective teaching tool” to “Let’s make it fun to learn!”. We decided that we needed to think of Break it Down mode as our core game mode. After all, players would probably spend most of their time there, so it needed to be fun!

NEXT SLIDE

Break it Down mode had a number of issues that we knew we’d need to solve in order to make it fun:

• There were no incentives to play (outside of learning moves)
• Sessions took too long. We’d mimicked real dance lessons, which took upwards of half an hour. So learning a routine inside of the game simply took too long, and players got bored.
• There was no tension; no experiential or emotional difference between doing well or doing poorly in the game.
• There was no presentational flare. As you saw in the video early, lessons took place in front of a drab brick wall. And there was no fanfare when the player triumphed!

NEXT SLIDE

So to solve the presentation problem, we began to borrow presentational flare from Perform It mode, in order to build further parity between the two modes, and make Break it Down feel more like a game mode (and not a tutorial mode).

We also recruited one of our sound designers, Arthur Inasi, to voice our Narrator “Boomy the Boombox”. Arthur was able to add a certain amount of authenticity to the mode. When you hear him, you think to yourself “I want to impress this guy! I want him to be my friend!”

NEXT SLIDE

We found ways to solve the other issues:

• We added various game-like incentives. Scoring systems and other rewards.
• We found various ways to shorten lessons (which we’ll show in just a sec)
• We added tension by (for example) making it possible to “fail” out of moves and be forced onto the next.

NEXT SLIDE

We didn’t discover and implement these solutions all at once! We came up with them over a series of months, and playtesting helped us to discover them.

We have an internal playtesting department at Harmonix. They are constantly running playtests. Internal tests are run daily; employees form up into “Dance Posses” and are always playing the game and giving feedback. External tests are run with great regularity and from very early on in development. We bring in a wide range of different types of people; young, old. Gamers and non-gamers.

NEXT SLIDE

Watch video!

The point is that...sometimes we run playtests at the beach, and roll around on the dunes.

(jokes!)

The playtest department and the Strike Teams follow a process where they’re both constantly in motion and pushing each other towards a shared set of goals. The gameplay Strike Team would implement a feature that was aimed at solving one of Break it Down’s problems (no tension, too long, etc). They’d then pass this off to the playtest department, which would immediately start gathering feedback on the feature (while in the meantime, the Strike Team would move on to a new feature and a new problem). Once playtest feedback had been gathered, it would be passed back to the Strike Team, which would then iterate on the feature. This process repeated over and over again throughout development.

NEXT SLIDE

So following this process, by around May 2010, Break it Down mode was looking something like this...

NEXT SLIDE

Watch video!

You can see now that:

• Players never had to passively watch a move anymore; they could jump in and dance at any time, and if they nailed a move on the first repetition they’d receive a “diamond” score and move on immediately.
• However, if the player failed a move too many times, they would fail out of the move and receive a red checkmark. Listen out for verb barks too, which were now back and in full effect.
• Recaps were now scored, and we found ways to shorten them and lessen the number of them across the board.
• Tons of presentational flare was now in effect; we’d borrowed venues from Perform It mode and added a reactive crowd, among other small details and tweaks.

NEXT SLIDE

During one playtest, we attempted to foster a social atmosphere. We had a bunch of people playing the game free-form (choosing whichever modes/songs they wanted to play) while hanging out and eating pizza. To our surprise, people were gravitating towards Break it Down mode, which we’d never expected! Who would have thought our game’s tutorial mode would ever be played in a social setting? The real watershed moment came when one guy was practicing a song, and his friend called out “Hey are you practicing that song or just playing the game?”. The guy turned to his friend with a grin and said “I’m not sure!”. It was at that moment that we knew we were on the right track! People were now learning routines AND having fun. Success!

NEXT SLIDE

Playtesting works! And so I have some recommendations to make if you’re using playtesting in your own development.

• Designers should ensure that the playtest department is working from the same knowledge set as the designers. Make sure they understand the ins and outs of the design: the current design, changes that are yet to be made, and the reasoning behind both. Integrate the playtest department into the design process as much as possible!
• By the same token, the playtest department should integrate the designers into the playtest process as much as possible. Designers should be attending playtest sessions in-person.
• In the end, both groups of people (designers and playtest coordinators) work best when their complimentary strengths are working together.

NEXT SLIDE

And in fact, it’s best when you can involve everyone in playtesting! Artists, programmers, everyone! As an example, for Dance Central we needed to develop a completely new type of menu system. And with that were brought many interesting and tough usability issues that we had to work through. I found that it became so much easier for us to solve these issues once our UI artist and programmer start attending playtests. When they saw with their own eyes the issues that players were running into trying to navigate our menus, they were able to better help solve those issues.

NEXT SLIDE

So now we were getting close to the finish line. It seemed that Break it Down mode was in a really good place, and that we were more or less done with making design changes to it.

NEXT SLIDE

But without much time to go, we came to realize that we weren’t done yet, and would need to make some last-minute changes before we could ship.

NEXT SLIDE

The final stretch!

NEXT SLIDE

So with only a few months to go, Microsoft’s playtesting department joined our own playtesting process. They were able to bring in tons of people to play the game in a very short amount of time, and get us lots and lots of quantitative data. The data that we collect in-house at Harmonix tends to be more qualitative; interview quotes and the like, so this new data filled the gaps in our own playtesting very nicely.

In many cases we were happy to find that Microsoft’s data was complimenting our own, and confirming various assumptions that we had been making about how people would play the game, and how they felt about it. However! In some key cases, we were forced to realize that our assumptions had been incorrect. Microsoft’s data caused us to face a few angry elephants in the room!

NEXT SLIDE

First, our game was simply too hard. Many of the dance routines landed far above beginner level play, even when played on Easy. We needed to find our game’s “low bar”, and then make a massive push to recalibrate the game’s difficulty curve. But where to start?

NEXT SLIDE

We put out a company-wide call; “Do you have two left feet? Never danced a step in your life? Well then, WE NEED YOU!”

All of Harmonix’s worst, most inexperienced dancers leaped forward heroically!

NEXT SLIDE

And then we stuffed them in a van and drove them down the road to the Dance Complex for a dance lesson that would go down in history! Frenchy and Marcos brought to this special class the easiest moves that they could muster. They threw these moves at the class to see what would stick; which moves were easy enough for these guys? Which were too hard?

By the end of the class, we had a much better idea of what we needed to do in order to make the game easy enough for newcomers. We left with a better sense of how to construct Easy and Medium routines and any completely new routines from then on . And now Marcos and Frenchy had a much better sense of what sort of people might play Dance Central, and just how easy they would need the game to be. It changed the way they would design future routines.

The effect on Break it Down mode was twofold.

The first effect was that we came to realize that we needed to make Easy routines “jump-in-and-dance simple”, to the point where practicing in Break it Down wouldn’t be necessary. This meant that people probably wouldn’t spend as much time playing Break it Down as we had expected. I think that it’s good that we didn’t come to this realization until late; if we’d known this earlier, we may not have put as much effort into the mode as we did (and it’s great that we did).

The second effect was that we decided to lock players out of Medium and Hard routines until they could prove that they were ready. By playing in Break it Down mode and getting a good score, they could unlock those routines. So now, players had an extra incentive to practice.

NEXT SLIDE

The final effect that Microsoft’s playtest data had on Break it Down was to force us to realize that we had pushed the mode too far towards the “play” end of the play/learn spectrum. People were craving some of the tutorial-like direct control that we had opted to hold back from them. They wanted to be able to directly affect and control the structure of their experience, and so we found various ways to give them that control.

NEXT SLIDE

So after making some last minute adjustments, we shipped Dance Central, and the final version of Break it Down mode. Just in time for Kinect’s launch, too!

NEXT SLIDE

Watch the video.

Note the last few changes that were made. Players could now control their experience quite a bit more; new options would appear in the top left of the screen that allowed them to:

• Retry moves as many times as they liked.
• Slow moves down to get a better look at them.
• Speed the move back up when they were ready.

NEXT SLIDE

We’re pleased with how Break it Down was received by the public.

NEXT SLIDE

We’re finding that players spend a lot of their time in Break it Down mode, around 20% of all songs played. Which is a huge amount, especially when you think about how much time is spent in the practice or tutorial modes of most other games.

NEXT SLIDE

We’re also finding that many reviews have nice things to say about Break it Down, which makes us very happy. It’s not often that the media specifically calls out the efficacy of a game’s tutorial mode!

NEXT SLIDE

Looking back at our prototyping process, a few key lessons emerge.

1. Don’t be afraid to be cheap and dirty when prototyping!

We were blessed to be working at a company full of imaginative people who were able to see through a lack of polish to the game potential underneath. This allowed us to quickly iterate without getting bogged down in implementation details. If your team can learn to do this, you’ll be able to make much better use of prototyping time.

2. Take hard turns!

Exploring ideas at the extremes of your possibility space can help the team determine exactly what they are trying to create. It’s tempting to latch on to a given design and iterate on it until you’ve made it work. Save that for full production. During prototyping, only work on a given concept long enough to see its value, then, if the team has another great idea, go after it!

3. Find dead ends!

If there are concepts flying around that you think are terrible or off base, try them out in prototyping. The best outcome? You find out your assumptions are wrong and the idea is great. The worst outcome? You’ve closed off a dead end and you have a prototype that shows why a given concept doesn’t work.

NEXT SLIDE

I’ll keep this short and sweet.

Even once you hit Full Production, it can help to remain in a prototyping mindset. Remain agile! As long as you keep your high-level goals in mind (“Let’s make a game that can teach people to dance”) it can be safe to make drastic shifts in direction through the course of development (eg. in the way that we swung towards both ends of the learn/play spectrum)

And finally, teams are always going to have tough questions that need answering. “How will our game teach people to dance?” for example. I think that it’s important for designers and their teams to spend less time thinking “What are the answers to these questions?” and more time thinking “What techniques or experiences will lead us to the answers?”. If you look back over the course of Break it Down’s development, this is very true. We came up with lots of creative ways to hunt down the answers that we needed (our choreographers and dance class, interfacing with our players through playtesting, consulting with a group of people with no experience in dance), which were all cleverly hidden away but became obvious when we uncovered them. So basically, think of yourselves as a group of private-eye detectives, on the prowl for clues and information, solving various mysteries!

NEXT SLIDE

The end. We hope you enjoyed our talk!