From Game Design Elements to Gamefulness: Defining Gamification

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

Here’s a download.

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

email
  • http://twitter.com/Lewisham Chris Lewis

    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 ;)

    • http://codingconduct.cc Sebastian Deterding

      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:

      • http://twitter.com/Lewisham Chris Lewis

        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.