The proceedings of the 2011 MindTrek conference are finally online in the ACM Digital Library, and with it, the paper I co-wrote with Rilla Khaled, Dan Dixon, and Lennart E. Nacke on “defining the damn thing” – that thing being “gamification,” of course. Here’s the abstract:
Recent years have seen a rapid proliferation of mass-market consumer software that takes inspiration from video games. Usually summarized as “gamification”, this trend connects to a sizeable body of existing concepts and research in human-computer interaction and game studies, such as serious games, pervasive games, alternate reality games, or playful design. However, it is not clear how “gamification” relates to these, whether it denotes a novel phenomenon, and how to define it. Thus, in this paper we investigate “gamification” and the historical origins of the term in relation to precursors and similar concepts. It is suggested that “gamified” applications provide insight into novel, gameful phenomena complementary to playful phenomena. Based on our research, we propose a definition of “gamification” as the use of game design elements in non-game contexts.
Here’s the link to the ACM digital library download: http://dl.acm.org/citation.cfm?id=2181037.2181040
And here’s the presentation:
From Game Design Elements to Gamefulness: Defining “Gamification”
It’s been a while since we wrote this paper (almost a year, actually), and my own thinking has changed a bit since – if anything, I have become even more sceptical of what on earth a “game design element” could be, let alone how to determine whether X “is” or “isn’t” one. So just between me and myself, I’m ruminating whether just saying “using game design in non-game contexts” might be enough and even less problematic. Other than that, I think the paper holds up quite well. So enjoy :).
Reference
Sebastian Deterding, Dan Dixon, Rilla Khaled, and Lennart Nacke. 2011. From game design elements to gamefulness: defining “gamification”. In Proceedings of the 15th International Academic MindTrek Conference: Envisioning Future Media Environments (MindTrek ’11). ACM, New York, NY, USA, 9-15. DOI=10.1145/2181037.2181040 http://doi.acm.org/10.1145/2181037.2181040
Re: game design elements…
I too, am a bit confused of where you are going with game design elements 🙂 You talk a bit about atoms/ludemes (which have never really been enumerated and just sort of hand-waved at, but are a compelling idea), but towards the end you write “One
solution is to treat game elements as a set of building blocks or
features shared by games (rather than a set of necessary conditions
for a game)” It’s hard for me to read that and not think of game design patterns, which you cite further down under your design section.
I’m not sure why you’re separating game design patterns in this way. Gameful design has never seemed, to me, to be borrowing DNA at a ludeme level, but at the higher patterns level. Ludemes have always seemed to be developed top-down, taking game patterns we have and breaking them down in the hope of finding some means of expressing game design without ambiguous words. I don’t see how gameful design study benefits from going to ludeme level.
Hopefully you can enlighten me, as it is a bit late here 😉
Hi Chris,
thanks for your incisive comment: It puts the finger right in the wound I spoke of in my post: What on earth is a ‘game design element’?
With regard to “atoms”, we alluded to Brathwaite & Schreiber’s (2009: 25-40) use of the word in their book “Challenges for Game Designers,” which as you will see is a much looser, broader notion of “atom” than the whole game grammar debate about ludemes, skill atoms, game atoms etc. (But I think there is value in that, see below).
Why not just say “game design pattern”? The main reason is that to have a definition that covers the current set of real-life implementations, we didn’t think it feasible to restrict a definition to one level of abstraction or granularity, which “game design patterns” arguably would have done. For instance, if you use overarching conceptual models or methods from game design (more abstract), or “just” interface design patterns (more concrete), these wouldn’t have been covered by game design patterns as understood by Björk and Holopainen.
* * *
So on to the larger issue lingering underneath: It is conceptually hard to make sense of the “elements/components/aspects/patterns of source
domain X in target domain Y”, precisely because elements/… are usually
domain-bound languages. It’s always a kind of analogy, like speaking of
the “anatomy” of a house with a “brain,” “lungs,” “heart,” “arteries,”
and so on. There may be direct morphological or functional symmetries,
and it’s sometimes helpful to tease those out to help understanding or
provide inspiration. But even if you would build, say, a ventilation
system in the direct, immediate image of a human lung, you wouldn’t call
this the “anatomy design element” of the house. You would call it
ventilation.
As I noted in another presentation, the *conceptual* issue with current
implementations of “gamification” is that they encompass either (a)
elements also found outside of games (goals, rules, feedback) or (b)
elements which are sold as “gamy” by vendors, but have no necessary
conceptual tie to games (e.g. notification streams or incentives). The
first point basically reiterates the issue that what a game “is,”
following the traditional definitions of Salen & Zimmermann or Juul, is
a set of multiple necessary conditions, none of which in and of itsels
has any Platonic “gamy essence” to it. So once you have a full-fledged
game in front of you, it makes perfect sense to analytically tease it
apart into these elements or conditions. But to speak of them as *game*
elements is only sensible as long as you’re speaking with regard to that
game, or the larger domain of game design. That’s why we opted for an
admittedly vague and blurry Wittgensteinian family resemblance notion of
“elements characteristic for games” instead.
But even with that, you run into the issue that an element in domain X
often also exists in domain Y (and Z and …), albeit possibly under a
different name. Goals is a good case in point: Goal-setting is
well-studied in psychology as a motivational strategy, it’s pervasive in
business as well as self-management, it’s implemented in many e-health,
business, persuasive technology … applications – *and* it is a core
element of games. So if an application like RescueTime allows users to
set themselves goals – is that now suddenly a “game design element” (or
“game design pattern”)? That’s the cause of my discontent with a felt
99% of Internet chatter about gamification: People take a given
design/site/app and retroactively describe it using some (alleged) game
design terms, with the foregone conclusion that this “explains” the
“success” of that design/site/app. But that’s just a language game of
post-rationalisation and marketing.
So on the one hand, it makes intuitive sense to speak of “game design
elements”, but on the other, it’s Pandora’s Box once you try to pin down
whether something “is” a game design element or not. That’s part of what
brought us to suggest “gameful design” over “gamification”: Because it
defines what you do not via the tools or building blocks you use, but
via your design goal – a specific experiential quality (or set of
qualities) you aim for. Likely, you will end up using many of those
building blocks; but you will also likely involve less concrete aspects
of game design as well, e.g. design methods, conceptual models, etc.
* * *
In reaction to that, I have lately warmed toward the notion of “lenses”
as used by e.g. Jesse Schell or Bill Scott
(http://www.uxbooth.com/blog/designing-with-lenses). A lense is a
specific design principle through which you evaluate and approach a
design, broken down into a set of questions you ask of the design. As I
see it, design lenses are enabled and facilitated by the vocabulary,
conceptual models and methods of a design practice from which that lens
“originated”.
To me, “skill atoms” or “game atoms” are maybe the most valuable lens
you can take from game design. Whatever design or interaction you
encounter, you can ask: “What’s the learnable challenge here?” “What’s
the goal, action/input, rule, feedback/output?” And then a small army of
further lenses/principles flows from that that tie either into the
global skill atom (variation, scaffolding, lacking challenge, etc.) or
its “subatomic particles” (juicy, variable feedback; interesting
choices; clear, nested goals; …).
Now you may ask: Isn’t that just design patterns under a fancy new name?
I think not. A lens is a perspective you assume, a question you ask that
comes with an apparatus of concepts and practices (you might say its a
miniature version of what Schaffer calls “epistemic frames”). It allows
you to see things as problems which wouldn’t count as problems from the
perspective another lens. A design pattern, by contrast, is a proven
solution for a known, recurring problem.
Let’s compare this to a typical situation in user experience design: A
usability engineer might view a design through the lens of “visibility
of system status” and find it perfectly okay, whereas a marketer might
view the same design through the lens of “brand” and find that it is not
on brand. Both have languages, concepts, practices to evaluate whether a
design is “on brand” or “making the system status visible,” both have a
lexicon of design patterns in the back of their heads how to make a
design address those issues. But crucially, the lens doesn’t prescribe
or limit them to those patterns: They see a problem and have ways to
analyse and solve it, and in the course, they might innovate a solution
that works better than existing patterns. And disconnected from the
lens, from an understanding whether or why something is a problem at
all, they are “solutions in search of a problem”. Which is precisely the
issue with most current slap-on-points-implementations of gamification.
Am 27.04.12 09:06, schrieb Disqus:
Aha. I see what you’re going for now, and it makes perfect sense to me.
I actually sat here and typed a much longer comment, which essentially just ended up being a retreading of your final paragraph, so I take that as explicit validation that I completely agree with your POV 🙂
It’s a shame we do not yet have good ways of attaching addendums to papers; this would be a useful piece of extra thought to put along with it.