The Chief operating officer, our marketing officer and I were discussing our website the other day and trying to determine what we will continue to offer to our service customers. We came across the entry for ‘Gamification’ and a discussion ensued about whether that was a service we would continue to offer as we move closer towards our goal of doing purely game development, rather than general application development.
The word ‘gamification’ made me cringe. We have done a number of successful gamification projects, and serious games but I have recently become concerned at what gamification has come to mean in the marketplace.
I recently read an article on Gamification entitled “Why Gamification is a Bad Idea”(https://byresearch.wordpress.com/2014/05/18/why-work-gamification-is-a-bad-idea/) and here is what the author of that article believes gamification is:
“the use of game thinking and game mechanics in non-game contexts to engage users in solving problems”
Now I don’t have any difficulty with this definition, but here, in concrete terms, was what that also believed was involved in implementing gamification:
“Typical game mechanics are scores that are earned for mastering certain activities, badges, so-called level-ups and finally a scoreboard, often to rank players”
and therein lies my problem with the current understanding of gamification. It all comes down to badges, level-ups and scoreboards. Unfortunately many attempts at gamification reflect this hollow understanding and in those cases many of the criticisms that author of the article ‘Why Gamification is a Bad Idea’ has of gamification aptly apply. Let me give you some reasons why your attempt to gamify your business processes will not succeed if you attempt to implement the ‘badges, level-ups and scoreboards’ approach.
Badges/Awards and Achievements
If you can take the system or process that you are trying to gamify and divide it into rewardable challenges you can gamify that system or process by offering badges as each is achieved. For example let’s say you are trying to gamify the process of resolving support calls. You might offer a badge for achieving ten resolutions in a day, and another for resolving twelve in a day, and so on. You might also offer badges for getting a five out of five for customer satisfaction and another award for getting five of those in a day.
There are two primary problems with badges. Firstly, badges have no intrinsic value and not everybody is motivated to collect these virtual tokens. When we implement achievements in games we implement them recognising one player type, the achiever. I will come back to this later.
Secondly, they are finite. In fact, to someone who is motivated by badges it is important that they can collect the whole set. How do you keep engaging people once they have collected all the badges? I suppose you could come up with badges, appropriately spaced to cover a lifetime but that would be frustrating to someone trying to collect the set.
The truth of the matter is, even in games badges and achievements are not primary motivators. What they are good for in games is promoting replayability. If you finish the game without all achievements you might replay areas to try and collect them.
The scoreboard, or leaderboard, while it seems like healthy competition, suffers from some serious drawbacks. My biggest problem is that these are often exclusionary, something of interest to those that will occupy the top spaces, and perhaps a few that fight for the bottom of the leaderboard. I played hundreds of hours of Ubisoft’s “Assassin’s Creed: Black Flag” and in all that time I had absolutely no interest in the leaderboard. It wasn’t until a screen alert informed me that I was the 7th deadliest assassin in my region that I paid it any attention, and this is in an actual game. Of course once that happened I competed to become the 6th, 5th and eventually 4th deadliest assassin.
The reality is, if you have a hundred employees and some task scoreboard that shows the top five you could be excluding and marginalising ninety five employees. This is made worse by linking that performance to some real world prize or bonus. For more information on that check out Daniel Pink’s video ‘Drive’(https://www.youtube.com/watch?v=u6XAPnuFjJc).
I have seen improvements to scoreboard systems that do get more engagements Having little motivators that occasionally tell you that the next position is in reach have proved to be useful. If you get a message to say “You are currently in position 17, if you make two more calls you will be in position 16” you might well stretch yourself to get to position 16”. However even these only work towards the top of the scoreboard. Imagine how demotivating is the message “You are in position 1237, if you make two more calls you will be in position 1236”.
A level up is a permanent change of status conferring extra privilege on the recipient once they have achieved some specific goal. In general these suffer the same drawbacks as badges. However they do indicate progress, but what is progress in a system or process. Mostly we want a system or process used the same way each time. The goal of gamification is engagement rather than progress. However some tasks, such as training or induction are inherently about progress and may suit the use of leveling.
Let me propose another definition of gamification.
Gamification is the use of game techniques to create measurable improvements in engagement with a system or process.
The word ‘measurable’ is key here. The improvement you are trying to make should be concretely specified. If your concrete goal is something like:
“We want a 20% improvement in engagement”
you just failed this step. Concrete goals must be codable so they should be specified in terms of measurable outcomes. For example:
“We want a 20% increase in the number of people that complete this course” in a gamified training course; or
“We want to increase the average number of support issues closed per day by 10%” in a gamified help desk centre.
Note that neither of these two goals mentions engagement or gamification. They are real world result that we hope to achieve through gamification.
The next step in gamification is to know your audience. Richard Bartle came up with a classification of video game players which has come to be called the Bartle Taxonomy. Bartle concluded that there were four basic types of players, based on the interactions between players and the environment or other players. The are:
In short, achievers like to get badges and achievements; Explorers like to explore your game and maps thoroughly; Killers are highly competitive and Socialisers will exploit any messaging aspect of your game to socialise. We have also added Nurturers to the list. These people like to create and build things, for example farms, towns, mafia clans. In Bartle’s quadrants these look like explorers but their behaviour is sufficiently different to warrant their own group.
We are all a mixture of these types. I have blogged about this taxonomy previously, and many people have heard me talk on the subject. The important thing is, to ensure you know your audience and decide who you are going to support.
The third thing to understand is whether your system or process, the thing you want to gamify, is something that is enduring (eg. a CRM system at work) or discrete, something that is worked through from beginning to end (eg. a training course).
If the the system is discrete, such as a training course or a course of rehabilitation then the gamification is easier because we know where the end is. Levelling and scoring are easier to determine. If it is enduring then it is harder. If you are implementing levels and rewards then these must be continuous and still have the engagement impact a year on that they had in the beginning.
Most of the systems we have implemented have been discrete. Here are a few examples:
Now, enduring systems are harder, as I have said, so I am going to give you some techniques that we have employed. Hopefully this will give you some ideas about gamifying your own systems.
An enduring system we have worked on was for health and wellbeing. We learned a lot of lessons with this. For achievers awards and achievements were linked with things of value, such as unlocking of recipes, master classes or videos of advanced exercise routines. This reward system worked both ways. The badge or award associated was regarded as having real value and the unlocked recipe or exercise tended to be actually used since it felt like privileged content. We implemented clan building, based on mentoring of other players, providing a hook for socialisers and nurturers. Competitions encouraged killers and puzzle pieces hidden in content leading to hidden content encouraged explorers.
Now, the problem you might spot here is that the elements of gamification can literally run out. That may be ok if the goal was to encourage the habit of using the system. If you want to keep the gamification running you would need to keep refreshing the content, adding new elements over time. That is certainly a retention strategy within the games industry. However, for the awards and achievements implement these in discrete sets to ensure that achievers don’t get frustrated at not being able to complete the set.
The other lesson I have learned in the games industry is to use metrics heavily to search for friction points in your process or system. These should be implemented before gamification and enriched during the gamification. I can’t stress this enough. Inspiration may be a key to innovation but objective metrics are the key to improvement.
So, you’ve had a stellar idea for a video game, but you don’t know the process? About once a week I get an email asking me, what are the steps to building a video game. Mostly the enquirer knows that they need art and programming, but the process is a mystery.
We have a workflow that we have refined since the early days at Stickmen Studios where we developed “Dragon Master Spell Caster”, “Kung Fu Funk” and “Doc Clock: The Toasted Sandwich of Time”. While its not the process you would necessarily use if you were a single developer pushing out the next iPhone “Floppy Turkey” game it is useful to see what the bigger process looks like.
You need to be able to communicate your idea to others, so the first step is to write a Game Concept Document (GCD). I usually start with a three page description of the game.In that short document I would describe the following items briefly if they make sense in your game:
This simple document will be used to communicate your idea to your team, in particular to anyone working on early concept. More often than not games start with a concept artist adding pictures to your concept document.
I tend not to favour descriptions in the form called “High Concept” that they use in film development. This is where you describe your game(or film) as a cross between two other games (or films) for example, “Its a cross between Bambi and Godzilla”. This has always seemed to me as a way to instantly convey the wrong impression. Would this film be a pointless struggle between a newborn deer and a 50 storey high monster; or is it the tearjerker story of a poor little monster who loses its mother to jet fighters in down town Tokyo. We’re not so word poor that we can’t write at least take a paragraph to explain our game.
The concept document will be expanded into a document called a Game Design Document (GDD). You will expand on all the items above, making each a section in your GDD. You will also add some sections such as:
You will get concept artists to create your characters and environment. They will fill in the details about the look and feel, and you will have some examples showing parts of levels.
The GDD is your game at this point. It will help you get interest in your project; raise money; get greenlit for release; and get a title code for consoles. By the way, if you want to develop for consoles you will need to become registered. Microsoft, Sony and Nintendo have processes to do this. When you have a GDD you should submit that to the console providers BEFORE you start developing in earnest. As part of their review process they will make suggestions that can solve a lot of problems early.
In a big game you may find you end up extending sections out into their own document. An Art Design Document (ADD) is common as it helps to coordinate a number of artists to produce the same look and feel. Check out an explanation here.
For our team the next stage is a vertical slice, one playable bit of your game. This will initially be done with rough characters and artwork and will demonstrate the fun, the game play. As I said, you will iterate over this until you have something you will enjoy playing, even with primitive or non-existent artwork.
Once the game has been funded the heavy work begins. The studio ramps up to the required capacity. Concept artists create orthographic views of characters and items in the environment. Modellors turn these into 3D models. Artists create textures for the models that are consistent with the art style identified in the GDD.
Animators take these art assets and rig them for action. That means creating a skeleton or armature so that the item can be deformed at run time. Then specific animations are created. Characters are given an idle animation for when they’re standing about; a walk cycle; a run cycle; combat animations.
Level Designers design each of the playable levels, laying out start positions, traps, puzzles, props and enemy spawn points.
By this stage a game engine has been chosen and the work of creating the game world begins Programmers begin laying out the framework for the game. Over time they will program every interaction the player can have with the game. They will also create a lot of test code to determine how things are working and how they could be improved.
As the game nears completion you’ll start marketing and deploying internal testers. When you have a stable alpha you will submit your game to a beta test server and invite members of your game audience to undertake beta testing. This is the most stressful time, when the game is nearly due for its market release, but bugs are being reported in droves. Developers are sleeping under their desks, the producer is losing his/her hair and the marketing team are peering nervously into the development area.
When you clear that, on most platforms you must meet some level of technical requirements for the platform you are deploying on. This testing is done by the platform provider (eg Apple, Sony, Nintendo). If you’ve managed your quality well its a nail biting wait until an all clear. If not, there are more fixes, more testing, and another submission.
Finally, the game is released, and then you read reviews, cringe whenever a reviewer mentions a problem that really should have been obvious and hopefully collect some income.
That’s game development in a nutshell. If you’re creating a big title there will be voice-over artists, motion capture and a heap of other things that I haven’t mentioned here.
You’ll also find many of these steps missing or reduced if we’re are making a simple phone game for a small budget.
If you’re one or two people starting out then your workflow will look like this :
I wish you well. If you have any questions, ask away.