Basic Strategies

Main goal for build orders in Sharpy is to create solid strategies that won't break or get stuck even if something unexpected happens. In order the keep up with this design, it helps to have some guidelines.

• Have as much of your build order as parallel as it makes sense
• Reduce the amount of conditions used to minimum
• Use priority=True for expensive units

Build orders reserve resources by the order of their execution. Upgrade acts always reserve resouces when the action is otherwise available, while unit and building creation acts only reserve resources when the priority flag is set.

Following will work just fine for example:

BuildOrder(
    AutoPylon(),
    ProtossUnit(UnitTypeId.PROBE, 50),
    GridBuilding(UnitTypeId.GATEWAY, 2, priority=True),
    GridBuilding(UnitTypeId.CYBERNETICSCORE, 1, priority=True),
    Expand(2),
    BuildGas(2),
    GridBuilding(UnitTypeId.ROBOTICSFACILITY, 1),
    ProtossUnit(UnitTypeId.IMMORTAL, priority=True),
    ProtossUnit(UnitTypeId.ZEALOT),
)

The bot would expand when it has enough money to do so, but in case the expansion site is blocked by an enemy worker, the build order would still continue to make probes, immortals and zealots.

Vespene mining

BuildGas is the same for all races for building vespene gas gathering buildings.

DistributeWorkers automatically manages balance for workers between minerals and vespene. You can change the minimum and maximum vespene gas workers by changing the .min_gas and .max_gas properties.

Building / Expansion Canceling

CancelBuilding Allows canceling building based in new information while PlanCancelBuilding automatically cancels any building that is under attack and in risk of being destroyed.

It is critically important to prevent new buildings from being built when using CancelBuilding or it might otherwise cause an endless cycle of building and instantly canceling buildings. For example:

Step(lambda k: not k.rush_detected, Expand(2))
Step(lambda k: k.rush_detected, CancelBuilding(UnitTypeId.COMMANDCENTER))

Changing values on the fly

Most acts allow changing values during the game. Let's make a simple ling roach act combination that creates 1 roach for every 3 zergling.

class LingsAndRoaches(BuildOrder):
    def __init__(self):
        self.roaches = ZergUnit(UnitTypeId.ROACH, priority=True)
        self.lings = ZergUnit(UnitTypeId.ZERGLING)
        super().__init__([self.roaches, self.lings])  # Note the order

    async def execute(self) -> bool:
        self.roaches.to_count = self.get_count(UnitTypeId.ZERGLING) / 3
        return await super().execute()