Encounter
Continuous sequence of challenges that test the player's skills; usually in combat with NPCs

What is an encounter?

An encounter is any continuous conflict or challenge, usually "player vs enemy" (PvE) single player combat against NPCs.
Every game has a different approach to challenge and conflict, and some games encourage players to resolve problems without violence or weapons. But for the purposes of this book, we will follow the commercial game industry's emphasis on combat design, especially with shooters and gunplay.
Encounters are systemic open-ended challenges that support a variety of improvised player tactics. In contrast, a puzzle is a designed challenge with more specific unique solutions. Players can use repetitive tactics ("cheesing") to complete an encounter, but generally, one cannot cheese a puzzle.
combat front diagram for a cover-based military shooter, from "Creating Conflict: Combat Design for AAA Action Games" by Michael Barclay, Sam Howels, Pete Ellis (GDC Europe 2016)

What you need for encounters

As discussed in pre-production, encounter design for an early project can be frustrating. It is difficult to prototype encounters when core mechanics, enemy design, and tools are not finalized yet. Nonetheless, building encounters for early prototypes is still important because there's no other way to validate mechanics, enemies, or tools.

Common combat mechanics

ADSR

Attacks, combos

Tells, telegraphs

Block, parry, counter

Enemy design

Implementing enemies in a game tends to require collaboration across game designers, gameplay programmers, artists, animators, and sound designers. That work is definitely beyond the scope of this book. So here, we're only going to talk about the general design part of that process.
The game industry has been making combat games for decades, and so game design culture has developed norms about what good enemy design should do. Below are some best practices for conventional enemy design:
  • Diversity. Each enemy type should feel different to fight, avoid similar enemies.
  • Hierarchy. Some enemies should be less dangerous, while higher ranking enemies are more dangerous. Make this ranking clear and readable to the player.
  • Longevity. Early game weak enemies should not be trivial or neglected in the late game. All enemy types should be interesting to fight, avoid enemy designs that become "obsolete". It's OK if an enemy type changes its role, e.g. a "mid boss" becomes a common enemy.
  • Emergence. Combinations of different arena designs or enemy types should create new unexpected dynamics and behaviors. The player should not be able to use the same tactics for the same enemy every time.
  • Intelligence. Enemies should give the illusion of intelligence and interiority, with different emotional states (idle, afraid, angry, etc.) in response to events during combat. "Smart" enemies should have high survivability, or else they'll die before they can show off how smart they are.
  • Consistency. Enemy behavior should feel predictable, and dangerous attacks should have "tells" for players to recognize and avoid.

Combat roles

Role
Behavior
Grunt
Mindlessly charge enemies
Squaddie
Take turns charging enemy; otherwise hang back
Commander
Buff nearby grunts and squaddies, run away from enemies

Encounter design / scripting tools

Strong scripting tools let you prototype combat mechanics or new enemies without touching engine code... (TO DO)

Player personas / play styles

A persona is a type of user with a certain type of behavior, play style, or motivation.
For example, a narrative-focused RPG might design multiple paths for melee, ranged, stealth, and conversation-based approaches to completing a quest. Cover shooter games often try to support long range sniper players as well as shotgun-preferring close combat players.
One of the earliest attempts to classify all players for all games was the 1996 Bartle Test of Gamer Psychology. Bartle was studying player behavior in early text-based MMOs called MUDs, and sorted all gamers into four general categories:
  • achievers want to score the most points, maximize game progress
  • explorers want to discover new places or systems, map-out the game space
  • killers focus on PvP / competitive conflict with other players, sometimes unfairly
  • socializers focus on cooperation with other players, roleplaying and fan culture
In reality, players are never just one category. People are a complex combination of all these motivations and more. Nonetheless, this reductive simplicity can be useful.
For each project, define your own player personas: (1) identify a player tactic / motivation, (2) label it with a good short catchy name. Some examples:
  • platformers might have runners, jumpers, gliders, swimmers
  • open world games might have explorers, fighters, drivers, collectors
  • strategy games might have rushers, turtlers, expansionists, diplomats
  • any game has completionists, speedrunners, lore hunters, streamers, etc.
Then apply the personas to your encounter design.
  • which levels should support which personas?
  • are you trying to support too many personas?
(TODO: link to user research in games)

How to plan an encounter

To design a battle / combat encounter, make a plan that answers these questions:
  • Who are we fighting?
    • Enemy types, enemy composition, spawn waves
    • Is this a small fight or a big fight?
  • Where are we fighting?
    • Terrain, points of interest, territory
    • Is there potential to use every part of the arena?
    • What is the overall balance of this combat space?
  • Why are we fighting?
    • Why these enemy types at this point in the game?
    • What is the experience goal for this encounter?
    • What overall goal must the player accomplish?
Your encounter design should flow from your game's overall experience goals and pacing plan.
There is no single best encounter design. Sometimes fending off an ambush feels exciting, and sometimes it feels unfair; sometimes grinding waves of weaker enemies feels satisfying, and sometimes it feels tedious. The context and framing matters.

Anatomy of an encounter

Encounters are all about pacing. What happens and when, and how does the encounter respond to the player's actions?
  • Before the fight:
    • Are enemies already in battle, or unaware / unprepared, or do they appear later?
    • Does player choose when to start combat, or are they forced into combat?
    • How well will the player understand terrain and enemy count beforehand?
  • During the fight:
    • Is this a short skirmish, or long gauntlet with multiple stages and waves?
    • Any scripted events that change terrain or enemy count?
    • Are there multiple viable strategies to win? How to help the player change strategies during battle?
  • After the fight:
    • How does the player accomplish their goals in the end?
    • How will the player know when the battle is over?
    • Are there multiple possible outcomes, rewards, or consequences?
Some encounter designers think of this as a combat story. If the player had to tell a war story of what happened during the encounter, how would they tell that story? Good encounter design helps player understand what's happening, enough to tell a coherent story with clear cause and effect.

Starting an encounter: footholds

For single player action shooters with an emphasis on cover, give the player an opportunity to survey the arena before the fight actually begins. They need time to look around where to fight from, predict where enemies will fight from, and create an escape plan in case the fight turns against them.
If you don't help the player understand the layout, then the player will just fight unimaginatively from the doorway without committing. Your arena design will go unused, and the player will blame the game for offering so little information and incentive to use the arena.
How do we entice the player to move into the arena, understand the layout, and then engage enemies? Andrew Yoder calls this "the door problem of combat design."
There are several ways to give the player a chance to find their foothold:

METHOD 1: Player ambushes enemies

Begin the encounter with enemies unaware of the player's presence, visually exposed from the arena entrance. This allows the player some time to form a plan, and attack when they are ready.
Although the player will likely eliminate the exposed unaware enemies very easily at first, you can just hide or spawn more enemies around the corner, and bring in these reinforcements when the fight begins.
This pattern is common in open world games, or any large landscape dotted with enemy outposts. It fits with the genre's aesthetic to promote freedom of movement.

METHOD 2: Enemies ambush player

Begin the encounter with no enemies, so the player will wander into the middle of the arena. Once they pass some sort of midfield threshold, trigger enemies and begin the fight. Optionally, place some items and resources in the middle as "bait."
Experienced players will likely understand this as a clear trap, and become especially suspicious if the empty room is structured like an arena, or if the bait is offered freely with no apparent cost or danger.
Note that the surprise quickly loses its luster after the player's first attempt. Avoid making enemy ambushes very difficult, because the repeated deaths and trial-and-error gameplay, combined with the player's lack of control over the ambush, may feel grating or unfair.
This pattern is common in classical shooters and horror games. Players more readily accept the contrivance when it is in service of shocking them.

METHOD 3: Vista with optional one-way entrance

Begin the encounter with unaware yet unattackable enemies, observable from a vista (high vantage point) but separated by an unbreakable window or long distance out of attack range. The player can collect information, form a plan, and begin the fight when they wish.
Optionally, force the player to enter the arena via one-way entrance, with a short vertical drop or airlock door closing behind them. This way there is minimal opportunity to surprise the enemy or cheese the fight. Once the player drops down into the arena, they are committed. The closest thing to a "fair fight."
If playtesters don't make use of the vista, try: (a) placing resources at the vista, (b) make smoother flow into the vista, (c) obstruct flow to the arena entrance and obfuscate the entrance at first (eg. with a U-turn typology), or (d) all of the above.
This pattern is common for boss fights or any big climactic set piece encounter. Forcing the player to stop at a purpose-built vista is a strong design gesture that warns the player: don't be thoughtless, be prepared.

Encounter design tools

Arena design

todo: break up sock's diagrams and talk about them individually
different floor design diagrams for encounters by Simon O'Callaghan
different fps encounter elements by Simon O'Callaghan

Example: combat bosses in God of War (2018)

Throughout the third person action game God of War (2018), the player can try to defeat 9 optional bosses called "Valkyries". All the valkyries share similar character art, animations, and move sets, but use these moves in different orders under different conditions, making effective reuse of the same assets while building combat variation.
The player unlocks a boss by progressing through the game and unlocking areas, thus implying an order but not forcing the player to fight them in order. The first three were specifically intended as loose tutorials for players to recognize tells and telegraphs, though sometimes the designers exploit this suggested order by mixing up prior patterns to force the player to relearn new timings.
Gunnr has 2 standalone attacks whose role is to encourage parry (yellow FX); their anticipation window/attack speed are similar to allow for consistent parry timing. [It] encourages the player to parry, but doesn’t require it. All of Gunnr’s attacks can be evaded left / right / back or parried [except] 1 unparryable (red) attack [...] performed after a series of initial attacks, so the player has plenty of time to prepare. The unblockable attack has almost zero tracking so the player can evade to the right with minimal precision. Gunnr usually evades away to initiate her standalone attacks. This gives the player an obvious visual tell but also a huge amount of layered anticipation time ~2-3s to prepare and react to the subsequent attack. [...] Gunnr has virtually no downtime after evading and then attacking which arguably makes the fight easier. This removes one less variable the player has to strategize against. The designers’ kept the intensity high, but actually put the enemy in a vulnerable position.
animated GIF showing Gunnr's attacks with long anticipation and yellow FX to encourage parry / evade (https://twitter.com/jasondeheras/status/1376005121830658049)
Unlike Gunnr, Kara’s has 2 attacks that strongly forces the player to evade/block. Since these attacks have similar startup poses, the player must identify the red FX to choose evade or block. [...] Kara shares Gunnr’s Dash, but [if] the player mistimes a parry/plays defensive, they’ll be vulnerable to nearby Draugrs, [adding tension.] Kara’s Wing swipe is a standalone attack that gives her another mixup when evading away and resetting the fight. [...] The range that Kara’s Wing swipe is initiated causes it to miss on purpose. This serves to lull the player to sleep and bait them into attacking if they aren’t paying attention or become greedy. The small burst of forward translation at the end makes this attack deceptive.
Geirdriful shares some moves from both Gunnr and Kara, but adds 2 unique attacks for a formidable/well-rounded moveset [...] Her lone closing attack is unparryable and gives her a high risk / high reward attack compared to Gunn/Kara’s dashing attack that can be parried. [...] Geirdriful’s wing swipe combo is the same as Gunnr’s, but used as a standalone attack (as opposed to Gunnr’s counter attack), another mixup to make the fight less predictable. Geirdriful shares the Gunnr wing thrust unblockable but as a standalone attack with increased translation/speed. If the player fought Gunnr first, then the removal of the wing swipes before the wing thrust unblockable will force them to relearn the cadence of this attack.
internal design spreadsheet showing the moveset matrix for valkyrie bosses in God of War (2018), by Jason de Heras (https://twitter.com/jasondeheras/status/1376005158656638977/photo/1)

Example: stealth boss in Dishonored

In the stealth first person game Dishonored, mission 7 "The Flooded District", the player faces a boss NPC. They can sneak past the boss undetected or attempt to fight the boss. Arkane Studios level designer Dana Nightingale commented on her design documents for the encounter:
Normally I hated boss fights so it was kind of excited to design one to avoid all of the stuff I didn't like about them. [...] Designing that encounter with Daud is still one of the things I'm the most proud of. I love watching people play though it. Big blocks of text is nice for a "dev commentary", but it doesn't work well if you have a hundred docs to keep up to date or you're the person who has to read them. Simpler, but conveying more, is always the goal. That's really hard.
Nightingale's original design documents (below) outline clear design goals for the encounter to justify the unusually closed-off arena layout. Additionally, because Dishonored is an "immersive sim" RPG game with many different player abilities, she uses a flowchart format to imagine different player strategies and how the encounter scripting should handle edge cases gracefully. However, as she points out, it is quite a lot to read; writing too much detail into a design brief does not necessarily improve planning or design.
design documents for boss encounter in Dishonored, by Dana Nightingale (https://twitter.com/DanaENight/status/1370643659792744449)
example stealth no-alert "ghost" playthrough of the boss encounter; does it accomplish Nightingale's goals? how does it differ from the initial design pitch?

Further reading

Last modified 22d ago