tricky point with MapPartitions
If you use the MapPartitions code that I posted, here’s a tricky point that I ran into.
Units can’t walk on a geyser, so MapPartitions puts the walk tiles of the geyser in partition 0, the unwalkable partition. It stays unwalkable if there is a refinery building on it. So if you check reachability like so, the.partitions.connected(this unit’s position, that geyser’s position) (to build on it), or the.partitions.connected(this unit’s position, that refinery’s position) (perhaps to mine from it, or to attack it), then the answer will always come back—no, you can’t walk there. It’s correct, you can’t walk on top of the refinery!
The correct check is: Can the unit reach any position adjacent to the geyser? The geyser blocks paths, so in principle it might be reachable from more than one partition. Maybe you can get to it from your side and the enemy from theirs, but there is no path between your bases because the geyser is in the way. Weird maps happen. To always get the right answer, you have to check each adjacent tile.
There’s no issue with checking reachability between 2 units, or between a unit and any building other than a refinery building. The ground underneath is walkable, and that is what counts. Only refineries cause extra complexity.
Trackbacks
No Trackbacks
Comments
Stanislaw Halik on :
The common problem the bots have is indecisiveness, or rather, retreating from attacks. The issue is that defending units will take potshots against attackers, leading to severe losses anyway.
The estimator can be modified to check the case of retreat, arriving at the objectively right solution - dragoons will chase back, giving one-two shots each.
The bots consider retreating even if the damage they receive is comparative to having the whole group die. But in the latter case at least they manage to achieve anything.
Dan on :
Helped a little but doesn't solve the fundamental issues:
1. Simulations aren't realistic. Due to performance constraints you can't simulate the full rules of the game engine. Collisions, terrain, Brood War glitchy unit behavior, splash damage, Scarabs, etc. There's room for improvement (there was some recent discussion about accounting for acceration and turning in simulated unit movement) but as I recall the best attempt I've seen (tscmoo embedding the OpenBW engine itself as a combat simulator) wasn't successful.
2. Simulations only indicate one possible future. You can only simulate a small possible set of behaviors out of behaviors^units^timesteps. Additionally, due to performance constraints, the micro rules that simulated unit follow are necessarily far weaker than the real rules. Simulations generally don't have kiting, focus-firing, Lurker burrow, spells, Shuttle pickup, etc.
3. Variance in simulated results is thus inevitable. You can take the same set of units, and slightly tweak their positions, and get radically different simulated outcomes. Worse, you wind up with a nasty tradeoff: The more frequently you adjust your fight/flight decision, the more reactive you are, but the more frequently you'll land on an edge-of-the-bell-curve simulation result, and choose an action that you quickly revert, producing indecision.
4. Simulations are incredibly hard to debug. You're generating tens of thousands of simulated events per second. The more realistic you want to make the simulation, the more rules you need; the more rules you need, the more complexity you introduce; and with more complexity comes more bugs. Unless you're prepared to manually audit thousands of simulated interactions to ensure that they're all realistic (I have done this, and it stinks) you have to limit the complexity of your simulation to ensure that it doesn't have atrocious bugs.
These issues which produce indecision affected the retreat simulation even more severely. Armies would see a retreat simulation of "everyone dies" and decide it was better to suicide into fights from which they could have retreated and saved a couple of units. Or they'd have a slightly unfavorable fight, see a successful simulated retreat that actually produces losses, and gradually bleed out from repeated errors.
The approach PurpleWave currently uses is to only perform an attack simulation, and to temporally adjust the threshold of acceptable cost/benefit, such that choosing to attack temporarily decreases the benefit threshold required to keep fighting (with the effect decreasing over a few seconds) and choosing to retreat producing the opposite. This hysteresis produces good results but is a bit magical in nature; and it doesn't escape the aforementioned tradeoff of "reactive units" vs. "decisive combat decisions".
Jay Scott on :
Stanislaw Halik on :
Otherwise, a bot player with good economy can inflict severe losses and replenish forces faster than the defender under contain.
The solution is similar to avoiding responding to hysteresis in a phugoid-like fashion (consider even GPU fan hysteresis threshold). Other than scouting the defending force size, either commit for good or don't take the potshots.
Jay Scott on :