1 / 16

Starcraft Behavior Tree AI

Starcraft Behavior Tree AI. Hashem Aayed Sean Boocock Michael Hsu Aadarsh Patel. Overview. Recapping our original goal Behavior tree implementation Other design considerations Replays! Future work Q/A. Original Goal.

poppy
Download Presentation

Starcraft Behavior Tree AI

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Starcraft Behavior Tree AI HashemAayed Sean Boocock Michael Hsu Aadarsh Patel

  2. Overview • Recapping our original goal • Behavior tree implementation • Other design considerations • Replays! • Future work • Q/A

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

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

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

  6. Behavior Tree Implementation • Stats • Build behaviors • Units • Seven ground and three air unit behaviors • Buildings • Fifteen buildings behaviors • Research behaviors • Flexible; currently eleven implemented

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

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

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

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

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

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

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

  14. Replays

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

  16. Q/A Thanks for listening

More Related