new bot ExampleClient
A new bot ExampleClient by Dan Gant has appeared on the Starcraft AI Ladder. It hasn’t been uploaded to SSCAIT or BASIL, so I imagine it is on the Ladder primarily as a robustness test (it did crash a few times and is currently inactive). Another possible reason that it is not on SSCAIT is that its strategy might break some older bots; see below. The name “ExampleClient” suggests that perhaps it is intended as a starting point bot for new authors.
ExampleClient is terran, and it plays a strategy similar to the current version of Stone: It makes one SCV with its initial 50 minerals, and sends all 5 SCVs to the enemy base, where they try to destroy buildings. But there is a cute twist: It lifts off its command center and flies it out of sight. It seeks a location on the map that is not reachable by ground and not visible to ground units, and leaves the command center floating there. When there is such a location, only air units can find and destroy the CC. When there is no such location on the map (as on Circuit Breaker), it sends the command center to the extreme lower left—the location is hidden by the minimap, so the CC is virtually invisible when watching the replay. The enemy will scout every starting base and see ExampleClient at none of them. See my post breaking scouting assumptions from 2017 for similar ideas.
Most of the bots on the Ladder seem unconcerned that they cannot find ExampleClient’s starting base. Steamhammer, for example, once it has defeated the worker rush, takes the situation in stride as end-game cleanup where the enemy owns no bases, makes mutalisks, and hunts down the floating CC. That is possible in part because it distinguishes “I inferred the location of the enemy base by seeing all the other bases” from “I know the location of the enemy base because I have seen it.” BananaBrain is higher ranked but does not seem to draw that distinction: I have seen it take all bases on the map except the one where it “knows” the enemy must be, even as observers fly over the empty base location, and hold its forces back as if it were afraid to attack the vacuum. In some games, BananaBrain does not make air units and never finds the CC, so that it only wins the game on points. Some bots are fooled, though they still win!
There are a lot of other cute ideas that I have never seen a bot try.
Trackbacks
No Trackbacks
Comments
Johan de Jong on :
It is true that this bot leads to some potato games versus BananaBrain, but since it does not seem to actually lose games because of this, it does bot seems to be important solve this right now. The TODO list of BananaBrain already has too much issues on it!
The following game shows that an Arbiter (using its attack) can be the MVP of a game: http://www.openbw.com/replay-viewer/?rep=https://www.cs.mun.ca/~z24rmk/starcraftailaddertest/replays/BananaBrain/2020-09-23T10-17-34.348Z_03579-BANA_EXAM.REP
Jay Scott on :
You’re right, BananaBrain doesn’t need any updates for this. Steamhammer could use fixes, though, because it sometimes loses buildings over and over before finally defeating the SCVs.
Dan on :
Dan on :
Actually, I did briefly upload a PurpleWave to SSCAIT that attempted a liftoff strategy. Rush with SCVs, attempt to kill a worker, then hide the CC and workers in the most obscure spots on the map, and try to win on score. It found pretty clever spots. In addition to being ineffective (worker defense is pretty good these days) the strategy is doomed to failure due to an obscure SSCAIT bug where a game that ends in timeout with only one player killing units results in the OTHER player getting the win. Code: https://github.com/dgant/PurpleWave/blob/master/src/Planning/Plans/GamePlans/Terran/Standard/TvE/WorkerRushLiftoff.scala
So, some background on the race to qualify for AIIDE. PurpleWave manages its own performance fairly effectively, and can typically maintain 15-20ms per frame in all environments. It passes the eye test of looking fast. But it's subject to spikes on individual frames. Some of those are my fault but others appear unavoidable -- the hazards of running managed code on few-core virtual environments.
Over the summer I added an asynchronous mode to JBWAPI. It copies BWAPI data into a buffer for the bot to consume asynchronously. JBWAPI holds control until the bot is done or a configurable amount of time has elapsed, whereupon JBWAPI returns control to BWAPI. This is modeled on TorchCraft's non-blocking mode, which works similarly; the main difference is that TorchCraft copies a selected subset of the game state and provides an alternative API, while async JBWAPI natively memcpy's relevant chunks of BWAPI shared memory, and provides the API unchanged. Code: https://github.com/JavaBWAPI/JBWAPI/pull/60
Asynchronous operation swallows a bot's performance spikes, helping ensure that the bot meets its SLA for AIIDE-style timing rules.
That's the theory. In practice, it didn't work in COG, and hasn't been working on the AIIDE ladder. From the bot's perspective everything is dandy; JBWAPI is timing everything under the sun and as far as it can measure, it's well behaved.
But what ExampleClient helped prove is that when the bot thread is running in the background, the StarCraft/BWAPI thread does not reliably regain priority. The AIIDE VMs have two logical cores, so it's understandable that they'd be in high contention, but I haven't found a way to persuade the BWAPI thread to resume after the main JBWAPI thread flips the "I'm done!" bit in BWAPI shared memory.
Along the way I dug into how BWAPI and the AIIDE Tournament Module measure time, and discovered a trio of issues which negatively impact timing, especially for clients. More on that at https://github.com/bwapi/bwapi/issues/860 and https://github.com/davechurchill/StarcraftAITournamentManager/issues/42
Chris Coxe made a very well-designed fix to the tournament module, which Rick Kelly very graciously included on the AIIDE ladder and tested. I am appreciative to them for helping pave the way for all timed client bots to compete. The timer precision limitation, which effectively shaves 16ms off the advertised time limits, requires a new BWAPI version to address, which I may yet petition to allow.
I am out of timely ideas to solve the BWAPI priority issue, so my plan now is simply to ensure reliable synchronous performance by PurpleWave. There's about a dozen low-hanging items which I should get through without too much trouble, but I don't know whether it will be enough. It'll be a race, as the deadline is fast approaching and I'm moving apartments in between. Hope to compete this year!