The newest iteration in my StarCraft II Build Order Calculator is a minimalistic approach, in comparison to the previous builds. Unlike the last few ambitious builds that attempted time and resource calculation, this is an attempt at the absolute basics. It is also my first build calculator that is somewhat usable right at the moment, as opposed to merely offering a glimpse at where I want to go with this system.

This calculator contains all units for all 3 races and allows for race changing and resetting the build. It also begins to toy with styles and the UI, although I didn’t spend much time other than getting elements in the rough position that I would like them to be.

I dropped back to a more minimal approach because I felt like the more advanced approaches I was working on were going in the wrong direction. I’d ultimately like a more advanced system, but I want to rewind a bit and go back to basics and consider alternative approaches to the other systems, that relied heavily on large data structures to store data, at times storing it repeatedly for different purposes.

I completed the third JavaScript iteration of the StarCraft II Build Order Calculator this morning and put it online. It took a few days longer than I expected, but I also drastically changed how the data is being stored for the build order. In my previous builds, I stored the data with the time as the lowest level element, whereas this build stores the unit as the lowest level element. This makes it easier to see what the unit is doing (and thus, what it is allowed to do), but makes it harder to display the timeline.

I also stored unit actions (such as build Probe, warp in Pylon, etc.) as functions within each unit. As I wrote the functions, it quickly became apparent that a huge number of functions are identical and should only be written in one place.

This build shows me the viability of storing unit actions within the function and keeping track of unit timelines within the unit, but also shows the weaknesses of displaying the timeline when I have to scan every unit for every second to see what has been done. It still does not take into account that you need a Gateway before you can make a Zealot, but I chose to not pursue that in this build when all of the flaws of this build became apparent. It does, however, take into account queuing and will not let you build more than 1 Probe from a Nexus at any one time.

I will begin my next iteration very soon and hope to have that online within the next few days. Each iteration definitely teaches me a lot about what will and will not work. I am still very far from a final build, but I still think it is possible to get the final build online before the game launches on Jul 27, 2010.