Help:Reading Build Orders

From Liquipedia StarCraft Brood War Wiki

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.

Definitions[edit]

Every Build Order article will contain a box or a list of actions he has to perform depending on either events occuring 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 independend from technology issues and can easily be adapated to overall game flow. For example, minute marks might change if the game lags or a different game speed than fastest is used; 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 cheat.

Supply Notations[edit]

"Examplary Build Order, Supply" Help icon.png
Picon.png
  • 8/9 - Pylon
  • 10/17 - Gateway

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 workers only (SCVs, Probes, Drones), but also with constantly producing fighting units. However, it should be noted that especially Zerg has to be careful when to stop Drone production, following the Zerg Economic Guidelines.

Event Notations[edit]

The second way to describe a time in the game at which a certain action has to be performed are events. Events are always noted in relation to the game flow.


"Examplary Build Order, Events 1" Help icon.png
Zicon.png
  • 11/18 - Hatchery
  • @ 100 Gas - Lair

In the examplary 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.


"Examplary Build Order, Events 2" Help icon.png
Zicon.png
  • @ 50% Lair - Hydra Den

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 half way done. Furthermore, he has to save up enough Minerals and Vespine 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 prinicple 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.


"Examplary Build Order, Events 3" Help icon.png
Picon.png
  • 8/9 - Pylon
  • 10/17 - Gateway
  • Send Scouting Probe

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 match up procedures and should be followed closely.

Assumptions[edit]

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 a 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)


Advanced Understanding[edit]

Any beginner must realize that Build Orders, especially the Build Order List/Box, are mere instructions. They are written down to help to memorize a simple list, which could be compared to 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[edit]

A universal Build Order able to counter or to describe all possibile 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 and 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 less opportunities to train all mechanics needed to effectively control his units or to manage a bigger base.

Analysing[edit]

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 analysed. However, especially beginners tend to make mistakes.

As explaind in the paragraphs before, no Build Order is invicible. 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 made first mistakes. Comparing the own game to an absolute standard is good way to create a contrast.

Adapting[edit]

Any Build Order needs to be adapted. Often times a beginner will face aggressive openings or will face a player who makes up build orders. Regardless of which of both scenarios hold true, 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 Match Up a player has certain attack frames. A Terran will have two time zones after Fast Expanding against a Zerg, in which he is most likely to deal an optimal amount of damage. In the first, the Zerg will switch from Mutalisk harass to Lurkers, but won't be able to fully stop a Marine&Medic Push. In the later stages, Terran has Vessel and Tank support, which can counter Lurkers in the time shortly before the Zerg obtains Defilers and Dark Swarm. If a Terran is denied to use 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, both players will most likely not have to adapt a lot if they want to follow their respective Build Orders. Only in scenarios two players face each other with radically different Build Orders, they will have to change their plan on a more global level. Each player's goal in this scenario would be to completly 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 is able to defend the rush without suffering huge economic damage, he will come out on top, hence cancelling 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 the most popular maps such as Python or Fighting Spirit. However, usually new maps are introduced, for which the Build Orders could not work anymore. 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.