Build Orders

[dak180]

It could be quickly drafted out in the wiki then once it's in a good state pasted in to the existing guide?

I wonder if the markup language used is the same.

The guide uses straight html.

[NoQ]

The easiest way to measure time is in 30-second ticks. It takes approximately 30 seconds for two trucks to build factory, lab, command, generator, for a factory to produce a truck or a mg viper wheels tank.

[aubergine]

I had a go at creating a graphical representation:



I don't think it's very clear though, particularly with respect to what the trucks are doing. I guess the research could be simplified down to just some key tech targets (eg. just twin mg shown, without the prerequisite mg techs). But not sure how to clearly convey what's happening with trucks.

[aubergine]

Simplified diagram + dashed arrow to represent "hypothetical term":



Changing diagram orientation and adding initial MG research step - - -> twin MG:

[Rman Virgil]

.

Quick aside on org tools...

@ aubergine: Checked out Flying Logic & Curio... very nice tools / apps. When I need that mode over DevonThink I use Personal Brain.

.

[Nameless]

The diagramming is a great idea despite the obvious limitations. The one thing I wonder is; for those who like timings, how would one incorporate the passage of time using that particular method? So far I've run into the same issues as you did.

.

Quick aside on org tools...

@ aubergine: Checked out Flying Logic & Curio... very nice tools / apps. When I need that mode over DevonThink I use Personal Brain.

.

Another mindmap tool available is Freemind. Which is what I'm using to diagram the above builds.

[aubergine]

I like Personal Brain's ability to publish to the web, for example I've been finding this brain very compelling since Rman Virgill posted a link to the bain site:

http://webbrain.com/brainpage/brain/d36 ... 955E68D9E8

However, not ideal for the task at hand.

I too was thinking about timings and how to incorporate them visually. It could possibly be achieved by time bars - so one horizontal time bar for the main base build, and then vertical timebars for the offshoots (eg. research, new trucks going off to build oils, etc).

But I cut myself short because I felt it was perhaps too much information. Build orders are great in that they open people's minds to different approaches at the start of the game. But I feel that making it too detailed is going to detract from their learning experience - in other words, it could make everything too mechanical and while initially giving good results would have bad long term effects in terms of player attrition rates.

Part of what kept me playing Warzone, and coming back to it over and over, is that I had to learn so much, and only then did I realise that I was barely scratching the tip of the iceberg. Through a process of trial and error, and getting more engaged with the community (albeit on a basic level mostly through these forums and scripting, rather than MP / IRC) I'm constantly increasing my knowledge of the game. And it's this effort and struggle I've put in that makes me want to commit to the game more, rather than become indifferent about it and defect to some other game.

EDIT: So in the following diagram:



I took minimalist approach - just enough to give the person the general order of actions to take, but with some uncertainty that they have to go and try things out for themselves and learn what works best for them.

I'd want build order guide to encourage participation from people reading it, as that will draw out much more tacit knowledge than any diagram or tabluar representation could.

[Nameless]

I agree that the whole timing thing is a bit overkill and I think in terms of diagramming the build, the minimalist approach would work the best provided that it's also accompanied with any notes that clarifies any ambiguities.

As a side note; StarCraft builds usually don't have any time indication other than "you should be at this point if/when this happens or the game is at this point."

[aubergine]

I guess alongside the build orders there needs to be a tutorial about queueing stuff and just generally getting stuff done faster.

I imagine that many players don't know how to queue build orders, and in particular may not realise that for a given droid you can mix both building and moving in the droid's queue; or that you can queue different types of building; or that you can extend an existing queue to add more things to it.

So, for example, when I have a truck building an oil resource, I have it queued to move to near where another oil resources is after it's built the current one - this way if I'm distracted doing something else, I hear the "oil resource" voice and know one of my trucks is about to become idle near a new oil resource that I can build on.

Some video tutorials showing these things in action, along with some notes explaining the importance of them, will help improve people's game a whole lot I would think (it certainly made me a lot better at the start of the game).

[Nameless]

Not just tutorials, how about a database instead?!

The database would contain such things as build orders, terms, definitions, common procedures/actions, general strategies, tips & tricks. Just snoop around http://wiki.teamliquid.net/starcraft/Main_Page, http://wiki.teamliquid.net/starcraft/Strategy and see what kind of trouble you can get into.

Incidentally, liquipedia is the main source from which I'll be adapting/converting builds to something more WZ-esque (as a start), along with any terms, definitions, and techniques that can be used in WZ.

[aubergine]

When you say database, do you mean that they are normal wiki pages but you can show lists of them in different ways (eg. lists of pages with specific label, etc)? If so the wiki I have does a load of stuff like that.

For example Droid object -- The lists of pages in the "order" and "droidType" rows of properties table are pulled directly from sections of Constants

[Rman Virgil]

.

"Freemind" is a good prog. I used it a few years ago when I was working on deving a new Strat Game using the Torque Engine & Torque Script (which is how I understand Emdek's vision for WZ vis-a-vis Mutators etc.). We used it to represent Tech Tree relationships and the design of RPS balance.

WZ MP was been played in earnest since 1999 and there have been BO strats around since - going on 13 years worth. Yet it's been almost exclusively word of mouth. Why has so little been published in all those years? Has everyone involved been too lazy to put something together on BOs for publication throughout all those years?

The answer involves a couple of distinct components.

I will only touch on one for now & it was just identified by aubergine: enough details to encourage learning and participation but not so much as to eliminate uncertainty altogether resulting in a boring roteness and predictability. Not publishing was the short term and short-sighted response to cultivating that type uncertainty.

This type of uncertainty is subtle and nuanced - challenging to work out the best balance but, nonetheless, a very important design guideline to counter boredom; one that dovetails with proposed Commander dev which inturn has a direct relationship to BO based strats. But that particular meta discussion is for another occassion down the road and I do not want to distract from what you are focused on doing here.

This is a very worthwhile project, long over-due and you are proceeding cogently and robustly. I am sure it will turn-out well indeed and fill a critical need that will help grow the games fan base in a substantive way. Props.

- Regards, RV

.

[cybersphinx]

I guess alongside the build orders there needs to be a tutorial about queueing stuff and just generally getting stuff done faster.

One of my longer term plans was to add more useful things to the in-game tutorial (or make a new one), after porting it to javascript.

[NoQ]

I guess alongside the build orders there needs to be a tutorial about queueing stuff and just generally getting stuff done faster.

One of my longer term plans was to add more useful things to the in-game tutorial (or make a new one), after porting it to javascript.

One of my plans on NullBot is to make a "rush tutorial" challenge. It starts on Startup and the scripts inside it give you hints on what to build and how many tanks your opponent (that plays FRCFF perfectly) has managed to build by that time (and how many tanks you managed to build).

[Nameless]

When you say database, do you mean that they are normal wiki pages but you can show lists of them in different ways (eg. lists of pages with specific label, etc)? If so the wiki I have does a load of stuff like that.

I meant a database of information, how it's rendered is still up in the air.

Although a wiki-esque setup is what I'd be gearing for. An extreme long-term goal of mine is to consolidate the resulting information into a PDF or series of PDF's that could be more easily distributed as a 'one-stop source.'

Here's the basic template that I'm using to outline the potential builds;

Code: Select all

{ build name }
Overview
{ Section describing the general aspects of the build, its type, what it's used for, etc. }

Standard Build Order
1. waka
2. waka
3. waka

Alternate Build Order
1. waka
2. waka
3. waka

Transitions
{ Due to the sheer complexity of WZ, the potential for a build to transition into other builds / options is great. This section outlines such options. }

Counters To
{ A list of or descriptions of other builds / techniques that this particular build counters effectively. 'Hard' or 'Soft' being open to interpretation of what the counter is like. }
Hard
Soft

Countered By
{ A list of or descriptions of other builds / techniques that this particular build is vulnerable to. 'Hard' or 'Soft' being open to interpretation of what the counter is like. }
Hard
Soft

Map Control
{ A list of or description of maps that the build is particularly effectively on or weak against. }
Strong Against
Weak Against

Build Mentality
{ The section outlining the philosophy that the build governs, and the section where a more in-depth description and usage of how the build should be used. It basically explains the reasons for why the build is the way it is. }

.
This is a very worthwhile project, long over-due and you are proceeding cogently and robustly. I am sure it will turn-out well indeed and fill a critical need that will help grow the games fan base in a substantive way. Props.

Thanks, I hope so too.