archive by month
Skip to content

what’s next for Steamhammer: the decision

I have decided what tactical skills to work on. My list included skills for specific units: Mutalisks, the most important; lurkers, which I’m most interested in for now; scourge, which Steamhammer spends heavy gas on and doesn’t always use well, defiler skills because Steamhammer often reaches late game. But those are only single unit types. And unit coordination skills, like storm dodging, scarab dodging, mine clearing and mine dragging, making the best use of the dark swarm that is on the map—all needed, all narrow and specific. And tactical analysis, my initial favorite. I have an algorithm in mind, which calls for a fast combat evaluator. MaasCraft’s tactical search also uses a fast combat evaluator. My idea is different, and I’m not satisfied with MaasCraft’s evaluator. Thinking through what’s needed, I concluded that the first draft would be easy to write, but would produce poor results. I think it’s likely that it needs a sophisticated combat evaluator to work well—I have an AI algorithm in mind for that too, but I fear I can’t finish it in time for SSCAIT in December.

To make the most progress before SSCAIT, I decided to work on the next level of pathfinding skills. Steamhammer currently calculates terrain paths without regard to where the enemy may be. On an empty map, ground units reach their destinations without getting stuck on terrain. When a unit is trying to reach its destination safely despite the enemy, a scouting unit or a drone transferring to another base, the unit reacts to dangers by leaving its path and running away from the enemy. It is not able to figure out a way around (though it may blunder into one), and it is not able to tell when its path is completely blocked and it should give up. So overlords scout less safely and less efficiently than they could, and worse, drones trying to transfer may end up burrowed all over the map, wasting supply and risking their lives to achieve nothing.

Steamhammer needs true safe pathfinding. It has to recalculate safe paths when the enemy is sighted. That opens the door to a lot of more specific skills.

• Don’t send drones to a place you know they can’t reach. This alone would save many games.
• Don’t even spawn extra drones inside a tight contain. They won’t get out.
• Better scouting, from maneuvering the early scouting worker to moving overlords and the Recon squad.
• Calculate least-danger paths for harassment. You can take hits as long as you escape.
• Similarly for drops.
• Reach safe spots to attack walls or other stuff from outside enemy range.
• Enemy vision is a kind of danger too. Find sneaky paths.
• Path through nydus canals. Nydus canals are part of my plan to support islands.

I don’t know how many of these I’ll get to by SSCAIT. There is a lot to it: Ground units and air units have different needs, safe paths and least-danger paths are different, sneaky paths are different. Safe drone transfers are the biggest weakness and have top priority. Part of the solution is to spread hatcheries out more, rather than putting all macro hatcheries in the main.

The first part of the job was to create a task manager to run background tasks. It’s simple, I wrote it yesterday. The idea is that pathfinding tasks will update safe pathfinding data structures behind the scenes, so that the calculation load is spread out and the data is reasonably up-to-date. Over time, I expect to add a lot of other kinds of tasks. Steamhammer runs fast, and for now there is little risk of overstepping the frame time limit. (Even in the late game when maxed, most frames take a handful of milliseconds, and spikes above 20ms are rare.) But I have thought up plenty of complicated tasks, and it seems likely to become an issue someday. I want the infrastructure to be ready, so that I can implement a principled solution instead of refactoring a lot of code when the day arrives.

Trackbacks

No Trackbacks

Comments

Bruce on :

There is some AIIDE news from Discord that relates a bit to your last point about timeouts: PurpleWave has withdrawn from the tournament as it somewhat mysteriously was timing out in most of its games. I say mysteriously since Dan has invested a huge amount of effort into making PurpleWave run asynchronously, which should make timeouts impossible.

Last year when the BWAPI client timing bug was being investigated, some other issues were discovered, like problems relating to the timer not being high-enough resolution and problems with the bot process being pre-empted by the OS and therefore appearing to have spikes that were actually nothing to do with the bot.

All of this has got me wondering if we should change the approach to timeouts. I think the 1- and 10-second limits are fine, but perhaps the 55ms rule should be an average over the entire game instead of a frame count limit. I’m a bit worried that the current rules will result in more unfair disqualifications or force more bot authors to spend a lot of time working around single-frame spikes, both of which are bad for our already-quite-small community.

Jay Scott on :

1. :-(

2. A big issue. I’ll write a post about it.

Dan on :

The AIIDE, COG, and SSCAIT timeout rules amount to a 98% SLA over a 10 minute game and higher in longer games. The per-frame requirements are helpful for ensuring bots play smoothly against humans, but are incongruous with tournament operating conditions, and excessively stringent for ensuring smooth tournament operation.

There are multiple challenges with trying to meet that SLA:

1. Hardware you can't test on (except SSCAIT)
2. Virtualized environments
3. 1-core and 2-core environments where threads are likely to block
4. BWAPI uses low-resolution timers for timing bots: https://github.com/bwapi/bwapi/issues/860
5. There's no built-in method for asynchronous operation; you have to roll your own and it has substantial cost overhead and technical risk
6. The ever-advancing skills of StarCraft bots that encourage increasingly sophisticated and expensive behaviors and make CPU time a resource to exploit :)

In most of my test games where PurpleWave is running synchronously and reached disqualification conditions, the slowdown is imperceptible. In the games Dave ran where PurpleWave was disqualified, the bot was averaging 2x realtime speed (which is about what I had it configured to do)

So I would also endorse timeout rules that just require a bot to play to a certain average speed over a game or a rolling window, and spare bot authors (and tournament operators) the demands of meeting and enforcing high-SLA realtime constraints.

Dan on :

And as Bruce said, apropos your post, the most likely cause of PurpleWave's bot-originated spikes (which should in theory be harmless given asynchronous operation) is PurpleWave's threat-aware pathfinder, which it increasingly (and expensively) uses for drop harassment. I intuit that A* does not perform very well with non-uniform cost grids due to the ever-expanding search horizon and the reduced efficacy of the minimum cost heuristic.

Dilyan on :

I think you are in right direction. If done well , that pathfinding thing surely will save lots of loses, i have seen many overlords die and many drones one by one that were keep sent to opponent like gifts. Nydus cannals would be amazing as well. In my "book" i rate nydus canal higher than ultralisk skill, guardians skill, queens skill or even defiler skills. Imagine flanking opponent with nydus canals, the bot opponent will probably bug out trying to figure what just happened LUL.
There is one thing that can win you many games vs every bot, including Stardust. Its a weakness on every bot. Probably for a reason (dificulty to implement?)
That is, when you have an army waiting for opponent to come out of his base.. then opponent comes with bigger army..any bot will back up all the way back to his base until he produces more units to fight upcoming army.. what he should do is "just" hide or get out of the way of that path and do counter attack which with bots logic that will force opponent army in middle of map to come back , but by that tine your zerglings or hydras will do lots of worjer kills or snipe that unprotected nexus or expo while having time to makro sunkens at home for example .


One of the other big issues that loses most games, from my observation thru sscait stream only is that, when SH opens with some aggressive cheese, all in 1 base play or 2 base and fails to kill enemy (or book ends) then starts to produce a mess. Tries to make a bit of everything (this unit, that unit, upgrades..sunken, even tho he is pretty much all in, going for hive on 2 bases without much drones or going for queens when his army is just a single control (12 units) ) without having the economy (mining bases, drone saturation)..starts to react , which is imidiately defense, but sure loss in long game. On top of that SH doesn't harrass well to buy some time in order to recover from low eco aggressivness. In fact i haven't seen on stream SH opening with standart long macro play or "proper" semi all in like 3h hydra bust or timing attack all in zergling bust..on top of everything he loses here and there units for free.
In game of chess, low rated players are obssebed by opening tricks and traps. They often gambit and thats how they win games. They want quick result.But very soon they hit wall where they can't progress, because of the bad habbits they have playing wrong and low tactical skills. Its even more dificult for them to transpose to normal game and its like learning game all over again.
But im sure you are on right direction now and sscait tour will be exciting for SH! CHEERS and gl!

MicroDK on :

When I implemented pathing for ground units, I experienced a higher frame time usage in general, so I had to optimise when to do the expensive calculations. And I had to go for the simple choke pathing solution to keep frame time down.
I originally planned to use BWEBs pathing functions, which also would make Microwave able to do save or least danger pathing, but they were too expensive for Microwave in mid and late game with a lot of units. But Microwave is using last an older version of BWEB, so I will try to update and test the frame time again.
It was also one of the reasons I opted to disable the flying save pathing I had implemented with BWEB for COG. I did not have time to test it enough to make sure that Microwave would not hit too many frame time limits.

Tully Elliston on :

Are any bots using threatmaps for pathing at this point? eg. break the map into a grid of cells. Calculate enemy threat in each cell based on observed or suspected enemy units. Update the threat value in a small/managable number of cells per frame. Use the threat map to inform more granular pathing decisions. Even a low resolution threatmap can be be useful for bypassing enemies, and a higher resolution threatmap can be used create eerie pathing between enemy range circles.

Dan on :

Yes, multiple bots perform threat-aware pathfinding. Overkill (Sijia Xu), tscmoo, CherryPi, PurpleWave off the top of my head. McRave has at some point and am not sure if it still does.

If you've ever watched Sijia Xu on the SSCAIT stream, the numbers it displays around its Mutalisks are precisely that: a grid-based threat metric used for navigation.

Tully Elliston on :

Its an old (but very good, the AI associated with it was fantastic) paper about a Spring RTS AI, but the micromanagement technique using threat maps shown on page 50 worked really well. As a human player trading efficenctly with the AI was a nightmare, as in combat every unit it controlled would be constantly shifting location to where it could best fire while minimising return fire.

https://drive.google.com/file/d/1rk_0yKY0qAL4K_6bYstLZ0GahhaV-Mxo/view?usp=sharing

Tully Elliston on :

I finally got round to poking through SH's code. I was suprised to discover that the criteria for attack or retreat was so simple and light, and that is essentially the same code. Also that the code that considers losses from retreating is commented out.

The combat logic doesn't have multiple states, so the same logic that decides whether to pick a fight also decides if it should leave.

As a result, you get constant oscillations.

Seperating the requirements for entering a fight and requirements for retreating seems like it would be a good first step to defeating the oscillations.

An attack criteria of "more than x% of our units remain" and a retreat criteria of "more than y% of enemy units remain" will give you much less oscillation for example, then "check who has units left" as the criteria for both.

The requirements of x and y are in reality are contextual. You would seek higher values of x when attacking a contained enemy than you would when defending your workers.

I like the "estimate ratio of losses from retreating" value, its a shame the present logic doesn't use it. I can see the way it was used before might cause issues. This ratio, combined with tracking the losses the cluster has received in previous franes, could be a good way to make AI understand the sunken cost inherant with moving melee units into range - and why once they are in range it can be better to leave them in than flee, even if they then die to an overall loss.

Jay Scott on :

The oscillations have more than one cause. Another cause is also simple: It does not do combat sim when far enough outside enemy range. So it advances closer, finds out it is losing, retreats outside of range, etc.

The retreat code is commented out because it caused more problems than it solved. Something different is needed.

But in essence, you are right. Steamhammer needs different criteria for advancing and for retreating. I did implement related ideas to reduce lurker burrow/unburrow and tank siege/unsiege.

Tully Elliston on :

> It does not do combat sim when far enough outside enemy range

For a lighter check of whether advancing non-flyers makes sense, maybe just compare mineral/gas cost of cluster vs that of known hostiles. Significant shortfall = do not advance.

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.