Combat reasoning

Jonas Nelson, Splash DamageIn BRINK

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

Attack

React

Hide

Chase

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

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?