Gamasutra is part of the Informa Tech Division of Informa PLC

This site is operated by a business or businesses owned by Informa PLC and all copyright resides with them. Informa PLC's registered office is 5 Howick Place, London SW1P 1WG. Registered in England and Wales. Number 8860726.


Gamasutra: The Art & Business of Making Gamesspacer
GDC 2001: Interactive Theme Park Rides
View All     RSS
October 18, 2019
arrowPress Releases
October 18, 2019
Games Press
View All     RSS







If you enjoy reading this site, you might also want to check out these UBM Tech sites:


 

GDC 2001: Interactive Theme Park Rides


July 3, 2001 Article Start Previous Page 3 of 3
 

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.

______________________________________________________

 

 


Article Start Previous Page 3 of 3

Related Jobs

University of Exeter
University of Exeter — Exeter, England, United Kingdom
[10.18.19]

Serious Games Developer
Wargaming Sydney
Wargaming Sydney — Sydney, New South Wales, Australia
[10.17.19]

UI Programmer
Deep Silver Volition
Deep Silver Volition — Champaign, Illinois, United States
[10.17.19]

UI Artist
Mutant Arm Studios
Mutant Arm Studios — Bend, Oregon, United States
[10.16.19]

Technical Game Designer





Loading Comments

loader image