When we first started designing our new game, Potato Pirates: Enter the Spudnet, a question often popped out every now and then: Are board games like Snakes and Ladders considered a game? Half of our team feels that a game that involves zero decision-making might as well be a storybook, yet the other half argues that what makes an activity a game is the fun it can provide. Undeniably, both sides have their merits but we will leave the definition of a game as a topic for another day. In this post, I would like to talk about the side involving decision-making in games and our thought process when it came to designing what a player can do.
In games that involve decision-making, there are choices that are given (by us, the designers) and decisions to be made (by players) at every stage of the game. Be it to move a ship left or right, to choose a special power, or to negotiate a deal— such choices are given in multiple stages of our game. But what exactly makes that part of the game fun? What makes a choice interesting or boring? How would we design such choices? My answer is to look at the triviality (or rather non-triviality) of the decisions. The crux is that for the decision-making to be interesting, decisions should not be trivial.
Here are my top 5 considerations when it comes to designing player choice in your game:
1. The impact of the choices
Take this: for example, you need to enter a building via a door. You are given two choices:
- Push the door
- Pull the door
Surprise surprise, the door is locked so pushing or pulling didn’t matter, you are still locked out of the building.
The golden question. To push or to pull. When all along…. it doesn’t matter.
When it comes to designing your player choice, each decision your player makes needs to have some form of influence on the outcome of the game. It does not necessarily need to be immediate or in a physical form (like currency/powerup) but it should be apparent to the player in some form eventually. Otherwise, the player would feel that their decision didn’t matter and as a result, feel less invested and lose interest in the game.
2. The opportunity cost incurred choosing that choice
Choices matter to us only because we lose something choosing another. This is what we refer to as an opportunity cost. With opportunity costs attached to each choice, we can create dilemmas which engage the players by asking them to weigh the choices.
One classic example that is often used in other games is the Prisoner’s Dilemma. Bear with me if you saw this before but I will give a brief description to those who have yet to see this.
In this scenario, we have two prisoners, A and B. Both of them are taken into separate rooms with no means of communication between them, for interrogation. If one testifies and betrays the other, the testifier gets off free while the other suffers a heavier penalty. If both stay silent, they both only serve 1 year. If both testify, they both get a heavy sentence of 2 years
(Taken from Business Insider, who took it from Wikipedia)
From our point of view, the best outcome would be for A and B to keep silent. Both prisoners will serve 1 year and only a total of 2 years will be lost. In reality, when personal gain outweighs the collective good, it’s not that simple. Say, A chooses to stay silent but deep in his mind, this doubt surfaces. What happens if B betrays me? Wouldn’t I have to spend an additional 2 years?! If A was rational, the more logical choice would be to betray because of the possible reward of getting off free or the less heavy punishment of only spending 2 years. But what if B was a loyal friend to A, and doing so will destroy their 10-year friendship? Would that change A’s decision?
That same logic can be applied to our player choice. By creating multiple “what if” scenarios, you add weight to the player’s choice. Do I use this powerup now and risk not having it in the later stages? But if I don’t use it now, I can possibly lose the game now, etc.
3. The amount of information given to make that choice and the weight-risk ratio
In the previous point, we mentioned creating dilemmas but we forgot to mention one important detail. The prisoners’ dilemma will only happen if the prisoners were told about the years they would serve in each scenario. If the investigators simply demanded that they testify. Prisoner A probably wouldn’t testify since he does not know what he can potentially gain or lose. Without knowledge pertaining to the choices, those choices lose their consequences and impact. Another example would be if the player does not know what money does, spending it now or saving it for later doesn’t really matter, because to him, both choices are equally unclear.
At the same time, having too much information is not necessarily good. Back to the prisoners, if A had perfect knowledge of what B is going to do (maybe with a mind-reading device), there would be a clear and obvious choice to take no matter what B does. If B chooses to betray, the best outcome rationally for A is to betray too. If B chooses not to, the choice that gives the most benefits for A is to betray B.
The golden question…. how to get rid of all those apples afterwards...
Although other choices are given, if one choice is always optimal, it causes the other choices to be arbitrary (just for show). Hence, to avoid that scenario, the choices you design should have relatively equal weight-risk ratios. A choice cannot be too risky and provide too little benefits or vice versa. The information you provide should be just right so that players can make an informed decision and at the same time, due to the lack of certain information, there is no clear choice at any point of time.
4. The amount and diversity of choices given
Imagine that you are really hungry and there is only one restaurant nearby. There are only two dishes you can order. There isn’t much choice to make, is there? If you didn’t like the two the restaurant had to offer, it feels bad to fork out money for something you don’t really want but you are forced to have anyways (or you can starve, which is technically a valid option). Giving too little choice limits the fun a player can have.
Now, imagine that you made the (sad) choice of the two and the next thing that comes is not the food but a question of which sauce would you like out of their 108 homemade sauces. It’s not just that. What awaits you is not the food but a 1000-question survey, of what side dish would you like, what drink would you want, etc. Eventually, you (or the player) gives up and takes the most convenient choice, which trivializes the whole decision-making process.
The above scenario is an example of placing too much cognitive load on the player. Cognitive load refers to the amount of information that working memory can hold at one time. In John Sweller’s paper on cognitive load theory, it is said that generally, humans have a limited capacity of working memory of 5 to 9 items of information at any point of time. Overloading that working memory will only cause undesirable results. And the last thing you would want in your game is players being overloaded and giving up that decision-making because it is too tough to make that decision.
5. The rationality of players
When it’s no longer about winning
This may seem contradictory to the previous 4 points but. The previous 4 points are based on a huge assumption that players are rational. That players play to win. Often or not, there may be scenarios where players don’t play to win but rather for various other reasons. Some may go for the sandbox approach to just try out new stuff or some may just be targeting specific others for revenge (and ignoring their win conditions). It is difficult to consider for such interactions but it is good practice to take into consideration that there will be players who do not follow your mindset (if it were you playing the game) when it comes to making decisions.
So what do we do now after all these points to consider? The next decision one should make is to use what to document your player choices. One of the most popular support tools out there would be a Decision Tree to help you visualize and map out those player choices/actions.
A basic example of what a basic decision tree is. Super basic
The above diagram shows a simplified overview of a basic RPG game, the player fights monsters, restocks in the shop and fights again.
Here’s a general guide on how to build a basic decision tree:
-
Start off with the scenarios in your game and put them in boxes
-
Colour the scenarios which require decision-making
-
For those decision-making scenarios, create outgoing arrows for each decision your player can make
-
Link those arrows to their resulting scenario boxes.
-
If the decision indirectly impacts another scenario, link its direct result to the scenario it indirectly impacts with a dotted line
Like all things on the internet, there are many variations of decision trees out there and this is just one of the many. You can use this guide as it is but it is usually better if you adjust it accordingly to fit your game. The general idea of it all is for you to organize and visualize the entire structure of your game. It should display which outcome does each decision lead to or influence, which decisions are critical and which are repetitive (aka the game’s core gameplay loop and hence should be optimized).
In our upcoming game, Potato Pirates: Enter the Spudnet, we went through many iterations to improve the core gameplay loop. One of the initial ideas had the player choose between collecting money or cards every turn. Money and power cards help players advance their winning condition. So this is how it is like:
Sounds like a good player choice? It wasn’t. Why? Here’s the breakdown:
- The opportunity cost of each choice is somewhat clear and balanced. Choosing to get cards would mean having less money, vice versa
- The amount and diversity of choice may be little but the cards (and their various effects) adds onto the “Choose cards or money” to become “Choose to activate this or that effect or money”
- The impact, however, is not immediate. Taking cards doesn’t allow you to use them immediately. You need to have money. Taking money doesn’t allow you to do anything (since you don’t have cards)
- The amount of information given is sufficient but the deal-breaker lies in this area. There is always a clear optimal path. Take cards, then take money to fuel those cards. Having either one is pointless but having cards first to use (and deny others from having those cards) is logically better than having money but be unable to plan how to utilize it.
- We assumed that our playtesters will play logically. Most did but there were a few outliers who just kept taking money. God knows why.
Out of the 5 considerations listed above, we only achieved 2 so this iteration was scrapped and we repeated this design process until it led us to the final product today. If you like potatoes and board games, come take a look at our new board-game, Potato Pirates: Enter the Spudnet!
