Jonas Nelson, Splash Damage

What we’ll cover  Combat State Machine  Dynamic Cover System  Developing Brink

Combat reasoning  State machine  Completely implemented in C++ with no direct designer control  Heavily based on dynamic cover system  No explicit team coordination

Combat State Machine

dynamic Cover System  No pre-calculated cover information  Circular sampling patterns  Traces determine whether position is a cover or an attack position

dynamic Cover System

Dynamic Cover System

Dynamic cover system

dynamic Cover System  Positions are evaluated constantly even when there's no valid enemy  Positions are only evaluated against the most important target for performance reasons  Result of evaluation is written to world state

dynamic Cover System  Every frame, evaluate one position for each bot  If the position is in a valid navmesh position (i.e we can move to it) – Perform trace to most important target – Result of trace determines visibility state for position  Traces are deferred and callback lets us know when it's done

dynamic Cover System  Every frame evaluate position queries for cover positions  Each type of query score the position differently – Cover – Closest attack position – Farthest attack position – Sidemove attack position  Punishing arrival distance to cover gives rise to simple flanking logic

Dynamic Cover System

dynamic Cover System  Moveable reference position gives ”cover” system many uses – Use cover while hacking – Detonating satchel charges – Use cover while deploying mines and turrets – Avoid dangers (such as grenades) while going to cover – During normal combat the reference position keeps moving relative to enemies and allies

Greatest Challenges  Small team size  Testing. Code coverage invaluable  Limitations of AAS compiler not taken into account when building maps  Transitions between combat and non-combat – Requires tactial awareness that bots lack

How to do this with a small team?  Don't spend time authoring tools, especially tools no one will use  Keep each component simple. Combining components will create complex behaviour  Piggy-back off gameplay. Good communication is key  Code coverage invaluable

What Worked Well?  People having difficulty telling bots from humans  Bots are good teammates – They play the game ”as it should be played”

Limitations  Bots aren't tactically aware enough, making them bad attackers  When playing against multiple humans, bots aren't challenging enough  Bots unaware of some human tactics (like rushing objectives)

Questions?