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.
Multiplayer missions require you to take into consideration
several extra factors which are not an issue in singleplayer
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.
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.
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.
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.
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.
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.
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 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