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:
- Feature: Door
- A user should be able to open a door in order to enter the car
- A user should be able to close the door in order to protect the user from falling out during travel
- A user should be able to know if a door is open or closed in order to be able to remedy errors in door closing
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:
- Feelling: Fiero – a player should be able to experience major elation based in epic win situations (note how we’ve added a “what”, the YYY part, to the feature)
- Players need to be able to take high risks in game changing situations in order to produce high tension
- Players need to be able to see the risks they’re taking in order to increase tension by making them aware of the looming failure
- Players need to be able to use skill to overcome the risks in order to make their win feel justified (note that a random win is less likely to produce a fiero moment than one that the player has fought for)
- Players need to get an unambiguous confirmation/instant reward for their win in order to trigger the fiero moment (a player that doesn’t realize they’ve won won’t feel fiero – they’ll just be in a situation where all their struggle suddenly ceases which is likely to produce confusion)
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…
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:
- Feature: Risk (players need to be able to take high risks, Fiero, Fear, Tension)
- Boss fight (Fiero moment), Risk inducing criteria:
- Uncertainty of own ability
- Knowledge of not all quests/items completed due to time constraints
- Knowledge of boss powers
- Uncertainty of true boss capabilities
- Ambush in woods (Fear moment)
- Boss fight (Fiero moment), Risk inducing criteria:
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.