|
 Features
Designing
Interactive Theme Park Rides:
Lessons From Disney's
Battle for the Buccaneer Gold
No one
goes to a theme park alone.
In order to create a successful interactive theme park ride, it is essential
to understand the mindset of the guests who will be experiencing it. While
many people play video games as a way to have a rewarding solo experience
free from social pressures, people almost never go to theme parks alone.
Instead, they go in small groups, with the intention of enjoying shared
experiences together. Many Location Based Entertainment titles suffer
from failure to understand this fact. Pirates turns out to be a powerful
shared experience, and one that many kinds of small groups can enjoy in
different ways.
- Boys
enjoy it in the obvious way, as an "adventure and battle fantasy"
where they can pilot a pirate ship, and man powerful cannons. While
they enjoy some communication, they stay very focused on the task of
defeating the bad guys as skillfully as possible.
- Girls
also enjoy it, but in a different way. The girls tend to help each other
more, and talk back and forth between themselves a bit more. They seem
to really enjoy the notion of "banding together" to protect
themselves against a common enemy.
- Mothers
enjoy it in ways that pleasantly surprised us. Generally, mothers at
amusement parks are less interested in having a good time themselves,
and are more interested in making sure the rest of the family has a
good time. Piloting the pirate ship becomes an ideal task for them,
because it not only affords them a good view of the rest of the family
enjoying the experience, but also allows them to tune the experience
(by steering the boat appropriately) to maximize fun for the family.
Two other
factors strengthened the social interaction of Pirates:
- Shared
visual and audio displays. Unlike some VR group experiences where each
player has their own monitor and speakers, in Pirates all the players
can be sure that all the other players are hearing the same things and
are looking at things from nearly the same point of view. As a result,
players communicate with each other in natural ways (shouting, gesturing,
and pointing), that might prove less useful with independent displays.
- Shared
input devices (cannons). We designed the game so that the gunners needed
to move around the ship to effectively deal with the enemies. The sheer
physicality of running around the ship, bumping into other players,
and quickly negotiating who uses what gun when, provides a fun and natural
social interaction amongst the group.
One potentially
"cool" feature was cut early because of the negative effects
it was having on social interaction. The original design called for a
separate "map" monitor that only the captain could see. The
idea was that by looking at the interactive map (which would show the
entire area, and track the enemies as they moved) the captain would be
able to better know where to next steer the ship, and not have to rely
on nearby visual cues. The hope was that the captain would be able to
use the map as a "God's eye view", glancing at it occasionally
to get a better sense of what was all around him, planning where to go
next, and warning the gunners of sudden attacks from behind.
Early prototypes
of the interactive map showed that captains didn't use it this way at
all. Instead, they either ignored it completely, or (more often) became
immersed in it, playing the whole game while staring at the map, and not
looking out to sea at all. This created a significant communication disconnect
between the captain and the gunners. Very often a captain "steering
by the map" would confuse the gunners by shouting for them to fire
on ships that he thought were good targets, but in reality were behind
the ship, or out of range. Sessions would begin with a lot of:
"Shoot
him!"
"Shoot who?"
"The ship on the right!"
"What ship on the right? There's nothing there!"
and end up with the captain giving up on the map, or (even worse) giving
up trying to communicate with the gunners.
Getting
rid of the map put the gunners and the captain in the same visual space,
allowing them to have useful conversations. And while we were initially
concerned that the captain "wouldn't have enough to do" compared
to the gunners (which was part of the reason we introduced the map), it
quickly became clear that in trying to:
- steer
the ship around nearby obstacles
- navigate
to distant destinations
- position
the ship so that the gunners could get the best shots at enemies
- keep
an eye on both sides of the ship to watch out for "surprise attacks"
- alert
the gunners about these attacks
the captain
had plenty to do, and he seemed to have a lot more fun doing it than when
the "captain's map" was there to distract him.
Iterative
design is crucial when creating new types of interactive experience.
As with any new medium, paving the frontier is a game of trial and error.
To reduce the risk of designing ourselves too far down dead ends during
development, we use an iterative design strategy. For Pirates we mocked
up the basic show concept - steering a ship and shooting cannons at enemy
ships - in less than two months. We were able to do this because we reused
existing in-house software tools and hardware systems developed on previous
DisneyQuest attractions. It was important to us to mock up the fun first.
By using temp sounds and quick artwork prototypes we learned early on
what dynamics were important to make the game work. This left almost an
entire year to concentrate on perfecting the balance, script, artwork,
and audio without worrying too much about the underlying game dynamics.
Throughout
the development of the project we used an interpreted scripting environment
written in Scheme that allowed us to reprogram the game while the attraction
was running live, even while guest testers were in the middle of the game.
This allowed for rapid iteration of ship behavior, cannon parameters,
difficulty settings, and general development of the game logic.
Guest testing
is always an important part of the process when developing interactive
entertainment. Guest testing assures that the designer's assumptions are
checked, game systems are properly balanced, and unpredicted social behaviors
can be understood and used to enhance the game. By testing early and often,
unpredicted issues can be dealt with eliminating expensive redesigns.
______________________________________________________
 [Back
to] Key Ideas
|
|
|
|
|
