1. Jonas Nelson, Splash Damage

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

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

4. Combat State Machine

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

6. dynamic Cover System

7. Dynamic Cover System

8. Dynamic cover system

10. 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

11. 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

12. 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

13. Dynamic Cover System

14. 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

15. 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

16. 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

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

18. 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)

19. Questions?