archive by month
Skip to content

inferring enemy buildings

I want Steamhammer to infer the existence of enemy buildings that it has not seen. Right now, the plan recognizer explicitly encodes its conditions: If I see an early factory, or a unit that came from a factory, or an armory, or a starport, then I can guess that the enemy is playing a factory opening. The zerg strategy boss uses related reasoning. Every bit of code that wants to know if the enemy has a factory has to also look for things that depend on the factory. It’s more general and powerful to decouple the inferences. The information manager should notice when it sees things that can’t be explained by known enemy structures, and infer what was necessary to produce them. If it sees a battlecruiser, it should infer the science facility with physics lab, the starport with control tower, and all the way down. Then the rest of Steamhammer can rely on the inferences, and not have to do any extra work on its own. In principle, it could draw conclusions like “Wait, I’ve seen the whole enemy base and there is no physics lab there. I should look harder at the rest of the map.”

Research counts too. If I see a wraith cloak, I know there is a control tower, even though a control tower is not necessary to make wraiths. It’s necessary to research cloaking. If I see a unit with an attack upgrade, I know what buildings were needed to research the upgrade.

It occurs to me that there are tricky cases. Suppose I break into the enemy base and find a factory—and destroy it. Later, I reach farther into the base and find an armory. I can’t infer that there is a second or new factory; the armory could have been started when the first factory still existed. To interpret the armory correctly, I have to remember that the enemy used to have a factory, and without more information I can’t be sure whether it has a factory now. This is building inference level 1; I have to know history to draw true conclusions.

But sometimes I can infer that there is another factory. If the armory is in a place that I know was empty when the first factory was destroyed, then I know that it is a new armory. There must have been another factory, or another factory was built after the first one was killed; in any case, I can infer a factory that I did not see. To do building inference perfectly, you have to not only remember the history of enemy buildings, you have to remember the history of places. This is building inference level 2; if I understand it, I can draw more conclusions.

Building inference level 3 (I’ll call it) is drawing conclusions about the number of enemy production buildings from the number of units that they are seen to have produced. “Hmm, my scout saw your barracks under construction, and by now it could theoretically have produced n marines. You have more than n marines, so you definitely have at least 2 barracks.” Resource counting can figure into this: If your scout counted the enemy minerals, or if you have a table “it’s possible to mine x amount by time t,” or if you simply know the maximum number of marines that can be produced by one barracks without being sure when it was started, you can draw inferences. In the most general case, you know all the good build orders and their production potential, and can rule out the ones which are not consistent with what you see. Later in the game it should at least be possible to make a rough estimate of the enemy’s income, correlate it to the types and/or number of units you see, and get a fair idea of how many production buildings are likely. At this point you’re making estimates instead of drawing definite inferences.

How many levels of building inference does PerfectBot have? “Oh, this army movement suggests that you are trying to draw my forces forward. Maybe you are trying to set up a drop in the rear? I’d say that means a 20% chance of a robo support bay....”

Trackbacks

No Trackbacks

Comments

Jay Scott on :

You can also infer supply. For terran, count known enemy army supply; subtract known supply depots and command centers; the leftover is some combination of supply depots and command centers that you have not seen.

Antiga / Iruian on :

Another interesting area you can infer is the amount of resources left in the enemy main / natural which can be used to decide which base to attack (Purplewave has this feature), so as the game goes on it becomes more and more likely to attack enemy expansions.

Jay Scott on :

It’s a good idea. I want to do a lot of game state tracking and prediction, but everything takes so much time....

jtolmar on :

Say you have an EnemyState object with their worker/building/resource counts. It starts with four SCVs and a CC, and starts ticking up resources. Every time the simulated enemy could make a decision, you split off a new EnemyState, forming a tree. When you go scout, you see an early expansion, so you delete all the states that don't have one, which ends up being all the ones with factories because there's not enough money to afford that. When you see a new enemy marine, you subtract 50 from all the mineral counts and delete any state that goes negative, because there's no way they could've afforded everything in that build and that army.

Anon on :

Sounds like keeping track of all possible chess moves, which would be a nightmare. Unless I misinterpreted something.

jtolmar on :

It's similar to keeping track of all possible chess moves N deep. But chess bots already do this, and get quite deep! If you abstract enough that your branching factor is similar to chess, it should be fine. You get to prune the tree whenever you scout.

Jay Scott on :

Are you neglecting that chess has alpha-beta pruning?

jtolmar on :

Yes, but I'm also neglecting that chess is bidirectional and this isn't. It's a handwavy comparison.

Jay Scott on :

It is a brute force technique, the same underlying idea as the catalog of build orders that I proposed a couple years ago. I think it may be possible to actually implement it, with good abstractions and simplifying assumptions to reduce the state space (waiting one frame and then starting the building is not a different decision), plus good implementation (merge indistinguishable states). Simplifying the problem will reduce the accuracy of the solution. I don’t know how much.

jtolmar on :

Good simplifying abstractions are definitely required. I'd assume that every building is created the instant the remaining money for that state ticks up to that point, or not at all. That leaves the possibility of being confused if you discover your opponent in the middle of floating a bunch of resources; I'd suggest having a recovery mechanism of, upon finding a building, adding the building and subtracting resources from any state that's missing it and has the resources. Which still leaves your bot confused until it finds the building, but at least it's only a weakness to weak bots. I already hinted at the other abstraction I think is necessary - instead of tracking each permutation of units the enemy could make, just track how many resources worth of units the opponent is known to have made. I think that's enough to simplify it down to manageable (chess-like) numbers of states, though you might also need to assume the enemy is always building workers after 10 minutes.

Jay Scott on :

Assuming the enemy is always building workers won’t work for zerg, and for terran or protoss it will only work for a while. Vespene gas is another complication. I expect that the idea can be made to work, but I’m not sure whether it can be made to work well enough to rely on....

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.