Enterprise Game Saga Episode 2: Achievement Unlocked

This is Episode 2 of a continuing series about enterprise gamification, exploring aspects of game design that have relevance in improving the utility and effectiveness of engineering software and processes. If you haven’t already, go check out Episode 1: Press Start, which introduces the concept of gamification from this perspective.

SNES_Cont_AchieveWhat’s probably the most identifiable and often copied aspect of modern game design in most any gamification context? Almost certainly, that would have to be achievements. But what the heck is an achievement? Achievements are independent goals abstracted from the main premise of a game, and are a wholly optional aspect of enhancing gameplay or extending engagement. Outside of gaming achievements are often referred to as badging or digital badges (not to be confused with badges on the iPhone). Unlike levels, quests, or other in-game objectives, specific achievements generally have no bearing on progressing gameplay though they may be related to those in-game objectives. Earning an achievement is generally an award for completing a milestone, demonstrating a skill, or accomplishing something unusual. While not vital to the specific game mechanic, they serve to enhance, incentivize, and encourage replayability. The idea is not original – witness the merit badge system long used by the Cub Scouts, for example. The concept is generally the same. Achievements are a visible motivational tool. Though as we will discuss, there’s potential for them to be so much more than just that. Emphasis on potential, in that achievements (even within the exclusive realm of gaming) are often poorly designed.

When it comes to gamification, proponents have often latched onto achievements/badging as part of a Points, Badging, Leaderboards (PBL) model . It’s assumed that if achievements increase engagement in gaming environments they should also logically do the same for more serious software, right? Reward! Engage! Profit! The result has been a proliferation of application software decorated with some sort of badging system. Badging systems that most users immediately recognize as entirely worthless. Why? The gamification assumption is seemingly sound: if the gaming space has achievements all figured out already, adapting that perfected mechanism will surely provide similar benefit. Well, except gaming doesn’t having achievements figured out. Well that’s just great. Game Over, man.

It just so happens most game achievement design is crap. Transform that crap from the gaming world into application software and you have -you guessed it- more crap. Game achievement design is often quite literally an afterthought. Design teams are honing mechanics, graphics performance, scalability, multiplayer features. You know, important things. Achievements are often just a checkbox on the bottom of the design feature list, and it certainly feels that way. Let’s review Exhibit A, the all-too-common achievement design mistakes that plague gaming (and now your applications):

  • The Pointless Grind: Do X an absurd number of times, where X is often trivial. Because on the 10,000th iteration of X, you will inevitably undergo a life-changing transcendental experience. In that ultimate epiphany, you will eloquently articulate: I can’t freaking believe I did that 10,000 times like some kind of listless, wandering cow!
  • The No-Prize: Congratulations! You’ve done absolutely nothing! Maybe you started the first level. Or tripped over on your face. Or you exist. DING! You are a champion. In fact you’re getting one right now for reading 545 words into this article! DING! And for knowing how to read! DING! You are such a reader, you. Incidentally I also got an achievement for writing up to this point. DING! Just wait until I finish.
  • The DaVinci Code: The laughably complex. Tom Hanks squints through the twelfth window on the second Tuesday of May while holding the magical pie of obscurity. Just as the planets align stand in the second door, look to the east and on the fifth day…oh, never mind.
  • Arbitrarily: You left something running over the weekend? That must be, like, the equivalent of 30 hours of gameplay! Ding!
  • You Got All the Crap: We hid some crap in places you can’t see, so when you get tired of actual gameplay you can look behind corners, and underneath things because… well, hey what’s that over there!

If you’re convinced that game achievements are an afterthought… imagine what they are in the gamification world. Double-afterthought-combo! DING! What’s the central problem with these examples?   None of them are skill-based, and they overwhelm what few achievements are skill-based. That’s the key: the missed objective is that achievements are not engagement for engagement’s sake, but rather the promise and potential to measure skill in a visible way.

Consider this: while achievements of some sort have existed in electronic gaming for the better part of two-and-a-half decades, the concept of aggregating achievement information outside of the context of any single game was widely popularized on Microsoft’s Xbox 360. The Gamerscore system was at its core intended as a skill measurement system. The system weighed each individual achievement on the basis of perceived difficulty in order to reduce a particular user’s entire gaming experience into a composite score. That was the original allure. But there was a bit of a problem… thanks in part to the poor design of most game achievements, combined with the fact that players started mining unpopular games simply to goose their Gamerscore more or less defeated any hope of creating a legitimate skill measurement.

As we look to gamification in the enterprise we should learn from these mistakes. We should level up on the concept of achievements. What should be done is what many gamers (including myself) have long wondered… what if all achievements were definitively skill based? What would that look like? And how helpful would that be? Why not attempt to measure skill systematically, this person has a higher than usual kill ratio when pitted against players of similar skill, that person hardly ever misses a platform jump, this person has the timing of the finest precision quartz watch. Now take that concept and apply it to how people work, their proficiency with applications, that effectiveness of their work products for time spent. Given careful design over time, an organic system to measure skill emerges – and quite by accident you’ve managed to map a team’s knowledge and abilities empirically. Isn’t that what every knowledge management system has tried to achieve? Ding.

Next in the series Episode 3: Open Worlds.

  • Pingback: Enterprise Game Saga Episode 1: Press Start | E(E)()

  • Lynn Grant

    I have looked into badges to promote various aspects of Agile Development, such as giving people badges for writing blogs, or helping other teams, or that sort of thing.

    The problem is that the badges work only if people are already engaged. The people who are passionate about Agile Development are going to write blogs in any case, and the badges just serve as sort of a pat on the back.

    But the people who are not already engaged are not going to see the benefit of getting badges and, in fact, will probably seize upon them as an example of why they think Agile Development is stupid.

    So I think badges can be part of keeping engaged people engaged, by showing them that the company appreciates their engagement. But I do not think they can be used to engage people who are not already engaged.

    • Lynn, I completely agree with you, achievements (badging) will not motivate those are already not motivated. We need to look at achievements in a completely different way. Not as motivators, but as an analytical skill measurement. Used correctly, proficiency analytics could be used as the foundation of a real-time knowledge management mapping for enterprise software. There’s untapped potential to measure proficiency in any complex software such as CAD, ECM, ERP, PLM, etc.