From Game Design Elements to Gamefulness: Defining Gamification

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: