 |
|||||||||
|
|||||||||
|
|
This past weekend my family and I did some vacationing at the Great Wolf Lodge, a massive hotel that also happens to have within it a ridiculously huge water park and many other amenities (most of which cost an arm, a leg, and sometimes an internal organ or two). While I certainly had a lot of fun at the hotel and the water park, one of the things that I spent most of my time thinking about was the overall User Experience of one of the hotel's attractions: a live interactive role-playing/questing game called MagiQuest.
The basic idea behind the game, from the player's perspective is this: you get a magic wand (and potentially other stuff like a belt or holster for said wand, plus a "tome of knowledge" to help guide you on your quests). Nearly half of the hallway space in this hotel that would otherwise remain "just a hallway" was repurposed as the setting for this game. The kids (and many grownups) go to a special forest with touch-screen monitors in the trees where they can be given quests. Once they have an active quest, they go around scavenger-hunt style "gathering" ingredients by waving their magic wand at everything from paintings on the wall to stars in the ceiling to animatronic raccoons. The game keeps track of what quests you've done, where you've been, etc. You can even go around hunting gold by waving your wand at the locks on chests, some of which tell you that you've found gold when they open.
From a technology standpoint, what you have is this: The magic wand is an IR transmitter and there are various devices with varying levels of motion/lights/bling that respond to IR transmissions. The wand sends what amounts to a GUID to each device. The device then reads the GUID, checks back with the quest server to see where you are in terms of quests, etc and then responds accordingly. This can be anything from triggering a video playing on a wall-sized screen to opening a chest to making a statue's eyes glow.
The game itself has all the hallmarks of being awesome for kids to play: persistent state, measured progress, rewards for completing tasks, unlocking of new tasks when you reach a given level, very creative interface and an extremely high degree of interactivity. What I found fascinating about it was its novel take on user experience, which I review below.
What developers should pay particular attention to here is how universal some concepts of UX are and how integrated technology AND design are when it comes to producing both good and bad experiences.
What I found utterly fascinating was the use of what would otherwise be completely dead space in the hotel and turn it into a space that is not only useful, but revenue generating, fun for the kids and a space that creates fond memories that can increase customer loyalty and brand recognition.
The software that runs the system is somewhat forgettable. It actually is pretty cliche, most of the screens that users interact with look kind of like scrolls or unfurled maps and everything is done in a medieval font. But what I think developers should take note of is that nobody remembered the GUI. Everyone remembers the experience they had running around the hotel looking for hidden objects and solving puzzles and getting their parents help to decipher clues. It's all about the experience.
While this was a truly awesome User Experience, there were also a lot of pain points, many of which were visibly frustrating the kids and driving the parents insane (myself included).
Just about everyone who has written server-side software or even many types of multi-threaded client applications is aware of the problems inherent with performing multiple tasks at the same time. These problems occur in software where two different requests occur at the same time (or nearly the same time). If the application is poorly designed, these types of requests can create inconsistent data at best or at worst cause ugly crashes. The hotel's game has this problem too : if two kids run up to a quest painting and wave their magic wands at it the painting lights up and gives the "congratulations" speech indicating that the kid got the item. The problems is, how do you know which wand triggered the painting? Kids have neither the patience nor the understanding of how crappy software works to be able to guess, "Hey wait. We should both try that again serially to ensure that we both got the quest reward." ... Hell no, the kids see the painting light up and both assume they got the reward. The kid who lost the race condition doesn't find out he lost until he goes to slay the dragon and finds out he doesn't have the Gem of Awesome or whatever.
There are few things you can do to screw up someone's impression of your application more than making it run slowly. This is especially true for non-technical users. "Regular" people don't give a crap about latency, network bandwidth, wireless radio interference, or any of the other excuses that us technical people can handle for poor performance. Regular people push a button and they want that button to do something, immediately. Kids are even less tolerant. Right around 9:30pm or so, about a half hour after the pool closes and every kid in the hotel has had a chance to change out of their bathing suits and into regular clothes - a swarming horde of kids descends upon the quest-enabled hallways. I've seen this bring the system to its knees. Kids wave their wand at the final encounter with the dragon. They know the dragon video is supposed to come up so they can start the routine to defeat him. But the dragon doesn't come up... So, the kids wait patiently until the request queue clears enough to allow the video cue request to come up, right? Hell no. The kids just start wanding the activation stone over and over again. Worse, multiple kids do it at the same time. So now when the system finally does unclog and is able to start servicing requests, instead of cutting the queue short, it processes them all, so the dragon spits, spasms, twists, contorts, makes a bunch of funny noises, and then 30 seconds later is congratulating the last kid to wave his wand... and nobody knows who got the reward.
Everybody has a different word or phrase for this user. This is the user that never pushes the right button, never waits for the system to finish doing what it's doing before pushing more buttons and always manages to find a way to completely screw up a system or put it in a totally confused state. The thing about this application that I can imagine was particularly difficult is that every single user of this application is a devil user. You cannot assume that anyone is going to "play nice" with the game... Especially when the interaction involves physically shaking a wand they're holding in their hands.
I think the single most important thing that stuck with me after this weekend was that the kids weren't talking about the cool screens in the application. None of them were talking about how awesome the back-end server infrastructure must've been. Nobody cared about the use of IR plus an accelerometer to "cast" the wand. Instead everyone remembers playing the game. They remember what it felt like to have their imagination stimulated, to solve puzzles, to experience the game. They do not remember interacting with the game unless the interaction was frustrating. You can screw up a User Experience very easily whether you are talking about a novelty live-action game at a hotel or whether you're talking about your company's corporate website.
The moral of the story here is that as developers, whether we're building iPhone apps or live-action interactive RPGs or enterprise websites, we should be thinking about how we can create a compelling experience and a truly forgetful user interface.
