Sign up to save your podcasts
Or
Share 002 – Building an Encounter System Part 1
Share to email
Share to Facebook
Share to X
Share to email
Share to Facebook
Share to X
Or
002 – Building an Encounter System Part 1
In Episode 2 of the Nerdlab you will learn the three fundamental pillars of encounter and combat systems. This episode is the first in a series of episodes that will deal with the topic of Encounter Systems. Today we will focus on how to ask your players the right questions in order to make the encounter an exciting and entertaining experience for your players. The theories in this podcast episode are inspired by tabletop rpg, storytelling and literature. Let’s see what we can learn from these fields and how we can transform the insights into board game components and mechanics.
What is an encounter?
Last week we talked about vision statements as design pillars for your game. One of the design pillars I formulated for my game is that I want a multi-facetted encounter system. That’s why I want dive a little deeper into encounter building today.
We can find some sort of conflict resolution in most games.The goal of today’s episode is is to find out which components of conflict resolution we need to create interesting, diverse and challenging encounters and how we can convert these components into actual mechanics for our games.
How is an encounter structured and what is the key difference between an encounter and a combat?
For me, combat is simply the resolution of one or more conflicts by force in order to achieve an objective.
An Encounter on the other hand is also a resolution of one or more conflicts. But instead of being limited to using force to solve the conflict, a variety of different interactions can be used to achieve the desired objective.
So the resolution is no longer restricted to killing your enemy. In other words we do no longer have to design quests that require our players to kill x enemies. The room for interaction is much higher in a well designed encounter. For example, a conflict can also be solved by convincing the opponent diplomatically, bribing him with gold, sneak past him, or by just handing over the item he was actually after.
Fundamental Building Blocks of Encounters
Fundamental aspects of combat systems and encounter systems
Although there are some differences between Combat and Encounter situations, the fundamental building blocks are the same for both variants, so the following explanations will be just as helpful if your game is more on the combat side of things.
Each Combat or Encounter system can be broken down into three fundamental building blocks which describe relatively precisely with which way of thinking we as game designers should approach the creation of these scenarios:
First pillar: Asking a question:
Combat design is nothing more than your game asking a question to the players. In a combat scenario this question is determined by the enemy behaviour you have implemented. In a simplified way a possible question to confront your players with is: Can the players kill all goblins? We get soon into the nitty gritty and learn how you can ask better questions in your game.
Second Pillar: Giving the player the tools to answer the questions:
The second pillar is giving your players the tools to answer the question. This means you have to design player skills, spells, items and everything players can use to determine their behaviour.
Third Pillar: Create ways to manage and manipulate the resolution
The third pillar is that you need ways to manage and manipulate the resolution of questions and answers for each instance of combat. This means you need to have resolution mechanics and in most games some sort of RNG like dice or modifier cards. We also need some way of keeping track board states such as hit points, damage dealt or number of uses left on a item.
Asking the right questions
With these 3 pillars of encounter building in mind, I first thought about how to design a system that allows us to propose better questions.
Instead of asking a simple question we are going to formulate dramatic questions. The dramatic question is the cornerstone of your story and it is always about the protagonist’s central conflict.
A dramatic question is a statement of the heroes’ current objective rephrased into a yes-or-no question.
Typically these questions are not communicated directly to the players, but the players have to be aware of the task they have to solve.
Conflicts
But a dramatic question alone does not make for a good encounter. That is why we need one or more conflicts. The heroes cannot just go into the dragon’s lair crap the egg and walk out. Monsters and NPCs can be sources of conflict, but so can traps, hazards, obstacles or environmental conditions.
And now we come to the reason why I hate all these kill x quests. A dragon in its lair is not a conflict. It’s just a thing in a room. But this is the level of abstraction most board or card games make. And for me this is just one step too short. We need motives and goals to create sources of conflict.
A source of conflict could be an ancient dragon mom her lair protecting her eggs. But this is still not a conflict. The real conflict only occurs when there is another party involved.. In the dragon example a possible conflict could be: the dragons desire to protect her eggs vs. the players’ desire to steal one of the eggs.
You have to understand the difference between a thing (a dragon), a source of conflict (the dragon’s desire to protect her lair), and the conflict itself (the dragon’s desire to protect her eggs vs. the party’s desire to steal one of the eggs).
The dramatic question for this encounter could be:
Can the heroes leave the dragon’s lair with at least one of the dragon eggs?
Multiple conflicts
The scenario currently described is quite simple. There are only 2 participants who have contradictory goals. It becomes really interesting when there are multiple conflicts in an encounter. But the complexity also increases dramatically, because you have to consider how the different conflicts interact with each other. In our dragon example we could easily add another group of adventures who are on the same quest of stealing a dragon’s egg. If there is only one egg in the lair their is definitely a source of conflict and we could add a time aspect to the quest. If there is more than one egg, the groups could also work together.
The different conflicts do not have to be static or preset at the beginning of a quest. They can also occur during the course of a quest.
Let’s say one of the dragons hatches during the encounter. Since he would certainly rather stay with his mother, the dragon whelp probably also has a competing goal, which then leads to a whole new conflict.
Also the environment could be relevant as a source of conflict. Let’s say once the dragon mom lost more than half of her life or if the players grab one of her eggs she enrages. In wild rage, she smashes her tail around and damages the structural integrity of the cave. Now we have a whole lot of new conflicts. The ceiling of the cave that wants to collapse. The heroes who don’t want to be buried under the stones and the good old dragon mom who doesn’t want her eggs to be crushed. All of these conflicts influence the behaviour of the participants and lead to a more realistic and more memorable scenario. But there is more. Until now we only talked about external conflicts.
Internal conflicts
What about internal conflicts? For example, one of the heroes might have a problem kidnapping an unborn dragon baby from its mother and selling it to the highest bidder on the market.
These conflicts are called internal conflicts because they happen entirely inside of one entity for example a hero or an NPC. Internal conflicts occur because players have more than one desire, purpose, motive, or goal and, sometimes, those goals clash and cause dilemmas. This is something that could be implemented by personal quest goals, life goals or some kind of character alignment. The goal here is to create interesting trade offs for the individual players.
So we now talked a lot about conflicts. Remember the main reason we need conflicts is because they give the players something meaningful they need to solve in order to answer the dramatic question of the encounter.
By skilfully constructing a scenery, we have formulated a dramatic question and created multiple conflicts that can be answered in different ways. For an open ended pen and paper RPG it doesn’t really matter how a conflict is resolved as long as it answers the dramatic question. It could be solved by death of the heroes, death of the dragon, surrender of one of the parties, outsmarting by luring the dragon into the open or sneaking past the sleeping dragon mom.
For a gm-less, self-contained game in which you can’t improvise, however, this approach doesn’t quite work. We cannot just ask a question and leave it to the players to solve it in any way they want. In my game I will probably need pre-defined solution paths for the players instead of completely open roleplaying choices. But for me that is fine as long as there are enough different options for the characters to choose from.
Decision Points
In order to make the countless possibilities of conflicts and their resolution more tangible for the players and also for me as a game designer, we need pre-made decision points.
A decision point is when your game asks your player: Here is the situation, these are your options. What do you do?
Decision points come in two different flavors. Either a player can choose between different conflicts and which one he wants to resolve OR the player can choose how to resolve a particular conflict.
Choosing which conflict to resolve occurs when a player chooses which enemy to target or what obstacle he wants to overcome (swimming through the lake or crossing the shabby looking hanging bridge). I call these decision points strategic decisions.
Choosing how to resolve a particular conflict occurs when a player chooses what spell or attack to use on the dragon or whether to sneak past the dragon or fight it. I call the how to resolve a conflict decision points the action decisions.
When we want to build interesting encounters we need both kind of decision points. While the action decisions should be covered by a well designed combat and social combat system, the strategic decisions depend more on the individual quests and we will have to make sure to implement enough tactical decisions every time we create an encounter.
Assuming that our combat and social combat mechanics generate more than enough action decision points to make the resolution of a conflict fun, we still have to find out how to introduce new strategic decisions during an encounter.
A strategic decision point comes up when there is a new situation in the game. Once the encounter starts, the players choose a strategy and start making progress. With ongoing rounds, the number of choices are reduced. In combat, people settle into their positions, the number of targets steadily decreases, until it comes down to one player making the last attack against the last target. For my game I want to add new stimuli the players have to respond to. New circumstances that require strategic thinking and decision making.
If we come back to our good old dragon lady, a new strategic decision point could trigger once she is at 50% of her starting life and enrages. The situation now has changed, the collapsing cave is introducing a new conflict. Maybe the characters are forced to change their previous plan from killing the dragon to just grab an egg and run for their life. (This would by the way be a great follow-up encounter. Can the heroes reach the city before the enraged dragon mom stops them?)
For my system I will use so called triggers that go off at specific situations (such as an enemy being at 50% of its starting life) and then introduce new conflicts to the scenario.
One more thing we have to take care about regarding decision points is that we make sure players have more than one option to choose from.
When a player is out of options, either because there is nothing left to decide or because the number of useful, practical options has become limited, that player will lose interest in your game and play with his mobile instead. We want to avoid that by all costs. This means we want to avoid the following:
Repetition of the same action over and over again (If you are the tank and have to use your entire turn to block for several turns in a row, that is not fun and there is no choice).
This can also happen if a character has no spells left. One example from Gloomhaven here. Once you have less than 2 cards in hand you cannot perform a normal turn. You have to rest. THis is not a decision point. However Isaac the developer of Gloomhaven distinguished between short and long rest. The difference is that you heal some life, refresh some of your items and can choose which card you lose on the long rest, while you lose a random card during a short rest but you do not have to spent a whole turn for the rest action. So even if you are out of spells, there is still an interesting trade off for the player to make.
If you have to react to something and your reaction is predefined this is no decision point. In a first prototype of my game I had saving throws. If you would get hit by a fireball you could make a saving throw against fire to mitigate some of the damage. This was not a decision point. It was obvious that you would do the roll. So I will get rid of saving throws all together in my next version.
Another argument against the saving throws is that most decision points should be focused on actions the heroes can take to resolve a conflict or pursue the dramatic question instead of avoiding negative effects and defeat.
How to implement the encounter concept in a adventure card game?
Now let’s break all that theory down into digestible pieces for our own games. I will use my game as an example.
We need the following components:
I will go with the scenario book to begin with because it is the simplest way to start and I do not see the need for interaction between the story and other elements. If this turns out to be the case I could also see a possibility to use cards instead of the scenario book.
Social combat
These cards are then placed in a trigger area, which players check at the beginning of each round to see if any of the conditions have been met.
Challenge:
Generic vs. quest specific quests
What I want to avoid is printing a lot of cards that can only be used once. On the other hand, I would still like to use the triggers as cards, because I think that leads to a good gameplay. I want to utilize the cards possibility to hold some kind of hidden information. The players will then know when something is happening, but they don’t know what is going to happen.
Therefore, I am currently looking for a clever way to implement the triggers as cards but make them generic enough to use them for a variety of encounters. Probably the easiest way is to have generic trigger abilities like (2 enemies killed) on one side of the card and a unique referral number on the back of the card that then refers to a specific section in the rulebook.
What I have learned for my game from todays episode:
I also made the conscious decision that my game should have many decision points with real options.
Resolution mechanic needs to be simple
Combat system needs to be simple – Get rid of movement & positioning
Universal Resource needed to use for both combat and non-combat interactions
Closing
I hope today’s episode helped you to understand how multi-facetted encounters can be created and what components you could possibly use to do so.
If you already have a game you are working on, try to identify situations in which your players have to make a decision but do not have real decision point. Situations in which your players are forced to perform a certain action. Then think about creative ways to either get rid of these pseudo decision points or add another layer as Isaac did for gloomhaven by distinguishing between long and short rests.
Maybe you got some inspiration for your own design or even got some ideas for my design challenges. If so please contact me: http://nerdlab-games.com/contact/
This is also the address to use if you want to get a weekly update of my design diary with all relevant resources I use to create this podcast and develop my game.
Next week we will probably talk about the second encounter design pillar. Giving your players the tools to answer the questions.
Thank you so much for listening to the entire episode and until next week keep shooting for the moon and nerd like a boss.
Sources:
Fundamental pillars of a combat system
Four things you’ve never heard of that make encounters not suck
View all episodes
By Marvin Hegen
5
1010 ratings
In Episode 2 of the Nerdlab you will learn the three fundamental pillars of encounter and combat systems. This episode is the first in a series of episodes that will deal with the topic of Encounter Systems. Today we will focus on how to ask your players the right questions in order to make the encounter an exciting and entertaining experience for your players. The theories in this podcast episode are inspired by tabletop rpg, storytelling and literature. Let’s see what we can learn from these fields and how we can transform the insights into board game components and mechanics.
What is an encounter?
Last week we talked about vision statements as design pillars for your game. One of the design pillars I formulated for my game is that I want a multi-facetted encounter system. That’s why I want dive a little deeper into encounter building today.
We can find some sort of conflict resolution in most games.The goal of today’s episode is is to find out which components of conflict resolution we need to create interesting, diverse and challenging encounters and how we can convert these components into actual mechanics for our games.
How is an encounter structured and what is the key difference between an encounter and a combat?
For me, combat is simply the resolution of one or more conflicts by force in order to achieve an objective.
An Encounter on the other hand is also a resolution of one or more conflicts. But instead of being limited to using force to solve the conflict, a variety of different interactions can be used to achieve the desired objective.
So the resolution is no longer restricted to killing your enemy. In other words we do no longer have to design quests that require our players to kill x enemies. The room for interaction is much higher in a well designed encounter. For example, a conflict can also be solved by convincing the opponent diplomatically, bribing him with gold, sneak past him, or by just handing over the item he was actually after.
Fundamental Building Blocks of Encounters
Fundamental aspects of combat systems and encounter systems
Although there are some differences between Combat and Encounter situations, the fundamental building blocks are the same for both variants, so the following explanations will be just as helpful if your game is more on the combat side of things.
Each Combat or Encounter system can be broken down into three fundamental building blocks which describe relatively precisely with which way of thinking we as game designers should approach the creation of these scenarios:
First pillar: Asking a question:
Combat design is nothing more than your game asking a question to the players. In a combat scenario this question is determined by the enemy behaviour you have implemented. In a simplified way a possible question to confront your players with is: Can the players kill all goblins? We get soon into the nitty gritty and learn how you can ask better questions in your game.
Second Pillar: Giving the player the tools to answer the questions:
The second pillar is giving your players the tools to answer the question. This means you have to design player skills, spells, items and everything players can use to determine their behaviour.
Third Pillar: Create ways to manage and manipulate the resolution
The third pillar is that you need ways to manage and manipulate the resolution of questions and answers for each instance of combat. This means you need to have resolution mechanics and in most games some sort of RNG like dice or modifier cards. We also need some way of keeping track board states such as hit points, damage dealt or number of uses left on a item.
Asking the right questions
With these 3 pillars of encounter building in mind, I first thought about how to design a system that allows us to propose better questions.
Instead of asking a simple question we are going to formulate dramatic questions. The dramatic question is the cornerstone of your story and it is always about the protagonist’s central conflict.
A dramatic question is a statement of the heroes’ current objective rephrased into a yes-or-no question.
Typically these questions are not communicated directly to the players, but the players have to be aware of the task they have to solve.
Conflicts
But a dramatic question alone does not make for a good encounter. That is why we need one or more conflicts. The heroes cannot just go into the dragon’s lair crap the egg and walk out. Monsters and NPCs can be sources of conflict, but so can traps, hazards, obstacles or environmental conditions.
And now we come to the reason why I hate all these kill x quests. A dragon in its lair is not a conflict. It’s just a thing in a room. But this is the level of abstraction most board or card games make. And for me this is just one step too short. We need motives and goals to create sources of conflict.
A source of conflict could be an ancient dragon mom her lair protecting her eggs. But this is still not a conflict. The real conflict only occurs when there is another party involved.. In the dragon example a possible conflict could be: the dragons desire to protect her eggs vs. the players’ desire to steal one of the eggs.
You have to understand the difference between a thing (a dragon), a source of conflict (the dragon’s desire to protect her lair), and the conflict itself (the dragon’s desire to protect her eggs vs. the party’s desire to steal one of the eggs).
The dramatic question for this encounter could be:
Can the heroes leave the dragon’s lair with at least one of the dragon eggs?
Multiple conflicts
The scenario currently described is quite simple. There are only 2 participants who have contradictory goals. It becomes really interesting when there are multiple conflicts in an encounter. But the complexity also increases dramatically, because you have to consider how the different conflicts interact with each other. In our dragon example we could easily add another group of adventures who are on the same quest of stealing a dragon’s egg. If there is only one egg in the lair their is definitely a source of conflict and we could add a time aspect to the quest. If there is more than one egg, the groups could also work together.
The different conflicts do not have to be static or preset at the beginning of a quest. They can also occur during the course of a quest.
Let’s say one of the dragons hatches during the encounter. Since he would certainly rather stay with his mother, the dragon whelp probably also has a competing goal, which then leads to a whole new conflict.
Also the environment could be relevant as a source of conflict. Let’s say once the dragon mom lost more than half of her life or if the players grab one of her eggs she enrages. In wild rage, she smashes her tail around and damages the structural integrity of the cave. Now we have a whole lot of new conflicts. The ceiling of the cave that wants to collapse. The heroes who don’t want to be buried under the stones and the good old dragon mom who doesn’t want her eggs to be crushed. All of these conflicts influence the behaviour of the participants and lead to a more realistic and more memorable scenario. But there is more. Until now we only talked about external conflicts.
Internal conflicts
What about internal conflicts? For example, one of the heroes might have a problem kidnapping an unborn dragon baby from its mother and selling it to the highest bidder on the market.
These conflicts are called internal conflicts because they happen entirely inside of one entity for example a hero or an NPC. Internal conflicts occur because players have more than one desire, purpose, motive, or goal and, sometimes, those goals clash and cause dilemmas. This is something that could be implemented by personal quest goals, life goals or some kind of character alignment. The goal here is to create interesting trade offs for the individual players.
So we now talked a lot about conflicts. Remember the main reason we need conflicts is because they give the players something meaningful they need to solve in order to answer the dramatic question of the encounter.
By skilfully constructing a scenery, we have formulated a dramatic question and created multiple conflicts that can be answered in different ways. For an open ended pen and paper RPG it doesn’t really matter how a conflict is resolved as long as it answers the dramatic question. It could be solved by death of the heroes, death of the dragon, surrender of one of the parties, outsmarting by luring the dragon into the open or sneaking past the sleeping dragon mom.
For a gm-less, self-contained game in which you can’t improvise, however, this approach doesn’t quite work. We cannot just ask a question and leave it to the players to solve it in any way they want. In my game I will probably need pre-defined solution paths for the players instead of completely open roleplaying choices. But for me that is fine as long as there are enough different options for the characters to choose from.
Decision Points
In order to make the countless possibilities of conflicts and their resolution more tangible for the players and also for me as a game designer, we need pre-made decision points.
A decision point is when your game asks your player: Here is the situation, these are your options. What do you do?
Decision points come in two different flavors. Either a player can choose between different conflicts and which one he wants to resolve OR the player can choose how to resolve a particular conflict.
Choosing which conflict to resolve occurs when a player chooses which enemy to target or what obstacle he wants to overcome (swimming through the lake or crossing the shabby looking hanging bridge). I call these decision points strategic decisions.
Choosing how to resolve a particular conflict occurs when a player chooses what spell or attack to use on the dragon or whether to sneak past the dragon or fight it. I call the how to resolve a conflict decision points the action decisions.
When we want to build interesting encounters we need both kind of decision points. While the action decisions should be covered by a well designed combat and social combat system, the strategic decisions depend more on the individual quests and we will have to make sure to implement enough tactical decisions every time we create an encounter.
Assuming that our combat and social combat mechanics generate more than enough action decision points to make the resolution of a conflict fun, we still have to find out how to introduce new strategic decisions during an encounter.
A strategic decision point comes up when there is a new situation in the game. Once the encounter starts, the players choose a strategy and start making progress. With ongoing rounds, the number of choices are reduced. In combat, people settle into their positions, the number of targets steadily decreases, until it comes down to one player making the last attack against the last target. For my game I want to add new stimuli the players have to respond to. New circumstances that require strategic thinking and decision making.
If we come back to our good old dragon lady, a new strategic decision point could trigger once she is at 50% of her starting life and enrages. The situation now has changed, the collapsing cave is introducing a new conflict. Maybe the characters are forced to change their previous plan from killing the dragon to just grab an egg and run for their life. (This would by the way be a great follow-up encounter. Can the heroes reach the city before the enraged dragon mom stops them?)
For my system I will use so called triggers that go off at specific situations (such as an enemy being at 50% of its starting life) and then introduce new conflicts to the scenario.
One more thing we have to take care about regarding decision points is that we make sure players have more than one option to choose from.
When a player is out of options, either because there is nothing left to decide or because the number of useful, practical options has become limited, that player will lose interest in your game and play with his mobile instead. We want to avoid that by all costs. This means we want to avoid the following:
Repetition of the same action over and over again (If you are the tank and have to use your entire turn to block for several turns in a row, that is not fun and there is no choice).
This can also happen if a character has no spells left. One example from Gloomhaven here. Once you have less than 2 cards in hand you cannot perform a normal turn. You have to rest. THis is not a decision point. However Isaac the developer of Gloomhaven distinguished between short and long rest. The difference is that you heal some life, refresh some of your items and can choose which card you lose on the long rest, while you lose a random card during a short rest but you do not have to spent a whole turn for the rest action. So even if you are out of spells, there is still an interesting trade off for the player to make.
If you have to react to something and your reaction is predefined this is no decision point. In a first prototype of my game I had saving throws. If you would get hit by a fireball you could make a saving throw against fire to mitigate some of the damage. This was not a decision point. It was obvious that you would do the roll. So I will get rid of saving throws all together in my next version.
Another argument against the saving throws is that most decision points should be focused on actions the heroes can take to resolve a conflict or pursue the dramatic question instead of avoiding negative effects and defeat.
How to implement the encounter concept in a adventure card game?
Now let’s break all that theory down into digestible pieces for our own games. I will use my game as an example.
We need the following components:
I will go with the scenario book to begin with because it is the simplest way to start and I do not see the need for interaction between the story and other elements. If this turns out to be the case I could also see a possibility to use cards instead of the scenario book.
Social combat
These cards are then placed in a trigger area, which players check at the beginning of each round to see if any of the conditions have been met.
Challenge:
Generic vs. quest specific quests
What I want to avoid is printing a lot of cards that can only be used once. On the other hand, I would still like to use the triggers as cards, because I think that leads to a good gameplay. I want to utilize the cards possibility to hold some kind of hidden information. The players will then know when something is happening, but they don’t know what is going to happen.
Therefore, I am currently looking for a clever way to implement the triggers as cards but make them generic enough to use them for a variety of encounters. Probably the easiest way is to have generic trigger abilities like (2 enemies killed) on one side of the card and a unique referral number on the back of the card that then refers to a specific section in the rulebook.
What I have learned for my game from todays episode:
I also made the conscious decision that my game should have many decision points with real options.
Resolution mechanic needs to be simple
Combat system needs to be simple – Get rid of movement & positioning
Universal Resource needed to use for both combat and non-combat interactions
Closing
I hope today’s episode helped you to understand how multi-facetted encounters can be created and what components you could possibly use to do so.
If you already have a game you are working on, try to identify situations in which your players have to make a decision but do not have real decision point. Situations in which your players are forced to perform a certain action. Then think about creative ways to either get rid of these pseudo decision points or add another layer as Isaac did for gloomhaven by distinguishing between long and short rests.
Maybe you got some inspiration for your own design or even got some ideas for my design challenges. If so please contact me: http://nerdlab-games.com/contact/
This is also the address to use if you want to get a weekly update of my design diary with all relevant resources I use to create this podcast and develop my game.
Next week we will probably talk about the second encounter design pillar. Giving your players the tools to answer the questions.
Thank you so much for listening to the entire episode and until next week keep shooting for the moon and nerd like a boss.
Sources:
Fundamental pillars of a combat system
Four things you’ve never heard of that make encounters not suck