[jonbaer]

I would like to find books which pertain to just this problem alone (build order planning) ...

"Another sub-problem of the wider StarCraft (Blizzard Entertainment, 1998) playing problem is build order planning. The problem here is in which order to build certain improvements to the player’s base and in which order to research certain technology, a complex planning problem at a considerably higher level of abstraction than micro-battles. Here, Weber et al have data-mined logs of existing StarCraft (Blizzard Entertainment, 1998) matches to find successful build orders that can be applied in games played by agents."

[mysterydip]

I wonder if Goal-Oriented Action Planning would be a fit here: http://alumni.media.mit.edu/~jorkin/goap.html

Ultimate goal being to destroy the opponent, different build orders meet that goal, scouting could show which direction the opponent is moving, and action plan adjusted to counter or take advantage of a weakness.

[dgant]

How to efficiently achieve build goals is itself a mostly solved problem. See BOSS by Dave Churchill.

The catch is that "can I build this without dying in the process" is an almost completely unsolved problem. Even "can my opponent just kill me now" is currently only solved by fairly crude approximation. Without being able to evaluate that statically we're nowhere near evaluating it over the course of a build order, accounting for incomplete information and multiple possible responses.

In general, Starcraft is tricky because very small differences in unrelated concerns can cause wild swings in expected outcome. Compare a Terran wall-in that blocks zealots vs. one with a zealot-sized gap. A few pixels of space -- a pathfinding concern -- radically impacts build order concerns.

Come check out the current state-of-the-art (and lots of earlier stage work as well) at http://twitch.tv/sscait

[yorwba]

I think the literature on instruction scheduling might also be relevant for build order planning. You have a set of things to build (= instructions to execute) in the shortest amount of time, using the available production facilities (= execution units). Except in most games you can build additional factories, which doesn't really have an equivalent in CPUs.

[philipov]

> which doesn't really have an equivalent in CPUs.

But it does have an equivalent in scalable cloud infrastructure, where you can literally download more RAM, cores, etc.

[thomasmarcelis]

An additional difficulty is that the fastest way to achieve a build/goal often means you are weak/exposed at crucial moments in the game

[posterboy]

> in most games you can build additional factories

You can't just buy addition execution units? Sure there are limiting factors - in games as well.

[yorwba]

Which scheduler automatically inserts instructions to add more ALUs to its CPU? ;)

[posterboy]

Well, I did take a step back from the instruction pipeline analogy, but it's still covered by operations research and mathematical optimization.

The cost of waking a sleeping CPU core is perhaps comparable to the cost of building a factory in-game. Whereas, building a ton of factories that can't be saturated by the incoming cash money is comparable to building a superscalar processor architecture that can't be saturated by the cache memory.

[jbpetersen]

Now you've got me curious how much people have experimented with making AIs play "incremental" games where there's literally nothing but build order planning.