Risk and reward in game design

We've all been there before; committing to choice. These are the moments we remember as being the big decisions we took. Whether its in real life or in a game, risk and reward is about gauging good and bad outcomes against one another, killing you with worry and excitement at the same time.

Judging from the emotional roller-coaster I've just described this phenomenon as, you can imagine how powerful a tool it is, to anyone working with game design. From the designer's perspective, it's all about understanding what's important to the user at each moment, then using that knowledge to present an opportunity:

• Win and we'll reward you with important stuff. 

• Fail and we'll hit you where it hurts - because we know what matters and we'll take that away from you.

Arnold knows so, too

What's important about risk/reward in this sense, is that taking the risk is optional. It is in having the choice, that the choice lies. It might sound silly, but if there is no choice to not partake in a risk/reward event, then it is not about risk anymore, but an inevitable, random event, that might have a negative outcome.

Doing anything like the above paragraph, is bad for the experience: In removing the choice to participate, we restrict the freedom of the users, which overshadows the value of a potential reward.

But as you can probably tell, knowing about risk and reward isn't worth much, if you don't know how to emulate value in your product. A reward as well as a failure, should have an impact on the experience. The bigger the positive impact, the more value and vice versa for failure. But what's valuable, per definition? 

Today's tune:
Before we get to that, here's the usual music that you can choose to have playing in the background as you read. I chose this one because it's still winter, but we've hardly gotten any snow where I live. That makes me a little sad, it's almost like I'm not living in a Nordic country. Had none during Christmas either. Oh well, there's always another year:

Risk and value:

As a rule of thumb, there are two factors that determine value in a fictive environment: Scarcity and usability. We commonly apply both of these factors when dealing with currencies, but mostly only usability if we're dealing with new mechanics, that changes how the users can interact with the environment. However, scarcity may also be applied to mechanics in a multiplayer environment. For example: In Elder Scrolls Online, vampirism and lycanthropy (two new skill-lines that the users can acquire), have a high usability, but thanks to the way you acquire them, also a measure of scarcity. They're not easy to attain, and so therefore that has some inherent value.

But what about risk? What's interesting about risk, is that the possible failure it implies, is the polar opposite of reward. Instead of gaining potential, you loose it. We can use our measurement of "what is valuable," to determine what we can impact as designers, to make the users feel it negatively.

For example; in a game where you don't heal automatically, it suddenly becomes a much higher risk if you loose health upon failure. This wouldn't have nearly the same impact in most modern games, where you simply recover after a short period of time.

Always remember to ingest your regenerative nanite-paste, kids!

What you should be really careful with, when dealing with loss, is the loss of mechanics. The reason for this, is that it moves the users into a mental space of disempowerment, which may lead to frustration: Taking away control, is bad. This can be accommodated for, by making it a recoverable loss. However, it's very important that the recovery depends on actions performed by the user, rather than time. Using time as a recovery factor, instead of actions, would make the loss as inconsequential as loss of health with auto-heal on.

Another big problem with time, is the pacing of the experience. If you make time a factor, you punish the users who have a faster progression rate, than the ones who wait. This adds a measure of artificial lengthening to the experience, which can be felt and will most likely put off the users. If you base recovery on actions - such as paying ingame currency for your recovery (very simple example, not a good go-to solution) - you accommodate for different paces of progression and skill.

The pitfall of imbalance:

While working with risk and reward, it is extremely important that your reward makes it worth to consider, in light of the risk you take to attain it. If your experience ends up being about "normal progression or failure" rather than "significant progression or failure", then the users get what I like to call the "every-god-damn-time"-syndrome.

If a tester makes this face after failing, back off two paces before asking questions.

This syndrome owes its existence to how our brains deal with memorability. We've dealt with novelty in user experience design before, but the memories that stick are not filtered for what's good and what's bad.

What that means, is that if your risk/reward scenario ever cooks down to "regular progression or failure", it's the failure that becomes the novelty in your design. If we don't fail in such an encounter, we won't pay any mind to it, because the result doesn't stick out. Unfortunately, the opposite is true if we fail. Which means that since we only notice the encounter when we fail, we'll feel like we fail it every god damn time, even if we've only failed a few times.

Risk and reward as a narrative tool:

Risk/reward is an extremely common element in any game that is aware of its users' basic psychological urges. A good roleplaying game is about being presented with choices, that aid to reinforce your feeling of being "in character" throughout the narrative. All users have some kind of ideal personae they want to enact in the game-world, and having choices that support the fundamental personality-traits of said personae, helps heighten the immersion.

Therefore, the best roleplaying games are riddled with choices. But a choice is basically a commitment and an exclusion: Pick this and you can't pick that. Anything that you can take apart and fit into those two boxes, can be twisted into some format of a risk/reward decision.

That means risk/reward is not always about statistics and difficulty. Sometimes it's just about making a decision in a narrative, and the risk lies in getting an undesired narrative outcome. The reward is, as follows, getting the desired narrative outcome. Of course, the biggest impact comes from when the user is the most immersed in your narrative. At that point, their heightened empathy means that they evaluate the choices as if they occurred in real life - making for some very tense moments, if done right. Which is why using story elements (if done right) is just as effective as tweaking numbers and mechanics as the outcome.

Rounding off:

Let's summarize:

• Risk and reward gives weight to optional choices.
• Reward only means something, if you can emulate value properly.
• Value is a subjective measurement, it is not inherent in mechanics and coin, but can be about story too!

If you want some more hands-on examples, keep on reading!

__________________________________________

Risk and Reward in games today:

Now we know what risk/reward is. But how is it commonly applied in games today? Interestingly enough, it is mostly present in a genre that has been resurrected over the past few years, after being "dead" for ages: Roguelikes.

I'll summarize what a roguelike is, to those of you who don't already know it: A "roguelike" game, per its original definition, contains procedural level generation, permanent death, turn-based gameplay and tile-based graphics. Today, however, it's a bit broader than that, as modern roguelikes tend to be more about the "permadeath" in the context of modern mechanics, instead of only being tile- and/or turnbased.

Imagine a board game about punching each other.

The core of roguelikes is, when isolated, about the random elements and the permanence of failure. Typical in modern roguelikes, there is an element of persistence across each attempt. In other words; the more attempts you've made, even if failing, the further you've likely made it into the game. It rewards you with a permanent bonus, if you make it far enough, that persists even if you "die" and start over. This is done to appeal to a wider audience, who prefer to feel that their every attempt matters.

"FTL: Faster Than Light":

A roguelike that comes to mind when talking risk/reward, is a game called FTL. This game is so full of both choices and random elements, that the odds of you getting two identical playthroughs, is almost nothing. But the risk/reward choices are what's important here.

FTL is all about traversing an area; or travelling a branching path if you will. Along each segment of this path, lies an encounter. An encounter is essentially a small board on its own, that contains an event. Sometimes you are forced to fight, but you are often given a choice:

Something obviously risky is happening!

• Partake for the potential benefit, facing the massive risk? 
• Or skip out and let go of any rewards that could have been?

What's so brilliant about these choices, in the context of FTL, is that the game forces you to move forwards all the time. Unlike common roleplaying games where you can stay in an area until you feel powerful enough to move on, here you will be killed if you do not move forward.

This setup forces you to consider both the risk of partaking in the event, as well as the risk of not doing so, as not having the potential upgrades from a successful encounter, will make the game incredibly hard later on.

That causes the game to have an absolutely brutal difficulty spike, as the pacing of the user has to be fast enough to not fail. Yet the luck in the randomization is enough to keep most people going, as "maybe next time I'll get lucky!"

Even though I have no idea what I'm doing.

Homework:

This is something I'll start doing from now on, which is to give you - the readers - something to do, in order to try to apply some of the theory you've learned here. It's not something you'll have send, as it's for the sake of your own learning. But if you feel like you need some feedback on it, feel free to comment on the article that the question relates to.

The assignment this time:

It's quite simple. I want you to find a roguelike and try to analyze it: Identify when you are set in front of a risk/reward choice. The reason I want it to be a roguelike specifically, is because the risk/reward choices are often inherent to games in this genre. However, if you know of any games you know displays a similar nature in choices (believe me, there are many), by all means; go ahead and analyze that as well.

Here's a bit of inspiration, if you have no idea where to start (don't worry, they're not all ASCII-based:

Once you've found a few examples, and feel comfortable enough in remembering the theory from this article, try looking at games that are lacking a risk/reward choice system. Then think about how such a system could be implemented. I recommend you really take a close look at what elements of the game matters most to the players, then consider how said elements could be rearranged to create some risk/reward choices.

Have fun!

~ Dave

Working with the fear of missing out - The Elder Scrolls Online special.

Time for another game design article! This time, I'll talk about a topic that is very relevant in modern society, which is the phenomenon of "non-commitment." It essentially means "when a person never commits themselves to a particular choice, so that every option is perpetually open to them." This time around, I'll be using The Elder Scrolls Online as my prime example for a good solution.

As  usual, I'm going to start off the article with a bit of reading-music, for those of you who like a backing track to your studies. As we're doing a bit of an Elder Scrolls special, I thought it fitting to use Jeremy Soule's music this time around:

A few generations back, it used to be that you grew up to take over the job of your parents, but now you have to choose for yourself. The choices (if you live in Denmark, at least) are virtually endless. But what does that do to our minds, when we're suddenly granted such an important responsibility to commitment, yet so many choices?

As you might have guessed from the term "non-commitment", people tend to suspend themselves, never being able truly commit to one thing: Committing themselves to one choice, is synonymous with letting go of another. This is true whether the individual acknowledges it consciously or subconsciously. It is the fear if missing out that keeps them suspended.

Unfortunately, this idea of suspending oneself in the choice of not making a choice, is a really massive flaw in our psychology: Time passes no matter what we do. However, most people grasp time entirely from a subjective standpoint, when they evaluate its passing (see "How to Christmas spirit" for a more in-depth explanation of the subjective passing of time). Yet you'll miss out on everything if you do not commit yourself to something.

Now if only I had a time machine to demonstrate it with.

To turn this in the direction of game design, many games are based around a series of meaningful choices. Whether its a moral choice, picking a character-class or choosing your companions, the choices are there. Mind that the problem only seems to persist in games, where the users are aware that they need to spend a lot of time dealing with the effects of their choices. This is very common in role playing games, particularly MMOs, or any other game where your choices will be reflected in your experience for a long period of time.

More casual titles do not tend to suffer from these issues, as they only require user interaction for a small period of time, or contain no significant choices.

The theoretical stuff:

In a well-designed game, the users quickly commit themselves to their choices. They do this much more confidently than they would ever pick something in real life - like when they have to choose a career path.

Oh god, the red beans are forming a worker's union!

But why is the virtual world so different to people?

The simple answer is: The games that make people behave this way, knows how to treat their users with care. It used to be that games could be extremely complex to boot, yet you'd still find a fair share of users enjoying the process of understanding the whole system. These people still exist, but the size of their audience is dwarfed in comparison to the younger ones, who suffer from having suspended themselves in this "choice limbo" in real life. That forces us to evaluate how we can include the bigger group, without letting go of the complexity that the smaller group has grown to love.

The most common way to tackle this issue, is through tutorials and procedural introduction of content. You can still make advanced systems, if you just introduce their individual elements one at a time; If you give people one piece at a time, they always just have that one new piece of information to reflect upon. If they have more than one new piece to deal with at once, they might overlook the functionality of one of them.

But as long as the users feel competent enough to make projections about what causes what, your design is generally in the safe-zone. When evaluating if your users can grasp this "action/reaction"-relation in your design, think about whether or not all of the game's elements have been presented in an isolated instance, before used alongside something else.

Another way that many games deal with the issue of indecision, is simply by letting the users have it all. Unlike real life, games are often a tangible, limited whole. If you just feed the users one piece at a time, they'll eventually have passed through the entirety of your system, never having had to make a choice in the first place. A lot of people will call this "too much hand-holding," however, and it will make for an very linear experience. What we want to know, is how we can let the users have these complex choices and be able to deal with them as well.

I don't think an explanation is necessary.

Again; to really overcome the problem, you must design your system to segment the experience into separate, tangible pieces. Every interaction that occurs, must first occur on its own, before occurring in tandem with other interactions. Use this as a rule of thumb, if you ever want to introduce something new.

However, even as we take these precautions to make sure that people understand the individual elements, the real danger lies within having too high a density in "the number of impactful choices that occur at the same time, at any one point in the user experience." When ascertaining impactful means, we need to look at it subjectively. Something that has impact, is something that behaves unexpectedly:

When a user is faced with multiple choices, where the outcome of each is relatively unpredictable, we observe two simultaneous negatives occurring within the mind of the user:

1. I don't know enough about this choice to commit myself to it, as the effects are uncertain.
2. I don't know enough about the other choices to exclude them from my personal interests.

If the users ever establish this kind of relationship with a set of choices, they are going to fatigue, eventually. Many people, after committing themselves to a choice made with the above points in mind, will also be in a constant state of curiosity and regret that they did not choose the other, thinking "what if." This can arguably be used as a driver for replayability in some games, but it might be bad in very long-term experiences that require commitment for the users to truly experience the game's content properly (namely MMOs).

Hold on to your hats, because here's a theoretical explanation of how you should look at user-progression in your game:

You can ensure the integrity of the flow of the user-experience, by examining it as a chart of occurring instances of choice, as well as weighing the importance of each choice, based on previous exposure to similar choices - or exposure to the possible consequences of said choices, before committing to them (in other words, telling the user that; "doing this may/will cause that to happen"). This enables you as a designer, to see where an overload might occur, where the user doesn't know what to commit themselves to, because they lack information.

The practical stuff:

That got really convoluted, so here's how you should do it in practice: 

It can be done very simply, by making a flow-chart of possible user progressions through your system's environment. By listing everything that your users have been exposed to through certain paths, you force yourself to recognize when new elements are introduced. You can even do this with completely non-linear sandbox games, simply by looking at how a character might evolve through its interactions with the environment. Just ask yourself "what can the user possibly do at this stage?" and write the answers down as connected bubbles in a flow-chart. This will help you visualize what elements of play are relevant when.

You can go a long way by examining your game this way, but you will only really know the outcome of your design, once you've tasked a group of users - over time - to gauge their experiences. But an even more effective way to get the information you need, is to data-mine how many "do-overs" each user has: Did they quit without saving? Do they have multiple saves on the same character? How many characters have they made? Did they reset their progress and at what stages did the resets occur? If things like these are happening often, your users might be suffering from non-commitment, and so they might quit half-way through.

And often discover things you weren't even looking for in the first place.

The biggest problem with overcoming non-commitment as a developer, is that time is such a big factor. And to make matters worse, users will often not suffer from this problem if they know that they have to start over anyway, when the game is released. Offering some form of persistence through the testing and into the final release, could help alleviate this issue.

Example-time!

Now we've spent a while talking about the problem and how to approach it, so I believe it's time we take a look at some existing solutions. This time in particular, I am taking a look at The Elder Scrolls Online (I'll refer to this as TESO from now on). While we won't be looking at what design-processes were used to create these systems, we will take a look at how they affect the user experience.

Respeccing:

So what does TESO do, to deal with these issues? Let's begin by looking at a very simple example, which is not uncommon in role playing games: "Respeccing."

If you've never heard of respeccing before, it means resetting your character's progress, while reclaiming the points you've invested. In other words, if you've spent 5 skill-points on skills that you no longer want to use, respeccing gives you those points back to be reinvested elsewhere. This means that the users always have this mental concept of "my choices have consequence but are reversible," granting them the freedom to experiment.

The average user-experience when starting a new game.

However, TESO takes this one step further, by having three stages of point-implementation and respeccing, instead of just one.

You see, while it is typical of role playing games to have two separate types of points for character progression (the second being attribute points, which typically affect certain statistics on your character), TESO introduces something called "skill morphing." A skill morph is an upgrade, that adds extra mechanics to your existing skill. To attain a morph for each skill, it requires an additional skill-point, and the original skill has to have been used for a moderate amount of time. This is brilliant for several reasons:

In terms of respeccing, the system can be broken up into three parts. While some games require you to invest a hefty sum of gold to reset everything, TESO lets you choose whether you want to reset your attribute-points, all of your skill-points, or just reset your skill-morphs for way less gold.

This means that for every step of personal commitment that exists in this system, there is an action to reverse it.

Now I can get my skillpoints back AND afford wizard-college!

The only exceptions to this rule would be when you choose a class (which is irreversible), define the anatomical features of your character, pick an alliance or perform certain moral choices in the story line. But if you consider the fact that people can have several characters on the same account, you'll see many of these issues - if not solved - marginally alleviated.

The second reason while this system is so brilliant, is thanks to the mechanic; that skills have to be used for a certain amount of time, before unlocking the morph. This forces the users to come to terms with how the skill works. Once you've actually reached the point at which you're asked what you want to morph your skill into, you've already come to terms with how you prefer using it. This makes it much clearer what the different morphs can potentially add to your play style, making the choice easier.

Multi-role classes:

Now here is something that I really like about TESO. Although picking a class and a race, locks you down with a certain pool of skills to choose from, the game itself is completely open with what items you can interact with and use. Which in turn means that every class can essentially fulfill any role in a team.

If you're not familiar with the classical roles in role playing games, they are typically sorted like this:

• Damage dealer - specializes in dealing as much damage as possible
• Tank - tries to take the punches for everyone else, as a buffer
• Healer - keeps everyone alive, especially the tank

That's the typical assortment. In most role playing games, picking a class would often lock you into one of these roles. This means that before you choose, you have to already have some idea of what your preferred play-style is. But in TESO, you are allowed to discover your play-style through experimentation. Any combination of existing elements in the trio above, is possible, regardless of your choice of class and race.

Lightning-powers and a giant hammer? Yes sir.

With a system this dynamic, we remove a lot of the pressure and consequences that such an early choice would otherwise carry with it. And by letting the characters become good at everything, if they spend enough time practicing, it shifts the choice from permanence to being a question of investing time. This is something that people can handle much better, because they miss out on much less. While some combinations of classes and roles might fare better than others, the fact alone that the possibilities are there, really helps defeat non-commitment.

The champion system:

This system is not actually in the game yet, but the premise of it is so closely tied into this article's subject, that I just have to include it. I'll start by outlining the system itself:

Originally in TESO, once you reached level 50, any level gained afterwards would count as a "veteran rank." Veteran ranks are essentially like character levels, but harder to gain and give a much more significant boost to your character's attributes. But now veteran ranks are on their way out.

To replace them comes the champion system. Now, when you reach level 50, instead of gaining veteran ranks, you gain champion points. These points are spent in the champion rank system, to advance your character. This is where it gets really interesting:

The champion system consists of a total of nine "pools," each containing passive skills for you to invest your points into. But these nine pools are separated into three major categories, each containing three of these pools each. These categories are thematically reflecting the three major attributes in the game:

• Magicka
• Health
• Stamina

Whenever you gain a point - and this part is very important - it will be dedicated to one of these categories. This happens in a cycle: If the first point you gain is locked into the Magicka category, the next one might be dedicated to the Health category, while the third one would then be dedicated to Stamina, before starting the cycle over.

If only real life skills were colour-coded.

As you can see in the illustration above, there are the three categories. The genius of this structure and the way you have to cycle through it, is that it focuses the decision-making process of the users to the individual categories.

If we look at the categories individually, we have the three pools contained within. Each of these pools are segmented into three tiers - each tier containing a number of passive skills. In order to unlock the next tier in a pool, the user will have to spend a certain amount of points into the previous tier. This segmentation further helps with the decision-making, simply by restricting access to a certain tier early on.

Combine the three primary categories with the tier-progression on the individual pools, and you make a very "easy-to-think-about"-system that entices the users to cut loose and experiment. And you can still preview the later tiers, letting the more advances users plan ahead - you just can't invest in them right away.

To top it all off, points earned in this system are account-wide. However, the points spent are only spent on the individual characters (they are still available for other characters to be used differently). This means that you can invest your points with a complete disregard for whether or not it benefits your other characters, once again leaving you with one less thing to worry about.

Preventing this from happening.

While this system was designed to balance user progress, you can clearly see how this ties into helping against user indecision and non-commitment. But one of the primary reasons that the system is as viable as it is, is the fact that it only becomes active when people have already reached the maximum level.

This way you can describe what the skills do in a very concise way, as we can suddenly rely on the users knowing a great deal about the system already. Concise information is very important when you want to ensure clarity in your communication, so the fact that we can cook the info down to not contain further explanations, helps the decision-making process even further.

Rounding off:

Alright, time to summarize what we've learned:

The world is changing, and these changes affect us. The fear of missing out, causing non-commitment to significant decisions, is a pretty big issue to recent generations in the modern world. But while it is problematic when it comes to real life decisions, we can use it as a force for good in game design.

By knowing what triggers these issues, we can look at what equates the opposite and use that in our design. In this case, segmentation is key. The most important thing to consider, is where the "mental frontier" of a particular user might be, when they perform certain interactions within the system. What this means, is to look at previous interactions, so we can make assumptions about the user's current understanding. 

 Realizing what the users know, helps us on two different fronts: It helps us cook down the information we deliver to an "as-needed" basis, but also makes us realize from a development standpoint, if there are any potential holes in the knowledge of the users, which might otherwise be required to understand what is happening at specific moments in the user-experience.

If information is missing, we have to present it in an isolated instance, before representing it in a broader context.

When we have ensured that our design adheres to these rules, we must always examine the amount of possible interactions that can occur at the same time. If too many options are presented simultaneously, the indecision kicks in. Information and interaction density are the two primary rules we must look at, to prevent non-commitment-driven user behaviors.

Keep in mind that a very large, complex system can still exist - just as demonstrated by TESO. But then you must present your content in bits and pieces, in a sequence that plays on information that has previously delivered.

Defining user information:

Now I've mentioned "what the users know" on several occasions. Mind that this refers to "what you have previously told the users, through interactions with your systems." Do not confuse this with what we can assume certain cultures to know beforehand. While culture is still important, as long as you design for an audience that has the same cultural background as you do (the western market, in my case), you can inherently make assumptions from your own experiences. 

But knowing your target audience is a whole topic in its own right, so we'll leave it at that.

Bonus video:

What's an article without a little extra inspiration. Here's a short video about the fear of missing out, for you extra curious people: