archive by month
Skip to content

impressive gas steal bug

Stealing gas is irritatingly complicated in Steamhammer. Today I discovered another bug: If the scout worker has been ordered to circle the enemy base forever, and while it’s doing that you decide (this late in the day) to steal gas, then the building manager goes haywire and moves the worker into a corner or some other useless location. Now what??? It worked when I told to it to scout once around the enemy base and interrupted the circle in the middle by deciding to steal gas, but circling more than once somehow breaks it... in a different module.

Of course everything works perfectly if you decide up front to steal gas, so the worker arrives at the enemy base knowing what to do. That’s the usual case. It sure would be nice to support late decisions, but there are interactions with the scouting command.

I think I should write a general purpose plan sequencer and reduce the gas steal to a plan represented as data, not code. It will be more complicated, but I only have to debug it once and it will have tons of uses.

Trackbacks

No Trackbacks

Comments

krasi0 on :

So have you figured what exactly causes that bug? Regarding the "general purpose plan sequencer" that processes just data, I'd be curious to know if you'd be able to implement such a beast in the future :)

Jay Scott on :

The bug was that some state change conditions were checked out of order, so that it didn’t switch into the correct state of the gas steal. Bugs like that usually mean that the code is too complicated. I fixed it by finding a way to make it simpler and more straightforward.

IMP on :

the way I solve such issues is to let each module such as building planner or scouter manage its own group of units. When attempting a gas steal the affected worker is removed from the scouter group and added to the builder group. Thereby the control of the unit is passed from the scouter to building planner and there won't be any interference.

Another advantage of this design is you can just move any unit from any group to the scouter group. The scouter will realize a new unit has been added to its group and will determine how to make use of it effectively.

A unit is only a member of one group at a time.

krasi0 on :

My approach is similar.

Jay Scott on :

Well, you need a way to assign units to tasks, and I don’t know what way would be very different. How do you deal with nested tasks? In my case, the gas steal is nested inside the scouting task, so a worker’s assignments are Worker Manager -> Scout Manager -> Building Manager -> Scout Manager, then if scouting comes to an end back to Worker Manager. It’s my only nested task, so I implemented it as a special case. But I expect more in the future, so....

Dang on :

My tasks have a priority order, and grab the best unit available for the job, which may include any units (or other resources) allocated to lower-priority tasks. So if stealing the gas were higher priority than scouting, it'd automatically grab the scout (as the closest eligible builder).

Jay Scott on :

That does seem like a smart arrangement. UAlbertaBot originally worked similarly, finding the closest worker to assign. Unfortunately, behind the scenes it depended on the worker being double-assigned to two controllers—at least I think that that’s one of the bugs I fixed that broke the gas steal. I also think the gas steal wasn’t as reliable as it should have been in the first place.

Arrak on :

My ideal plan was to centralize and shift all the control elements, like move and attack commands, down to unit-level. The worker decides what task is highest priority and how to execute it. If the worker is being chased by zerglings, then it can also handle that first. It's fine here if the worker is both the Scout and the Gas Stealer, so long as it's only obeying the Gas Steal order - so no control conflicts.

I think this would have made for easier implementation of kiting improvements, and pathfinding with nydus canals and mineral walking. I didn't manage to detach the worker controls from the building manager yet, though.

IMP on :

The problem with the approach of shifting control down to unit level is collaboration between units ( e.g. "there are already 3 workers dealing with the harassing ling, I can keep mining"). To achieve such collaboration you need either a centralized decision maker (the opposite of shifting down control) or very good communication between the independent units. I'm currently experimenting with the latter using private/public blackboards and a messaging system. An idea I picked up from a paper on swarm intelligence.

IMP on :

I avoid any kind of double-assignment ("A unit is only a member of one group at a time"). There is no way one manager can interfere with another. There is a universal inventory of units, which also tracks which workers are available for tasks. By default, mineral mining workers are available. At least in my design it doesn't make sense to nest a gas-steal task inside a scouting task, since it's not up to the scouter to decide whether or not to gas-steal. The scouter only provides the necessary information to the decision maker.

Jay Scott on :

I guess I should stop thinking of plans as literally nested and remember that they are only conceptually nested.

IMP on :

I use two mental concepts that help me think about such issues. One is the concept of plan repair (which I wrote a couple words about at http://www.teamliquid.net/blogs/527888-towards-a-good-sc-bot-p4-planning-2-3).

The other is the concept of asynchronous state machines. My unit micro is implemented via a fiber framework modelling each unit as an independent actor with its individual asynchronous state machine. In such an implementation it is important not to switch from any state to any other state directly, because it might lead to a stack overflow. Instead the state transition pattern resembles a star, always returning to the "base state" (reducing the stack) before deciding where to transition next. This is the analogy of always giving control back to a central decision maker when changing from one task to another (e.g. scouting to gas steal). Hence no nested tasks.

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.