- Generated by
1.16.1
|
ProtoBot
|
| CAction | Actions for squads to be able to perform |
| CAreaIdHash | Hash used for storing <AreaId, Area> pairs |
| CAreaIdPairHash | Hash for storing AreaId pairs as keys |
| CAStar | AStar is a static utility class that any manager can call on to use A* pathfinding. It makes use of precaching and caching to optimize pathfinding, as well as some optimizations within the A* algorithm itself (using a priority queue for the open set, using an array for the closed set, etc.) |
| CAttackingState | The AttackingState has all units in the attacking squad move towards the assigned attack position |
| CBlockData | The BWEB does not store the data about the specification of a block. The class BlockData allows the BuildingPlacer to preprocess Blocks generated by the BWEB to be able to distinguish the amount of possible placements we have |
| CBOIDS | (DISCONTINUED) Unfortunately, BOIDS could not be optimized enough to be run within tournament computation time rules. However, the algorithm is still a cool implementation of a flocking algorithm for unit movement, so it is being kept in the codebase for potential future use |
| CBuilder | An instance of a Builder is created when ProtoBot's Build Manager has done the following for an approved ResourceRequest. - Found an ideal location to place - Found A worker that is avalible to construct the building - Attempted to generate an AStar Path to the located |
| CBuildingPlacer | The BuildingPlacer is the way ProtoBot is able to utilize the BWEB blocks generated to place down buildings. This allows for a single class to be able to find places to build and returns information about the placement info if anything goes wrong. When the BuildingPlacer is first created the Blocks that generated are stored into lists that ProtoBot is able to use based on the building type of a ResourceRequest. This allows the BuildingPlacer to find a suitable generated locations without having to loop through ever single block on the map. More blocks are added based on the areas the ProtoBot controls. To prevent the risk of ProtoBot building in enemy territory, ProtoBot will only build in the areas that ProtoBot currently 'controls'. When a nexus is created this expands ProtoBot's influence and makes more blocks avalible if any are generated in that location |
| CBuildManager | The BuildManagers responsibility is to be able to service the ResourceRequests passed to it and verify a unit is able to create the upgrade or combat unit. In the case of buildings more work is required to be able to find suitable locations to make sure that building can be constructed. The class is also responsible for defining and executing the openings for each race that StarCraft has, allowing ProtoBot to have openers similar to chess at the beginning stages of a StarCraft game |
| CBuildOrder | BuildOrders are a similar line of thinking to opening you would see in chess. ProtoBot emulates oepnings that proffesional StarCraft players and the community have refined over the course of the games lifetime. ProtoBot performs 2 opening against all 3 races: Protoss - 2 Gateway Dark Templar Terran - 2 Gateway Dark Templar Zerg - 2 Gateway Observer To see other oepning that have been created you can view them in the link below: https://liquipedia.net/starcraft/Protoss_Strategy |
| CBuildOrderStep | Represent the instruction ProtoBot should perform for a BuildOrder step |
| CBuildTrigger | |
| CCombatManager | Combat module of ProtoBot |
| CDarkTemplar | DarkTemplar Controls scouting behavior for a Protoss Dark Templar. Combines movement, target prioritization, and stealth-based harassment to pressure the enemy while scouting |
| CDefendingState | All units move towards assigned chokepoints and defends against any enemy attacks |
| CEconomyManager | The EconomyManager is responsible for the assignment of workers to be able to farm optimally across the nexus's ProtoBot creates over the course of a game. Each nexus has a defined NexusEconomy that implements a resource farming algorithm to optimally schedule workers to gather resources |
| CEnemyBuildingCounter | |
| CEnemyBuildingInfo | |
| CEnemyLocations | |
| CEnemyTechCounter | |
| CEnemyUpgradeCounter | |
| CFriendlyBuildingCounter | |
| CFriendlyTechCounter | |
| CFriendlyUnitCounter | |
| CFriendlyUpgradeCounter | |
| CIdleState | When any squad is created, it is assigned this state by default. This state does nothing |
| CIncompleteBuildingCounter | Buildings currently being constructed (not completed) |
| CInfluenceMap | |
| CInformationManager | |
| CKitingBehaviors | |
| CNexusEconomy | A NexusEconomy is a the way we are able to assign workers to a specific Nexus to farm resources at the Resource Depots that ProtoBot has created. [Note] I have to admit the code structure for this is honestly terrible and is not great the way to be able to assign workers. If you are reading this and wanting to create a SC BW bot, make workers a class on their own and define a state machine for their specific behaviour and create components that are able to find optimal ways to farm, scout, and build given some extra arguments. It makes the handling of workers from different states easier and makes crashing less likely to happen if you dont have them as references else where |
| CNode | |
| CPath | Class representing a path and its information (vector of positions, total distance, etc.) |
| CPlacementInfo | When an attempt to find a location to place a building fails, the PlacementInfo struct is able to provide the details on what exactly is preventing us from building. \nProtoBot not being able to build can happen because of many reasons: - Tiles is not powered. - No BWEB geenerated places for supply left to build. - No avalible gysers are avalible for a refinery. - No BWEB blocks for buildings are all used. - No avalible expansion locations are avalible |
| CPositionHash | Hash for storing BWAPI::TilePositions |
| CPossibleBuildingRequest | |
| CPossibleRequests | When a unit is requested to be made, a couple checks need to be put in place to see if ProtoBot is making units at a expected amount. A PossibleRequests is a way to be able to consider the creation of the unit before actually making a request |
| CPossibleUnitRequest | |
| CPossibleUpgradeRequest | |
| CProductionGoals | |
| CProtoBotCommander | The ProtoBotCommander is the main way information and BWAPI events are passed to the managers of ProtoBot. The class holds no real intelligence besides passing ResourceRequests to the StrategyManager and BuildManager of ProtoBot. The main purpose of this class is to be able to provide a easy way for information to be passed around when needed and for each manager to process events in the defined order specified in each function, updating infromation along the way |
| CProtoBotProductionCount | Counter of the amount of units that are ProtoBot currently has created. Units in StarCraft have two states 'created' and 'completed', while the InformationManager has a counter for ProtoBot's units, the counter only considers completed units |
| CProtoBotRequestCounter | Counter of the amount of requests of a specific unit type are already in the list of ResourceRequests in ProtoBot |
| CReinforcingState | Squad moves towards nearby friendly squads being attacked. Once no nearby squads are being attacked or the squad moves too far away from its defensive position (MAX_REINFORCE_DIST defined in SquadStateTypes.h), the squad returns to its defensive state and position |
| CResourceRequest | A ResourceRequest is a way to be able to keep an detailed decsription of what ProtoBot is wanting to make and is currently making. A resource request goes through 4 states and changes based on the type of ResourceRequest we are dealing with. The creation of units and upgrades is something that happenes almost instantly in StarCraft's game engine and doesnt require any other information expect the trainer that will service the ResourceRequest. However the construction of a building is more complicated. Due to the possibility of a worker being destroyed on its way to construct a building or the tiles where a building is going to be placed is already occupied. You can compare this type of request as something that is more asynchronous. This requires more information and fault tollerance from ProtoBot to be able to full service a ResourceRequest for buildings |
| CScoutingManager | ScoutingManager Manages all scouting units and their behaviors. Assigns units to the appropriate scouting behavior, updates them each frame, tracks enemy locations, and coordinates transitions between scouting and combat |
| CScoutingObserver | ScoutingObserver Controls scouting behavior for a Protoss Observer. Maintains vision over key enemy locations, avoids detection threats, and monitors expansions using a slot-based system. Observers either hold fixed positions near the enemy base or dynamically patrol expansion locations to provide map awareness |
| CScoutingProbe | ScoutingProbe handles the initial scouting of the enemy base. The probe then steals gas if available and then starts a cycle of harassing enemy workers then orbiting their base |
| CScoutingZealot | ScoutingZealot Controls scouting behavior for Zealot and Dragoon units. Combines positioning, threat detection, and movement control to provide safe and consistent map scouting |
| CSeparationCell | Structure for cell within the spatial grid used for BOIDS separation optimization. Each cell has an x and y coordinate, as well as an operator+ for adding two SeparationCells together and an operator== for comparing two SeparationCells |
| CSeparationCellHash | |
| CSpenderManager | The SpenderManager is the way ProtoBot is able to reserve the resouces ProtoBot wants to spend and approve the requests of units ProtoBot is able to make. This prevents ProtoBot from spending resoucres that ahve already been allocated to another request and allows ProtoBot to make decisions based on what it has already made |
| CSquad | Group of combat units owned by ProtoBot |
| CSquadInfo | Contains squad information such as its units, positions, and current state |
| CSquadState | Base class for squad states. Each state has its own Enter(), Update(), and Exit() implementation. These states and their implementations can be found in SquadStateTypes.h |
| CStrategyManager | The StrategyManager is way ProtoBot is able to make macro level decisions about what to do. Utilizing information stored in the InformationManager and data strcutres of its own. The StrategyManager is able to dictate production and manipulation of units |
| CThreatGrid | ThreatGrid Maintains spatial threat information for enemy units. Uses a grid-based system to efficiently query danger levels at any position, allowing units to avoid unsafe areas |
| CEnemyStamp | |
| CGridData | |
| CThreatQueryResult | |
| CTilePositionHash | Hash for storing BWAPI::TilePositions |
| CTimer | |
| CTimerManager | |
| CTrackedEnemy | |
| CunitCMHash | |
| CunitHash | Hash for storing units as keys |
| CUnitProductionGameCounter | Counter for the units ProtoBot has created over the course of a game |
| CUpgradesInProduction | Upgrades currently being made |
| CVectorPos | Custom Vector class that extends from BWAPI::Point, with added vector operations and functions |
1.16.1