Multiplayer Tutorial

In this document, we'll cover how to design and FRED a multiplayer mission. We'll also cover some of the common problems you may encounter if you are used to making singleplayer missions but have never FREDded for Diaspora multiplayer. This tutorial assumes that you have already been through and completed the Extended Walkthrough or have some other experience with building missions using FRED.

Important design considerations for multiplayer missions

Multiplayer missions require you to take into consideration several extra factors which are not an issue in singleplayer missions.

1. FS2_Open evaluates all SEXPs and all scripts on the server. It is important to remember that there may or may not be a player actually on the server. The player might be running the server on the same computer they are playing on, or they may have connected to a standalone server. This can cause problems with certain SEXPs and scripts. For instance, in the R1 singleplayer missions, it was very common to use the key-pressed SEXP to launch the ship. If you try this approach in multiplayer it will work when the player is running the game on their own PC, but as soon as they do this using a standalone server it will fail as no one on the standalone server is pressing that key. 
2. Certain SEXPs simply do not work on client machines. In some cases this is a bug, in others it is simply a consequence of the way they were designed and they can't be fixed. key-pressed and player-use-ai are examples of the latter.
   
3. The player (and other AI ships which could have been players) are able to respawn in multiplayer missions. This must be taken into consideration when dealing with them. You can never assume that the player is actually in the mission at any time after the game starts as they might be respawning. 
4. Players can choose to self destruct and respawn at any time. Never make assumptions that because a player is in a certain place, they can't be at the respawn point a second later no matter the distance between them.
   

Tube launches

Many of your missions for Diaspora will require you to start with a tube launch from a battlestar. This is a significant problem in singleplayer but is even more difficult to achieve in multiplayer since you need to consider what to do if the player respawns. In Diaspora R1, tube launches were handled mainly using SEXPs. This approach is rather cumbersome and as a result Diaspora R1.5 introduces a brand new script based system which can be used in both multiplayer and singleplayer missions. For multiplayer missions, you can't use script-eval because it only evaluates on the server. Instead you need to use the multi-eval SEXP which allows you do say which computers evaluate the script.

In order to have a tube launch, you need 4 steps.

First you need to tell the game which ship is the battlestar. You do this using the tblParShip script.

Second you need to state which docking tube you are setting up.
You then say which ship you are setting up. At this point the ship will be moved into the launch tube.
Finally, you tell the script to actually launch the ship. It is generally a good idea to have at least a single frame delay between putting the ship in the launch tube and actually launching it. The third argument is actually optional. It isn't particularly necessary but its presence prevents the script being executed needlessly on other machines.

For multiplayer you also can face another issue if you launch several ships at the same time. The AI is generally not good enough to deal with several fighters launching (and often being given orders) when very close together. The first time I tried a tube launch with multiple ships they all flew out of the tube and proceeded to smack into each other. The best way to avoid this is with a staggered launch of the ships. In the show we've seen that the Galactica doesn't do launches in sequence anyway ships seem to launch somewhat at random. So here's a way to achieve that effect which doesn't execute needlessly on the other clients.

First we list the ships and set the trigger (remembering not to depend on a key-pressed SEXP!). Then we use the string-concatenate SEXPs to build up the required string. Finally we call multi-eval to actually evaluate the script. This event will of course need to have multiple repeats/triggers (12 in this case since there are twelve ships). The event also has a 1 second delay between repeats but if you wish, you could change that delay by use of variables.

At time of writing it is not actually possible to create this event in FRED as variables can not be given as an argument to string-concatenate. Instead a text editor like notepad must be used to manually edit the mission. Hopefully this issue will be solved soon as it is pretty easy to accidentally screw up a mission using notepad.

Launching from tubes following a respawn

Having tube launches work after a respawn is even more complicated unfortunately, requiring two events for every ship you want to respawn in the tubes (Plus a set up event for all of them). Here's how you do it.

Firstly you set up a variable to hold the number of respawns each ship has. Do NOT use a literal number to set this up. You should always grab the number of respawns from the ship itself for two reasons.

1. It is possible for the host to alter the number of respawns every player has.
2. At some future point, someone may decide to improve on that system so that certain players have a handicap or advantage by having more respawn. If you simply grab Red 1's respawns for Red 2, the mission would break, so this is a good way of futureproofing the mission.
   

Now we come to the three events that actually handle the respawing itself. You'll need copies of both events for every ship you want to respawn.

Firstly you need some way of actually detecting the respawn itself and moving the ship into the tube. This can be achieved thanks to the variable we set up above at the start of the mission, and the respawns-left SEXP. We then write the current mission time (in milliseconds) into a variable.

Next you need an event to actually launch the player. Unfortunately due to the fact that you currently need a frame to have passed between placing the ship in the launch tube and actually launching it, this is a little more complex than simply launching the ship in the SEXP above. Instead we simply use the variable we set above to launch the ship as soon as time has passed since setting it.

In this case the event is also made more complicated by the fact that we don't want the ship launching upon respawn if the mission is almost complete and other ships are trying to land. Launching with only 10 seconds left before the battlestar jumps out is rather silly. So for this reason, this particular event checks if the battlestar is counting down before jumping out, if so the player isn't launched but simply waits in the launch tube for the other ships to land.

The Players_Landed variable is used to count the number of players which have landed (unsurprisingly enough). Since we're not launching the ship, we should increment this variable here.

Combat landings

Combat landings are fortunately much easier to handle as we can simply tell the AI ships to leave the mission and give them a target of the relevant battlestar in most cases. The players of course can handle their own landing so all that is really required for a combat landing in multiplayer are versions of the single player events using when-argument and some minor changes to make them work in multiplayer.

The is-player SEXP is used because the AI ships are simply told to depart via the battlestar in the Wings Editor so we don't want them affected by the SEXP.

The conditions in the OR SEXP are basically the landing conditions used in R1 (Ship is within a certain area or a certain distance from the fighterbay subsystems).

If all the players are down, it's time to jump out. You may have noticed the reappearance of the Players_Landed variable. In another event we simply check the number against the number of players in the mission and jump out as soon as they are equal, end the mission.