Author: Tim White

An explanation of how to create events in the new event editor in Exogate Initiative, released in Patch 0.8.4.

Events are dialogue scenarios that sometimes occur during missions on exoplanets, where your teams of gaters may contact you and ask for help. A single event is usually associated with a single planet on the procedurally-generated star map.

If you need an exhaustive reference of most if not all of the editor’s functionality, you can consult the full editor documentation[docs.google.com].

• Events used to be called Contacts, and this term may still be referenced in the documentation from time to time.
  
• The version of the editor you’re using might be different to the one used in this guide, meaning some of the information and screenshots might be slightly different. We may update this documentation from time to time, but hopefully it will be clear enough for the version you’re using.

1. Open the Event Editor from the title screen main menu.
   
2. From the editor main menu, choose to create a new mission event.
   
3. Choose the flora event type for this example, and call it “Upside-Down Tree,” filling in the 4-letter ID field with a shorthand version of the name e.g. “TREE.”
   
4. An event is made up of one or more “steps” (a step is each unique time the team contacts the player and asks for help during an event), but for this example we only need a single step - click the “+” icon in the top-right corner to add a new step.
   
5. Give the step a name, e.g. “Strange Tree,” and click Create (you can ignore the “Time since last step” slider, as this only affects the second step onwards).
   
6. Save the event by clicking the save icon in the top-right corner, then click the new step to open the visual editor.

1. Now the main editor interface is open, our basic goal is to connect the Start node to the EndStep node, filling the space inbetween with dialogue from the team of gaters, and options from the player, to create a fun and interesting branching narrative.
   
2. For this example we will simply have a single dialogue from the team and two options for the player, as shown in the image above.
   
   • (Hold the right mouse button to scroll the editor view; if you accidentally lose the location of the diagram, click on the target icon in the top left, to return to the Start node.)
3. Add a dialogue node by clicking Dialog in the header, or by pushing the D key. Drag and drop to position it to the right of the Start node. (If you accidentally add the wrong node, or add too many, you can delete them by clicking the header of the node, then pushing the Delete key; or you can right-click the node and choose Delete.)
   
4. Write this dialogue into the text box, as in the image above:
   
   1. Hello, XO.
      
   2. [line break]
      
   3. We found an upside-down tree. What should we do?
5. You can now link the Start node to the first Dialog by dragging a connection between the two connectors on each node (hold left click to drag, then click again once you’ve moused over the destination connector). Alternatively, with the Start node selected, hold Shift and left click in the header of the Dialog node to instantly connect them.
   
6. It’s fine for now to leave the Speaker as the team leader, but you can set the Emotion (how their face will appear during the dialogue) to “Surprise” to match the context.
   
   • (You’ll also notice the “Time-limited” tick box on the Dialog node, which forces the player to make a choice from the following Options within a time limit; however we rarely impose this feature if at all, and if used it should generally be for climactic moments.)
7. Next add two player Options as in the image above, and write the player’s dialogue into each one:
   
   1. Take a sample please. [despite the dialogue, we aren’t actually implementing taking a sample here - but it illustrates an interesting option for the player]
      
   2. That sounds freaky - return to base.
      
   3. (Note that the order of player Options, presented top-to-bottom for any given choice, is randomized at run-time, irrespective of their order in the editor.)
8. Connect both player options to the EndStep node, and set this node to End_Event.
   
9. Save the event using the icon in the top right, and click the X icon to exit back to the top level of the event.
   
10. Fill in any “meta” information for the event, now it’s complete - add a short pitch/summary, and select the narrative tonal style, making sure to save changes.
    
11. Click the Export button in the top right to export the event so it will work in your local game.
    
12. The event is now considered valid to appear during your gameplay, for any new or existing save games! Since it is a flora event, it may occur during a mission to a science planet (see the Appendix for information on what mission types trigger what kinds of event).
    
    • It is a good idea to playtest your event in the emulator too, to make sure it is behaving as you expect before you encounter it in the game - see below.
      
    • Note that you need to re-export any changes each time, before they will appear in the game or emulator.
13. If you’d like other players to play your event in their games, you’ll also need to upload it to the Steam Workshop for them to find and download. Click the Upload to Steam button in the top right of the event’s main screen to do this.
    
    • (Visibility, version history, deletion, etc. are controlled from the Steam Workshop itself.)

1. Now you can go to the emulator and play the event as a player would experience it in the game, to make sure it’s working as expected.
   
2. Click the X in the top right to return to the editor’s top-level list of events, and click Emulator in the top right.
   
3. Click on New in the top left to roll a random team of gaters (or customize them as required), select your event from the list (should be at the top of the list if it’s the last one you worked on), then click Start Mission in the top right.
   
4. You can now play the event as if it had popped up during the game!
   
5. When you’re done, you can click the Editor button in the top right to return.
   
6. (After playing the event in the emulator, you may see a “What should we do next?” line of dialogue appear at the end, along with some options, none of which you wrote; this is because of ending the event with End_Event on the EndStep node, rather than End_Mission. End_Event ends the event, but allows the team to continue on the mission if there’s time left, which may lead to them gaining more resources (or injuries!) should the player choose to do so. This is the preferred way to end most events. Whereas End_Mission ends the mission and brings them home immediately.)

There’s a lot we haven’t covered, such as skillchecks, granting XP and other rewards/penalties (the stat changes you normally see in the Log section during an event), and linking events together into a recurring Storyline - see the other sections of this guide for more information.

We look forward to seeing what you create beyond the Exogate!

The above image shows a short flora event in the game, FLO-0001-TREE, which demonstrates most other functionality you will need to create events. I will describe how it was created below; but rather than a step-by-step tutorial, I’ll cover the additional features not used in the My First Event example. I’ll also assume that you’re familiar with the user interface and user experience from My First Event, such as how to add and connect nodes in the visual editor.

• It’s often useful to designate specific members of the gater team, for use in skillchecks or as specific dialogue speakers.
  
• Use an Instruction node to set these before they are needed (often good practice to do immediately after the Start node, so all the different gater designations are done at once).
  
• In this case you’ll see that we use two “Set target gater” instructions, to set one gater as the “scientist” (BestOfClass Scientist), and another as “climber” (BestOfAttribute Body).
  
• Another common use of “Set target gater” is to identify the team leader (IndexInTeam == 0).
  
• If you set a gater in an instruction, and want to reference them immediately in the same instruction, you’ll need to close the instruction and open it again to refresh the data.
  
• Similarly, if you set a gater in an instruction, and want to use that gater as the Speaker in a Dialog node, you’ll need to exit the visual editor to the event’s meta screen and then go back into the step, to refresh the data and add them to the Speaker drop-down.

• The editor supports various keyword tokens, which when used in Dialog and Option nodes, will replace the token at run-time with actual data, such as the name of the team, individual gaters’ first or last names, the name of the planet they’re visiting, etc.
  
• The “Keywords help” menu (“{{x}}” on the toolbar) offers shortcuts to copy a variety of these, which can then be pasted into a text box.
  
• The “Target gaters keywords” menu (the icon with the crosshair on the toolbar) offers similar functionality to quickly copy the first name, last name, country of origin, or class of any gaters identified by “Set target gater” instructions.
  
• In this example we simply use the “{{PLANET_NAME}}” token, which will insert the name of the planet the team are currently on when the event fires, e.g. “ZA-561.”

• The Jump node is useful to connect one part of the branching tree of nodes to another part that is far away across the diagram; rather than having a long connecting line that might be hard to follow visually over such a distance, you can add a Jump node, which will automatically create two nodes: a “From” and a “To,” with each Jump pair added given an ascending letter of the alphabet.
  
• This means you can connect a node into “From A,” and the flow of the narrative will automatically jump to the “To A” node, which you can then connect into another part of the diagram.

• In the FLO-0001-TREE event above we use the Jump to create a “hub” design pattern, where the player can ask a question, which a team member answers, but then flow is routed back to the top of the hub, leaving only the remaining questions the player can ask.
  
• (Although not technically needed here, since the Jump To node only connects to the remaining two question options, notice how the “Was there a hurricane?” Option has the “Remove after selection” box ticked; this ensures that even if we accidentally routed the Jump To node back to all three options, this specific Option would no longer display because it would have already been selected.)

• You’ll sometimes want to gate (restrict) Options based on the player’s (or rather the team’s) stats. Most commonly, you’ll want to only allow an option to be selected if the player has a certain class of gater on the team. This is sometimes a mechanical requirement enforced by the editor, such as if the looting of a Bio Sample takes place beyond an Option, then the Option needs to be gated behind a Scientist class check, since only a Scientist can loot Bio Samples. Other times, class gating like this could be used for interesting narrative insight and stat changes, such as asking an Engineer how they think a piece of alien technology works.
  
• In this example, we use a Scientist class check, since yes indeed it is followed by a looting Instruction for a Bio Sample!
  
• We do this by adding a Condition to the player Option itself (click the blue Condition button on the Option node), using the “Targeted rules” check to ask if “AnyGaterInTeam” is of Class property “Scientist” - see below:

• If not conditioned like this, and a looting instruction follows the Option, then an “auto-fix loot option” message will appear in the editor, which if clicked and accepted will automatically add the required condition (and customization text - see below).
  
• Typically you don’t want to check the box “Hidden if inactive,” since we want the player to know when they have missed out on being able to choose an option due to their team configuration or stats (this might make them think about diversifying their team more next time, or want to try another run of the game later with different team configurations, so they can explore different event options).
  
• The editor won’t let you gate all Options in a single choice behind a class check, otherwise the event could get blocked if a player has none of the desired classes. So you’ll always need at least one option that is selectable no matter the team makeup.
  
• Bear in mind as well that although team configurations can technically be any combination of classes, certain mission types (and thus certain events) require certain classes. For example, Science missions require at least one Scientist (and there are a lot of Science planets on the star map), Material missions at least one Engineer, Cultural Studies at least one Scholar, etc. (see the Appendix for more information). And in a general sense, players are encouraged to bring Soldiers and Medics on missions where they can, to reduce injury chance and injury severity respectively. So most class-gated choices probably want to cater to Scientists, Soldiers, and Medics, since these are the classes that will most often be sent on missions.
  
• Other uses of Conditions on Options could be to show different options to the player based on a team member’s health, or other attribute.

• You can customize the player Option text to indicate special conditions associated with that option, and in extreme cases to warn the player of a potentially dangerous option - click the Customize button on an Option to open its menu.
  
• Usually this is to indicate the gater class that is required to choose this Option, or the attributes that will be tested in the skillcheck that follows the Option.
  
• (In terms of skillcheck attributes, the player cannot actually query the attributes of the team members during the event - but still it might be useful to know what attributes are to be tested. Querying attributes is also often unnecessary, as the success chance of a skillcheck directly following an Option will be indicated on the Option at run-time, allowing the player to make an informed choice.)

• You can create variables that will persist for the duration of an event, across multiple steps, allowing you to track branching logic to create unique consequences later on.
  
• Custom event properties are created from the toolbar, using the cogwheel and pen icon. (We recommend writing variable names in camelCase for readability.)
  
• In FLO-0001-TREE there is a single boolean variable called “cutting,” which is initialized to “false.” If the player chooses the “Take a cutting” Option, we use an Instruction embedded in that Option to set the variable to “true.” Although this is never used again in this event, we could check this value later (even in another step of the event), to determine the Option the player chose here, and to branch the narrative accordingly.

• Player Options followed by a Condition skillcheck, which can pass or fail, and associated rewards and penalties conveyed via Instruction nodes (and ensuing dialogues) are one of the most important aspects of any event.
  
• Although interesting player Options and ensuing team dialogues can be fun, ultimately the player wants to put their team’s stats to the test in a challenge, with different mechanical and narrative outcomes occurring based on the result (as shown in the Log section during an event). These skillchecks and results can be the turning point of an entire step, event, or even a whole storyline itself. They make for a great dramatic climax!

• As long as a Condition skillcheck immediately follows a player Option node, the success chance of the skillcheck, based on the team’s stats, will be automatically shown to the player at run-time (otherwise no success chance is shown).

• The Condition skillcheck used for the Scientist “cutting” option looks like this; the skillcheck is performed on the designated “scientist” gater alone, and it is a 100% Knowledge attribute check with Easy difficulty.

• This is a reward Instruction node, which allows a Scientist to loot a Bio Sample of size Small, and grants a Medium amount of Knowledge XP to the gater set as the “scientist.”
  
• Rewards and penalties should be small mostly, in the Very Small to Medium range, with large changes reserved for special occasions. Though due to the way events are balanced in the game, relative to non-event missions, it’s not really possible to skew the game balance from what you do in events. (That’s not to say event stat changes are pointless, because they still show choice consequences, and accrue to impact future happenings in later events and in the base - but it’s a nice safety net, so you can experiment narratively without worrying about game balance.)
  
• There are no hard rules on what penalties and rewards should be given based on what narrative situations arise - as long as they somewhat make sense, and create harmony between narrative and game mechanics. But some general guidelines we tend to follow:
  
  • Grant XP for the skillcheck that was just performed, so a Knowledge skillcheck should grant Knowledge XP.
    
  • Grant XP relative to the difficulty of the skillcheck, so a Medium skillcheck will grant Medium XP if it passes.
    
  • It’s also nice to give some XP even if the skillcheck fails, typically two magnitudes smaller; so if Medium XP is given for a pass, give Very Small XP for a fail.
    
  • Sometimes it’s nice to reward the player for having the right class of gater to access a specific choice option - in this case the skillcheck might be easier than it would otherwise be, due to the ideal candidate being present on the mission (but it might still give the same rewards - just with a better chance of getting a pass). So while game balance doesn’t really need thinking about, it’s nice to create some internal balance consistency within a specific event, across the different paths the player might take through it.
    
  • The order of Instructions within the node is the order they will be executed at run-time (and thus the order they will appear in the notifications log during an event); typically we want to show the most prominent negative outcomes first, such as suffering Stress or gaining an Injury, with XP being the last thing to be awarded.

• Typically the team leader is the one you want to handle most dialogue during an event (and they are the default speaker when adding a Dialog node), but it’s fun to vary things up and sometimes have different speakers - such as those you’ve assigned using the “Set target gater” instruction, or a BestOfClass Soldier if it’s most relevant to get a soldier’s perspective (say if the Soldier was the one doing the skillcheck).
  
• Both the Speaker and their Emotion (how their face will appear during the dialogue) can be customized on the Dialog node.
  
• When changing Emotions for a speaker across an event, try and keep them realistic, unless the narrative calls for a sudden change in emotions. E.g. if the gater begins the event afraid, they might eventually become neutral (smiling) over the course of the event, or even joyful by the end. But generally don’t go from “Fear” to “Joy” from one Dialog to the next.
  
• Setting the Speaker to None can be a useful trick, which renders no one in the video call, just the planet’s background. This could be used for example to simulate losing contact with the team, with the player’s Option dialogue calling their names in an alarmed way, but with no response (only an ellipsis, perhaps) from the empty video call.

• End_Event is the default way to end most events in their last step, which if there’s time left on the mission, will let the player choose for the team to continue exploring the planet (to potentially gain more resources and XP - or injuries!), come home, or treat injuries if there’s a medic on the team.
  
• Sometimes however we want to use End_Mission instead, to bring the team home immediately if the narrative warrants that. Some event types are designed to always use End_Mission though - Geological and Artifact events do this.
  
• Go_To_Next_Step will simply launch the next step of the event, after the set number of days has elapsed (“Time since last step,” as set on the next step).
  
• Jump_To_Step will go to the specified step after the set number of days, allowing you to branch the event to specific steps.
  
• Direct_Jump will link the specified step to the end of this current step, as if they were all contained in the same step - so the specified step will run immediately.
  
• Loop_Step will replay the current step after its set time delay of days (we rarely if ever use this one).

Proofing mode:


Player mode:

• Accessed from the toolbar, these two modes are helpful for proofreading dialogue and playtesting interactivity respectively, which is often needed when event steps get longer and more complex.
  
• They do have limitations: the proofing view doesn’t allow you to follow the branching logic as clearly as in the editor view; and although the player mode lets you do this, it cannot perform skillchecks, requiring you to manually choose their outcome (useful to test all branches though); nor can it replace keyword tokens, as seen in the image above.
  
• However they are useful because proofing and testing often work best when you can switch context, to see things in a view more like how the player would experience them; your eyes tend to notice issues more in these less cluttered views, compared to the default editor view. Plus these can be accessed with a quick click from within the editor.
  
• The ultimate way to proof and test though is using the event emulator, which renders an event just as a player would see it in the game - but this requires leaving the editor (but not the game) completely to access. For more information on the Emulator see Tutorial: My First Event.

• Comments are an important part of blocking out your event step as you layer up the content. Once the basic blocking is in place, it’s useful to add a Comment node for every Condition and Instruction, explaining in a few lines what mechanical effects are going to happen in each one, serving as a kind of “pseudo code” shorthand e.g.
  
  • For a Condition skillcheck:
    
    • ~ knowledge easy scientist
  • For an Instruction to give rewards:
    
    • + loot bio sample small
      
    • + XP know mid scientist
• These comments are then useful on the next iteration as a guide to implement the mechanics in the Conditions and Instructions.
  
• Leave the comments in place afterwards too, because they are useful when skimming over a step later to understand how it works, without having to click into each node individually to see what it’s doing (useful when debugging); or if another writer comes to look at it later, they will see clearly how it works at a glance. Thus it’s important to update comments with new information if the contents of the Conditions and Instructions change.

• If you want more text box space to see and edit text for Dialogs and Options, push the Return key with the node selected (click into its header area to select it, rather than clicking into its text box). This opens a larger tex box, which might be easier to work with if the node contains a lot of text.
  
• Push the Escape key to close the expanded text box once you’re done and return to the editor.
  
• (Occasionally I have encountered a bug here, where the text box will not close again, locking you out from returning to the editor diagram, so it’s always best to save before opening the expanded text box. Possible work arounds if this happens to you: exit the editor by clicking the X in the top-right corner and then go back in; failing that, you can open a second client for the game, and load the event editor there to see the version of the event you last saved, so you can continue your work - simply close the original errored client once you no longer need it.)
  
• In the case of player Options, there is a character limit imposed on the default text box, to prevent you writing options that are too long for the event user interface during gameplay. However, opening the expanded text box will overrule this restriction, allowing you to write longer player option texts. (If an Option’s text is too long for the gameplay interface, it will wrap onto a new line, which looks acceptable and does not obscure the text of the option below it, though this is generally not recommended. Best practice is usually to keep player Option text short.)

• Sometimes you might want to link multiple Dialog nodes together, such as if multiple branches share the same ending dialogue, or just to space the dialogue across multiple nodes if it’s getting too long for a single node.
  
• In this situation the game will concatenate (join) the nodes together at run-time, as if they were written in a single node.
  
• But because of this you need to be aware of line breaks. If the first concatenated Dialog node has no line break at the end of it, and the one it’s joined to has no line break at the start, then there will be no empty line between the dialogues in each node. However, in the game’s style guide (and in most online media), a new paragraph should be on a new line separated by an empty line - so we have a problem.
  
• The easiest way to solve this is often to add the line break at the beginning of the following node in the concatenation, because that can easily be seen at a glance when reviewing in the editor - unlike a line break added at the end of the preceding node, which is invisible unless you click the cursor into the text box.
  
• Note that when concatenating multiple Dialog nodes together, the Speaker and Emotion from the first in the sequence will persist over all of them, irrespective of what is set in the later ones (see image above); the Speaker and Emotion can only change from one Dialog node to the next if there is a player Option between them.

• The editor doesn’t support text search functionality on the contents of events, such as if you want to do a find-replace across multiple events.
  
• However, Visual Studio Code (or any other third-party text editor that allows you to search the contents of files in a folder directory) can help here, and is what we use ourselves.
  
• When you create an event it creates an ECG file, which is updated each time you save the event or one of its steps. This is a source file used by the editor, and is located here (on Windows):
  [local user directory]\AppData\LocalLow\XenoBits\ExogateInitiative\EditorFiles
  
• When you export an event it creates/updates an ECD file. This is the file used by the game at run-time, and is located here (Windows):
  [local user directory]\AppData\LocalLow\XenoBits\ExogateInitiative\Contacts
  
• (Localization files for other languages are also stored in the ECD folder, but with a different file extension relative to their universal language code.)
  
• When doing a find and replace, you need to make changes in both the ECG (source) files, and the ECD (exported) files. You could do these at the same time, though of course you will have duplicate search results across both ECG and ECD files. Alternatively, you could update only the ECG files, refresh the editor (see the section on making changes on the file system below), then re-export to get new ECD files.

When making changes to events outside the editor itself, such as doing a find and replace as discussed above, or deleting event or storyline files, changes will not automatically show up in the editor (for source file changes) or in the emulator (for exported changes) if they are already open (what you see instead is cached data from when the editor or emulator was last opened).

However, the changes will appear the next time the editor or emulator is opened - so simply return to the title screen then go back in, or bounce to the other one and back (open the emulator from the editor, then go back, or vice versa) to refresh the data.

There are still aspects of events we haven’t covered here, so I would recommend checking out the test event, TME-0000-TEST, accessible from the top level of the editor, which showcases many features of events. Play this in the emulator, then look at how it works in the editor.

Notably I haven’t yet talked about linking events together to create a Storyline. Just as an event can comprise multiple steps (also not demonstrated here - though many events in the game have multiple steps), a Storyline can consist of multiple events, and thus span multiple planets on the star map to create a larger narrative arc. See Storylines for more information.

Storylines are mini-campaigns of more than one event, which take place across different planets on the star map. You create multiple events and link them together into a Storyline.

1. From the top level of the editor click “Custom storylines” then “Create new.”
   
2. Name the storyline with a unique ID and give it a title and description (the ID could be a few words from the title, or an initialism). The name and description can be changed later, but the ID is fixed.
   
3. Also choose the language for the events of this storyline (fixed).
   
4. The storyline will now be added to the list of existing storylines, and can be clicked on to view the events it contains (empty to begin with); changes to the storyline meta information can also be saved and exported from here.
   
5. Saving a storyline adds/updates a new file type, an ECP file (a source file used by the editor), to a Storylines folder here (on Windows):
   [local user directory]\AppData\LocalLow\XenoBits\ExogateInitiative\EditorFiles
   
6. Exporting a storyline adds/updates a new file type, a CMP file (a file used by the game at run-time, which contains the data for the storyline and its events - though note that events need exporting individually if testing in the emulator), to a Storylines folder here (on Windows):
   [local user directory]\AppData\LocalLow\XenoBits\ExogateInitiative\Contacts

1. To add an event to the Storyline, find the first event that will begin it in the editor main menu (or create it if it doesn’t exist yet) and click into its top-level meta information screen.
   
2. Tick the “Storyline event” box, and then from the Storyline ID drop-down select the new storyline that you created earlier.
   
3. You must also select the “Trigger conditions” option to specify what will trigger the event. There are many different options here, so please experiment and explore to find what will work best for the storyline’s narrative and gameplay.
   
   • If no trigger conditions are set here, the event will trigger under its normal circumstances, i.e. on a suitable planet (see the Appendix for the different triggers per event type).
     
   • Note that if a World_Threat trigger is selected for a storyline event, AND the event is already a World_Threat event type, the storyline world threat trigger will override the event’s own settings.
4. Repeat steps 1-3 for all events in the Storyline, adding them in turn (by default the first event you add will be the starting event).
   
   • You can filter the main event list in the editor by specific Storylines, to see only those events.
5. To control the order of events, you specify which is the next in sequence from the EndNode of the previous event; when selecting End_Event or End_Mission an additional drop-down called “Storyline next event” appears, which lets you choose another event from the storyline. This event will then occur next when a team visits a suitable planet, and when the event’s trigger conditions are met.
   
6. If you want to change which is the first event in the Storyline, return to the “Custom storylines” menu and click the storyline in the list to open its settings; then in the Events section, click the event you want to be the first in the sequence.
   
7. From the storyline settings menu you can also create global custom variable properties that will span across multiple events within the storyline; so you could set a variable in the first event, check (or change!) its value in a later event, and thus branch the narrative accordingly (much as event property variables persist across event steps).

Once all events are added to a Storyline, the storyline has been exported from its menu to get latest changes (which will auto-export all included events), and you’ve tested the events individually in the emulator (you’ll have to manually test each event in turn, although storyline custom variables should persist over the same emulator session), you can upload the whole storyline with its events to the Steam Workshop. Do this from the storyline’s settings menu (and indeed this is the only way to upload Storyline events - the individual events themselves cannot be uploaded while they are part of a Storyline).

Intelligent Beings events are where you encounter an intelligent alien race living on an exoplanet. They have a Storyline-style sequence of events, but aren’t actually created as a Storyline, since they have very specific events that must occur at each stage.

In the current Early Access version of the game, the sequence of events is as follows:

Stage 1: First contact (required)
The Initiative meets the aliens for the first time during an event.

Stage 2: Further relations (optional)
Depending on whether the aliens are Friendly or Hostile towards the Initiative, the next missions are either Cultural Studies or Defensive Missions respectively (if the aliens are Neutral, the player can choose either route).

After several of these missions, one or more events can trigger relative to the path taken: Cultural Study events, or Defensive Mission events. (Note that events at this stage are optional, and progress towards claiming the planet will progress regardless of whether any missions trigger events or not.)

Once the alien culture has been fully studied (or defended against) over a series of missions, their planet can be “claimed” under the Initiative’s area of influence.

Later Stages TBD
As the game moves towards its 1.0 version, more event stages are planned for after a planet is claimed, using the currently-unreleased Diplomat class to forge diplomatic relations.

Before creating Intelligent Beings events, you must first create the data for the alien species that will feature in the events. This is similar to Storylines, where you must first create the Storyline data before adding events to it:

1. From the top level of the editor click “Alien races” then “Create new.”
   
2. Name the alien species with a unique ID and give it a name and description (the ID could be taken from their name). The name and description can be changed later, but the ID is fixed.
   
3. Also choose the language of the events for this species (fixed).
   
4. Set the “Relation after first contact” (determines what happens in stage 2, above).
   
5. Also set the “Assimilation complexity,” which determines how many missions it takes to complete stage 2 (complete the cultural studies, or defensive missions), before you can claim the planet.
   
6. The alien species will now be added to the list of existing aliens, and can be clicked on to view its details and the events it contains (empty to begin with); changes to the species meta information can also be saved and exported from here.
   
7. Saving a species adds/updates a new file type, an EAL file (a source file used by the editor), to an Aliens folder here (on Windows):
   [local user directory]\AppData\LocalLow\XenoBits\ExogateInitiative\EditorFiles
   
8. Exporting a species adds/updates a new file type, an ALS file (a file used by the game at run-time, which contains the data for the alien species and its events - though note that events need exporting individually if testing in the emulator), to an Aliens folder here (on Windows):
   [local user directory]\AppData\LocalLow\XenoBits\ExogateInitiative

1. Now you’ve created your alien species, you can add events for each of the (currently) two stages of an Intelligent Beings event sequence.
   
2. Simply create each event in turn, the way you would any other event, but choosing “Intelligent Beings” as the event type, selecting the ID of the alien species you created earlier, and choosing the subtype of event this is: first contact, cultural study, defensive mission (note that some references to “defensive mission” may be labelled as “pacifying”).
   
3. Then proceed to create the event as normal.
   
4. Intelligent beings events are assigned to “Alien encounter” planets on the star map; so the first visit will trigger the first-contact event, and later visits to the same planet will trigger cultural study or defensive mission events (depending on alignment).
   
   • For official content we typically create a single first contact, and cultural study and/or defensive mission per species.

Once all events are added to an alien species, the species has been exported from its menu to get latest changes (which will auto-export all events for that species), and you’ve tested the events individually in the emulator (you’ll have to manually test each event in turn), you can upload the whole alien species with its events to the Steam Workshop. Do this from the alien race settings menu (and indeed this is the only way to upload Intelligent Beings events - the individual events themselves cannot be uploaded).

Intelligent Beings events have certain game design requirements, regarding team configuration and looting, as shown in the Appendix.

There are also writing and narrative design best practices, elaborated on in the Text Style Guide[docs.google.com], such as during a stage 2 event refreshing the player on what this species is about, since many missions and events could have occurred between first contact and stage 2.

However, since there are no visuals or other assets associated with Intelligent Beings alien races, only description told through events, you are free to be as creative as you want in how you describe your aliens - their biologies, psychologies, languages, homes, names, societies, genders, and so on.

These aren’t rules, just guidelines.

Create events in an iterative, layered way, using version control after each stage if you can. We’ve found this approach works well:

1. Write a basic bullet point outline somewhere for how you want the event to go: how many steps, what happens roughly in each step, what are the main skillchecks going to be, and the main branching points - even any cool dialogue you might have thought of already. Keep it simple though, and allow yourself to pivot from the outline if you think of cooler stuff while making it, but it will likely be easier working from this than from nothing.
   
2. Open the editor and block out the nodes with placeholder dialogue to show intent (no need to connect them yet).
   
3. Add comments for all the conditions and instructions to figure out and indicate the mechanics.
   
4. Implement the conditions and instructions.
   
5. Now connect all the nodes, since things are unlikely to change.
   
6. Set speakers and emotions.
   
7. Add “final” dialogue (though this will want a few drafts itself to ensure quality).
   
8. Check dialogue in proofing mode to spot any writing issues; playtest the interactive continuity in the player mode to check it flows as intended.
   
9. Add the pitch/summary description and check all the other “meta” info is correct.
   
10. Export and playtest a few times in the emulator to make final tweaks.
    
11. If you can give the event time to breathe, say for a few days, or even a week, and come back to it with fresh eyes you’ll probably spot further improvements.
    
12. And you can never beat getting fresh perspective by getting feedback from others, as they’ll spot things you are too close to it to notice. (Hopefully they are kind and constructive in their feedback - if not, then don’t use them again! And as with any feedback, you get the final say.)

(These details generally apply to any scale of narrative, whether it’s a single Step, Event, or Storyline.)

• Try and plan for a twist towards the end to surprise the player (though it generally needs to be a plausible surprise, nothing too contrived or deus ex machina).
  
• Don’t get too bogged down in lore, backstory and character bios; sometimes these are needed to help you realise the setting and narrative when you begin to write the script, but ultimately the work will live or die by what the player experiences - which is the script! And I often find that you think of better ideas when in the scripting trenches anyway, informed by the current narrative needs, which can make a lot of pre-planned backstory redundant. Writers are good at making things up as they go!
  
• Though you don’t have to follow it precisely, it can be useful to bear in mind general narrative structure/order when planning and outlining, i.e. rising action, climax, resolution (the bell-shaped curve). Or thinking in terms of five acts, as I’ve often found useful (thanks Film Crit Hulk!):
  
  • Inciting incident - start with a bang and grab the player’s attention
    
  • Main plot event - what sets the story in motion, and the rising tension
    
  • Turning point - significant event which changes the direction of the narrative
    
  • Spiral - short and fast towards the big climax, really railroading the plot now
    
  • Climax - big finish - but don’t forget the resolution!
• Think about how you end things as well: sometimes it depends on genre, but generally you want to be aiming for a “mixed” ending: something that’s equal parts positive and sad (all positive is often too cheesy, all negative is often just too much of a downer and rude). It should also hopefully be both expected AND surprising (but plausible!), and leave some mystery and ambiguity, to keep the player wondering long after they’ve turned the game off.
  
  • This is perhaps less relevant in a game where after a mission the team return back to base and continue their lives, but generally don’t skimp on resolution at the end of a narrative: players want to know how things turned out for the characters they’ve invested in - so it’s perhaps more relevant to the aliens you’ve left behind in Exogate.
    
  • BUT likewise don’t go past the ending! Dramatic arcs have a bell shape for a reason: after the climax there’s meant to be downward action towards the resolution as you wrap things up. Don’t then begin telling more story, and building to another climax, as players will wonder when it’s ever going to end... You might have missed the best time to end the story and get out.
• Subplots can also play a useful role in narrative, following different characters and threads, which support the main themes - and tend to climax with the main plot.
  
• Since events don’t typically repeat in a single run of the game, there is no need to maintain narrative continuity along different branches through an event, since the player will only be able to observe a single branch of the event in a single run of the game. If they choose another branch with different continuity on a later run, that’s fine, because with each run the star map is regenerated and it’s a different story continuity. So this gives you freedom to create wildly different paths through events, if it’s easier or desirable to do so. (Of course, if the player can choose multiple paths during an event, then continuity parity would need to be maintained.)
  
  • Events can’t repeat, but there are some exceptions: like if a gater unexpectedly dies during a geological survey mission, before the ore sample has been collected, the event is aborted and team come home; but the event can be replayed again later so you can still obtain the ore.
    
  • The player could also save scum to explore different branches, but conceptually that is resetting continuity anyway.
    
  • (The same is true for balancing skillchecks, penalties and rewards across branches too - it’s more important that they fit the narrative of that branch, rather than be consistently balanced across all branches in an event.)

• Consult the game’s Text Style Guide[docs.google.com] for consistency of style and formatting, and basic lore and setting information.
  
• Think about the “meta” stuff: genre, tone, target audience (not just age range to ensure suitable language and references, but who your implied players are). Exogate may be a light sci-fi game, but the mission contacts are designed to have a wide variety of tonal differences to keep things fresh: comedy, tragedy, fantasy, horror, sitcom. So yes, always think about your intended player, but don’t be afraid to try new and interesting stuff.
  
  • In a general sense it should sit within the overall setting and tone of the game, if it’s going to feel like an integrated part of it; but within that, get creative!
• We write to a PEGI 12+ age rating (see the Text Style Guide[docs.google.com] for more information), so bear that in mind; content should feel age-appropriate. Any content that exceeds this rating should have a content warning in its description on the Workshop. Anything too extreme may have its content descriptors updated under moderation, or may even get banned.
  
• Think about what themes you want to tackle and put out there into the world (every creative endeavor says something about the beliefs and politics of the people that created it - it has to, because you make tons of small decisions along the way, which are naturally informed by what you’re interested in and believe); as a writer you have an unwritten responsibility to think about what you’re saying to people.
  
• Start “in medias res” (in the middle of things); it’s usually more exciting to drop the “reader” into the middle of a situation that’s already happening, rather than starting at the boring, logical beginning. It gives the impression of a pre-existing world, not one that just popped into being when the reader arrived. This can also help create an inciting incident.
  
• Conflict is the source of drama - this doesn’t mean all out war, but any kind of disagreement or difference in perspective or opinion.
  
• Evoke the scene, all the senses (albeit through dialogue only in Exogate - though your team can serve as narrators of a sort).
  
• Don’t forget subtext! It’s interesting to read.
  
• Changes in status are cool - whoever’s involved in the conversation (individual gaters, the player XO, aliens), vary who’s in charge of the conversation at different times for dramatic effect. It should be a dramatic to and fro.
  
• Since the dialogue voice can be applied to any gater on any team, it needs to be a somewhat neutral catch-all “voice,” which could work for any professional gater doing their job on an exoplanet; though you can and should embellish from time to time when it makes sense too, such as in extreme emotional situations. If you know the class of the speaker too for example, or perhaps even their country of origin, you could vary dialogue based on those (such as making a soldier’s dialogue brusque) - though be careful not to stereotype.
  
• Three player dialogue options at any one time is usually considered a golden number, though different situations call for different things so it’s only a guideline. Sometimes you want only a single player option, to throttle the branching and move the narrative along.
  
• Try and avoid the classic good, neutral, evil range of options, and think more in terms of what would just be interesting things for the player to say or ask at any given time; also think about providing interesting ranges of roleplay expression for the player (beyond binary morality).
  
• Keep dialogues short where possible, broken up with a player option, even if just a single option to continue; if you need to relay a lot of information in a single dialogue, typically don’t exceed three or four short paragraphs (always playtest in the emulator to see if your dialogues are too long for the in-game event interface).
  
  • Since we’re reliant on text and limited emotes alone to carry these narratives, the writing should generally be pithy - concise, expressive, and potent.
• About 500 words total is a good guideline for an event (including all steps); sometimes it’s more if you want to create something sprawling and epic, sometimes it’s less if just want it to be short and sweet. Always remember that an event (or more specifically, a contact step within an event) will interrupt the player’s base-building and management gameplay (albeit with a timed alert, so they can usually choose when to begin the event), and you probably don’t want to keep them away from the core gameplay for too long - unless it’s a really epic point in the game’s narrative!

The mission triggers and requirements for the various types of event:


Recommended equipment for world threat destinations to avoid triggering an event (image from game design documentation); also a useful guide as to what equipment to check for via the ArmorTech property, when setting gaters (instructions) or checking for the presence of equipment (conditions):

Full-size image here[drive.google.com]

Editor User Manual[docs.google.com] - the full documentation for the editor written by the dev team
Text Style Guide[docs.google.com] - info on the game’s text format and style, basic setting information, etc.