Creating Missions

A simple overview

The VO mission editor is based on individual stages. Each stage is made up of actions, objectives and events.

Actions cover what will happen in a given stage. Actions are done in sequence for each stage, first to last. Spawning an NPC can be done by selecting the "Spawn NPC" action, then selecting a type of NPC, faction alignment and action. Once you've defined an NPC, a variable will be defined (npc_1 or some such) to allow you to refer to it from other areas of the mission. All the variables for the mission are listed at the beginning of the mission.

Objectives are what is required of the player in order to complete the current stage. For instance, if you spawned the NPC (npc_1) and wanted the user to kill that NPC to progress, you would define a "Destroy one ship" objective, and then select the (npc_1) variable.

Events are the various actions that can be taken by the mission itself when different things happen. For instance, in the Objective defined above, you could set a "new objective event" to "Target killed by someone else" and then define the action "Fail the mission". Thus, in the mission stage we've created in the past three examples, an NPC is spawned, the user must detroy it, and the mission will fail if someone else destroys it.

Events, Actions and Objectives are not limited to the above examples, that's just a simple case. Events can be handled mission-wide, for instance. At the bottom of the mission editor is an area that says "Event handlers (during any stage)". Here you can define global events that will be triggered from ANY stage. Ie, a global event handler for player death: You would go down to the bottom area, click "new event" and then "player died". Then click "new action" within that event and then "write to mission log". Put in some sort of text like "Wow, it's too bad you died, please try again." Then click "new action" again and select "Fail the mission". Now if a player dies at any point in the mission (any stage, anywhere) it will print the message to their log and then fail the mission.

More on Stages

Stages are the mission segments that you create in order to have different types of activity. A given stage usually has actions and objectives, and the objectives MUST be fulfilled before it will fall through to the next stage. A given set of objectives only apply to their current stage. If no objectives are defined, then the stage will simply do whatever other Actions have been defined and then immediately fall through to the next stage.

You can also have missions fork based on different objectives or events. For instance, in the earlier example we spawn npc_1 and give the user the objective of killing him. In our Objective Event example, we have the mission failing if someone else kills their NPC. Instead, we could change that "fail mission" Action to "jump to stage", and then input the number of a later stage (say, Stage 10). Then, we could create another Objective Event for the same initial stage, and make this one based on "Status: Player killed someone else". Then we could also define a "jump to stage" action here, which jumps to a different stage than the previous Objective Event (say, Stage 15). In this way, we've created a 3-way split for the mission: 1) the player succeeds in the basic objective and kills npc_1, then the stage succeeds simply and falls through to the next in sequence. 2) the player fails in the basic objective because someone else kills their target, and the mission proceeds to jump to another special stage specific to that case (stage 10). 3) the player kills someone else, but not the target, and the mission jumps to stage 15.

In all these cases, the stages that the mission would jump to would be some specific stage with special-case actions based on the previous user behaviour. For instance, one might print out to the screen "Hey, you aren't supposed to be killing other people! Just your target!" and then fail their mission. Another might say "Wow, someone else killed your target, we're going to move you to a different sector" and plot a new course to a new sector for them.

These are trivial examples intended to illustrate the basic point. The stage-based system is a simple flow-chart. Stages fall through incrementially if their base Objectives are passed or they have no Objective defined. Stages can jump to other stages if specifically requested based on an Event. Actions can set Mission Failure or Mission Success in any stage, so there can be many different ways to succeed in the same mission. If all the stages are passed, the mission will automatically succeed (there is no need to define a special Complete the Mission action).

Another Simple Example

Let's create a slighty more complex mission than above. Something not unlike what we have for tutorials. The mission will fit this basic premise: The player must launch, go somewhere, kill a bot, then return and dock. Here's how it works:

Stage 1
	Action 1: write to mission log
		"Hello [player], welcome to the mission, we're going to have 
		you fly somewhere and kill stuff. It'll be great. You'll love
		it. Launch from the station now. <update> "

	Objective 1: launch from station

Ok, here we're just telling the player who's just taken the mission what they're generally getting into, and what to do (don't actually use quotes around your mission log text in the editor). The "update" (in brackets, not quotes) is a special command to the client that tells it to notify their mission computer to Update. In flight, this will make the little "M" icon come scrolling out and bounce. In the station, this will auto-select the Mission Log interface. This is very useful for sending a message to a user right after they've docked, since it makes their client switch directly to the Mission Log rather than going to Welcome or whatever interface they had previously used.

Stage 2
	Action 1: Wait, then do remaining actions (MM:SS) 00:05
	Action 2: write to mission log
		"Ok, now that we're in space we want you to follow the nav
		route we've plotted for you to a remote sector, where you 
		will face your opponent. <update> "
	Action 3: Set Nav route to.. (sector in system of type) (sector_1) (System player is in) (Empty sector)

	Objective 1: Go to sector.. (sector_1)

Now we're defining where they should go, and the fact that they need to go there. You'll notice there's a timer at the beginning of the stage. This will delay the rest of the stage from progressing for five seconds, which is important as it makes sure the mission update won't be sent to the user until their HUD has been properly created. Otherwise, the "M" icon scrolling out might not be seen (more important when you're writing text directly on their HUD which you don't want missed). It's also important when having them jump to a new sector, as the warp/jump animation takes several seconds, and any messages you print on their HUD in that time might be missed.

Notice how we define the type of sector we want them to go to. It must be A) in the current system and B) empty. The sector's variable is (sector_1) and you can use this to refer to that specific sector from anywhere in the mission from now on. We use it immediately by creating a new Objective to go to that sector (sector_1).

Stage 3
	Action 1: Wait, then do remaining actions (MM:SS) 00:05
	Action 2: write to mission log
		"Great job. Now we're going to spawn a Combat Drone for you
		to fight. As soon as you're ready to fight the drone, press 
		the button and we'll spawn it.
		<update> <button title="Spawn Drone" expand="NO" alignment="ALEFT" msg="" action="spawn"/> "

	Objective 1: Wait for user input

Here we wait five seconds for their jump animation to be finished, and then give them a mission update with the option to progress to the next stage when they're ready. The "button" syntax is another special markup option that's interpreted by the client as the special action to create a new button. The "msg" option is what would be printed in the log after the button is pressed (for instance, if it represented a chat-text exchange with an NPC, the player would want some log of their choice). In this case, it's left blank. The "action" field allows different text parameters to be passed back to the server, so you can have two different buttons which do different things. One could be spawn, another could be fail, the latter option failing the mission. In this case, since we only have one button, there's no real need for the action field, and the "Wait for user input" Objective requires no additional parameters. If the user sends anything back to the server, it'll be acted upon as the "button pressed" trigger.

Stage 4
	Action 1: Spawn NPC.. (npc_1) (Combat Drone) (Hostile) (Warp into sector) (sector_1) (Attack..) (The player)
	Action 2: Send message to player's HUD..
		"Here he comes! good luck!"

	Objective 1: Destroy one ship.. (npc_1)

Here we have defined an enemy NPC who will spawn in our (sector_1) location and attack the player. We also write a brief message to their HUD, telling them they have incoming hostile. The NPCs can be defined to be from any faction, of course, but then killing them will have negative repurcussions on standing and the like. By setting the NPC faction to "hostile", a generic enemy, we avoid all of that.

Stage 5
	Action 1: Write to mission log..
		"Great job, [player]! Ok, now we want you to head back to
		[station_issuing] and we'll wrap this up. <update> "
	Action 2: Set Nav route to.. (sector containing station) (sector_2) (station issuing mission)

	Objective 1: Go to sector.. (sector_2)

Here we write them a brief congradulatory note, and tell them to head back to the original station. In this case, the [player] markup will be replaced with the player's character name, and the [station_issuing] with the location and name of their destination station. We could just leave it at that and have them find their way back, but we'll be nice and also set their nav route for them (a good thing to do, for most missions, makes things clearer and less tedious). Then their objective is to go to that sector.

Optionally, we could have done away with the whole "go back to the issuing sector" objective here, and just set the nav route and then defined the Objective as "dock with station.." and set that station as the issuing. Generally, this is a better way to wrap things up, unless you specifically want to trigger some more actions when they actually enter the sector, rather than when they dock. In this example, we're doing it when they enter the sector, and THEN when they dock (next stage down) to let us say some more text about how to dock..

Stage 6
	Action 1: Wait, then do remaining actions (MM:SS) 00:05
	Action 2: Send message to player's HUD..
		"Fly in the bays with the blinking arrows"

	Objective 1: dock with station (Station issuing mission)

Stage 7
	Action 1: Write to mission log..
		"Way to go out there. You rule. <update> "

..and that's it! We don't have to define a special success action, success is implied by the mission falling through the last stage. Now, to make this a real tutorial mission we would also have to put a lot of different event handlers in here. Some of them global (like player death) and some of them specific to the individual stage. For instance, when you initially tell the user to fly to the remote sector (Stage 2) you might want an Event handler for docking with the station again, to tell them "Hey, you aren't supposed to dock again, get out there!". Or later, when they're fighting the NPC, we would definitely want to have an event handler for someone else killing their NPC. Otherwise, they would be unable to finish the mission, and probably be confused about what happened. In any real mission-creation scenario, you want to handle as much of the "unexpected" as possible.. the outside cases that could happen if people don't play your missions "correctly", or if outside factors (like other players) intervene. This way you have stable missions where the player always knows what's going on, and no one is left confused and frustrated.

I should also briefly mention Accomplishments. These are flags that can be defined by a mission, and place a piece of information in the user's character entry in the database. Accomplishments can be seen in the Requirements section at the beginning of the mission, and can also be defined by an Action at any point in the mission. In this way, for instance, you can have the user do some odd optional thing that does not seem to have any visible impact on the mission, but invisibly opens up a whole new mission tree (which Require that accomplishment).

Accomplishments can be set based on a must exist/not-exist state, or based on being a certain value. In this way, you can create a tree of dependent missions, each one completing the last stage with the action:

Increment accomplishment flag.. (name of accomplishment)

And that accomplishment can be re-used throughout your mission tree.

Conclusion

That's about as much as I can put in a simple tutorial text. There's a lot more options and possibilities out there, but the best way to learn them is to see some examples. Hopefully we'll be posting some example missions in the very near future, with different common types of missions. You can do a lot of complicated things with this mission editor, but you have to think it all through properly. Good luck!