archive by month
Skip to content

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.

Trackbacks

No Trackbacks

Comments

Dan on :

I'm tickled to hear about this because in this same conference's tournament PurpleWave added a bunch of drop tactics (Reaver, Storm, Speedlot) that work almost identically! We're both using A* pathfinding with cost as a function of distance, enemy vision, and enemy threat. The main difference is that I opted to use a fixed-length repulsor from the center of the map rather than avoid likely scouting paths; PurpleWave has that data around from its old liftoff-and-hide pranks but the simple repulsor seemed more robust.

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 :

I'll observe that when using speed shuttles, aggressive paths were pretty safe as long as you recalculated the path regularly. Shuttles would sometimes encounter a Dragoon en route but a Shuttle's vision range is longer than a Dragoon's attack range so it reliably jukes out of the way and usually takes no damage. Of course, it'd be silly to do against a human (you don't want to give away the drop) but serviceable against bots for now.

Dave Churchill on :

Hey Jay!

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

Add Comment

E-Mail addresses will not be displayed and will only be used for E-Mail notifications.

To prevent automated Bots from commentspamming, please enter the string you see in the image below in the appropriate input box. Your comment will only be submitted if the strings match. Please ensure that your browser supports and accepts cookies, or your comment cannot be verified correctly.
CAPTCHA

Form options

Submitted comments will be subject to moderation before being displayed.