jonas nelson, splash damage. what we’ll cover combat state machine dynamic cover system ...
TRANSCRIPT
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?