Using SCRUM to design player emotions

I love Scrum. It’s a great way to run agile development projects, with a focus on clear communications, goals and measurable achievement. But that’s not why I love it.

I love it because Scrum is great for game design. Yepp, I said “design” not “development” (ok, it’s great there too, but bear with me). See, if you’re willing to bend the rules of Scrum a bit it becomes a fantastic tool to set, analyze and refine player experiences. It also leads to a player-centric design strategy.

A bit of an aside: you can analyze game design along multiple axises. You could, for example, look at interaction vs analysis where you’ve got player interaction (an extrovert activity) on one end and player analysis (an introvert activity, i.e. sitting and thinking) on the other. Of course this is a simplistic view, you can always make a model more complex (for example you could throw in a “group strategy” node and get a three axis model and then throw in a “beer & pretzels suitability” and get a six axis model and so on). But we’re going to look at a single axis here, mechanics-centric design vs player-centric.

In a mechanic centric design you look at how the mechanics interact. You value different actions and items the players can acquire in some sort of currency (for example, an ax is 0.3 of a kill and a sword is 0.5 of a kill then a sword is 66% more effective than an axe and should cost 66% more – or have a 40% lower rating in some other, equivalent, ability).

This evaluates the different ways in which a player can act upon the game. We could even call it a “action-centric” design strategy. On the other end of our scale is a player-centric design strategy where we look at the player: how does the player react? What does the player feel? So when we’re designing in a player-centric way we’re designing the player’s emotions and reactions (and yes, we could call it a “feeling-centric” design strategy but that sounds silly).

Scrum: an overview

So, back to Scrum (if you Scrum already, skip this part). In standard Scrum you look at the features you want you product to have and divide them up into user stories. Say that you’re designing a car and want a door feature. Then you’d get:

Each user story is written on the form of “A XXX should YYY in order to ZZZ”. This is a way for high level designers/developers to communicate their intentions to lower level developers, the people doing the actual work. (And yes, this is only one form of Scrum, ask some other guru and you’ll get a slightly different one – Scrum is amazingly adaptable!)

Then the user stories are broken down even further, mostly into acceptance criteria that define the user story on a slightly more granular scale and work as a definition of done, and demo instructions which specify the “why” (the ZZZ part) even more. (And then the development guys break it down further into actual tasks, but that’s beyond what we’ll be using it for.)

But we’re not building a car. We’re building a game.

Designing for feelings

And here’s where Scrum is incredible. We can replace the “Feature” with “Feeling” and the “User story” with “Player trigger” and, voila, instant player manipulation tool!

Let’s take an example. Let’s say that we want the player to experience fiero moments (fiero is that “OMG!!!! Epic Win” feeling where everything just goes boom inside your mind). So we’ll set it up:

You can add more prerequisites for fiero (try it, it’s a good excercise) but you get the point. Another good thing is to bold the key requirements so that your brain has an easier time locking on to them (i.e. “loading them into short term memory”) when you’re working with them.

Scrum for analysis

So, we’ve specified our player emotions, we’ve broken them down into requirements. Does that mean we’re done?

Nope, sorry. This doesn’t tell us how to create or fantastic, fiero-inducing game, but it does give us a checklist for creating fiero moments. Then you can use it in order to know what to add to your design in order to make them possible, and, from the other angle, you’ll know when your game will be unlikely to produce fiero moments.

At this point the design requirements are still pretty general. One fiero list is pretty similar to another. But when you put the feelings you want together, side by side, and extract the requirements they’ve got, then you can look for similarities. For example, you might want high risk in fiero and high risks in fear, and high risks in tension, and high risks in…

Combining elements

Sure, you could build different elements to fulfill all of those requirements. You could have a boss monster at the end, a fear of losing your base/engine/other to bandits and a way to gamble with the local crime lord in order to get grain to feed your peasants. But what if you could roll all of these into one? Would it make the story more focused? Would it be possible to foreshadow the boss monster through attacking the village?

Once you get your requirements analyzed you get to go back to our Scrum model and work on the acceptance criteria. Here we’ll bastardize Scrum some more: we’re going to switch out our features for design elements and our user stories for flow points (or story elements, whichever you like), like so:

Ok, this part is a lot harder to do in general terms since the story points are dependent on the game you’re making. The story point could be “launch major attack” in Risk, or “try out shoe” in a Cinderella game or anything that’s thematically and mechanically solid for your design (notice how we’re marrying feelings to mechanics here – they axis of opposites we spoke of earlier? Purely an analytical tool).

The main point I’m trying to make is that you can reuse your Scrum skills in different guises throughout the entire brainstorming and design process. Don’t limit yourself to using Scrum in development; Scrum is a methodology, not a coding language or mechanic. Use it wherever you find it usable.

Filip Wiltgren blogs about game design, writing and motivational psychology every Monday at www.wiltgren.com.