archive by month
Skip to content

SparCraft and overcoming its limitations

MicroDK recently suggested in comments 2 ways to alter SparCraft’s input for better results.

1. Don’t feed in uncompleted units. As written, parent UAlbertaBot and the live Steamhammer will feed SparCraft our own uncompleted units when they are in the combat circle. SparCraft doesn’t know the difference and assumes that they can fight. It’s a bug. I fixed it for the next Steamhammer by not tracking our uncompleted units in MapGrid, since we should never care. It was a waste of resources to track uncompleted units.

2. Exclude out-of-range static defense. This is not a bug, but it is an interesting idea. SparCraft predicts which side will win a battle. If you have, say, zerglings and sunkens versus zealots, SparCraft may say that zerg wins. So the zerglings confidently rush forward out of sunken range and die unnecessarily. MicroDK suggests: If the sunkens are out of range of zealots, then don’t tell SparCraft about the sunkens. The zerglings will hang back as they should, unless and until they can win on their own.

I see a lot of related misbehavior in Steamhammer, where SparCraft takes everything into account but the bot could do better by considering a more restricted part of the situation. For example, in the live Steamhammer, when mutalisks see units that they can’t beat, they retreat out of sight range, including sight range of supply depots. It would be the right behavior if the plan was to circle around and try another angle (that’s why I put it in), but instead Steamhammer sits there, unwilling to move forward and unable to see or engage anything. If it isn’t going to circle around, it ought to at least take shots at a supply depot until chased away! The mutalisks could fight better by ignoring all anti-air units that they are out of range of, not only static defense.

SparCraft accounts for all units that you tell it to, and Steamhammer tells it to include all units in a large circle. Another example of the problems this causes: Melee units which are close by air but distant by ground may be in the circle and accounted for in the simulation. Or ranged ground units which are out of range of the battle and can’t reach it soon enough to help, because the ground distance is too great (they have to go around an obstacle, or whatever). In these cases the attacker may defeat the forward forces and then retreat before the distant forces arrive, while SparCraft expects them to wait around. Then you may fight when you should retreat until your forward and rear forces join up.

I will probably implement some kind of situation pruning to help. It seems easy and likely to be effective, and some of the errors it avoids seem hard to avoid otherwise. But there is also an underlying conceptual weakness in SparCraft that I would like to solve eventually.

SparCraft answers the question “which side wipes out the other?” It is not always the question that we want answered. It is a reasonable question given UAlbertaBot’s tactical model: Draw a line from our base to theirs, move forward along the line as long as we can win, move backward along the line until we can win. But UAlbertaBot’s model is ultra-simplified and isn’t suitable for drops, or vulture raids, or mutalisk harassment, or runbys, or picking off reinforcements... or most tactical maneuvers. For all these situations, SparCraft is not a natural fit, and at best you’ll have to use it carefully to get good answers.

The underlying issue is that we want SparCraft to answer different questions in different situations. Eventually I want to have a more flexible combat predictor that can cope with more questions: “Here’s the goal, can I achieve it?” Either I will upgrade SparCraft with new goals and behaviors, or I’ll find or write another combat predictor.

  1. If these units run by the enemy position, how many will survive on the other side?
  2. Will this drop or raid do enough damage to pay for itself before it is destroyed?
  3. Will this harassment attempt kill at least one enemy unit and get away safely? (Mutalisks keep shooting as long as the answer remains “yes”.)
  4. Will the enemy be able to surround and trap this squad, or can it escape? (Should I run away or make a last stand?)

Question 4 might be too hard for SparCraft, but for 1-3 I can see how to modify it to answer the question directly. When Steamhammer’s tactics boss becomes smart enough to know what question to ask, this will move to the top of my to-do list.

Trackbacks

No Trackbacks

Comments

PurpleWaveJadien on :

(1/2) You're obviously far more in tune with SparCraft's strengths and weaknesses than I am. I've experimented with a lot combat prediction approaches that *aren't* SparCraft. And my conclusion is that SparCraft is the best existing approach and the best basis for further improvements, including ones which provide more meaningful outputs than a list of expected survivors. Heuristic approaches (AILien, McRave, and current PurpleWave) can be good but are awful at accounting for geometric considerations. I spent a month experimenting with policy-based simulation (as opposed to min-max searching) but it produced very noisy predictions due to the stupidity of all high-performance policies and the tendency to produce radically divergent outcomes based on how units behaved.

Jay Scott on :

The 2 basic approaches are what I would call simulation (like a chess program) and estimation (like AlphaGo). They’re both heuristic, technically, but I think we all know what you mean. :-) It’s hard to be sure, but I suspect that estimation is likely to be the better approach when fully developed. Deep learning should be excellent for combat prediction. As soon as somebody comes up with 100,000,000 training examples, we’re ready to start! OpenBW should eventually make that possible.

PurpleWaveJadien on :

Yeah, I fully agree that learning-based techniques have a far higher ceiling than anything we're doing now (for both combat prediction and anything else, really). The line I'll draw in the sand, though, is that search-based simulation (ie. SparCraft) is more potent than any hand-crafted estimator we'll see. It's representative of the Starcraft problem as a whole. Unit damage/health, unit speed/range and terrain/collisions/pathfinding lie in entirely different domains. The challenge of accurately integrating them lies at the top of a skyscraper for which machine learning is the elevator and hand-crafting is the stairs.

PurpleWaveJadien on :

(2/2) One of SparCraft's weaknesses, as you mention, is that it doesn't produce actionable information. The strength of policy-based search was to at least try to inform how units should behave as a result of the simulation (ie. try these two policies in simulation, and execute the one that produces better results). If I were working in C++, the approach I'd try now would be to build that into SparCraft. For example, run the simulation with/without my workers fighting and see which produces the best results. As I understand, the primary limitation there is a performance limitation (the 100 unit limit), but the workarounds for that limitation (like merging units or splitting the calculation across several frames) may be a worthwhile price to pay for getting more actionable output.

Jay Scott on :

The new SparCraft version does not limit the number of units it can simulate. I still haven’t tested its performance, though....

PurpleWaveJadien on :

Queuing up a mass zealot build vs. tscmooz would be a pretty good workout!

PurpleWaveJadien on :

(3/2 because I can't stop typing) I just watched a game of Lukas Moravec vs. Marine Hell. Lukas' army was flanked by a mass of Marines, and based on the SparCraft prediction he retreated -- directly through the marines! That's the kind of situation where testing multiple policies would help out -- does the simulation in which we retreat produce a worse outcome than the one in which we fight?

Jay Scott on :

I agree. We want to compare different actions, at least at the tactical level. And we should be able to do it, too, because SparCraft runs within 1 frame and we can take several frames to make a tactical decision like whether to retreat or make a last stand, or whether to pull workers for defense (though for some reason SparCraft doesn’t support worker combat), or whether to pause and put our army in good formation before attacking. But we can only compare a few broad courses of action; we can’t do much thinking and still play in real time.

PurpleWaveJadien on :

For sure. And even output of that granularity doesn't tell us how to execute in order to achieve the predicted outcome.

MicroDK on :

I have just updated with the two changes to Sparcraft input. I am a little conservative so I exclude all my buildings, it was easy to add. ;) Lets see how it plays out... hopefully Microwave will win more consistently against zealot rushes. At least thats what my tests show. I have plans to test different inputs in different situations. Maybe thats the key to handle Sparcraft.

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.