The Puppet Master Problem: Design for Real-World, Mission-Based Gaming
Tuesday, 24th January 2006 Jane McGonigal, Game designer, 42 Entertainment, and researcher, UC Berkeley Download video (wmv)
When gamers interact with their environments... probing often
takes the form of seeking out the limits of the situation, the
points at which the illusion of reality breaks down, and you
can sense that it’s all just a bunch of algorithms behind the
curtain.
Puppet master: An individual working "behind the curtain" to
control the game. Puppet masters are the first real-time, digital game designers. An invisible creative team composed of shadowy, often anonymous figures, they work behind the scenes as the writers, programmers, directors and stage managers of live pervasive gameplay. In a cross between a digital dare and street theater, puppet masters challenge gamers to take their gaming public, to create face-to-face community with other gamers, to play in environments they wouldn’t normally play, to interact with strangers they wouldn’t typically acknowledge, to make spontaneous spectacles of themselves, and to rewrite the social rules of a given space in highly visible ways. I am a puppet master. This talk will explore two sets of problems posed by the growing popularity of puppet mastered experiences: alternate reality games like ilovebees and Last Call Poker; mission-based pervasive games like the Ministry of Reshelving and the Go Game; public social games like Tombstone Hold'Em; and gaming contests like Hex168. I will present some of my experiences puppet mastering these various projects, and then discuss them from both research and design practice perspectives. The first problem set belongs to the gaming theorists and to gameplay ethnographers: Why would any gamer agree to be a public "puppet" of an anonymous game designer? Where is the fun in such a rigid gaming structure? And furthermore, where is the propriety? To some critics, such an unbalanced power dynamic seems a bit perverse; to others, it seems downright dangerous. The second problem set of this essay belongs to the game designers: How do you structure a game so that you can effectively, and remotely, ‘pull the strings’ of dozens, hundreds, or thousands of players without making them feel like mere puppets? How do you develop the puppet master-player relationship into a collaborative one, and what real-time recourses do you have to actively manage that relationship? I will offer a series of critical frameworks for understanding both the pleasures of the puppet mastered experience and the real-time design strategies that support those pleasures. |