how to beat Stone, according to AIL
I took a little time off from my main goals for Steamhammer 1.1 development to follow AIL’s advice on how to beat Stone. AILien’s implementation is in WorkerManager::handleCombatWorkers(), so I guess AILien’s drones are given combat orders when an enemy is very near. The suggestion was for drones to attack enemies that came within range 50 and were not moving.
My implementation is a little different. I put it in WorkerManager::updateWorkerStatus() and was careful to disrupt mining as little as possible. I tried ranges 48 and 64 and decided that 64 worked better. The else if condition ensures that a worker which has been fighting returns to mining as quickly as possible (idle workers are put back to work within the same frame). A possible disadvantage is that gas miners do not defend themselves (but they never did before, either, and it’s not hard to add).
// If the worker is busy mining and an enemy comes near, maybe fight it.
else if (workerData.getWorkerJob(worker) == WorkerData::Minerals)
{
BWAPI::Unit target = getClosestEnemyUnit(worker);
if (target && !target->isMoving() && worker->getDistance(target) <= 64)
{
Micro::SmartAttackUnit(worker, target);
}
else if (worker->getOrder() != BWAPI::Orders::MoveToMinerals &&
worker->getOrder() != BWAPI::Orders::WaitForMinerals &&
worker->getOrder() != BWAPI::Orders::MiningMinerals &&
worker->getOrder() != BWAPI::Orders::ReturnMinerals)
{
workerData.setWorkerJob(worker, WorkerData::Idle, nullptr);
}
}
I also had Steamhammer build a sunken when it could. That freed up zerglings from chasing SCVs so that they could pay a visit to Stone’s base. Games became short and decisive. In a test match, Steamhammer beat Stone 15-0. The closest it came to a loss was getting down to 3 drones before the sunken came on line; most games were one-sided.
Steamhammer 1.1 will take that much longer to come out, but it will be that much stronger. The bot should lose fewer drones to harassment by the enemy scout, which will help in many matchups.
Update: The code has a bug! To fix it, change this condition
else if (worker->getOrder() != BWAPI::Orders::MoveToMinerals && worker->getOrder() != BWAPI::Orders::WaitForMinerals && worker->getOrder() != BWAPI::Orders::MiningMinerals && worker->getOrder() != BWAPI::Orders::ReturnMinerals)
to this, adding one more check:
else if (worker->getOrder() != BWAPI::Orders::MoveToMinerals && worker->getOrder() != BWAPI::Orders::WaitForMinerals && worker->getOrder() != BWAPI::Orders::MiningMinerals && worker->getOrder() != BWAPI::Orders::ReturnMinerals && worker->getOrder() != BWAPI::Orders::ResetCollision)
Drones (and I presume other workers) go into ResetCollision mode for just one moment as they finish mining minerals. The effects of the bug are subtle but far-reaching. Drones going toward the minerals have the mineral-mining job. Having finished mining, they hit ResetCollision and, since they are carrying minerals, end up with the return-cargo job until they return their minerals to the hatchery, when they go idle again and are reassigned to gather minerals. (Returning cargo is not part of UAlbertaBot. I added it to reduce unnecessary loss of resources.) Mining appears to proceed normally, but behind the scenes drones are switching jobs unpredictably. You can no longer accurately count your mineral drones. Other tasks looking for mineral drones do not accept return cargo drones, which can cause buildings to be constructed slightly later. The effects are small and not immediately noticeable, but harmful.
Sneaky sneaky one!
Trackbacks
No Trackbacks
Comments
MicroDK on :
Under which conditions will Steamhammer create a sunken?
Jay Scott on :
Jay Scott on :
MicroDK on :
Jay Scott on :
MicroDK on :
Jay Scott on :
MicroDK on :
Ail on :
Yesterday, after another game against IceLab, I have decided that I cannot continue using UABs approach to unit management.
Basically what happens over and over: My bot has awesome macro, can pull ahead or stay on par with its opponent but when armies are spread out or attack it, its unit-control falls apart and becomes a mess.
I have made modifications to it in the past but whatever I do, there's issues that cannot be resolved with it and so I will code my own unit-management from ground up beginning today.
What UAB does is: It puts units in Squads, gives the whole squad a target and does one SparCraft-Simulation per Squad centered on a point (per default the unit closest to the squad-target).
The problem with that approach is: The more that there's going on and the further spread your and your opponents units are, the more likely it is that the SparCraft-simulation-center is useless. Increasing the simulation-radius can help to some extend but comes with other disadvantages. Trying to alter the location of the center can also help to some extend... but comes with other disadvantages once again.
You either keep your units clumped together or the UAB-approach will fail. This is very well demonstrated by the current state of my bot, where I tried things with spreading units out. Doing so costs me roughly 15% Winratio.
A main-problem is that it is not possible to use SparCraft for every individual unit. It is not just a comparison of numbers but a real simulation and as such it simply will become too slow if you do that with higher amounts of units. And for the decisions that UAB uses SparCraft for, such detailed simulation usually is overkill anyways.
What I want to do is make every unit have their own decisionmaking not only for micromanagement but also for "where should I be on the map" based on an analysis of its surroundings (Friends and Foes nearby).
Combat-predictions will initially be based on nothing but added costs but quite likely be further refined later on. They will, of course, never reach the accuracy of SparCraft but I hope it will eventually be good enough.
I also want to look into having different thresholds for engaging and disengaging based on the location of the combat and thus do something against the common UAB-issue of being to indecisive and going in- and out without achieving anything that happens quite frequently.
I see that initial further regression (as in losing even more win%) is very likely with a revamp of the approach but I feel it is a risk I have to take in order to elevate my bot to the playstyle that I envision.
Jay Scott on :
AIL on :
From my observations tscmoo oftentimes does questionable things in that regard and seems to miscalculate outcomes and then runs away from fights that looked like they would have gone in it's favor.
I think some refinement to the unit-cost-comparison can get close to real simulation-results.
Of course a Mutalisk shall not think it can beat a Missile-Turret because it costs more and a Zerglings should not be more afraid of a Dragoon than a zealot just because the Dragoon is more expensive. But for now it's more about seeing whether the concept as a whole does work and fix the most important issues with it. Making the predictions more simulationesque will follow shortly after.
MicroDK on :
AIL on :
I have already uploaded the first version of that new approach and it seems to do quite well already.
It has beaten UAB-Protoss in a test-match. Something my old approach has only done about 2 out of 20 times in total.
I've spent a lot of time trying to bend the UAB-approach to do what I want and always had to struggle with side-effects.
Other bots passed mine in strength and I felt powerless to do something about it.
Now I have a working base which I fully understand and thus can easily tweak to do exactly what I want. If my bot makes mistakes now, it is now my fault and it will be easy to know why it happens and what to do about it.
I think about it a bit like infesting Kerrigan:
Kerrigan has worked before and was effective at what she was doing. But in order to best work in symbiosis with the Zerg many parts of her body had to be replaced by Zerg-Parts.
So that's what I'm doing with UAB now: Infesting it into an Ailien.
MicroDK on :
MicroDK on :
This shows three things (and properly more):
1. Stone has exceptionally good micro.
2. My bot needs to do scouting when it has enough units. Actually a drone started scouting, but was recalled because of low worker count so scouting never found Stone's base. Recall of scout was something that I just added.
3. Divide the main attack squad into more squads, so that not all units follow the same target.
Jay Scott on :
Jay Scott on :