archive by month
Skip to content

the BWAPI unit ID exploit

In comments to the previous post, lIllIIlIlIlIIlIIl pointed out that unit IDs are assigned sequentially and the sequence is shared by both players, so that each player’s sequence of unit IDs conveys information about the other player’s production. In other words, bots can cheat by looking at their own unit IDs to learn without scouting what the opponent is doing. If a bot makes 2 units one after the other, it can tell how many units the opponent produced in between by simply subtracting the unit IDs.

I tried it myself, and it’s true. It is trivial for a cheater bot which is steadily producing workers at the beginning of the game to recognize that an enemy zerg is going 4 pool or 5 pool. More complicated builds are more difficult to recognize, and the information you get depends on your own build too (for example, if you’re saving up for a new base, you don’t get new information via this cheat until you start the base). But even there, I think it’s not too hard to usually tell the difference between 9 pool and 12 hatch and other early build orders. Later in the game, you could use the cheat to recognize when the opponent is supply blocked, or when the opponent is maxed, and judge whether the opponent is making many cheap units (marines, zerglings) or fewer expensive units (tanks, mutalisks). The cheat seems to have many uses.

Also, it seems possible to use this cheat with little risk of being caught. To avoid being caught by behavior, don’t accurately react to unscouted zergling rushes too often. I think most other behaviors that the cheat enables will be difficult for observers to detect. To avoid being caught by code inspection (in a tournament that publishes code), use some code obfuscation—stash IDs with other stuff in a data structure, so that it’s not obvious what information the computation is operating on. A machine learning algorithm would make an excellent code obfuscator: Simply feed it unit IDs along with everything else, and a good enough learning algorithm will learn on its own how to cheat without giving any clues away. Machine learning data can be extremely difficult to interpret.

It is a terrible exploit. I have opened an issue at the BWAPI repo.

How the hell are we going to catch people who abuse this? If it is fixed in a future BWAPI release, it will still take time before we can require that new bots use the new BWAPI—especially if there are other incompatible changes.

Maybe the answer is to make 4.1.3 and 4.2.1 releases which are compatible with the current 4.1.2 and 4.2.0 releases, with the only change being that IDs are randomized or otherwise mixed up. Then it might be possible to deprecate 4.1.2 and 4.2.0. If BWAPI allocated unit IDs in blocks (of 100, say) and randomized the order in which they were assigned within each block, then even a bot which used the IDs as an array index would continue to work.

Update: Besides randomizing unit IDs, there is another solution: Partition the space of IDs so that each player that creates units is assigned IDs from a different partition. For example, if there are 2 players (me and you, since the neutral player doesn’t create units after the game is underway), assign even IDs to my units and odd IDs to your units. That might still allow unit counting exploits (“you have a unit with this ID, so you made at least x many units”), but at least you have to see the enemy units first.

Next: New bots SummerHomework and Prism Cactus.

Trackbacks

No Trackbacks

Comments

Antiga / Iruian on :

My understanding is that unit IDs in bwapi 5 dev versions are not available if they are in vision, that said it does nothing for bots using existing versions.

Joseph Huang on :

Is this even against the rules?

Jay Scott on :

Good question! Since it’s not a long-known exploit, there is no explicit ban. The AIIDE rules say vaguely “Programs that attempt to cheat will be disqualified.” There is room for interpretation, but if I were interpreting the rules, I would call it cheating.

Joseph Huang on :

Not sure how you can view this as cheating but not looking at enemy orders.

Jay Scott on :

You have a point! They’re both part of the API, after all. To me, the difference is that enemy orders are a direct use and ID differences are a sidechannel use.

Arrak on :

Out of principle, I have thus far opted to not use enemy orders and targets (though I do recall something about using isRepairing). I use the enemy's velocity and facing direction to guess enemy unit intentions, which I think is fair game to a human, and more useful in most circumstances. Still, if it's considered fair game, I suppose I could think of some uses for enemy targets.

Barcode on :

It could still be on sequential incrementing basis, just don't add the invisible enemy units

Jay Scott on :

Well, that is a possible design change. If we want to maintain compatibility, which is necessary if we want to patch old BWAPI versions and continue to trust old bots, then all units need IDs one way or another.

Tully Elliston on :

Is anyone already using this information in their not?

krasi0 on :

We should just add a rule that bans this particular exploit in any tournaments. If a bot author gets caught (one way or another) using it, they will be distrusted by the community for life. Besides, I don't believe any serious contender has already / would resort to such shenanigans for so little gain (defending against the rare case of a 4 pool)

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.