Far Gate Campaign Editor Tutorial
By Louis S Carrozzi, Mission Designer - Far Gate
Super X Studios - Seattle, WA, USA
Section 4: Advanced Trigger Editing and Multiplayer Mission Scripting
IMPORTANT NOTE: If you have NOT completed the previous Mission Tutorial Sections (Sections 1-3) it is STRONGLY recommended that you do so before diving into this section.
If you're a PC computer guru, or a "hard core gamer" who is familiar with scripting missions, OR you have fully completed the previous tutorial, then none of this should be
You are the best judge about what you can handle, but I thought I'd warn you up front.
Having said all that, let's get cooking!
Now that you are familliar with how to set up a basic single player mission some basic triggers, its time to get into the "meat and potatoes" of the editor.
This section will be divided into 3 sub-sections:
Section 4A will cover the Far Gate Triggers Architecture in detail.
Section 4B will cover Trigger Conditons and Actions in detail.
Section 4C will cover the specifcs of Multiplayer Mission Settings and cover some basic concepts of creating Multiplayer missions and scripts with the Far Gate mission editor.
SECTION 4A: Far Gate Trigger Architecture
There are a few definitions that will need to be clarified to understand how the Far Gate Trigger Architecture is set up:
TRIGGER: A trigger is defined as 3 part system of logic used to execute actions in the game. It is composed of a "name" which identifies each trigger as a unique piece of logic, and at least 1 "condition", and 1 or more "actions".
CONDITION: A condition is just that: Its a conditon that must be met in order for a TRIGGER to execute.
ACTION: An action is something that a TRIGGER does when its CONDITION(s) are met.
TOP LEVEL TRIGGER: Any TRIGGER which is displayed on the far left of the trigger editor window.
CHILD TRIGGER: Any TRIGGER which is listed underneath and to the right of a Top Level trigger in the same trigger chain.
TRIGGER CHAIN: A series of triggers composed of one Top Level Trigger and descending through 1 or more Child Triggers.
Here's a picture which should better illustrate how Trigger Chains are set up in Far Gate:
SOME MORE TRIGGER CONCEPTS:
- A trigger "chain" can be thought of as a series of steps (triggers) that must be executed, in order, reading from left to right starting with a "Top Level" trigger and cascading down through one or more "Child" triggers.
- There are only 2 kinds of Triggers: Top Level and Child.
- A "Parent" trigger is defined as any trigger (child or top level) that is above and to the left of a child trigger in the same trigger chain.
- Each and every trigger chain MUST have a "Top Level" trigger which executes the instant it is "Enabled".
- Some top level triggers are "Initially Enabled" which means that the Top Level trigger will be enabled the instant the mission is started.
- Other Top Level triggers are NOT initially enabled, and these will get enabled later in tne mission via an "Flow: Enable Trigger" action executed from another trigger (Top Level or Child).
- You can see here that a typical mission can have multiple trigger chains. This screenshot is taken from Mission 1 of the Single Player Game:
Also note that any given "parent" trigger can have multiple children on the same horizontial level. This is how you can create "IF-Then-Else" loops in a particular trigger chain. You read a "trigger chain" from top to bottom, then left to right.
Here is an example of an "If-then-else" loop:
In this example, trigger#1 executes first, lets say for example that it has a 0 second timer condition, so it executes immediately, and since it has no action to carry out, the chain then executes trigger#2.
When trigger#2 executes, it checks to see if a particular cruiser has been destroyed. If "none of" that cruiser is destroyed, in other words if that specific crusier is NOT destroyed, then the trigger goes back and executes trigger#1 again via the "Flow: Goto Trigger" action which points to trigger#1.
This loop executes continuously since we have a set a 0 second timer on trigger#1. If we changed the timer on trigger#1 to 10 seconds, then the loop would execute only once every 10 seconds.
Once that cruiser is destroyed, then the condtion for trigger#2 is NOT satisfied, and then it gets skipped, and because it gets skipped, trigger#3 then executes, because it the next highest trigger in the chain. and is on the same level (horizontally) as trigger#2.
You can have more than 2 child triggers under one parent, but you will rarely need such a set up. (we only used that once in the entire single player game, in mission 1) so you will not likely need such a set up at all, but this setup is perfectly acceptable:
I have no idea what kind of scenario you'd ever use this for, but it is possible to do so its worth pointing out...you may come up with a scenario where you can utilize this feature.
The last item I'll cover here is the conditonal logic slot, and what the different settings mean. This is the conditonal setting slot:
The conditonal settings are: "ANY OF", "ALL OF", "ALL AT THE SAME TIME", "NONE OF", and "ANY OF NOT". Here's what they mean:
ANY OF: This setting means that if ANY OF the conditions are met, then the action(s) for the trigger will execute.
ALL OF: This setting means that ALL OF the condtions must be met in order for the trigger to execute its action(s). The conditons can be met in any order, regardless of time. Once ALL OF the condtions have been met, then the action(s) execute.
ALL AT THE SAME TIME: This is the same as ALL OF, except that the conditons must all be met AT THE SAME TIME. If the conditons are not all met at the same time, then this will NOT execute the action(s) of the trigger. You will most often use the ALL OF setting instead, but there are certain specific instances where an ALL OF may not do the trick in which case you can use this setting.
NONE OF: This setting means that the trigger will execute when NONE OF the condtions are met. This is especially useful for creating range triggers for detecting if a certain unit type, such as hub, exists for a particular player, and if not, then failing the mission. For example, if you created a trigger that checks to see if either a Station Hub or a Prefab-kit exists (is within 9999 units from the sun) via two "range" condtions, then when NONE OF those two conditons are true, that player can't possibly build any more units, and you could use that fact to execute a child trigger and fail the mission.
ANY OF NOT: This setting is the reverse of the ANY OF condtional setting. If any of the condtions are NOT met, then the action(s) for the trigger will execute.
Final NOTE on Triggers: After doing 17 single player missions, and making every type of mistake with this editor, we highly recommend that you NAME each of your triggers something that makes sense to you, or describes what the trigger does.
It may sound like a lot of extra work to do so, but it will make your life much easier when you try and track down mission logic bugs and you have to sift through 20 or more trigger chains and possibly hundreds of child triggers looking for "that missing action" that isn't executing like it should. 'Nuff said.
That's basically it for the trigger architecture. Once you understand how its set up, its actually fairly intuitive and it is very logical. James set up the architecture to be highly flexible, and as a result its also very powerful. The downside is that its also easy to create logic bugs, so we're working to correct that problem with a visual debugger in future versions of the editor.
In the next section we'll discuss the specific condtions and actions you can use (currently) and give examples for each.
SECTION 4B: Trigger Conditons and Actions - In Detail
In this section, we'll discuss the specifics of all of the conditions and actions available in the shipping version of Far Gate, and I'll give examples and tips for using each.
SECTION 4B-1: CONDITIONS
Here's a complete breakdown of all of the possible condtions that can be used in conjunction with conditional settings (discussed in Section 4A) and what they do:
The CONDITIONS currently available are:
All units destroyed, Always, Destroyed, Detected, Range, Range (type), Spacebar, Timer, UI event, Variable comparison, Wormhole entered (type).
Let's take a look at each of these in detail:
ALL UNITS DESTROYED: This conditons checks to see if ALL UNITS of a particular player are destroyed. If they are, then this condtions returns "true". If there are any units remaining of the specified player, then this will not execute. Here's what it looks like:
Simply choose which player you want to check for ALL UNITS DESTROYED. The radio buttons are ignored for this condition, (its a bug that you can choose them...) but you can error on the safe side by selecting "all".
WARNING: Units entering a wormhole are technically "destroyed" when they enter "wormhole transit" so you must be careful to disable an "all units destroyed" trigger if the goal of a mission is to escape via a wormhole. Mission 6 in the single player game is a perfect example of such a scenario. If the player loses all units except the ones that get through the wormhole you could potentially create a scenario where the player "wins" the mission by escaping through the wormhole, but then immediately "fails" the mission when the last unit enters wormhole transit.
ALWAYS: This condition specifies that the trigger ALWAYS executes, and requires NO addtional condtions to execute it. Use this in conjunction with an "ALL OF" conditonal setting, and you are guaranteed that your trigger will execute the instant its enabled. Here's what it looks like:
DESTROYED: This condition is met when one or more units of any player is destroyed. Here's what it looks like:
In this example, I have selected a cruiser in the main editor window and then hit the [Set Objects] button to assign it to this condition. You must currently select your units in the main editor window FIRST and then hit the [Set Objects] button to insert them into the object window. The object window is the white text box with "cruiser (1)" listed in this example.
**SPECIAL NOTE ON "Spawned Units": You can use spawned units (units that show up after the start of the mission) in a trigger like this one, however spawned units usually don't appear in the main editor window at the start of the mission, so you must PLAY the mission until those units physically show up, and then pause the mission, then select the units you want to use in the trigger, and then hit the [Set Objects] button to assign them to a trigger condition or action.
See the "GAME: SPAWN OBJECTS" action in the "Actions" section of this tutorial to find out how to actually spawn objects into a mission and control when and where they arrive from.
The ID's for spawned objects are always set at the beginning of the mission, regardless of when the units actually show up in game time. When you [Reset] a mission after adding your spawned units to a trigger, the spawned units listed in the object window will be listed as "None" in the object list. That's OK.
The ID's of the spawned objects are retained, so this trigger will still work when the spawned units arrive. Once the spawned units show up in your mission, then the "None"s in your list will be replaced with the actual unit names of the spawned units you previously selected to set up your trigger.
Spawned units (explained in detail below) can be used in all condition and action types that invlove "selected units" just like any regular units can be assigned to them. Regular units are units that you place via the [ADD] button to your system and are physically present at the start of a mission. That is, you added them to the system instead of having the computer spawn them.**
DETECTED: This condition is used for "detecting" one or more units by a certain player. In this example, when Player 2 detects the cruiser (1) with any of his/her units, then the condition is satisfied. The rules for this are the same as for "Destroyed" above regarding setting objects and setting spawned objects.
Detection is defined by a unit(s) sensor range. The target unit(s) must be in sensor range of at least 1 of the "player"s units in order for this condition to be satisfied.
RANGE: This condition checks to see if one object is in range of one or more other objects. In this example, when cruiser (1) is within 150 or less units from the Gas Giant_Purple planet, then the condtion is satisfied. You must have the Grid turned on (checked) in the object panel in order to measure distance visually. Each square represents 10 game distance units. This example will trigger when the cruiser is within a 15 square radius of the planet.
The same rules apply for this conditon as for DESTROYED above in regard to spawned units.
RANGE (TYPE): This condition is similar to the RANGE condition, but allows you to specify a type of unit instead of a specifc unit. In this example, if Player 1 has a Station Hub (hub) within 9999 units of the Blue Sun (39) , then this conditon is true, and is met.
The same rules apply for this conditon as for DESTROYED above in regard to spawned units.
This is extremely useful for detecting if a certain type of unit "exists" for a certain player.
Since 9999 is the maximum distance any unit can be from the center of the Far Gate universe, this effectivly checks to see if player 1 has a hub.
This can also be used to see if a player builds a certain type of unit, as well as failing a mission (via some kind of Action) if a player lost all their bases, and no longer has the ability to build etc.
Whether to use RANGE or RANGE (type) totally depends on what you are trying to do.
Important NOTE: When typing in the "Type" of unit, you must use its parenthetical name, spelled exactly like it is show here outlined in green:
SPACEBAR: This condition is met if the user hits the [SPACEBAR] key on their keyboard. It looks like this:
TIMER: This condition is met when the timer has counted off the number of seconds entered. In this example, the conditon is met when 15 seconds of game time have passed.
A timer starts the instant a top level trigger is enabled. For a child trigger, the timer starts once the child trigger's parent trigger has executed. The child will then execute when the timer has finished counting off its number of seconds.
NOTE: If a timer is used in conjunction with another condition, it can effectively act as a "delay" conditon. For example if you have two condtions such as a "destroyed" and a "timer" with an "all of" condtional setting, then the the "destroyed" condtion must be met AND the timer has to have counted off its seconds before the trigger's action will execute. This can be very useful for controlling when events happen in a mission.
UI EVENT: This condition is used for checking to see if a certain type of UI (User Interface) event has occurred. In this example, the condtion will be met when the user hits the [Deploy] button to deploy a Prefab-kit into a Station Hub.
Most of the user interface events listed above are self-explainatory once you are familiar with playing the game, so I won't go into explaining all of them here. Special 1, 2, 3 and 4 were used for the mission tutorials in the game, so you won't find much use for them in custom missions.
VARIABLE COMPARISON: This condtion is used in conjunction with a "FLOW: VARIABLE" action (explained further in the Actions section of this tutorial) and checks the value of a user defined variable.
The condition example below will check to see if the "Planets_Captured" variable is greater than or equal to 4. If Planets_ Caputered is greater than or equal to 4, then this condition is met, and you could use this condtion to trigger a "victory" for the player, for example.
You can also compare the value of two variables by typing the second variable name in the 2nd "Variable" field.
The symbols shown above mean the following:
= is "equal to"
!= is "not equal to"
< is "less than"
> is "greater than"
<= is "less than or equal to"
>= is "greater than or equal to"
A user defined variable in the Far Gate Campaign Editor is simply a memory unit that stores the value of a number.
You can create, set, or manipulate a variable (and give it any name you want) using the "FLOW: VARIABLE" action. Then you can use a VARIABLE COMPARISON conditon (like the example shown above) to check the value of that variable against a number OR compare it to another variable.
To make the above example work, we'd need to have some way to "count" how many planets are "captured" and define how they are "captured".
You could create a simple "capture planet" mechanism for a mission by doing something like this:
First, create a top-level trigger and call it "Set Planets_Caputured Variable". Give this trigger a "timer" condtion set to 0 seconds. Make the action of this trigger be a "FLOW: VARIABLE" action. Have the "FLOW: VARIABLE" action create a user variable called "Planets_Captured", and set the inital value of that variable to 0. It will look like this:
Then, create at least 4 more top-level triggers called something like "captured planet 1" "captured planet 2" etc, 1 of these triggers for each planet in your system.
For our example to work, we also should have at least 4 planets physically in the system, and we need to use these planets in the "capture" triggers, shown above. ( You can cetainly have more than 4 planets in the system if you want...)
In each "Captured Planet" trigger, use a "RANGE (TYPE)" conditon to detect whether a certain type unit of player 1 (for example) gets within a certain radius around each planet.
Use the grid to judge and set the distance you want... and then add 1 to your "Planets_Captured" variable in each of these triggers by using a "FLOW: VARIABLE" action in each of your "Captured Planet" triggers that adds 1 to the "Planets_Captured" variable.
Then, set up 1 child trigger as a child of your "Set Planets_Caputured variable" trigger and use the screenshot example condition:
Your final setup should look something like this:
Each Captured Planet trigger executes once, when a certain unit type of player 1 (for example) get within a 150 unit range of each planet, and adds 1 to the Planets_Captured variable each time a new planet is in range.
I would recommend setting up the last trigger as a "child" trigger of the "Set Planets_Caputured Variable" trigger primariliy because you want to set your variable up BEFORE checking its value, or you could wind up with some weird results, or even mission bugs!!
This last child trigger shown above will check to see if the value of "Planets_Captured" value is greater than or equal to 4 but only after the variable is created. If this trigger's conditon is met, then you could use the child trigger to succeed the mission, succeed an objective, or do any other type of action you wanted to.
In the example above, the child trigger succeeds objective 1, toggles the com panel on (objectives On) and shows "Mission Successful!" on the screen in the Mission Name spot.
This is just one example of what you can do using variables, and there are many other uses.
Variables are a key tool for "succeeding" of "failing" complicated objectives in a mission that can't be done easily any other way.
**IMPORTANT: You should be familiar with how variables work in Far Gate before you get into Multiplayer Mission design because multiplayer missions use variables extensively. You are free to use the multiplayer missions we create as templates for designing your own multiplayer or single player missions. Many of the triggers used in multiplayer missions are common to all multiplayer missions, and can be re-used with very little modification. You can use the "Delete All Objects" menu option in the object panel to create a new, blank mission while retaining all of the triggers of the mission you have open when you do the delete. NOTE: If you do this, be sure and immediately "save as" the file with a new file name, or you might accidently over-write the template mission file you just used!**
WORMHOLE ENTERED (TYPE): This condition checks to see if a certain type of unit passes through a specified wormhole. In this example the conditon will check to see if Player 1 sends a shuttle through wormhole (47). If they do, then this condtion is met.
That's it for conditons. The next section will discuss the actions that you can use in your triggers.
SECTION 4B-1: ACTIONS
Actions are mechanisms that allow triggers to actually DO something when the condtions of that trigger are met. (See above definitions for triggers, actions and conditions).
FLOW: ENABLE TRIGGER: This action will enable OR disable a top-level trigger. Top-level triggers are the only triggers that can be enabled or disabled via this action. (Child triggers are always enabled by their parent trigger whether its a top level trigger, or another child trigger.)
In the example below, a "FLOW: ENABLE TRIGGER" action is set to enable Trigger#1. If Trigger#1 was not initially enabled, then it will be enabled when this action executes. However, if you uncheck the "Enable" checkbox, then this action would disable Trigger#1 instead. It works both ways.
FLOW: GOTO MISSION: This action will exit the current mission in the game, and load a new mission in its place. In this example, the FLOW: GOTO MISSION action would load a file called MyMission.mis.
NOTE: You must actually have a mission file called MyMission.mis located in your ..\Far Gate\missions folder in order for the above example to work. **Also, note that this particular action type CANNOT be play-tested in the editor. Unlike most other action types, this action will only execute in the game itself, and will not execute in the editor.**
FLOW: GOTO TRIGGER: This action type skips up or down a single trigger chain and executes a parent or child trigger located in the same chain as the currently selected trigger. In this example, the FLOW: GOTO TRIGGER: action would execute Trigger#1, regardless of where on the chain Trigger #1 happens to be.
NOTE: Only triggers listed in the drop-down listbox can be "gone to" by a trigger using this action. You cannot use this action to goto triggers on a different trigger chain.
FLOW: UNLOCK MISSION:
FLOW: VARIABLE: This action is usally used in conjunction with a VARIABLE COMPARISON condition (as described above in the Conditions section). In this example, the FLOW: VARIABLE action is set to create a variable called "Planets_Captured" and also set that variable's value to 0.
You can also use this action type to add or subtract a specified amount from a variable, or generate a random number for a variable.