Help:Reading Build Orders
A build order is a specific series of steps that one takes in the early game to achieve a specific strategy. By using a well-defined build order with every game, a player is able to perform a solid opening which is time-tested and approved. All build orders dictate which actions to perform based upon supply and events.
This article aims to provide a beginner with the knowledge required to fully understand the abstract concept of build orders in a way he can fully realize strategies in game.
Every Build Order article will contain a box or a list of actions the player has to perform depending on either events occurring during the game or if a specified supply limit is hit. The actions are always written on the right side of the box, while the supply count/events are written on the left side. The build order starts on top and ends on the bottom.
Events or Supply Counts are used instead of time units (seconds, minutes), since they're independent from technology issues and can easily be adapted to overall game flow. For example, minute marks might change if the game lags or a game speed other than fastest is used, but supply counts and events would still hold true. Furthermore, most competitive leagues and ladders forbid the use of an in-game time plug-in and consider such an add-on as cheating.
|"Exemplary Build Order, Supply"|
The table above displays an excerpt of a standard Build Order for Protoss. In this example "8/9 - Pylon" tells a player that he has to build a Pylon when he hits 8 out of 9 Supply and the required amount of minerals (100).
A Protoss player starts with only 4/9 supply. If nothing else is noted in between two Supply marks - in this case 4/9 (Player spawns) and 8/9 (Player has to build a Pylon) - the player should build Probes and send them to mine. This is done to avoid adding redundant information.
In later stages of the game, any player should not only fill the gaps in the notation with worker production (SCVs, Probes, Drones), but also with constant production of fighting units. However, it should be noted that Zerg in particular has to be careful about when to stop Drone production, following the Zerg Economic Guidelines.
The second way to describe a time in the game at which a certain action has to be performed is with events. Events are always noted in relation to the game flow.
|"Exemplary Build Order, Events 1"|
In the exemplary table above an ordinary event is listed. The player is told to morph one of his Hatcheries into a Lair when he has one hundred gas (@ 100 Gas) and after he built his second Hatchery.
|"Exemplary Build Order, Events 2"|
The line "@ 50% Lair - Hydra Den" is a bit difficult for beginners to perform and to understand. First off, the player has to closely observe the progression of the Lair upgrade, so he knows when the progress bar is about halfway done. Furthermore, he has to save up enough Minerals and Vespene Gas to build the Den. However, if the instruction is followed closely, both Lair and Den will finish at the same time, thus enabling the player to upgrade Lurker Aspect without further delay.
Event Notations often follow this underlying principle of knowledge, which isn't noted elsewhere in the build order to save space. As a result, a player often has to think through why an Event Notation has to happen at this exact timing. However, since these special Event Notations often combine complex thoughts and experiments, the more crucial ones are often explained in the context of strategy articles.
|"Exemplary Build Order, Events 3"|
This last example shows when a Protoss has to send out a Probe to scout (gather information). This kind of information is often left out or explained outside of the Build Order Box in a special paragraph. However, if an Event Notation suggests to handle a unit in a special way (in this example to Scout), it means the Build Order slightly varies from overall matchup procedures and should be followed closely.
To leave out redundant information and to not repeat general knowledge, some actions are left out in Build Orders:
- Generally speaking, Terran and Protoss will produce workers over the entire game. Zerg players balance out their Drone-to-Hatchery Ratio according to Zerg Economic Guidelines
- If Terran or Protoss is told to build a Nexus or Command Center, respectively, it is assumed they build it on expansion spots
- Whenever a Nexus or Command Center is completed, Workers have to be sent to mine there immediately without further instructions
- Unless specified otherwise, the time of when an attack has to performed is left to the player
- Unless specified otherwise, a Protoss scouts after building his first Pylon, a Terran after building his first Supply Depot, a Zerg with his first two Overlords and one of his first three Drones after building the second Overlord (10-12 Supply)
Any beginner must realize that Build Orders, especially the Build Order List/Box, are mere instructions. They are written down to help memorize a simple list, which could be compared to using a recipe to cook a certain dish. However, the entire Build Order must always be adapted to the overall game flow and a number of different factors. The most important ones are usually described in the Build Order articles; others, especially subjective ones, depend on the skill of each individual. It's trivial that almost any player might be able to perform a 5 Pool Build order, but almost nobody can play a difficult strategy involving a Corsair/Reaver combination.
Build Orders of Choice
A universal Build Order able to counter or to describe all possible outcomes does not exist. A general rule of thumb states that a beginner should focus on the more macro-oriented build orders. These usually dictate the game to the latest stages, most times describing actions up to the 150 supply mark. The longer a list is, the more possible scenarios can be handled. At the same time, a beginner needs less time to think about what to build next and can focus on performing the actual tasks without any kind of distraction.
Build Orders dictating rushes or exotic play can be viable and more fun to execute, but will make the learning process harder at times. Games end sooner and a beginner has fewer opportunities to train all mechanics needed to effectively control his units or to manage a bigger base.
A Build Order has to be learned and it will take more than a dozen games until a beginner (or an experienced player) is able to fully understand it. It is recommended that every replay of a game using a specific Build Order is analyzed. However, especially beginners tend to make mistakes.
As explained above, no Build Order is invincible. In some cases a Build Order can be followed perfectly, but will still be countered by the opponent. While it's easy to recognize why an exotic Build Order failed, some of the more complex Build Orders might be harder to grasp. It might help to understand a Build Order by comparing it to the ones listed in the "Weak/Hard Counter" sections. This way, the full picture is easier to see.
Following the logic of gathering as much information as possible, a player should also try to find VODs or Replays of a Build Order on different maps performed by good players. With that help he might be able to reconstruct the exact time when he first made a mistake. Comparing one's own game to an absolute standard is good way to see a contrast.
Any Build Order needs to be adapted. Oftentimes a beginner will face an aggressive opening or an opponent who makes up a build order. In either case, the original game plan must be adapted. The more complex Build Orders usually suggest how to react. However, if there are no suggestions, the player should realize he has to change the plan on his own.
For this, some of the following advice is generally true:
- Time windows for attacks
Depending on the Matchup a player has certain attack frames. A Terran will have two time windows after Fast Expanding against a Zerg during which he is most likely to deal an optimal amount of damage. The first is while the Zerg is switching from Mutalisk harass to Lurkers, as he won't be able to fully stop a Marine&Medic Push. Later in the game, Terran has Vessel and Tank support, which counter Lurkers until the Zerg gets Defilers with Dark Swarm. If a Terran is denied his first time window, he should try to realize his second window.
- Weakness of the opponent's Build Order
If two players use complex and macro-oriented builds, neither will have to adapt their Build Orders much. Only when two players face each other with radically different Build Orders will they have to change their plan more drastically. Each player's goal in this scenario would be to completely exploit the opponent's weakness. An example would be a fast expanding player meeting a player going for a 5 Pool Speed. If the fast expanding player defends the rush without suffering huge economic damage, he will come out on top—therefore, canceling the Fast Expansion altogether is an understandable reaction, despite the Build Order telling otherwise. This example is one of the most radical ones. Please note that the same might hold true for a Fast Expanding player meeting an aggressive player who isn't aiming for an all-in. The same idea holds true nonetheless.
- Map Specifics
Most of the Build Orders are designed to work on popular maps such as Python or Fighting Spirit. However, when new maps are introduced, the Build Orders may not work as well on them. The same holds true if a player uses any kind of exotic or outdated map. Especially on two-player maps, it might be sensible to use different scout timings to find out about hard all-ins early on.