160 likes | 182 Views
Delve into the intricate design of an AI system for Starcraft: Broodwar, its behavior tree structure, key strategies, and future developments. Learn about the implementation of attack, defense, gather, scout, build behaviors, and the critical role of Blackboard in managing data for optimal decision-making. Discover the challenges faced and proposed enhancements for improving AI performance. This overview provides insights into creating intelligent game-playing agents in the competitive realm of Starcraft.
E N D
Starcraft Behavior Tree AI HashemAayed Sean Boocock Michael Hsu Aadarsh Patel
Overview • Recapping our original goal • Behavior tree implementation • Other design considerations • Replays! • Future work • Q/A
Original Goal • Develop an AI capable of playing a full game of Starcraft: Broodwar as the Terran race against other Ais or human opponents and at least at the level of the game’s most difficult, stock AI
Results • Our AI defeats the stock AI the vast majority of the time on arbitrary maps and in all three match types (TvT, TvZ, and TvP) • Has also shown success defending against more gambit style openings like early zergling rushes and Dark Templar rushes • Plays “smart” using recognizable strategies that emerged from the AI priorities, not baked in build orders
Behavior Tree Implementation • Stats • Attack behaviors • 4 Attack behaviors (and two independent state machines for units) • Defend behaviors • One defend behavior for base defense • Gather behaviors • Two behaviors for resource gathering • Scout behaviors • Two behaviors for scouting (with scvs/vultures and command center comstat)
Behavior Tree Implementation • Stats • Build behaviors • Units • Seven ground and three air unit behaviors • Buildings • Fifteen buildings behaviors • Research behaviors • Flexible; currently eleven implemented
Behavior Tree Implementation • Stats • Parent (node) behaviors • Our tree was built of sequence behaviors that iterated through their children. Several of these behaviors had “decorators” that added additional functionality • BuildAirSequenceDecorator • BuildInfantrySequenceDecorator • BuildMechSequenceDecorator • BuildUnitsSequenceDecorator • GroundAttachSequenceDecorator • And more…
Behavior Tree Implementation • Basic architecture • Sequences of sequences with leaf nodes representing individual (or sometimes group) unit behaviors • Democratized and central planning • Sequences would dynamically cut off portions of the tree based on certain conditions throughout the match • Central planning controlled by the Blackboard class/manager
Behavior Tree Implementation = Sequence • Sequence with decorator that adds logic for: • Should we attack? • If so, what is the appropriate target? Root = Behavior Attack Individual units powered by state machines in addition to the behavior controlling the “army” AttackGround AttackAir MechAttack AirAttack GroundAttack
Behavior Tree Implementation • Sequence with decorator that adds logic for: • Should we build units now or are we saving up for something? • If so, what is appropriate for our opponent? = Sequence Root = Behavior Build • Sequences with decorator that adds logic for: • Should we build buildings now or are we expanding? BuildUnits BuildBuildings BuildInfantry BuildMech BuildAir BuildProduction BuildResearch BuildBarracks BuildMarines BuildVultures … BuildFactory BuildFirebats BuildMedics …
Behavior Tree Implementation • Blackboard • Data repository and management • Provides services for behaviors like self and enemy units/buildings, state information, callbacks for events, and base management • Base • Both self and enemy bases are represented by the Base class providing a logical container for Base specific information/state like • Units/buildings • Location • Local resources
Design Considerations • Handling priority • Behavior activation/priority is handled variously by the behaviors themselves, their parents, and the Blackboard planner • Basic priorities are baked into the structure of the tree itself with modifications in response to events (ie discovery of opponent’s race, reaching supply/mineral thresholds)
Design Considerations • BWAPI idiosyncrasies • Using the Broodwar API we were limited to all and only the information a human player would have about the game state • This meant we could only get limited snapshots of enemy units/buildings based on scouting • Another limitation was no built in support for event callbacks like building construction starts/completions/failures or attacks on units; everything had to be divined from the limited game state we had access to
Future work • Rearchitect parts of the implementation to expose as many tunable parameters as possible • Refine our implementation of proxy bot, a java server/client wrapper for BWAPI, to run randomized instances of our AI against each other and train them with a genetic algorithm
Q/A Thanks for listening