Join

Making Python Bot Build Orders Easier

•

Drekken

Ever tried updating a build order in your bot at 2 AM? It’s not fun. Hardcoding supply counts and unit names quickly clutters your code, and any tweak means digging through lines of logic. That’s where a build runner comes in—a lightweight system that treats your build like a checklist, so you can swap or adjust it without touching the guts of your bot.

In this post, I’ll cover:

  • What build orders are and where to get them
  • How to format them for your bot
  • The basics of writing a build runner

What Are Build Orders?

Build orders are recipes. They tell you what to build and when—usually in terms of supply count, in-game time, and action.

Example:

  • 14 supply / 17 seconds → Build a Supply Depot

Humans rely on these because the first few minutes of a match are fairly static. Optimized builds from pro players squeeze out every edge possible. Later in the game, things get too dynamic to script.

For bots, timing values aren’t as strict. Bots often act faster than humans, so what really matters is:

  • The supply count
  • The action (build this structure, train this unit, etc.)

That’s enough for a build runner to work.

Where to Get Build Orders

You don’t need to reinvent the wheel—pull from the best:

  • Spawning Tool: a database of pro builds (spawningtool.com).
  • YouTube: many pro players (like uThermal, PiG, or Probe) explain their builds in detail. Grab the transcript and extract the steps.

I usually use ChatGPT to convert builds into YAML format. It’s human-readable, bot-friendly, and makes it easy to swap builds without touching the code.

LLM Prompt Sample:

Below is a Build from StarCraft 2, extract the build and place it in a YAML format for my Python sc2 Bot.
Follow the format of my sample. 
---
steps:
  - 14 PYLON
  - 16 GATEWAY
  - 16 GAS
  - 20 NEXUS
  - 20 CYBERNETICSCORE
  - 21 GAS
  - 22 PYLON

A Simple Example

Let’s start small: say you want your bot to build a Pylon, a Gateway, and then a Zealot.

The runner keeps an index of where it is in the build order. Each game loop, it checks:

  • Do I already have this (or have it building)?
  • If not, can I afford it?
  • If yes, build/train it.

When that step’s satisfied, it increments the index and moves on. Once the build order’s done, the runner exits.

It’s just a loop over a to-do list, nothing fancy.

Sample Code

Here’s a simple Python-sc2 build runner implementation:

# hello_runner.py (tested example using python-sc2)
from sc2.bot_ai import BotAI
from sc2.ids.unit_typeid import UnitTypeId as U

class HelloRunner:
    """
    A barebones build runner demonstrating fundamental build order execution.
    Takes a sequential list of units/structures and attempts to build them one by one.
    """
    def __init__(self, bot: BotAI, order):
        self.bot, self.order, self.i = bot, order, 0

    async def run(self):
        if self.i >= len(self.order):
            return
        
        want = self.order[self.i]
        have = self.bot.units(want).amount + self.bot.already_pending(want)
        
        if have == 0:
            # naive: try to build/train exactly one
            if want == U.PYLON and self.bot.can_afford(U.PYLON) and self.bot.workers:
                pos = await self.bot.find_placement(
                    U.PYLON,
                    near=self.bot.townhalls.first.position.towards(self.bot.game_info.map_center, 5)
                )
                if pos:
                    self.bot.workers.closest_to(pos).build(U.PYLON, pos)

            elif want == U.GATEWAY and self.bot.can_afford(U.GATEWAY) and self.bot.workers:
                pos = await self.bot.find_placement(
                    U.GATEWAY,
                    near=self.bot.townhalls.first.position.towards(self.bot.game_info.map_center, 5)
                )
                if pos:
                    self.bot.workers.closest_to(pos).build(U.GATEWAY, pos)

            elif want == U.ZEALOT:
                for g in self.bot.structures(U.GATEWAY).ready.idle:
                    if self.bot.can_afford(U.ZEALOT):
                        g.train(U.ZEALOT)
                        break
        else:
            self.i += 1  # step satisfied

This runner is deliberately naive, but it captures the essence: step through a list, check conditions, then act. Once a step is satisfied, move on.

Standard Builds (YAML‑ready)

Here are some plug a play YAML builds for every race

These cover the most powerful “core before specialization” builds from PiG’s Bronze to GM guide. Copy them straight into your project, or fork and adapt as needed.

Next Steps

From here, you can:

  • Read directly from YAML files (recommended!) so you can swap builds instantly.
  • Add build locations to YAML for precise placements.
  • Handle parallel builds (like training multiple workers while building structures).

This makes your bot’s builds both easier to manage and easier to experiment with.

Wrap-Up

Manually coding builds is a chore. A build runner fixes that by making early-game play plug-and-play. Once you’ve got YAML + a simple runner, testing new builds is as easy as copy-pasting a pro’s recipe.

From here, the fun starts: you can layer on matchup-specific branches, greedy eco openings, or crazy all-ins—all without rewriting your core bot logic.