EPTSummary:
+ Show Spoiler +
Introduction into latency considerations and one example how to apply it in a micro situation.
When programming a bot sooner or later you will deal with latency. And more likely than not you will experience a couple of surprises the first time you play against other bots over a network.
This posts intends to save you some frustration and shed some light on the internal workings of Brood War.
Let’s start with some definitions to create a common vocabulary for discussion.
Latency Frames (constant throughout the course of a game)
Latency in Brood War is the maximum delay between the frame a command gets issued and the frame that command gets executed. Latency Frames define the maximum delay in terms of number of frames.
Turn (constant throughout the course of a game)
A turn is a set of sequential frames, which are bundled together such that commands issued in any of those frames are executed together. If a turn consists of 3 frames, then any commands issued in frame 1 and 2 will be executed together with commands issued in frame 3.
Turn Size
The number of frames per turn
BWAPI Remaining Latency Frames (variable per frame)
Remaining latency frames indicate the actual delay until an issued command is executed (as opposed to the maximum delay). Since commands from the same turn are executed together, this delay varies depending on when during the turn the command was issued. If a command is issued during the first frame of a turn, then Remaining Latency Frames will be equal to Latency Frames. That is, the actual delay will be equal to the maximum delay.
BWAPI latency compensation (default: enabled)
BWAPI has a functionality to simulate status changes as soon as a command is issued rather than when it is executed. This includes order, target position and a bunch of stats like isIdle, etc. The drawback being the information is not actually correct. So there might be just as many cases where latency compensation backfires and does hurt more than it helps. Imagine an SCV constructing a building and you tell it to stop. With latency compensation enabled it will immediately show as isIdle. But relying on the unit to be idle may result in an error since actually the unit is still constructing. The general recommendation is therefore to disable latency compensation.
Example: latency frames = 6, turn size = 2
Frame 0: issue unit1.attack(). Remaining latency frames: 6
Frame 1: issue unit2.attack(). Remaining latency frames: 5
Frame 2: do nothing. Remaining latency frames: 6
Frame 3: do nothing. Remaining latency frames: 5
Frame 4: do nothing. Remaining latency frames: 6
Frame 5: do nothing. Remaining latency frames: 5
Frame 6: execute unit1.attack(), execute unit2.attack()
How do you detect the latency settings?
Latency Frames and Remaining Latency Frames can be queried via BWAPI. To detect the turn size you need to calculate how many frames it takes until Remaining Latency Frames equals Latency Frames.
Application
Consider the scenario where a marine runs into a group of hostile units. The image below shows the exact moment a teal marine detected it is outnumbered and turned around to run away. The circles show the attack range (weapon max range) of the respective units.
As you can see, the teal marine is well within the attack range of the closer red marine and will therefore take hits.
![[image loading]](http://i.imgur.com/q9TYrik.jpg)
Two factors are responsible:
1. If the teal marine issues a move command to run away the exact moment it spots enemy units within their weapon range the command will only be executed <remaining latency frames> later.
2. Furthermore, the teal marine will require a couple of frames to turn around (between 4 and 5 in this case)
So how do we make sure we run away in time?
We could of course just run away as soon as enemies are in sight range. But this will result in a very conservative behavior with many missed opportunities to get your own shots off.
Instead, we account for latency and frames required to turn as follows:
If (distance between enemy position and my position <= enemy weapon range) then run away
Becomes
If (distance between enemy position in <remaining latency frames + turn frames> frames into the future and my position <remaining latency frames> frames into the future <= enemy weapon range) then run away.
Ok, but where will each unit be x frames into the future?
For your own units you can just extrapolate along the current path.
For enemy units, there are two main approaches:
- Either assume they are walking directly towards you (conservative case)
- Or assume they continue their current direction at their current speed
The image below shows a scenario where the green marine accounts for 6 latency frames and 4 frames to turn. It therefore calculates the distance between where the teal marines will be 10 frames into the future and itself 6 frames into the future (since it turns on the spot).
![[image loading]](http://i.imgur.com/W5jqKUe.jpg)
The result is a very precise micro, where the green marine will remain just outside of enemy weapon range.
Disclaimer:
A word of warning: escaping is considerably harder than attacking. You need to avoid getting cornered and may have to take unexpected turns, allowing the enemy to catch up. It might be a good idea to introduce some safety margin to account for this.
Credits:
Thanks tscmoo for proof-reading
RadicalZephyr explained turns and latency well at https://github.com/RadicalZephyr/bwapi/wiki/Latency
