When I just read Daniel Cook’s article on Gamasutra I had to think about something we are trying in our team for an experiment - incorporating a game into our Scrum-based development cycle.
The experience Daniel Cook’s wife had with WiiFit clearly shows the impact of games on human psyche and how to make good use of it in a beneficial way aside from mere entertainment - not completely removing the fun from games though.
1. Grinding != Playing
When you look at people playing MMORPGs you find quite a few that actually play the game for fun. But others are rather working, grinding their way through a world that offers nothing but the feeling of having achieved something - even if this achievement is marginal or the way to get there was tedious and exhausing. That even goes as far as playing for hours or days to get this feeling - a process I call play-working. As soon as I saw this I began to think about a way to use this phenomenon and put it to a prolific use. So the idea was born to try to motivate people to work on tasks by integrating the work into a game that works similar to a MMORPG like the before-mentioned. Let’s try to get from play-working to work-playing!
2. Analysis: The Seven Rules
To make this work you need to analyze the core mechanics of games that evoke this phenomenon of play-working. (Note: besides MMORPGs other games also make use of “achievement grinding”, i.e. TeamFortress 2 and Call of Duty 4)
- Community
- Milestones
- Clear, short-term tasks
- Perpetual gain of small achievements
- Vizualization of achievements
- Persistence of achievements
- Usefulness to the player
Let’s get a little bit into detail on these.
Community
First of all there has to be a community the player is part of. This obviously is a common feature of MMORPGs by their nature of being driven by multiple players engaged in one world simultaneously. A community is important for enabling the players to “show off”. Achievements are worth nothing when there is noone else to recognize them. Hence the community creates some sort of competition amongst players, motivating them to go after achievements.
Milestones
The player needs to have a milestone, a destination for his journey. This may be a level-cap, as often used in MMORPGs, or even something as simple as offering the possibility to be the best player in the community and having it recognized. Maybe a milestone is not truly neccessary but it helps the player to get an idea of the length of his journey. Thus it takes away the uncertainty to some degree and motivates the player to start journeying.
Clear, short-term tasks
According to MMOs these are the quests given to the player by NPCs or other players. Quests need at least a start, a destination/goal and a specific challenge to bear. More complex quests feature multiple locations and/or multiple challenges and may even hide information from the player to raise difficulty. Yet aiming at the achievement the player prefers clear goals, as long as they don’t kill the motivation by being too easy, i.e. when challenge and achievement are imbalanced.
Perpetual gain of achievements
It is not enough to provide a player with one big achievement at the end of his journey. The player needs to have a perpetual gain of smaller achievements to stay motivated and go after the milestone. More interesting than this is an occuring side-effect: you can give various tasks to the player that are repetitive in their nature but often hidden behind a nice coulisse as long as they yield a reward. One needs to be aware though that the demotivation on the player’s side rises exponentially with the amout of repetitive tasks.
Visualization of achievements
As mentioned above the player needs to have his achievements shown to other players. This works best by visualization. The more the player can brag with his achievements the better because it stimulates competition.
Persistence of achievements
This is especially important if the player spends quite some time with the game. Everything the player achieves has to stay visible to others to not lose its value. Maybe the player will still feel proud of his achievements personally but not being able to show them publically hurts the motivation to get more achievements.
Usefulness to the player
One thing that helps with achievements is making them meaningful or useful to the player. A plain number or some coin motivates less than a new powerful weapon.
3. Applying the Rules
So these seven rules are critical to the success of making players play-work in your game. Let’s see if we can find some analogies when applying them to a games project.
The community is the team working on the project and everyone involved is a player in this “game” called work. Then there’s at least one milestone - the day when the project is finished. This date may not be as accurate as a Level-50-Cap but it can at least be estimated and serves its purpose as destination for each player’s journey. Actually every milestone can be set as THE milestone, but for this article I’ll assume our journey’s destination is the project’s completion. The tasks are simply the assignments given to each team member. Having a task-driven development cycle like Scrum helps a lot since it already requires tasks to be very short-term and clear.
The tasks need to reward the player. The simplest form is to compliment the proper team member upon successful task completion. Since compliments can be used more than once they allow for a perpetual gain of achievements. Yet they lack the potential to be visible and persistent to others. So we need to refine our system and that’s the point where we actually design our game to make people work-play.
To keep it simple let’s assume the game is a virtual layer sitting on top of the actual “real” work. Every team member gets its own representation in this virtual layer - an avatar. Keep in mind that this virtual layer may be digital as well as analog so the avatar can either be a 3D-Model of the player, an Excel spreadsheet or simply a stickman painted on a sheet of paper and pinned to the wall. Now that there is an avatar it is possible to visualize achievements.
As said before the assignments will be the tasks that yield the perpetual achievements. The tasks need to get weighted in order to assure some balance since tasks normally differ in time consumption and complexity/difficulty. A simple approach would be to assign points to the tasks ascending with the degree of time consumption and/or complexity. The amout of points is used to determine the reward’s quality.
Now that we have build the framework this is where the fun and creativity comes in. The team can now think of various achievements, the graphical representations and the rules for getting them credited, i.e. special items or badges rewarded at X points collected within Y time units. The only importance is with obeying the seven rules that reinforce the system.
4. Chances and Risks
So far I was not able to gather much information. Me and my team are currently implementing a game following this pattern into our Scrum-based development cycle. Hopefully we will soon be able to evaluate it.
So far it is only possible to try looking for potential risks. First of all you really need everyone to get involved. Team members that do not engage in this game will likely be a kill-joy to the others.
Developing the game can become quite complicated. You need to watch for balancing issues since they will likely create displeasure if competing players get the feeling of not being competitive anymore (i.e. programmers getting more points than designers because complexity of tasks is overrated).
Also when looking at competition, motivation can turn into envy and thus into demotivation. This is especially dangerous in teams with varying qualification.
Despite the risks this approach may result in higher motivation within the team since the team members may think less about work as tedious must-do activity and instead link it with something fun. Providing the right achievements is one important step towards this goal.
Have fun play-working!
I'm a student in "Game Design" (B.A.) at Mediadesign University of Applied Sciences in Munich, Germany. I'm interested in everything about games and the science behind it. Yet my focus is on game design, storytelling, producing and team-management.