movement simulation
Steamhammer is nearly prepared for AIST S4. I made 3 major improvements, plus smaller ones. Not everything I tried succeeded, though. Today I want to write about a new feature I implemented that is definitely valuable, and that Steamhammer will find uses for in the future even though my first use case didn’t work out as I hoped.
Steamhammer inherited from UAlbertaBot a weakness in retreating. It is Steamhammer’s longest-standing serious weakness. The point of retreating is to get away from a fight, so the units get move commands and ignore enemies they meet on the path to their retreat point. Nearly all cases where Steamhammer’s units run into or through or past enemies without fighting are because it is trying to retreat them. There are spectacular failure cases, like running ultralisks through a field of cannons and losing them for nothing. My past attempts to fix it have been half-hearted, since I want to delay coding a full tactical analysis until later. I thought I’d try something more courageous.
So I implemented retreat simulation in FAP. Moving is a lot easier than fighting, and it didn’t take much code. Pass in a target position, and our simulated units move to the position while the enemy’s keep chasing and shooting as usual, with no change to their side of the simulation. We’ll say the retreat “succeeded” if the fleeing units’ losses were lower than some percentage.
My idea was: If the regular combat sim said to retreat, then I ran a retreat sim in the same frame. If the retreat failed, then don’t run away, keep fighting regardless. The retreat sim runs fast because it is simpler, and also I cut its duration to only 2 seconds. I didn’t meet any problems with the frame time limit. In principle, the retreat sim can conclude “the cannon will kill us even if we run away, so keep hitting it,” and notice when the retreat path is blocked, and distinguish a faster force that can escape from a slower force that the enemy will chase down (yes the speedlings will kill your marines for free if they run, better to make a last stand).
In practice, the retreat sim might be worth it on average, but I was not convinced. The sim results were as noisy as ever, and there were times when it hurt. Also, in some situations it’s conceptually the wrong thing to do. Having the “retreating” ultralisks fight cannons is better than running past the cannons, but better yet is to understand the situation as an attack rather than a retreat, and to stand aside until you can win. And that seems to call for the tactical analysis that I was saving for later.
I called the internal routine in FAP not retreatsim() but rather movesim(), because it can answer many questions about when movement is safe.
- Will this runby succeed in running by?
- How far can the transport go before it must unload?
- How many scourge will survive to hit their target?
- Will this plague/broodling/etc. succeed, or will the caster be killed first?
- If I mind control that unit, will it live to join my army?
And with a little more elaboration, questions like
- If it lives to cast, will the defiler/queen/etc. also escape safely?
- Is there time to unburrow/unsiege, or should the immobile units remain as they are?
- Can the mutalisks pick off another marine and still get away without losses?
I think it’s a safe bet that Steamhammer will be answering some of these questions before AIIDE this year.
Trackbacks
No Trackbacks
Comments
Bytekeeper on :
I also do believe that staggering the simulation is worthwhile, although my bot makes such poor target decisions that it hard matters:
Instead of running 1 attack sim with a few seconds horizon, I run a few of them for some frames and use the maximum outcome instead of the final outcome.
The basic idea: Maybe it would generally be better to retreat because in 10 seconds I will have lost a lot. But if I stay 2 seconds longer, I will have killed 2 more units - so I might want to retreat after that.
That's not possible with a fixed horizon, as it will just retreat far too soon.
I also check which units die, regardless if they retreat or attack and keep attacking with them.
In the end, I believe those features are good, but my bot engagement logic is just not good enough - it would be better to attack the same way as the sim does - closest enemy first....
Jay Scott on :
Dan on :
1. It's less valuable than a more accurate sim (modeling terrain awareness, collisions, targeting, and kiting, turning/acceleration, high ground miss)
2. It's less valuable than making sure sim behaviors are more similar to real unit behaviors
3. It's less valuable than applying well tuned hysteresis to fight decisions
4. It's less valuable than good judgement on the numbers which pop out of the simulation
5. But if those were all taken care of, it could be valuable
The biggest issue is that retreating is much harder and more dangerous than it looks in a collision free simulation especially for low hp units (zerg!) and units that have to turn around to run (zerg!). A sim might tell you that running your zerglings from their zerglings after a fight has begun works perfectly but in real gameplay is usually catastrophic.
I'll say that one of the big reasons Stardust is smashing everyone in the 4-gate mirror is due to having some basic modeling of terrain effects in combat simulation. It's that important. The way bots play tug of war, any type of fight you know to avoid due to better modeling is also an error your opponent will commit repeatedly.
Bytekeeper on :
Units running away also only get 90% speed. And I use a Locutus like collision grid.
Attacking sim uses the current target for all units (incl. enemy). Kiting is simulated, high/low ground is taken into account (but not updated within the sim).
This all runs at a good enough speed - terrain modelling is a tough nut though.
I'm quite happy with the decision making regarding attacking/fleeing. There's not much back and forth.
But: My bot's combat decision is poor. Engagements it should win are horribly lost due to it switching targets, ie. suddenly attacking buildings.
What I said above could be completely rubbish, because I cannot prove the results - I focused too much on the sim, the rest got neglected. It doesn't matter if you can make a good prediction on how bad your combat is going to end if you forgot to build units...
Dan on :
Jay Scott on :
It has been on my to-do list for a long time to work systematically through the combat sim and fix where possible and necessary. I think you’ve already done that. It competes with another item, to write a machine learning combat estimator. I conjecture that best would be an accurate combat simulator for small-scale fights and a combat estimator for big fights and ones where there is more uncertainty in the inputs.
Dan on :