...continued...
Here is the convention for labeling these types of triggers:
- '~' = Perpetual triggers. These run until constantly until something on the outside turns them off.
- '[ ... ]' = Hyper trigger-timed. These triggers are part of or directly controlled by hyper triggers, and if their conditions are active, will run as fast as the hyper triggers allow them to. Within the braces any combination of other labels can be used, such as the above '~' label.
- '##' = A number, which can have two meanings: if the number is before, say, the '~' label, it specifies how many times that trigger will perpetuate during the time its running. If it is placed after the '~' label, it specifies how long (in hyper trigger 'wait's, if hyper triggers braces are provided, otherwise the units are time between each preserved trigger's default reactivation period) between each activation in the perpetual sequence the trigger will occur. Numbers can exist both before and after a given (approprate) label.
- '? #:#' = A randomized event. The #:# part of the label specifies the chance of this trigger being the one to activate during the randomization (like a 1:8 chance this trigger will activate out of 8 other possible random combinations.) Randomization is a fairly high-level concept involving randomizing switch state(s) and linking together several randomized switches to get a randomized number range, which I will not explain here. PM me if you want to know how this works.
- '|' = A guardian trigger. As described above, this will run only to enforce or prevent something from happening. For example, say you have a location in your map that you don't want any mutalisks to fly into. A guardian trigger would activate whenever "at least 1" mutalisk enters the location, and thus kill it. It is possible if mutalisks are constantly flying into the location that the trigger will stay active constantly, as per each activation period the "at least 1" condition will be reset anew, but unlike the '~' perpetual triggers it will ONLY run as long as the condition is artificially (that is, from an outside source) kept alive, while the guardian triggers themselves constantly seek to clear that condition. The same rules for the '##' label can apply to guardian triggers as they do to perpetuating ('~') ones.
- '_' = As stated above, this would be any triggers that don't have a preserve trigger action, or else activate only once during the session their underlying context is active. Obviously, these cannot be combined with the '[ ... ]' or '~' labels, but they CAN be combined with the '|' guardian trigger label, to indicate the guardian trigger will only activate once per its context.
- '__' = Similar to the above, only more specialized: these triggers will activate only once at the start of their context. For instance, if you have a trigger that will activate at the start of the map to set everyone's default player alliances, you would label it with this.
A blank label can be substituted for triggers with '_|', for simplicity.
[*]
Variable Names: Variables, in the starcraft sense, include any switches, unit death counters, score types, resources, countdown timer seconds, and even quantities of units/types of units within a given map location. Anything that holds a number or value that you can check with a trigger condition is a storage variable. However, only switches and death counters can be custom given names, for which the convention works as follows:
For switches, the name of the context they control or events they activate should be provided in 1-3 words that all fit within the switch list view, and adaquately and
uniquely describe that switch's intended function. Switches can use a similar labeling convention as triggers:
- '~' = Part of a perpetuating event. More than one trigger can use this and stay perpetuated with it, as long as their other conditions permit.
- '? #' = Randomized event switch. Instead of the two #s in the '#:#' label shown above for triggers, the one # is the bit position of the randomized range the current switch is part of, unless it is the only randomized switch used, in which case the # is optional.
- '- ... -' = This indicates the switch will set the ball rolling for an event sequence once set. Pretty basic.
- '< ... >' = This indicates the switch is the owner of its own context. The name between the arrow brackets is all capitalized. A place where this would be used is, say, after the intro splash screen and after all the game settings (player alliances, vision, etc.) have been properly set, and the game is ready to begin. This sets the "game-is-running" context, which can be used by all the game triggers to tell them when they are allowed to begin doing their thing.
A blank label can be used for all else.
[*]
Location Names: Last, but not least (especially if you are using lots of locations), is this convention for naming locations. The main thing to note here is that locations are sorted in alphabetical order in their list, so it is benefitial to group all locations that function in a specific context/area/purpose under their own alphabetically-friendly catagorical label. On a side note, typing the first letter of the catagory within the list view will take you to the first location in the list with that name as its first letter. Anyway, first thing first: the labels:
- '+' = These are mobile locations: ones that will be frequently used for "move location" operations and are generally not expected to stay stationary.
- '|' = These are out-of-the-way locations that are used to contain something not part of the regular game. Things like computer-owned arbiters, for purposes of a recall spell, or nuke silos, for the purpose of building nukes for casting in a cutscene, for instance.
- '##' = A numbered label, usually placed after the context name portion of the label. If there are several like locations of the same context/area/purpose that are positioned differently or are used as part of a sequence, then this identifies the position in that sequence or its place among their peers.
Here is a sample location name, using the alphabetically-friendly context name first, the number position second, and the function/location descriptor last:
And so, that's that. I devised this system way back before I started my Starcraft TV, and refined it since, and finally actually took the time to write it down formally so I can share it with the world. I'll probably refine it further still, but for my purposes this about covers everything I usually do with my triggers, and once you get used to using it, can make things tremendously more organized and readable, especially in large mapping projects.
So, if you actually read through that
, what are your thoughts?
