The final
prototype of Dysphoria implemented
our core game mechanic, more or less the way we’d specified it in our original
design document. Whether we achieved our
other design goals in terms of theme, aesthetics, representation and narrative
appeal… well, that’s another story.
Our very
first design constraint to be committed to paper was, “Manipulate the world,
not the character.” Our second
constraint was to use some kind of surreal aesthetic. Rotoscoping was a nice choice because it
reflected our theme of insomnia and neurosis (our third design constraint), and
also because the constant fluctuation of rotoscopic graphics helped to express
the sense of the character’s identity, moods and environment being in constant
flux. That’s how it made sense to me,
anyway, but it’s not something I would have thought of myself, as I am not
artistically or aesthetically minded (the rotoscoping constraint was Vignesh’s).
We knew that:
-
Player
and character are separate. The character should never be controlled
directly. Rather, the character has
his/her own goals, and while the player can influence those goals by attempting
to evoke different moods or interactions with objects placed into the world, there
is no way to directly control the character.
- The character should have dynamic and meaningful interactions with objects. Interactions should have a cumulative nature and a lasting causal effect. They shouldn’t be transient events that pop up amusing animations and then disappear without a trace.
To this end,
we implemented the DREAMS framework, in which the player had six mood stats (Disbelief,
Rage, Enervation, Anxiety, Mirth, Sulkiness) that would change as he/she
interacted with objects, and that would affect the nature of future
interactions. The DREAMS stats were selected
based on their ability to reflect the kinds of reactions the character might
have to the player’s manipulation of the world:
·
Disbelief:
the extent to which the character is incredulous as to the reality of events occurring
around him/her.
·
Rage:
the extent to which the character is really pissed off about what’s going on.
·
Enervation:
the extent to which the character is physically and emotionally exhausted.
·
Anxiety:
the extent to which the character is nervous and upset about what’s going on.
·
Mirth:
the extent to which the character is amused and enjoying the humour of the
situation.
·
Sulkiness:
the extent to which the character is being sullen and self-pitying.
I spent
about an hour trying to see if I could come up with a decent acronym, before
settling on DREAMS. I was inspired in
part by other clever character-stats acronyms, like SPECIAL (strength,
perception, endurance, charisma, intelligence, agility, luck) from the Fallout series. Character stats are a bit of an old and tired
game mechanic, and I think players are acutely aware of the awkwardness of
quantifying subjective and transient characteristics like mood, so having the
acronym was an attempt to ground our use of a stat-based system in our theme.
Our Core Mechanic: Did It Work?
According to
Zimmerman (2003), the core mechanic is “an action or set of actions that
players will repeat over and over as they move through the designed system of
the game.” Furthermore, “the prototype
should help you understand what this core mechanic is and how the activity
becomes meaningful over time.” In
Dysphoria, the core mechanic is as follows:
SETTING:
Character is
a semi-autonomous agent with own goals and stats.
ACTION:
Player
assesses character’s goals and stats, develops his/her own objectives, and
introduces objects into the environment in an effort to manipulate the
character in the desired way. The player
has no way of knowing for sure how the character will interact with a given
object, but he/she can make an educated guess based on the character’s moods
and behavioural patterns, as well as the nature of the objects themselves.
RESULT:
The player
interacts with the object, which produces some change in the character (i.e.
mood stats), thus unlocking the potential for new kinds of interactions. The player may see new ways to achieve
his/her objectives for the character, or may modify his/her intentions.
The mechanic
becomes meaningful over time as previous choices create and exclude new
possibilities, but also as each choice has an emotional effect on the character,
whom we wanted players to experience as a living, feeling human being, in spite
of his/her apparent lack of identity.
Our end prototype only implemented a handful of objects in one room. While it demonstrates the principle that
object interactions affect moods which determine the possibilities for future
interactions, and while it also had some interim objective (get the character
into a state of mind that will induce him/her to leave the room), it plays out
this mechanic in a simplistic and small narrative space, thus limiting the
potential for players to actually care about whether actions are meaningful or
not.
Narrative and Meaning-Making Goals
We wanted
the character’s progression through the day to be wholly dynamic, but we
envisioned two basic styles of play. On
the one hand, players might attempt to introduce objects to provide a
therapeutic environment for the character, thus helping him/her to get out of an
emotional rut and become productive again.
However, players could also choose to be somewhat sadistic, and attempt
to frustrate the character at every turn.
We saw the therapeutic objective as the game’s “primary” goal (using the
tools at your disposal, help this person to have a good day and to sleep easy
tonight), but we wanted the sadistic objective to be possible (screw with this
person for your own amusement). We
anticipated that the game would ultimately end with the character going to
sleep, whether because he/she was able to relax and improve his/her mindset, or
because he/she eventually collapsed from exhaustion following a harrowing day
of frustrating object interactions.
Either way, we wanted the player to feel like his/her actions were
meaningful, like they had an effect on the character’s life. As Laurel says, “being able to see the effect
of our actions is what gives us a sense of agency or personal power” (2001: 68).
Lazzaro and
Keeker (2004: 1) suggest seven user-centered goals for video games. While our original design sought to satisfy
all these goals, I think that our end prototype was not completely
successful. This might have a lot to do
with our lack of playtesting on the final prototype (during playtesting
sessions, we had others observe and interact with our game, but our prototype
was at that time very limited and not fully functional). The class’s reaction to our final
presentation may be somewhat instructive in assessing our achievement (or lack
thereof) of some of Lazzaro and Keeker’s user-centered design goals:
·
Entertainment:
well, people laughed at our animations, and seemed to enjoy the idea of playing
around to find out what objects could create what kind of whacky cartoon
animations.
·
Fun
to beat obstacles: in our prototype, we really only implemented one set of
obstacles. There is only one way to make
the character leave the room (max out sulkiness, which can only be achieved by
engineering an accident on the tyre swing).
In a more complete game, there would be multiple ways to get the
character to leave the room, and different kinds of interactions would be
available in the next room depending on the circumstances under which the
character left the first one. We didn’t
want fixed obstacles that users could only achieve by jumping through a series
of hoops in the right order. We wanted
the obstacles to be weakly determined, and to depend on what the user hoped to
accomplish.
·
Intrinsic
rewards: we thought that helping a character feel better or be more productive
might be an intrinsic reward. This goal
isn’t really achievable in our prototype though. It is fairly easy to make the character
frustrated, though. So the only real
intrinsic rewards our prototype offers are the generation of funny animations
when the user messes with the character’s head.
And that’s why people laughed, I guess.
·
Process
as its own reward: again, present in our original design, not emergent in our
limited prototype.
·
Assumes
humans need to be challenged: actually, more interesting here is that the
character needs to be challenged by the user… again, something that didn’t
really come through. Our prototype seems
to be more about “messing with this dude’s head” than it is about generating a
series of constructive events to create good cognitive effect.
Aesthetic Goals
Our final
visual assets were certainly not quite what we had all envisioned at the
beginning. They look unrefined and lack
an aesthetic consistency. I think this
is in part because we had this idea that we wanted rotoscoping and a
silhouette, and we should have been iterating sketches thereof early on, but
our artistic iterations ended up being separated by spaces of a couple
weeks. So we never really refined our
overall look-and-feel. Not only should
an ideal, refined look-and-feel play into our central themes (refer back to my
second paragraph), it should also be compelling and immersive, so as to create
a sense of connection with the game space and the character therein. (I feel like our unrefined assets and lack of
visual dynamism more likely created a sense of disconnect).
Affordances
We planned
from the beginning to provide a limited interface into this game world. Unlike in most games, the player cannot
control the character directly. The only
interface is through the introduction of objects, which should provide some
feedback to the user. We originally
wanted a lot of freedom in where users could place objects. We would provide a number of “anchor points”
but in general, an object could be placed anywhere it made sense – for example,
the tyre could be placed on any patch of open floor, the hose hung anywhere
along the ceiling. In our final
prototype, we severely limited the size and number of anchor points so that we
could get our animations to work without looking like crap and without having
to test for a bunch of special cases (where do we position the character in
order to have him/her kick the tyre, if we aren’t sure where exactly the tyre
is?). We used the technique of highlighting
(Norman 2004) to indicate actionable objects and areas of interaction – when the
user picks up an object from the gallery on the right-hand side, all its
possible anchorable locations are highlighted in the main view.
Norman
(2004) asserts that “we care much more about what the user perceives than what
is actually true” – which is to say, implemented mechanics don’t matter if they
don’t entice the user to take advantage of them. But since I was responsible for writing most
of the game’s code, I was much more interested in the implementation of
affordances, and specifically in the idea that each individual piece of code
provides certain affordances to other pieces of code. The user interface isn’t the only important
interface. How the core game engine is
designed has an effect on what is possible, and also on how easy it is to
implement new objects or new features. Farmer
and Morningstar (1990: 736) say that the implementation of presentation is not
nearly as important as presentation itself, yet they also, in an apparent
contradiction, say that “an object-oriented data representation is essential” (1990:
735). In other words, the data
structures we use are important determiners of what we can accomplish. Central to Dysphoria’s game engine is the
character’s Goal Queue. We figured that
the character has a set of goals with associated actions that will be carried
out in a certain order, and these goals may change over time. We needed a data structure to represent
this. The Goal Queue is implemented as a
Deque, which stands for Double-Ended Queue.
A Deque is a data structure that can store a list of objects in
order. Objects can be added to or
removed from either the front or back of the queue. In this case, objects were Goal objects that
we implemented to store the characteristics of where/when an action should
occur, as well as the details about how to carry out the action itself. A goal could be something like, “Walk to the
left-hand side of the room, then pause.”
Introducing new objects could generate new goals. For example, if the tyre is introduced, a new
goal could be added that makes the character walk up to the tyre and kick
it. We always remove goals from the
front of the queue, but because the queue is double-ended, we can add goals to
either end. This means that low-priority
goals can be added to the end of the queue.
They have to get in line and wait their turn to be fulfilled. High priority goals can be put directly on
the beginning of the queue and can thus pre-empt existing goals. For example, if a freakin’ bird were to
suddenly appear in the room and start flapping around, this would probably be distracting
enough to make the character abandon, or at least delay, his/her current goals.
Goodnight, Dysphoria
Obviously a
significant gap exists between our original design goals and what our prototype
actually accomplished. However, at least
the prototype does implement and demonstrate the basic interaction and the core
mechanic, which hopefully provides a workable framework for expansion and
refinement.
REFERENCES
Farmer, F.
Randall and Chip Morningstar. 1990. "The Lessons of Lucasfilm's
Habitat." In Salen and Zimmerman (eds), The Game Design Reader. Cambridge,
MA: MIT Press, 2006.
Lazarro, N.
& Keeker, K. (2004). "What's My Method? A Game Show on Games." In
CHI 2004 Conference Proceedings, April 2004.
http://www.xeodesign.com/whatsmymethod.pdf
Norman, D.A.
(2004). "Affordances and design."
http://www.jnd.org/dn.mss/affordances_and.html
Zimmerman,
E. (2003). "Play as research: The iterative design process." http://www.ericzimmerman.com/texts/Iterative_Design.htm
Comments