An article about running science fiction rescue scenarios,
influenced heavily by Gerry Anderson's
Thunderbirds
From what I've seen of SFRPGs, most scenarios seem to fall
in one of two categories: exploring strange new worlds, and
criminal capers involving stealing spacecraft and/or money.
These ignore the wide range of possibilities inherent in
SFRPGs. This article will attempt to cover one small area, that
of rescue operations.
A rescue scenario requires a setting where a disaster has
taken place, leaving individuals trapped where they are
difficult to rescue. This basic structure is then embroidered
with a range of complications to make matters more interesting
for the rescuers, who are of course the player characters.
Trapped in the Sky.
When writing a rescue scenario, try to find an interesting
setting. This gives the scenario initial interest for the
players, and can provide many of the problems inherent within
the rescue.
Aspects to consider in choosing a setting are the resources
close at hand (a rescue set next door to an robotics factory
could give your PCs a ready-made solution fresh off the
conveyor belt), the technical problems automatically part of
the setting (such as the lack of pressure in deep space), the
people in the vicinity (headhunters in the jungle could be
embarrassing for rescuers), the problems of getting to the
setting, and how much players and GM may know about such
things.
In most worlds finding a good setting should not be difficult.
Depending on the world, a few ideas are high mountain roads,
monorails or railways, deep mines, complex chemical plants,
high towers, deep sea installations, oil rigs, ocean liners,
high-speed aircraft, dirigibles, cable cars, space stations,
advanced vehicles, underground tunnels or tubetrains, or
perhaps a high bridge or a spacecraft. The list is endless: the
above is just what I came up with in ten minutes.
Unusual settings are not obligatory, of course. A good rescue
can equally well be set in a city towerblock (see "The Towering
Inferno" for details) or in an airport.
Brink of Disaster
The second part of an interesting setting is the nature of the
accident. Particularly in technologically advanced cultures,
small accidents can have catastrophic results. The problem is
that catastrophic accidents tend to leave no survivors. When
setting up a suitable accident, people may be killed, but make
sure that some of the victims can survive to need rescuing.
Think about the setting, think what could go wrong, and work
from there to figure out where victims could survive, trapped.
Don't be afraid to put in freak chances - most accidents happen
through a chance incident that had not occurred to the
engineers or designers responsible. Remember also that one
accident can give rise to three or four seperate rescues, for
instance when a bridge collapses in a storm, dumping one
pressurised auto into the river estuary below, leaving another
teetering on the edge of the drop, whilst the bridge crew are
trapped in their control room at the top of the main support
girder.
Accidents come in various shapes and forms. The simplest is a
crash (whether by a plane, a car, or a starship), trapping
people in or beneath the wreckage. Alternatively, the crash has
caused secondary damage, for example to a tower, and the people
at the top are trapped.
Another major form of incident, of course, is a systems
failure aboard a starship or major construction machine, which
is therefore heading for a collision with a city or a dam or a
nuclear power station (as I say, the range of permutations and
combinations are endless). Then we have the hole in the ground,
perhaps from an earthquake, into which a person or vehicle
falls. (A good varient on this is Clarke's Fall of Moondust, in
which a moon tourist craft sinks into a dust-filled crater).
For added problems, there may be a raging fire at the bottom of
the hole. Then there is the monorail or lorry that gets
stranded when a bridge collapses. Another option is the storm
that causes an already weakened tower or vehicle to suffer some
form of failure and get into trouble.
Then there are explosions. Surviving an explosion itself can
be difficult: however, explosions are a good cause of secondary
problems, such as unstable towers or blocked mineshafts. These
are also a good source of fire, always a useful problem. Either
a fire must be stopped before it does more damage (such as
exploding a massive storage tank full of volatile gas), or
people are trapped within a chamber within the fire, and must
be rescued before they fry.
Another major source of rescue missions is sabotage. Good
examples are bombs in aircraft undercarriage, explosives in
monorail tunnels, sabotaged jet fighters, or even the trusty
standby of bombs in nuclear reactors. Remember that sometimes
the operation can be to prevent an accident or disaster
occuring, rather than mopping up afterwards.
However, inventing an accident is easy: the problem is making
the accident one that normal rescue services cannot cope with,
causing the player characters to get involved. The easiest way
of achieving this is to set the accident somewhere where there
are no rescue services; newly colonised worlds are a good
choice here. However, they tend to lack any major structures to
get into trouble. Another solution is to arrange for the party
to have immobilised the official rescue services through a
previous misdemeanour ("Well, you accidentally shot down our
main transport ship, so we can't get to the danger zone. If you
want to stay out of jail, you'd better rescue them."). For that
matter, if you want to run a number of rescue scenarios, the
party could be hired to form the local rescue service.
Alternatively, the PCs might be the only people presently on
planet with the range of skills needed to handle a particular
problem - perhaps a starship has crashed, and only the party
known enough about starship systems to be able to cut through
the wreckage to rescue the trapped crew. Finally, it might be
that the PCs have a vested interest in rescuing the victims,
perhaps because a victim is a friend or knows something the PCs
are after.
Move and you're Dead
The next problem is to make the rescue difficult. A man stuck
at the bottom of a hole is easy to lift out with a few ropes;
however, if the shaft is on fire and the trapped man within a
steel cage that is slowly heating up, the party may have more
of a problem. Good obstacles are fire, poisonous air, water,
and vacuum.
Alternatively, make it difficult for rescuers to get close
enough to carry out the rescue without killing the victims. For
example, if the trapped people are on a high bridge in a partly
derailed monorail, the downdraft from a jet or helicopter
coming overhead might well cause the bridge to collapse
completely. For that matter, the victims might be trapped
inside a vehicle or craft; breaching the craft might let
poisonous fumes in. Or perhaps the accident was within the
ubiquitous nuclear plant; cutting in through the walls might
not be a good idea if the walls in question are those of the
containment vessel. It may be that digging out victims could
cause a further collapse, killing them. Or there may be a piece
of wreckage balanced above the trapped victims, which could
fall at the slightest movement.
Use these with care: only put in additional obstacles if the
basic problem is REALLY straightforward. Often, something that
looks easy during design can provide players with real
headaches. Only when the reverse happens is it worth
introducing a complicating factor, if necessary during the
rescue.
The man from MI5
Another useful complication is bureaucracy and government (and
corporate) departments. If your victims are trapped within a
military complex, it may be difficult to get authorisation to
enter restricted areas. Do the party ignore the military and go
in to get them out? Or perhaps a local secret service was
responsible for the disaster, and do not want PCs getting
involved. Megacorporations often object to nosey PCs wandering
into their plants to rescue people - they may fear industrial
espionage more than burning down their research centres.
Sometimes, a rescue might be straightforward, if it were not
for the local bureaucracy. Do the party want to risk carrying
out a rescue whilst holding a blaster at the head of the local
ruler to keep her army off their backs?
The Duchess Assignment
This leads nicely to the people in the scenario. Ignoring the
victims (of whom more below), any danger zone is likely to
contain a nice range of characters for the party to have to
deal with. It is always worthwhile detailing the personalities
of a range of NPCs at the danger zone, as a source of
complications, entertainment, light relief, and if need be
assistance. Most players enjoy chatting to NPCs, and this is a
good opportunity for them.
The obvious NPCs are the normal rescue service (who may not be
too happy about the party muscling in on their job - perhaps
the local union will turn up and picket the party for
threatening the jobs of the rescue service) and the local
police force (who can range from the redneck type who object to
anything out of the ordinary to the extremely helpful who want
to get involved). There will almost certainly also be
reporters, who at the very least may get in the way and might
well become part of the problem, needing rescuing themselves.
Reporters are always a good source of troublemaking; the
addition of a nosey or pushy journalist can turn a fairly thin
scenario into a classic.
There may also be relatives of the victims (a good opportunity
to stress the fact that the victims are people, not just plot
devices) who will come asking what is happening at awkward
moments or who might give useful information about the trapped
people ("Didn't you know Sylvia is a skilled electronic
engineer?").
Less helpfully, if the accident arose out of sabotage or enemy
action, there may be troublemakers present. There may be a
military presence as already discussed; there might also be the
local area director or land-owner, who may object to the
presence of the rescue craft messing up their lawns. ("Young
woman, if you do not remove that monstrosity you call a helijet
from the cricket square at once I shall have you arrested!")
There may also be sightseers or even autograph hunters. Play
all these people for all they are worth: nothing turns a crisis
into a drama faster than troublesome extras.
NPCs are not always only to be found at the danger zone:
sometimes, a reasonably straightforward rescue may be possible
if (for example) the party can obtain plans of an
out-of-control machine. Trouble is, the only plans are in the
lab of a very awkward scientist hidden in the wastes to the
north, or in the jungles. Getting to the scientist (or
whatever) may be an adventure in itself: getting him or her to
hand them over may be another one. Always think what the
player-characters might find useful in a rescue, and give them
an interesting (not necessarily a difficult) time obtaining it.
The Perils of Penelope
The other important characters are the trapped people. Rescuing
a faceless, nameless person you've never seen or spoken to
carries far less importance than striving to free a man you've
been talking to or whom you can see over a TV link. Always try
to arrange some form of link between rescuee and rescuer, even
if not the other way. (In some rescues, being able to
communicate with the victim may make the operation far easier,
so don't automatically give your PCs this advantage. Don't be
afraid to tell players that for example the victim's radio
receiver is broken, but the transmitter still works). Always
ensure that players know the names of the trapped people; it
makes them far more alive. Good means of communication are CB
radios in vehicles, or monorail cab circuits, or starship
communicators, or even closed- circuit TV (for example, if a
bank official is trapped in a vault, he or she may well be in
view on the security cameras). This is also a useful means to
inspire your players with increased urgency, as they watch the
victims choking or stifling or drowning, or hear their moans
and screams over the radio. It makes the victims into people
rather than plot pawns, and gives the rescue some purpose. If
the PCs do fail, it is more likely to matter to them.
Occasionally, it may be possible to devise a plot where the
rescue victim is actually someone already known to the
player-characters. In particular, if a player misses a session,
his or her character makes a good victim. Of course, if the
character is actually killed, you and the other players may
have to face a very annoyed player!
A careful choice of victim can also be useful for plot
purposes. If the trapped people are aliens, they may not be
able to breathe our air; this may well hamper rescuers greatly,
as well as providing a timelimit. Or suppose Zimmerman, the
only person who knows how to defuse a bomb at a nuclear plant,
is trapped aboard a crashed spaceliner, slowly sinking deeper
into the ocean, to a depth where the fuselage will collapse....
The only problem here is maintaining any credibility -
coincidence can only go so far. On the other hand, it isn't
difficult to provide rationales to link two rescues. To take
the example above, you could claim that the people who set the
bomb deliberately sabotaged the spaceliner to get rid of
Zimmerman.
Thirty Minutes after Noon
This brings us nicely to time limits. All the best rescue
scenarios have some form of timelimit. Timelimits are normally
easy to set; often, as in Zimmerman's spaceliner above, they
arise naturally out of the situation. Anywhere where a vehicle
is moving has an easy timelimit (when it will hit something).
The same applies where there is a fire ("It'll take the fire
three hours to burn through to the trapped men"; or "Our
cooling system can only last forty minutes at the present
level"). Pits filling with water also provide a nice
straightforward timelimit (but be aware of the possibility of
getting air tubes or spacesuits to the victims, turning a tense
race against time into a walk in the park).
If your plot doesn't have any of these useful elements, bombs
are a useful standby for limiting time; so are injured victims,
whose conditions slowly deteriorate.
The Mighty Atom
Any rescue is easy to carry out, if the rescuers have the
correct equipment. It is very easy for players to learn the
facts and then roll out the latest Amclair ZX C-5,000-QL
nuclear-powered drilling mole with atom blaster for breaching
vault walls, with integral emergency breathing systems (or
whatever, as appropriate). This does not make a good scenario.
What equipment the party will have available depends on their
circumstances, and will vary from game to game. However, the
basics that most rescue missions will require will be some form
of transport craft, some form of helijet or lifting body from
which people can be lowered into the danger zone, and a
collection of smaller equipment such as breathing apparatus,
ropes, cutting tools, communicators, lights, heat- resistant
suits, scuba gear, etc etc. Be careful with equipment: players
will always want one extra and useful item, and will always try
to stretch what they can do with it. If their idea is
reasonable, let them get away with it; clever planning is one
of the major means of achieving a rescue. But don't let them
persuade you to allow something impossible or very unlikely.
Think about it in real terms, and tell them their chances and
likely consequences of failure - then let the players decide if
they want to take the risk.
More usually, the equipment the PCs can get hold of will be
whatever happens to be at the danger zone. Think about what
would realistically be there: if the PCs are at a monorail
station, there will be repair kits and similar hardware
available.
If no PCs have the skills to operate equipment they need,
introduce an NPC with a suitable skill. This again provides
someone for PCs to talk to, and brings the scenario to life a
little more. It can also introduce its own problems. For
instance, if the only person who can program a Tandetti F:GME
12/864 model H computer happens to be a keen potholer, and is
currently deep underground, some of the PCs will have to go and
find her. Alternatively, the NPC may just be an awkward cuss
who specialises in being obstructive.
The Uninvited
However, if a party's carefully devised rescue plan worked
every time, the game would soon become very tedious. There must
always be an element of uncertainty in any rescue mission. For
a start, the party may not succeed with a part of the plan: it
is all very well intending to climb down the shaft and attach a
cable to the fallen lift cage, but if the climber slips the
rescuers may end up with an extra person to rescue. Always make
PCs exercise their skills in carrying out a rescue; just
because a PC has piloting skill, don't let her hold the helijet
over the chasm whilst her colleague is lowered down to the
monorail - make her roll to keep it steady. Make it clear to
player-characters that they CAN fail; if they slip up badly,
the victims will die. (On the other hand, do not automatically
kill victims if the PCs fail just one roll; always give them a
second chance, though you may require a trickier roll in some
cases).
Secondly, use the NPCs to keep the scenario alive and moving.
NPCs are not automatically going to do what they are told to -
though make sure you can justify why an NPC acts in a
particular way. If a party have had a chance to talk to someone
in whom they intend to trust, and didn't, they should not be
surprised if that person turns out to have a good reason for
not co-operating. ("Why won't you help?" "Because that bitch
down there seduced my husband! I hope she fries!")
Thirdly, there may be factors about which the party are not
aware. The first of these is sabotage; where an accident arose
out of sabotage, the saboteur may wish to hamper rescue
operations. Be careful with this: in a difficult rescue, a
clever saboteur may be able to kill the rescuers as well.
Always think what effect a saboteur could have before using
one.
The other matter that rescuers may not be aware of is problems
on site. A straightforward rescue may turn into a nightmare if
the rescuers discover that the truck balanced on the brink of a
cliff is actually loaded with volatile nutomic charges. Or how
about finding out that the logging machine out of control is
heading for a dam? Or perhaps the site of the rescue contains
some hidden hazard. ("I can't use a laser to cut them out of
there: if I do, I'll ignite the flammable Luminite packing on
the walls. Didn't you know about the Luminite? The construction
team used it because it was cheap.")
Also, the rescue may run into problems while it is underway.
Perhaps a fire will start as a result of the rescue, or a water
main will burst, or an electrical fault will plunge the danger
zone into darkness. This is a useful backup to have in reserve
if a scenario lacks tension.
Security Hazard
Finally, of course, the rescue operation may well lead into
another scenario, particularly if sabotage or enemy action was
involved. Some routes into other scenarios are obvious; but
others may occur. For example, if the party find out during the
course of a rescue that a particular monorail or machine was
unsafe due to shortcuts by the construction crew, they may have
to deal with murder attempts to silence their testimony.
For that matter, during a rescue, the party might cut through
into a previously unknown tunnel complex requiring exploration;
or perhaps a transporter, flying to the danger zone, may pass
over a mysterious pyramid that needs investigation. Or perhaps
the security service may decide that the rescue service might
provide a useful cover for a spying operation, with all the
ramifications this could lead to.
It might also be that some other group may impersonate the
rescue team in order to commit a crime, thus forcing the real
rescue team to find them to clear their name.
Or perhaps a rescue mission may mess up some illegal scheme,
angering the criminals involved, who might well try to get
even. The possibilities here are endless.
Give or take a Million
This article is not designed to provide suggested rule
mechanics for rescue scenarios. Basically, the simplest method
for determining rules is to settle the skills needed, and think
of a probability. Don't be afraid to fudge this, or change the
decision after the players roll. Obviously, systems like Star
Wars that have difficulty levels are better for this than
systems like Traveller that are showing their age. The
important thing, though, is to make the players think they are
having a tough time and to keep things moving, rather than to
get bogged down in pages of tables and the minutiae of rules.
End of the Road
Hmmm, not bad, 3,600 words without saying "Thunderbirds" once!
For anyone who hadn't worked it out, the major source for this
article is a certain well-known puppet series by Gerry and
Sylvia Anderson, which is heartily recommended as a source of
ideas and scenarios. The basic structure is normally the same;
it is only the plot details and the trappings that change. The
Andersons managed to keep the formula going for 32 episodes and
two feature films without any serious problems; just writing
this article I have come up with half a dozen other plots that
should work just as well, and I suspect most readers can do far
better than that. As astute fans may have noticed, many of the
examples above are based on episodes from the series (sorry, no
prizes for identifying them), while all the section headings
are episode titles.
Acknowledegements
- Thunderbirds:
- the classic rescue service puppet series. Now available
as a T-shirt.
- SIG magazine:
- this is the official Gerry Anderson fan club magazine,
and is available from NGale publications, 13 Primrose Avenue,
Squires Gate, South Shore, Blackpool FY4 2LJ.
Back to
Traveller Page