For a long time, Spawning Tool lampshaded its lack of support for Chrono Boost. The timing on Protoss build orders was consistently a few seconds ahead for upgrades and some units, and we just marked it as a “caveat.” With the release of filterable build orders (that included workers) and playable build orders (where times really matter), it became very apparent that we needed to correct that. So we did.

For the curious, we can go into more details about the technical challenges to get to here and the remaining issues with it.

Why we were lazy about fixing it

Chrono Boost has been marked as an issue to address for a few months now but has been a known issue for over 2 years. It has been tricky because the data between casting abilities and building units is hard to line up.

Spawning Tool largely depends on the “tracker events” data that were added as part of the replay enhancements in this patch. For actually viewing a replay, the replay file includes when a player clicks on a certain building or issues a certain command. Although it’s complete, it is hard to extract a build order from that low-level, input data. The tracker events, however, are a separate list of when units were born or when buildings were started. It is much easier to translate into the formatted build orders we all know and love.

The problem is that these tracker events only specify when a unit or building actually appears on the screen. Although you may have started your Probe at 0:01 right as the game started, the “unit born” event is only marked at 0:18 when the Probe pops out as a selectable unit. The same goes for upgrades (however, this is not true for Warp Gate units or buildings since those appear on the screen as soon as you build them). To account for the build time, Spawning Tool just subtracts the build time for each unit (e.g. 17 seconds for Probes) and uses that time instead.

As you probably figured, this is a problem for Chrono Boost because Chrono Boost effectively reduces the build time for a unit. During the 20 second Chrono Boost, 30 seconds of build work is completed. Without any special logic for Chrono Boosts, Spawning Tool build orders were consistently ahead for non-Warp Gate units and upgrades.

To fix this, we needed to figure out when Chrono Boosts were applied. Unfortunately, casted abilities are considered input events, not tracker events, so we need to cross-reference 2 different lists and match them up. This was difficult for several reasons:

1. You technically aren’t Chrono Boosting the unit being built: you are actually Chrono Boosting the building that the unit is coming out of, so the Chrono Boost replay event target needs to be translated from the building to the unit
2. Unit born events only specify the location where the unit appears, not what building it came out of (or worse, upgrades have no location). Although lining up the nearest (x,y) locations is mostly accurate, the location itself can technically be ambiguous with adjacent buildings and rally points.
3. Chrono Boosts can be both wasted if a Chrono Boost is still active as well as shared if the current unit finishes and the next one starts with a Chrono Boost

How we fixed it

Spawning Tool cut a few corners to make Chrono Boosts work. You can see the full code change here. The biggest chunk of the change was restructuring the data so that we know what building each unit comes from. The actual logic is as follows.

First, we go through and find every Chrono Boost cast. For each type of building, we batch the Chrono Boosts into a single list, so it looks roughly like this:

• Nexus: 1:00, 1:15, 1:40
• Gateway: 4:00, 4:35
• Forge: 10:00, 10:20, 10:41

Then, we post-process the data to figure out what time range that the Chrono Boost was active. This avoids duplicates and simplifies the next step. This data looks roughly like:

• Nexus: 1:00-1:35, 1:40-2:00
• Gateway: 4:00-4:55
• Forge: 10:00-10:40, 10:41-11:01

With this we can then adjust unit build times from where units overlap with these Chrono Boost time ranges. For example, let’s say there is a Probe completed at 1:40. According to the constants, Probes take 17 seconds to build out of the Nexus. From the data above, Chrono Boost was active for the first 12 seconds (roughly from 1:23-1:35), and we can do the math to reduce the build time by however many seconds. The Probe, then, effectively took maybe 13 seconds to build, so we can say that the Probe started at 1:27 instead of 1:23.

And that’s it.

The Caveats

This isn’t perfect. In fact, there are some major gaps here, which some of you may have noted.

First, by aggregating all of the buildings of the same type into the same list, we can erroneously apply a Chrono Boost to a building. For example, if you have 2 Forges going with +1 Weapons and +1 Armor and Chrono Boost only the first upgrade, Spawning Tool will treat both of them as being Chrono Boosted and adjust their times accordingly. Given the ambiguity, I think it’s the best fix given the data. It avoids double-counting (if the Chrono Boost is active when another one is casted), and generally players slap Chrono Boosts across multiple buildings simultaneously.

Second, the process for calculating Chrono Boosts backwards is suspect. Because we are counting backwards from the completion time, we have to use the overlap to determine how much of a Chrono Boost was applied. This, however, overcounts the Chrono Boost’s effectiveness because the Chrono Boost itself decreases the start time and reduces the overlap. I would appreciate it if someone smarter than myself could take the time to figure out the correct way to do that approximation. As such, if you watch the replay, you may notice timings are sometimes off by a second or so.

Third, we can’t actually say how many Chrono Boosts were applied to a particular unit. In Spawning Tool, you will just see “(Chrono Boost)” next to the unit. This is a consequence of having collapsed the data down to ranges in step 2 above.

And finally, we can overestimate the application of a Chrono Boost. For example, most Protoss players first Chrono Boost the 10th Probe as the Pylon finishes. However, they may start it in the last second of the 9th Probe if they get antsy. Again, because we collapsed the ranges, we only know that there was an overlap (and therefore the 9th Probe counts as Chrono Boosted), though any human transcribing the build would never say that.

Final Thoughts

In practice, it easier to address than it might sound from above. There’s a tradeoff to consider with Spawning Tool in that you can think of a build order as an “abstract” model of a replay: it doesn’t go through all of the mechanics of the StarCraft game engine with clicking and such, but it gets the high level strategy. As the build orders become more faithful to the game itself, the model (i.e. Spawning Tool code) becomes increasingly complex, which, when taken the logical extreme, ends up being a StarCraft game engine emulator. Before Chrono Boosts, Spawning Tool was definitely too simple: adding Chrono Boosts is a huge improvement to the code. It doesn’t precisely work like StarCraft the game, but it is a close model without adding too much complexity.

Hopefully you enjoyed this post. I prefer to focus more on StarCraft the game or details about actual features on the Spawning Tool site, but I felt that was technically interesting but also accessible for non-coders. But whether you enjoyed it or didn’t, I hope you Protoss players out there take a shot at the Chrono Boosted build orders in real-time!

-StoicLoofah

 Loading ...