Starcraft AI blog

#4 where are you? where are you?

CombatCommander::getMainAttackLocation() figures out where the “main attack” squad should aim to attack. It thinks the enemy main base is the top possibility. Here enemyBaseLocation is the location of the enemy main base (the comment is a little off), null if the enemy base location is not known.

    // First choice: Attack an enemy region if we can see units inside it                                                        
    if (enemyBaseLocation)
    {
        BWAPI::Position enemyBasePosition = enemyBaseLocation->getPosition();

        // get all known enemy units in the area                                                                                 
        BWAPI::Unitset enemyUnitsInArea;
        MapGrid::Instance().GetUnits(enemyUnitsInArea, enemyBasePosition, 800, false, true);

        bool onlyOverlords = true;
	for (auto & unit : enemyUnitsInArea)
        {
            if (unit->getType() != BWAPI::UnitTypes::Zerg_Overlord)
            {
                onlyOverlords = false;
            }
        }

        if (!BWAPI::Broodwar->isExplored(BWAPI::TilePosition(enemyBasePosition)) || !enemyUnitsInArea.empty())
        {
            if (!onlyOverlords)
            {
                return enemyBaseLocation->getPosition();
            }
        }
    }

The isExplored() check is supposed to account for the case where the location of the enemy base has been inferred although the base has not been seen. (UAlbertaBot infers the location of the enemy base when it has seen all but 1 starting location and they’re all bare.) But the check is not correct, because of how onlyOverlords and isExplored() are combined.

The effect is that, if the enemy base location has been inferred, the first combat units do not go toward it but believe that the enemy base is empty. If no other enemy buildings have been seen, the squad ends up exploring the map trying to find the enemy whose location is already known. This happened in one game of Steamhammer 0.2 versus PeregrineBot, and it was the main reason that PeregrineBot won. I’ve seen it in other games too.

The exploration check can be made correct by separating it from the onlyOverlords check.

	if (enemyBaseLocation)
	{
		BWAPI::Position enemyBasePosition = enemyBaseLocation->getPosition();

		// If the enemy base hasn't been seen yet, go there.
		if (!BWAPI::Broodwar->isExplored(BWAPI::TilePosition(enemyBasePosition)))
		{
			return enemyBasePosition;
		}

		// get all known enemy units in the area
		BWAPI::Unitset enemyUnitsInArea;
		MapGrid::Instance().GetUnits(enemyUnitsInArea, enemyBasePosition, 800, false, true);

		for (auto & unit : enemyUnitsInArea)
		{
			if (unit->getType() != BWAPI::UnitTypes::Zerg_Overlord)
			{
				// Enemy base is not empty: It's not only overlords in the enemy base area.
				return enemyBasePosition;
			}
		}
	}

#5 there is always a building rush

Here is how UAlbertaBot checks whether it is getting proxied.

bool CombatCommander::beingBuildingRushed()
{
    int concernRadius = 1200;
    BWAPI::Position ourBasePosition = BWAPI::Position(BWAPI::Broodwar->self()->getStartLocation());

    // check to see if the enemy has zerglings as the only attackers in our base                                                 
    for (auto & unit : BWAPI::Broodwar->enemy()->getUnits())
    {
        if (unit->getType().isBuilding())
	{
            return true;
        }
    }

    return false;
}

Well, there is an incorrect comment, but that’s not a bug. The routine omits one little condition.

        if (unit->getType().isBuilding() && unit->getDistance(myBasePosition) < 1200)

UAlbertaBot thinks it is being proxied whenever it knows the location of any enemy building anywhere on the map. The bug causes workers to be pulled for emergency defense more often than originally intended. See CombatCommander::findClosestDefender. Here’s the rather confusing line you may want to rewrite to change when workers are pulled for defense:

        if (!Config::Micro::WorkersDefendRush || (unit->getType().isWorker() && !zerglingRush && !beingBuildingRushed()))