archive by month
Skip to content

deliberate production delays

In a system inherited from UAlbertaBot, Steamhammer keeps a queue of items to produce (units, buildings, research, etc.). As soon as the prerequisites for the next item in the queue are satisfied, it produces the item: There have to be enough minerals and gas; for a spire the lair has to be finished; etc.

It’s kind of strange, but this isn’t always best! There are times when it is better to mine a little longer rather than sending a worker to construct a building right away. This is true even when the building is definitely the next thing to make, and you don’t want to schedule anything ahead of it.

I know a clear example among Steamhammer’s openings. In the terran BBS opening, terran builds 2 barracks at 8 supply. Steamhammer starts each one as the 150 minerals for the building become available. It’s best to start building the 2 barracks simultaneously: The SCV that would start the first barracks gets to mine a little longer, and the marines are not delayed (in fact, they’re stronger in a group, so there’s an advantage to producing them 2 by 2), so delaying the first barracks puts terran slightly ahead.

Building a spore colony because the enemy got mutalisks earlier is 2 examples in 1: First, as a game issue, you want to time the spore colony to finish just before mutalisks reach your base. Second, you need both an evolution chamber and a creep colony, and purely as an efficient production issue you would like to time the creep colony (300 frames to complete) to finish simultaneously with the evo (600 frames to complete), so that you waste as little mining time as possible. Another example is starting a hydralisk den to finish simultaneously with the lair, or to finish when you have just enough gas to start lurker research. I expect you can think of examples for other races.

How should this be implemented? Ideally, the bot should figure out for itself when it is better to delay production. Game issues like timing the spore colony should be decided by a tactical calculation outside the production system itself; somebody else needs to tell the production manager, “get this by time t.” For purely production issues, the bot might simulate the timings to find the most efficient, or it might set up a system of constraints and solve the optimization problem. These calculations are very elaborate—I might implement one of them someday, but not any time soon.

In the meantime, I’ve been wondering whether there is a good way to manually configure delays in common cases. It would be easy enough to add a command to the build order, like “wait for 300 minerals” that you’d put before starting the 2 barracks for BBS. The problem is that that is only one case. Sometimes you want things to start simultaneously (the barracks), sometimes to finish simultaneously (the evo and creep colony), sometimes to finish exactly when conditions are right for something else to start (hydra den finishes when you have 200 gas for lurker research). I haven’t thought of a simple way to specify the different conditions you might want.

Well, in the end, this is a minor optimization. Steamhammer has bigger problems with building stuff efficiently. Even so, I’d like to address it someday. So if anybody has ideas....

Trackbacks

No Trackbacks

Comments

jtolmar on :

The spore and lurker tech cases can be merged into "get me x with its requirements at time y or ASAP." Then the bot navigates backwards through the tech tree, delaying everything so it finishes just as it's time to start the next item (and finally shifting the entire schedule if the longest part won't be ready by time y). I guess that also works for double barracks if x can be multiple objects, but that sounds trickier to implement (maybe but in this case, but the shared requirements behave differently in double factory, double gateway, and double spore).

jtolmar on :

The multi-building one is, yes, but I don't think automatically navigating the requirements for one item is so hard. I might only think it's easy because my bot is already based on spending future resources though (see my comment on "even easy skills are difficult"). So buildWithRequirements(starport, 4050) calls schedule(starport, 3000) and buildWithRequirements(factory, 3000) which calls schedule(factory, 1800) and buildWithRequirements(barracks, 1800) which calls schedule(barracks, 400). (I'd have to swap the order of schedule and BWR but this way around was easier to explain).

MicroDK on :

You could add "wait until x mineral" and "y @ z frames" commands. The latter could be used to build the creep z frames later and setting z to something that will make the creep and evo finish at the same time.

MicroDK on :

Thinking about it, it will be difficult to use "@ natural" with the latter command...

Ankmairdor on :

I think adding “wait_minerals 300” as well as grouped build orders(i.e. "group_same_start{Terran_Barracks,Terran_Barracks}") would allow for a lot of optimization by the user. I think grouped actions could be powerful if paired with stuff like drops. I have thought a little about build orders, but my plan is to scrap UAB's manually provided build plan, probably for some form of tree search with periodic pruning. The essential part of automatically optimizing build orders is treating actions differently. For a rough model, we can separate actions into two groups: terminal(stuff that we want) and instrumental(stuff we need to get what we want). Generally our terminal actions are producing fighting or casting units/buildings. It could be more complex, like a group of marines and medics. Also, workers can be either terminal or instrumental depending on the situation/perspective, especially for Zerg, so that one can be tricky. Unless otherwise specified, we would assume that terminal actions should be performed ASAP, thus we create a timeline backwards from each terminal action as well as adding any missing instrumental actions. Most people probably already know of the BWAPI::Unittype functions, but I recommend using them for dynamic build plan optimization. There are lots of simple functions for getting the data you might need. Using that data, we work backwards down the tree passing some or all of the cost to any preceding instrumental goals. We can consider workers to build in parallel but nearly every other action is serial. Resources increase over time(or for this model we could say that they decrease as we go back in time), so depending on the difference in times to complete parallel actions there may be some reduction in upfront costs from harvesting. To combine parallel lists of actions into a single serial list, calculate the total time cost of each item, put them all in one list, and sort by total time into descending order. Though, it seems that rushing Arbiters is probably the only time you need lists of parallel actions for a terminal action of a single unit type. Given the complexity of all this, I think it's faster to add some commands to the build order.

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.