Build Orders

[aubergine]

Aha, I've also used DEVONthink, but after a while I felt that wasn't the right sort of tool for me. Currently I use tools like Flying Logic Pro and Curio.

Anyway, if migration of existing content is required then it's pretty much a copy and paste task between the two wikis, although someone who knows the content in the trac wiki would have to identify what needs transferring and also what sort of spaces there should be on new wiki.

I wouldn't want to head down that path unless everyone agrees it's the right approach though - when I started that wiki it was mainly so I could store notes on my EggPlant AI and document some of the libraries I'm making for it, because I have a brain like a sieve (or put another way, I'm like Dory from the film "Finding Nemo"). But the wiki just sort of kept growing, especially when I decided to collate all the things I was learning about the JS API. If it keeps growing and gaining other projects, that would be awesome, but I don't want to step on anyones toes.

[Rman Virgil]

Aha, I've also used DEVONthink, but after a while I felt that wasn't the right sort of tool for me. Currently I use tools like Flying Logic Pro and Curio.

Not familiar with 'em. Will definitely check them out. Thanks for the heads-up.

Anyway, if migration of existing content is required then it's pretty much a copy and paste task between the two wikis, although someone who knows the content in the trac wiki would have to identify what needs transferring and also what sort of spaces there should be on new wiki.

Yup on both counts.

I wouldn't want to head down that path unless everyone agrees it's the right approach though - when I started that wiki it was mainly so I could store notes on my EggPlant AI and document some of the libraries I'm making for it, because I have a brain like a sieve (or put another way, I'm like Dory from the film "Finding Nemo").

Agree about consensus. But I don't have the foggiest notion of exactly how such a decision-making mechanism would be set in motion here.

Dory...Lol. With me it is because I am on the cusp of entering the official senility years. Coyote always talked about himself being a old coot but I used to say - hey dude, don't forget, you're my junior!

But the wiki just sort of kept growing, especially when I decided to collate all the things I was learning about the JS API. If it keeps growing and gaining other projects, that would be awesome, but I don't want to step on anyones toes.

I hear ya.

.

[Nameless]

We'd still need a short notation to explain build orders precisely, like "8 pylon, 10 gateway" ...

Ahh.. but I've already settled on a build notation similar to the likes of the build order section as found in; http://wiki.teamliquid.net/starcraft/1_ ... s._Terran).

---

As for the 'fragmentation problem'; I have to agree, fragmentation of such a degree can be a project killer. Which is why I'd like to simply release the information as a PDF / raw text files / <markup> formatted text files, (which what I'm doing for the StarCraft Build Order PDF that I'm currently writing). In the short term this method I think, would allow a safe medium from which the developed content could be ported other areas. As for the long-term; I.D.K.

[aubergine]

What about something more basic like:

Factory → Research → Research → Factory → HQ → Power gen

[NoQ]

What about something more basic like:

Factory → Research → Research → Factory → HQ → Power gen

Let's think. First, you can't produce tanks until you get a CC. Which makes it as slow as RFFRC against rush. The difference with RFFRC is that you make the first truck 30 seconds earlier, but start your research 30 seconds later. But at the end, you will have the same amount of trucks and research points.

To survive against rush, halftracks seems to be the only way (cause you won't go ahead in machinegun research anyway, for it only takes a single lab to do it, so any rusher will just max it), and RFFRC allows you to invent them right when they are necessary to save you against an overwhelming number of wheels (on a maps of the size of Startup). But you delay them by 30 seconds (enemy tanks cover 1/3 of the distance between bases on Startup during this time), which may be fatal. On the other hand, your early truck won't help you to stand against a rush, cause middle oils will be wiped anyway.

The order you are proposing will be thus highly unrecommended on short maps like Startup, but it might be a nice alternative to RFFRC on maps like this, that are a bit too large for rushing, but require taking faraway backward diagonal oils quickly.

I'd need to to have a look in-game, of course. It might be also interesting to use the first (or the second) truck to help building the base.

[aubergine]

I was just using that as an example of notation for a build order (ie. how to convey a build order), not an actual recommended build order

[NoQ]

[Nameless]

What about something more basic like:

Factory → Research → Research → Factory → HQ → Power gen

The same build presuming that both trucks build the same buildings.

Code: Select all

2/2 - Factory
2/2 - Research Building
2/2 - Research Building
2/2 - Factory
2/2 - HQ
2/2 - Power Gen

-OR-

Code: Select all

2 - Factory
2 - Research Building
2 - Research Building
2 - Factory
2 - HQ
2 - Power Gen

Just sayin'.. although the notation for build's encompassing multiple construction actions AND production of units is still up in the air.

[aubergine]

What do the 2's mean?

As for what units to make where, maybe a table layout would be better (easy to do in a wiki)

[NoQ]

multiple construction actions

They are never useful, apart from capturing oil derricks. You'd always rather complete one thing and then complete the other than complete both of them at the end of the same time interval.

[Nameless]

What do the 2's mean?

As for what units to make where, maybe a table layout would be better (easy to do in a wiki)

Just 2 variations on indicating the number of units available to the player. Personally, I prefer the single 2 notation because (to me at least) 2/2 suggests a psi requirement that WZ doesn't have.

multiple construction actions

They are never useful, apart from capturing oil derricks. You'd always rather complete one thing and then complete the other than complete both of them at the end of the same time interval.

True, but I'd rather leave the option open for those who'd like to develop such builds that require such a thing.

[NoQ]

Code: Select all

2 - factory → 2 trucks
2 - lab → twin machinegun
2 - command | 1 - derricks
2 - factory | 2 - derricks
2 - factory | 2 - derricks
2 - generator | 2 - derricks

The arrow explains the purpose of the thing on the left of it, so the first truck will only come out and start taking derricks at the moment lab is finished and command is started.

Code: Select all

2 - lab → halftracks, power module
2 - factory → 3 trucks
2 - factory → 2 trucks
2 - lab → heavy machinegun | 1 - derricks
2 - command | 3 - derricks
3 - generator | 4 - derricks

[Nameless]

Another issue I see with notations is the issue of indicating expansions or other long-term actions. In the StarCraft world, it's understood that when a step involves expansion or other long term action; its understood that you can move onto the next step if the build allows it. Hence;

Code: Select all

2 - lab  - halftracks
2 - factory - 3 trucks
2 - factory - 2 trucks
2 - lab - heavy machinegun 
2 - hypothetical Term
2 - command
2 - hypothetical Term
4 - generator
4 - hypothetical Term
5 - factory - Machingun Viper Wheels
8 - some other command down the line

"hypothetical Term" would be the side note that tells what the action involves, and this style would remove the ambiguity of the whole pipe or arrow usage

[aubergine]

Ok, so the number is the number of trucks assigned to build something? And the pipe | is indicating a sort of branch where you start constructing two things at once?

[Nameless]

The number indicates the total number of units available to the player regardless of the unit type at that point in time. Ultimately the number is tentatively.. numbered because it's used at the best estimate of production times or build order.

As for the pipe? I believe so.