updated paper on sneaky dropship paths
The CoG 2021 proceedings includes one Starcraft paper. Sneak-Attacks in StarCraft using Influence Maps with Heuristic Search by Lucas Critch and Dave Churchill is an updated version of a paper from last year, “Combining Influence Maps with Heuristic Search for Executing Sneak-Attacks in RTS Games” by the same authors, which I wrote up as paper on dropship paths.
The dropship paths themselves appear identical to last year’s. The main news is an experiment to test how well the sneaky paths work against the built-in AI, as compared to straight-line paths. Somewhere in the world, hidden from our mortal eyes, there now exists a version of UAlbertaBot which does sneaky drops—at least in one restricted case, fast four-zealot drop by protoss. (The bot AIUR plays fast four-zealot drop too, but it doesn’t have the fancy shuttle pathfinding. Perhaps the authors will give us chances to play against this UAlbertaBot version?) The pathfinder replans the path on a fixed schedule, once per second, and stops replanning when it nears the drop point, because it has probably been seen by then anyway and it’s time to stop dodging and get on with it. The shuttle does not react to being shot at (though if the enemy wasn’t seen before then it may change course when the path is replanned). It’s clear that improvements are possible.
Results: A shuttle taking the direct path was somewhat more likely to be seen along the way, and was substantially more likely to be shot down before unloading (versus terran, way more likely to be shot down by marines). The direct path was faster, which had countervailing advantages in some situations. It’s not clear to me how well the results will generalize to other opponents, because they depend on details of the built-in AI’s play. A bot author, as opposed to a researcher, would rather find out whether the sneaky drops produce more wins in a tournament against a range of opponents.
Steamhammer’s skill kit system makes it relatively easy to record data about specific opponents, and to use the data for decisions. It wouldn’t be hard to record the kind of data shown in the paper—survival, damage taken, moving into enemy sight—and use the information to decide whether to drop and what category of path to follow if so. Steamhammer could figure out during a tournament what works against each opponent. I plan to eventually collect at least enough data to decide whether and when to drop.
A new idea in the paper is to use the sneaky pathfinder defensively, to place your buildings to prevent enemy sneak attack: If you find a good path for the enemy to attack you along, place a building that has vision of the path so you see the attack coming. This seems like overkill to me. I don’t think you gain much from a fancy pathfinding algorithm to place buildings for vision. If you want vision all around the edges of your base, then by the time drops are possible, you should have enough pylons, or supply depots, or zerg overlords, to have all the vision you can use. And besides, you have to weigh vision against the risk to the buildings, especially if you have a low-ground main base. I would prefer to spend the effort to react correctly to an incoming attack that you do spot.
If you want source code, you could try contacting the authors.
Comments
Dan on :
The pathfinding basically just worked out of the box (it helps that it's a trivial change to PurpleWave's existing parameterized pathfinder) and required minimal tuning to get pretty good paths. 95% of the work was all the other steps required for competent drops. It works well. I'd recommend the approach.
For those interested in an implementation in code:
The parameterized pathfinder: https://github.com/dgant/PurpleWave/blob/5ba03a56dd21a3cbd41899efc992d6c7d2ddb5d5/src/Information/Geography/Pathfinding/TilePathfinder.scala
Generic drop logic:
https://github.com/dgant/PurpleWave/blob/5ba03a56dd21a3cbd41899efc992d6c7d2ddb5d5/src/Tactics/Missions/MissionDrop.scala
Reaver-specific drop logic:
https://github.com/dgant/PurpleWave/blob/5ba03a56dd21a3cbd41899efc992d6c7d2ddb5d5/src/Tactics/Missions/MissionReaverDrop.scala
Generic fast per-unit influence maps:
https://github.com/dgant/PurpleWave/blob/5ba03a56dd21a3cbd41899efc992d6c7d2ddb5d5/src/Information/Grids/Floody/AbstractGridFloody.scala
Enemy vision influence maps:
https://github.com/dgant/PurpleWave/blob/5ba03a56dd21a3cbd41899efc992d6c7d2ddb5d5/src/Information/Grids/Floody/GridEnemyVision.scala
Dan on :
Dave Churchill on :
Trust me, nobody wants this source code right now :)
It's incredibly hacked together, and the bot literally stops playing at the point that the Shuttle reaches its destination. This paper was all about evaluating the path for survivability of the dropship, not on whether or not dropping itself was a viable scenario. For example, we never pull out of the drop, no matter how much defense the enemy has, etc.
Also, Lucas (who wrote it) is off in the job hunt right now, so I doubt the source code will ever make the light of day in any sort of cleaned up form. It's super easy to implement though and the paper describes it pretty exactly. This code won't be making it back into the official UAB releases for this reason - it was just for a few experiments for an MSc thesis and was never intended to be extended to really be ready in a competition setting
Jay Scott on :