Less is more: 4 reasons to keep your rewards scarce

less is more

Rewards are at the heart of games. They come in many flavors.  

When balancing economic rewards such as Currencies, XP, Items and other quantifiable things, we often face a challenge like: “Where do we give the player what?” And “How Much of what?”

This article discusses how giving fewer rewards is more desirable for making a game’s economy tighter and the game more enjoyable for players.

Argument 1: The Presenters Paradox

A study shows that adding less desirable information to more desirable information actually diminishes the total value of all the information that are presented.

The same is true for items with a quantifiable monetary value (see study 1 in the paper). The problem is that the evaluator of a “bundle” (multiple items) subconsciously averages the value of the all the items.  Mixing something very valuable with something that is less valuable will reduce the value of the higher valued item. Hence, when both are combined, the sum is lower. The perceived value is lower than the sum of its parts. If your bundle aims at conversion, this might not be your biggest concern. But if the “bundle” is a set of rewards that players receive, then you probably create a lower motivation to pursue that reward by adding more items to the rewards.  Less, in this case, is more.

From the study

“They could either bundle an iPod Touch MP3 player with 8MB of memory with a cover or the same iPod Touch MP3 player with 8MB of memory with a cover and one free music download. […] They were willing to pay more for the smaller package that contained only the iPod (Mean: $242.19) than for the larger and economically more valuable package that contained the same iPod plus a free music download (Mean: $176.71)“

presenters paradox


 

So what does it mean?

As the balancer, we have 2 Axises to balance our rewards

  • Type (What do we give?)
  • Amount (How much do we give?)

It sometimes hard to decide how to tweak the rewards along these vectors. The presenters’ paradox can be used to inform that decision. As the designer/balancer, you should be cautious about mixing different TYPES of items. Because you risk watering down the individual reward. You would give out less bang for a bigger buck!

  • When your economy has multiple resources and systems: Giving out high valuable items together with lower value items, makes it less special!
  • This is something you should strongly consider when you are in charge of designing bundles/prices for items in shops of free to play games! The perceived value of the bundle will be lower than the combined value of the individual items.

The presenters’ paradox also works for penalties (check “Study 3: Littering penalties” in the study). Hence, if your game has a losing condition where players lose something, then just losing 1 Item/resource can be more powerful than losing multiple things.

Argument 2: Exclusive Rewards Guide Player Behavior

Rewards can be a tool to reinforcing or incentivizing a certain behavior. By receiving a reward, players know they have done something “right”. That they have reached a desirable game state. Players, of course, come with a certain intrinsic motivation and don’t play the game for rewards. Yet, players expect to get something back from the game when they have achieved something or made a choice. Explicit rewards can also motivate the player to engage in an activity that they otherwise not have e.g. Achievements. 


 

What does that mean???

  • Consider what reward types in your game should be exclusively tied to one activity
  • Ask yourself what rewards should the player receive for which activity and why
  • Exclusive rewards motivate players to dig into a certain system or practice a certain skill or to play the game in a special way
  • An exclusive reward tied to a performance goal can create a high sense of achievement
    • If possible, give players the opportunity to revisit their exclusive rewards. Players can relive the memories of their journey towards that reward (items, cutscenes, achievements)

reward

Argument 3: Choices

So we know that giving out multiple things for one activity can have a diminishing effect. Also, we know that we can incentivize player behavior with certain rewards. This means we introduce a choice. That’s cool. But as the designers, we must carefully adjust our reward-sources to meet the sweet spot between “exclusivity” and “uniformly distributed” rewards. Uniformly distributed means that you multiple reward-types from every system in the game. This means that players actions or choices come at a lower opportunity cost since they get more of the different types of rewards from any action. On the other hand, this reduces the sense of choice.

balance_design_choice

Again I would like to emphasize that there are tons of other factors that make players enjoy a game. Rewards are just one (important) element. Players will have preferences for mechanics/systems based on many factors (which we only have partial control over). What we do have control over, is the rewards balancing. So let’s continue with that.

The point is: Know your players, decide what kind of decisions you want them to make, and then adjust the reward balancing to that. None of the approaches are perse bad. But we should make it a choice in the design rather than just letting it happen. These small decisions heavily influence how player experience the game and informs their decisions. As designers, we have to use every opportunity to shape that experience.


 

What does that mean???

  • Opportunity costs and resource scarcity drive players decisions, so by reduction of rewards/opportunities, you end up with a higher player agency. Less is more.
  • Carefully adjust the rewards of your game through the lens of players choices
    • What systems are part of the core loop, which rewards belong to these systems and which ones not?
    • Analyze sources sinks, and try to assign the sources only to those systems where you need them.
  • By deciding what players receive for what activity, you also inform their mental model of how the game works

 

Argument 4: It is easier to understand

Argument 2+3 lead to players having an easier time of building a mental model of the game’s economy or system. When it is clear what choice yields what reward, the players can grasp more easily the systems intentions.

  • Reduce noise to help players understand what really matters and what they should do

 

Real Life example

With a small team, I am working on a turn based squad tactic game. We can place loot on the map but also enemies can drop loot of various kinds: currency, med packs, and other consumable items.

Instead of adding loot crates that drop a bit of everything, we decided to have distinct loot-crates for each of the item types. Players can then get an idea what the loot crate might contain and incorporate that into their strategy. Whereas if all the loot was the same, it doesn’t really matter where players go with their squad (Argument#3). We also wanted players to feel rewarded when they get the loot. Since it is actually quite rare to get it, we also decided to put just one item into the crates for the sake of Argument#1.

 

A resumé of 20 side projects

Many professional game developers maintain personal projects as a creative outlet. The day to day work can be very restrictive and we operate under tough requirements. Working on the same game for a long time means that the mind is mostly busy the same set the problems within a certain design space.

For me, it is crucial to get my mind of the everyday problems and give me some fresh problems from time to time. This is a personal resume of almost 2 years of working on side projects.

The Goal

When I started a project, the goal was usually pretty simple: “Create something fun”. To see if I have reached my goal, I off course need to create a prototype and then validate the games concept in a playtest.

If a project does not reach the stage of a player holding it in his or her hands, then I consider that project as failed. If there is no player, then there is no game. Projects who reach a stage where I can test them I consider as a success. No matter whether players proved or disproved the concept. These are the ones I could learn the most from as a designer.

20 Projects

In the last 2 years, I have started 20 projects Of which I released one. 3 Other prototypes turned out to be not as much as fun as I thought to be while 16 others I would consider as a failure. I only count projects that I attempted to actually build, so all of the “failed” projects ended during the development phase, for the following reasons.

Reason #1: Design

These projects ended because something went wrong mostly on the design side. I would divide this into two further groups.

The Premature Idea

The reason for these games to get cancelled is that I simply didn’t think them true. The typical story is that I have a “great idea” which sounds super fun in my head but once I start building it, I realize that there are some major holes in the design. Luckily these projects end quite fast and not so much time is wasted.

The Spiral

These are the most dangerous projects. That were stuck in a place where I believed in them and tried really hard to make the design work. One cause for these projects were too high ambitions. In some cases I wanted to create a game that would be valid in the market. This opposed more challenges on the design the project became everything else than fast. In other cases, the designed turned out to be harder to prototype and I went back and forth between paper – and digital prototypes. These projects are dangerous because of a strong Sunk Cost bias combined with the feeling of an imminent breakthrough. Needless to say that the time-cost here is huge. And the more time I invested, the harder it was to end it.

Reason #2: Development

These projects turned out to be too complicated to build in order to prove the initial design. I would argue that the problems of these projects are also rooted in the design phase, though since I could have foreseen many of the issue and complications ahead.

My Learnings

In the creative industry, it is widely accepted that “failing” is part of the process. Motivational quotes that encourage failing are all over the place. But the time spent while failing is only worth it if we take a step back and reflect upon the shambles that lay before us. After all, we want to improve (mostly by not repeating mistakes).

Personally, my biggest challenge is that I stress out too fast. Which is not really helping since these were side project which ought to  provide me with some relief by letting me exercise my design-brain.  My personal lesson from this time of trying really hard is that the journey is its own reward.  While I was going for a solid end result, I forgot to enjoy the moments that lead there. I forgot that the quality of a designer is determined by his or her creative-process and not necessarily the outcome.  The outcome of a project (if it is released), varies on many factors. The only thing we can do is to make sure our decision now is the best that we can do.

PS:  In my next article, I will lay out some tips which I hope will help people who are on the same path as I am.

Game Design Analysis: The Promised Land

header

Learning from Games

As designers, we can learn from every game. So naturally, whenever I play a game, I play them as a player but also as a designer.  To be efficient with my resources (time), I want to learn as much as possible from the games I invest time in. For this purpose, it doesn’t matter if it is a critically acclaimed blockbuster or a niche casual game. There is potential to learn from every one of them.

In fact, I believe it is easier to learn from the not-perfect games as their mistakes are easier to identify. Playing games, learning from their mistakes and also from their accomplishments, helps to build a library of systems, mechanics, and emergent behavior. This library, together with the right level of seniority, enables designers to make the right call and see more paths that their products could take.

The Game

game_general

The first screen of the game, workers arriving and setting up the colony.

The game that I will discuss in this post is the “Promised Land”. I picked it up in a Steam Sale for just a few cents. I am interested in all genres of games, and I make my living by creating casual games so it was an easy choice.

The Narrative

In “The promised Land” the players take over the control of a colony in medieval times and ensure its prosperity by building, expanding and trading.

The gameplay

The Promised Land Loop - New Page

The Promised Land Entity Relationship Diagram

Core System: Production Sites

To make this narrative happen players assign their workers to various production sites. Upgrade states for all the production nodes can be unlocked by researching them with research points. This is a resource that is produced by assigning workers to the observatory (a production site).

The goal is to establish the colony by building more production sites and discovering the whole map. Hence, exhausting the content.

To offer players a brief choice, the game is balanced so that  there are more production sites than workers. This forces players to strategize what resource they will need next. This information is established by guiding the players with missions and trade events.

New workers can be obtained by solving quests or by trade.

Through the course of the game, players unlock more production sites that they can assign their workers to.

Core Mechanic: Assigning Workers

The interaction (input, verb) to drive the core system is simply drag and dropping workers on their worksite.

Supporting System: Worker Happiness & Efficiency
worker_info

Worker Info

Over time, workers become hungry and unhappy. By drag & dropping workers next to each other, they will initiate a conversation which will make them happy again. This only comes at the opportunity cost of them not being able to work on a production site in that time.

Hunger is solved by assigning a worker to a table, this will consume harvested food resources but it will also come at a time cost.

To not make the game to punishing and tedious, workers will automatically go to the table or start talking. A good design decision otherwise the players will find themselves merely managing unhappy workers the whole time.

By micromanaging, players can streamline the process and choose a more suited time or conversation partner for the worker.

Workers are trained at a specific activity by working in one of the production sites.

They even have a personality that determines their efficiency by production-type.

Supporting System: Trade
trade

The trading screen. Once a trade a has been initiated, it takes time until it comes back. Players must choose wisely what to trade.

After unlocking the ship, players can trade resources for money or other goods that are needed to build more production sites. Although it is a supporting system, it is necessary to progress. The items you see on the right, can not be obtained from anywhere else in the game.

offer

Once in a while, a certain resource yields higher sales.

An important feature in this system is the bonus payment. For a limited time, players get additional pay for specific goods. This asks players to shift their worker-economy towards the production of a certain good. This is one of the main drivers to keep the game entertaining and somewhat demanding.

Supporting System: Research

science

The observatory can be worked like any other production site which will earn players research points. These are used to unlock techs that are organized in a tech-tree, where certain techs can only be acquired if the previous one has been learned.The research system serves as one of the major progression blockers because generating the resources for the upgrades takes very long.

Supporting System: Crops & House Micromanagement

2016-01-05_00012

Some buildings offer additional properties that players can tweak. This gives players one layer of depth that is entangled with the research system.

Minigame: Angry Birds

2016-01-11_00005

This is a minigame that is unlocked after building a fort. In angry birds manner, the players need to shoot a cannonball on pirates. As a return, they will receive gold. I find this game mode very problematic as it is aiming at totally different players. The regular game is not asking for any physics-puzzle related skills. Fortunately, the minigame is not vital to the progression of the game. But IMO it was not the most valuable way to spend development resources on. Some players might have liked, it, but it there is also a big chance of alienating many of the players that were targeted originally.

Quests

The quest system sets up some breadcrumbs to give players the next goal. They are introduced by one of the characters and make sure players always know what to do next.

Gameplay Assessment

In “The Promised Land”, there is no loose-state the only punishment for not solving the game’s problems is that progressing takes longer. Players can not lose progress. This is one of the most important implications of casual games. The “cost” of playing bad, should never be too high. Systematically this is not handled very well in my opinion because there is virtually no reason to use many of the supporting systems.

8 kinds of fun legend

I will use Marc Le Blanc taxonomy of kinds of fun to categorize the games focus on creating fun for its players. The main goal and, therefore, the motivation of the player is to reach a fully upgraded map. Therefore, the game triggers the players curiosity and urge to discover the remaining pieces of the world.

The somewhat relatable and approachable setting is responsible for my higher ratings in the Narrative categories.

What Works
  • Simple loop that is very accessible, just feeding of a worker placement mechanic
  • No fail state, the game just goes on, players can not really screw up, the worst the player can do is playing inefficiently
  • Good example scaling in complexity only, not in depth
  • Small addition systems unlocked  over time keep the game interesting

 

What doesn’t work
  • The game offers many systems that focus on the “efficiency” of workers, but there is not much incentive to use these systems. Making the workers more efficient simply means that they produce things faster. But the time it takes to micromanage the workers, is barely regained by the increased production speed
  • The minigame  it is targeted at other players than the core gameplay
  • Being targeted at a very casual audience, I think the tutorial and the beginning of the phase lacks many explanations, e.g. highlights in the terrain would be needed in order to see where production sites are