So I started programming a simple Zerg AI in Starcraft. I wanted to start with zergling rush strategy. It turns out that there's many different guides for fastest zergling rush, as well as other fastest builds, such as lurker rush.

I was thinking about this and basically a build order is a little comlicated state space diagram, if you treat time as just another "requirement" for units. So probably that must be a math-based way to prove that one solution is the best.

  • 2
    Sum the build times for each of the units prerequisites, the hard part being determining if you have enough resources at that point in time. Maybe I'm wrong but you'd get a pretty complex formula fairly rapidly. It might be easier to narrow down to a few and test by drawing timelines with resource rate and build times together. – Shelby115 Apr 24 '15 at 20:53
  • @Shelby115 It must be state space search in time, not just simple formula - exactly because resources play a role, as well as build slots. But there are many things that can be simplified or ignored. – Tomáš Zato Apr 24 '15 at 20:58
  • You also have to keep in mind that the fastest build order for a certain unit does not necessarily mean the BEST(smartest) build order. Keep in mind that SC is a resource management game, you have to spend money to make money, so it's easy to build 1 specific unit quickly, but you will leave yourself vulnerable in many other areas. Try to pursue a build order for a GOAL rather than for a UNIT. – RenaissanceProgrammer Apr 24 '15 at 23:10
  • @RenaissanceProgrammer You are totally right but frankly defining goal is beyond any mathematical calculations. And most of fastest build strategies rely on the fact that having certain unit means secured victory. It's more risky of course - it's known that zergling rush is failure if the enemy terran manages to build bunker and 1 marine already. – Tomáš Zato Apr 25 '15 at 13:06
  • @TomášZato yes that's true, and more to your point, it should be possible to create such a formula as long as you focus on resource gathering rate by the second, this way you're formula takes into consideration how many resources the user has now and will have in 1 second, and how many resources it costs to construct the prerequisites to construct a unit as well as the time from those prerequisites. So for the z-ling rush examples: you need to calculate resource gathering rate, account for time needed to get 200, time needed to build Pool,resources available at building completion – RenaissanceProgrammer Apr 27 '15 at 16:26

For a zergling rush specifically:

  • Resources to consider:
    • Minerals
    • Larva
    • Supply
    • Time
  • Influencing factors:
    • Queen (larva inject)
    • Drones (mineral gathering rate)
    • Overlords (add supply cap)
    • Extractor trick (temporarily 'adds' supply cap and lowers mineral rate)

For just a zergling rush, you can limit yourself to considering one of the following choices at each stage:

  • Build a drone
  • Build a spawning pool
  • Build an overlord
  • Build a queen
  • Build a zergling
  • Perform an extractor trick, and build a drone, queen, or zergling
  • Wait until when you are able to perform an above action which you are currently unable to

Obviously you would need to check if you have the prerequisites (other buildings and/or resources) before doing any of the above.

You could certainly brute force it if you so desired. This program doesn't prove or guarantee optimal times, but if you want to see SC2 build order optimization at work, check out these:

If you are looking for a generic way of "proving" a certain build order is best, I think you will find accounting for the diminishing returns of workers, resource exhaustion, expansion, travel times, and other factors will make it a rather herculean task unless you make so many simplifications that "best" becomes largely meaningless.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.