Steamhammer’s greatest misses
All bots have bugs, even strong bots. Watching a game Krasi0 vs Iron today, I saw that Iron had built many academies, some in rows like subsidized housing. Sadly, its devotion to education did not help it win. Krasi0, by the way, has a similar bug with turrets. It’s a kind of symmetry.
Here are some of Steamhammer 0.2’s most dramatic bugs.
drone defense aka suicide
Steamhammer loves to defend with drones. You can almost hear it jumping up and down, “Can I send out the drones yet? Can I send out the drones?” When it works, it looks brilliant—how did it kill all those zerglings and only lose 1 drone? When it fails, it looks ridiculous. Here the drones are blocking the bot’s own zerglings and the game is about to be a massacre.
suicide aka drone non-defense
Despite its love of drone defense, Steamhammer sucks at defending its drones from early harassment. Its system of chasing the enemy scout with one drone is adequate against weaker bots, but often loses 1 or more drones against strong opponents. Here Bereaver’s probe already has 2 kills, and the newly-hatched zerglings are speeding past ignoring it. Not their job.
gas > life
Many bots share this play bug. Steamhammer 0.2 believes that vespine gas is more precious than life itself.
If you kill a gas drone, the bot will replace it. If you kill all but a few drones, it will put the survivors on gas and mine no minerals. If you kill a hatchery and leave the extractor, it will send drones to long-distance mine the extractor, and if you kill those, it will send more. Leave a few units in the destroyed base and Steamhammer 0.2 will ship over its entire mineral-mining population 3 at a time to be exterminated. Gas is more precious than life.
This bug is related to strategy, so it is mostly fixed. Steamhammer dev version has skills to start and stop collecting gas at sensible times. Tonight I’ll fix a bug in the interaction between automatically turning off excess gas collection and gas limits specified in the opening book. Later I’ll fix the one last corner case that I know of: If you kill an expansion hatchery while its extractor is still morphing, the bot will still do the extermination train when the extractor finishes.
expand to the enemy base
Some have wondered why, in longer games, Steamhammer sometimes sends a drone or two to the enemy base to die. That’s simple. It wants to expand there. What’s to stop it?
UAlbertaBot’s native “where’s the next expansion?” routine does not take into account where the enemy is. It only checks whether the spot is blocked by a known building, and I suspect that the check is not correct. The dev version tries to expand away from the enemy, only sets its sights on untaken bases, and is reluctant to take a base in the same region as any known enemy building (but it still will try, in a pinch).
scouting by mistake
But expanding to an enemy base is not so bad if you didn’t realize. After the early game, Steamhammer does not scout again until all known enemy buildings are destroyed. If you build where Steamhammer does not want to attack, there’s a good chance that you won’t be discovered until late game. It usually finds enemy expansions eventually, though, because it likes to expand across the map.
Scouting is high on my list, which means I should get to it sometime in February.
detection? what’s that?
Who would even try a straight dark templar rush against zerg, with no attempt to chase away overlords? Well, MegaBot would. It worked, too. Here the drones are trying to help out in a fight against invisible assassins that can kill them in one blow. Sure, you can send in the drones, stop jumping.
I’ll take this base twice—no, three times!
If you watch Steamhammer games, sooner or later the camera will move to a new base with a hatchery, one or two idle drones, and nothing else. The nothing else is because the bot does not try to balance its drones among bases; it only transfers as old bases saturate or mine out. The idle drones are because Steamhammer tried to take the same base more than once at the same time. The production queue had 2 or 3 hatcheries in a row, and the building placer decided to put them in the same spot. Often 2 drones arrive simultaneously and repeatedly prevent each other from starting the building—no need for an enemy, Steamhammer can harass itself. Eventually one succeeds, and then the other drones are despondent and go idle.
Nice one, right? It turns out that the building placer was missing a check, “don’t place a hatchery in a spot already reserved for another.” I added the check, but it still behaves the same; either the check is wrong (which I suspect), or else there’s another mistake. Steamhammer dev version at least puts the idle drones back to work.
So little to do, so much time! How will I alleviate the boredom?
Trackbacks
No Trackbacks
Comments
Jay Scott on :
krasi0 on :
BTW, did you mean that there was a game between me and Iron which I won? That would be surprising with the version of my bot which has been uploaded to SSCAIT.
Haha! I loved that "Not their job." commend xD
Gas == Spice (on Dune) > life
Jay Scott on :
krasi0 on :
Jay Scott on :
Jay Scott on :
AIL on :
And since your's is built on UAlberta aswell, I can hint you to how.
Some fixes are really easy as suprisingly some stuff is implemented but somehow not used in UAB.
Drone Defense: I could only improve it slightly by limiting the range over which drones are pulled to defend. But it's still possible to exploit them by walking them away and singling them out from the flock. Need to do more here.
gas > life: I only assign drones to extractors as long the amount of gas-workers is below 20% of that of mineral-workers. So early on that often means only 2 drones to gas and minerals are preferred when the drone-count is low. But I, right now, haven't taken drones from gas if mineral-drone-count drops while gas-drones does not. Also I have redone the rebalance-worker thing, so the distribution of workers in my bot in general is much better.
expand to enemy base: Haven't fixed that yet, but allowing min-onlys to be taken aswell delays the issue. ^^ But on "Destination" that causes drones to bug because the mineral-obstacle is not removed.
Detection: For some reason overlords were commented out from being added to squads. If you do that they will automatically be treated by the detectormanager. I slightly modified how they are treated. For example I don't use the other way of scouting, as this tends to suicide overlords and I only add 10% of the overlords (but at least 1) to the army, so that I can have more overlords in bigger battles but also not all incase the army underneath them dies.
However, DTs still bug out the Regrouping, even if they are detected, which is another issue. But Lurkers for example are not so much of problem anymore.
Oh, and sometimes "unitclosesttoenemy" also bugs and gets the wrong unit, having the overlords fly back from the main army somewhere to a unit that's on their way.
Multi-taking of bases:
Still kinda have that problem of several drones going there but my drones won't idle there. For some reason in updateWorkerStatus() idle drones with the job to build something were prevented to get their status set back to idle and thus weren't used for other jobs like going back to mining.
Um... can we maybe talk or chat on Skype or somewhere else sometime? There's some issues I'd like to know how you resolved them. I'm especially interested who to debug crashes. My bot crashes in certain scenarios and I've been spoilt by Unity automatically telling me where it happened, so that I don't know how to find it out here. I built a debug version of the bot and run the debug-BWAPI-plugin but what's the next step? 8[
Jay Scott on :
AIL on :
I initially only tested against the default AI, to which it generally did not lose and thus also did not lose it's pool
But when I switched to testing against UAlberta, this happened a lot.
But as I'm writing this I got a theory. I think it's the combination of wanting to build a building something but not having drones.
So not trying to build any buildings when there's no drones left might fix it...
Jay Scott on :
AIL on :
The real reason is probably somewhere else there. But that won't explain why other UAB-derivates don't have that issue. So I might have broken something there afterall.
Not crashing was the most important as that really sucks for testing to have to start BroodWar again.... Now trying to improve drone-defense.
AIL on :
The actual cause was that I gave an Overlord to the scout-manager in order to save drones.
However, the overlord was returned to the worker-manager, which, when all workers were dead but that overlord still alive, it would try to build something with the overlord.
And this is what crashed the game.
I used Overlord-scout to find the base but now that I want to know whether to defend against some sort of rush the overlord scout is bad anyways, as it won't "meet" enemy rush-units on the way to me.
Jay Scott on :
Ail on :
Btw. I did a series of like 15 games between the Sscait-downloadable version of Steamhammer and my Bot and it was like 12:3 in favor of mine.
Steamhammer dies too easily to early ling-pressure. The times he won was always because of getting more mutas out sooner while not having neglected lings too much. I'd like to test against more other bots than Steamhammer and Uab but most are linked against another version of Bwapi so I don't know how to test vs. Them.
Jay Scott on :
Jay Scott on :
AIL on :
And it was not an issue with SparCraft but with a method that checks units before throwing them into SparCraft:
InformationManager::isCombatUnit
This filters Overlords out but not Observers.
And it filters Lurker out, that's why apparently it seemed to work against them.
So SparCraft thought: There's a DT but I have no detection, even if detection was present.
Jay Scott on :
AIL on :
I managed to find out what the main issue was with the slip-ups in the regrouping where it sometimes would cease to work for a moment and all units died.
But it's not a simple fix, because there's several separate reasons to that and it cost me about the whole day.
There's two main-issues:
1) Sometimes the regroup-point jumps to an overlord, who is behind the enemy-lines. Make sure that BWAPI::Position Squad::calcRegroupPosition() does not return the position of an overlord.
2) Regroup does not work for defender-squads.
Getting it to work was a real hassle. For whether to regroup or not, the unit closest to the the target is checked.
But the target returned by getDefendLocation() is just the base that is being attacked. So I rewrote that method completely to return the enemy-unit closest to the base and not the base itself.
Then I needed a different retreat-location for defense-units. A unit wouldn't work, as that would just cause them to look how their base is destroyed. So I'm looking for sunkens to fall back.
And then I had to change how SparCraft is fed which units partake, because the Lings happyly attacked enemies just outside of sunken-range, thinking the sunken would help. So I halfed the radius in which buildings are added to SparCraft.
In the end I could defend against UAB-Protoss for really long... until it had massive amounts of supply standing before and I had massive amounts of supply in my base. In the end UAB still won but it was not just a rollover of my bot.
Jay Scott on :
Ail on :
And I think I also fixed that I can't do several upgrades at once despite having several evo-chambers. But I need to reimplement doing upgrades at all to test into my new approach. When it works, I will post the code.
Yeah, there's so much to do, to get a good bot. It is kinda frustrating to see how hard it is to deal with the cheap default Uab-rushes.
Jay Scott on :
Ail on :
I tried to copy the files back to the other folder and push it via source tree but it somehow doesn't recognize any changes.
So I'll probably just upload some kind of zip archive myself or have someone who knows how it works to do it via git hub.
Jay Scott on :
Jay Scott on :