                                  DROP DEAD
                ADVANCED DEATHMATCH VARIATIONS FOR QUAKE v1.01
                               By Walter Lord
                          With Inspirations by Many


PRELUDE:

This is the first release of a set of alternative Quake source devised to make
deathmatch and teamplay more enjoyable.  It will be updated with new features
and will be recoded as dictated by each new version of Quake.  Future versions
of this set of Quake source will have the following naming convention:

     DDqqqVvv.ZIP

Where DD is the Drop Dead abbreviaion, qqq is the version of Quake for which
it is coded, and vv is the version of the source.  The first release could
have been aptly named DD101V1A.ZIP, but I choose DROPDEAD.ZIP to better
attract attention.

A registered version of Quake is required along with the Quake C compiler.
To use Drop Dead features, you must create the following directory structure:

    /QUAKE          - The root Quake directory.
    /QUAKE/DD       - The base directory for Drop Dead files.
    /QUAKE/DD/PROGS - The location of the all Quake and Drop Dead source.

Copy all the original Quake source modules into the /QUAKE/DD/PROGS
directory and then overlay them with the Drop Dead modules.  Be sure to
include the Drop Dead PLAYER.MDL file in this directory.  Now compile the
Quake source by typing QCCDOS or QCC (depending on whose Quake compiler you
are using).  Drop Dead should now be ready to go.  Simply add "-game dd"
to the command line when you run Quake (i.e. QUAKE -game dd).  When running
an internet server, I request that the server name include Drop Dead or DD to
aid players in identifying use of this program.

To report any bugs, make comments, or provide suggestions, please Email me at
Lord@Brodart.com.


HISTORY:

As much as I love Quake, I was a little disappointed by its Deathmatch/Teamplay
capabilities.  Sure, you no longer get the lockups that were prevalent in
Doom, but I missed the monsters in Deathmatch and found Teamplay allowed way
too much cheating.  I'm sick of some Joe belonging to the RED team temporarilly
changing colors so he slip in amongst the ranks of the BLUE and then change
back to RED and massacre the lot.  Sure the carnage is neat, but the gameplay
sucks!

Then I recently came across some source written by Dennis Noordsij that
offered skin textures for teamplay.  It still linked each team to a color but
definitely made it easier to tell friend from foe.  Included amongst the
textures are Duke 3d, Terminator, Stormtrooper, and about a dozen or so
others.  With keys linked to impulses, a player could select which texture he
or she desired.  Better yet, a player, without the source installed at his/her
end, could still play but would only see the default Quake Guy.

I took off with this concept and have added the features listed below.


PREDEFINED LOCKED TEAMS:

The server can now be easily configured for multi-team play.  Up to four teams
can be defined with each team having its own skin texture and its own color.
The default teams include RED (Default Quake Skin), YELLOW (Duke 3d),
WHITE (Stormtrooper), and GREEN (Toad Skin).  By adding a line which reads
teamplay followed by a 2, 3, or 4 to the CONFIG.CFG file, the server will track
two to four teams.  This line can also be typed in Quake's console which is
displayed during gameplay by pressing the '~' key.  Better yet, players CANNOT
switch teams!  When a new player enters the server, he is automatically
assigned to the most needy team - the team with the fewest players.  In case
of ties, he is assigned to the team defined first.  Using this logic, players
on a local network can still choose sides.

The default teams can be reconfigured by editing the WEAPONS.QC source - look
for the section near the top dealing with teams.  I pretty much leave editing
the source up to experienced programmers adding that the actual_teamX
variables, the DisplayTeam function, and the ConfigTeam function need only be
changed.  Note that the actual_teamX variables pertain to the team color plus
one.  Also note that there are 19 skins numbered 0 through 18 and listed in the
DisplaySkin function.  I would prefer to have placed all the teams options in
variables, but the current version of the Quake compiler is not happy with
string constants.  : (


TEAMMATES NO, SELF YES!

Teamplay has also been slightly altered.  Teammates still cannot be hurt by
other team players.  However, a player can now injure himself - so beware of
genade and rocket blasts!


GAME OF TAG:

If teamplay is set to 5, Quake takes on a variation of tag.  One player
is IT and the other players must "tag" him.  The player who frags the IT
player gains three frags and becomes IT.  If the IT player can survive, he
will earn a bonus frag for each minute he remains alive.  The IT player takes
on the features (color and skin) of team two while the other players take on
the the features of team one.  By default, the IT player has a Duke 3d skin -
thus everyone is out to get Duke!  : )  However, note that team damage rules
are turned off - any player can hurt any other player.

For a different variation of tag, set teamplay to 6.  This variation allows
an IT player to tag another player IT by touch.  Now the IT player can sneak
up on another player, tag him IT, and gib him to earn three frags.  Instead
of fleeing, as in the first tag variation, the IT player tends to actively
pursue.  Note that, after becoming IT, a player cannot tag another for two
seconds.


DEATHMATCH MONSTERS!

Yes, one thing missing from a Quake deathmatch is monsters.  Now the
deathmatch variable can be set to 3 to indicate play with monsters.  It can be
added to the CONFIG.CFG file or entered at the console.  Note that when a
Quake server is configured from the menu, the deathmatch variable is ALWAYS
reset to 1, so you must then manually rekey it to 3 at the console.  You may
also want to key "restart" to respawn the level and add monsters.


SOLID, GIBBABLE CORPSES:

Now anyone or anything that dies (but is not gibbed) can be blasted into
pieces!  This makes for some nice bonus carnage and some interesting piles of
bodies.  The corpses are also solid and serve as speed bumps and sometimes
blockades.  I do not claim to have originally penned this concept - merely
refined it by including player corpses as gibbable and allowing jumps while
standing on corpses.  I also fixed a problem with corpses becoming suspended
in mid-air when corpses beneath it are gibbed.


NO MORE SKIN CHANGES:

Sorry, Dennis.  Skin changes can no longer be made on the fly.  With the team
concept in mind, this feature became unwanted.  As mentioned previously, a
player is automatically assigned a skin based on his team.


KNOWN "BUGS":

Currently, the only known bug is the occasional stuck fire button.  This
appears to take place when DD is doing a player color change, such as when
assigning teams or when an IT player is tagging another player, and a
weapon is being fired the exact same time.  As soon as the fire button is
pressed again, the stuck condition is relieved.  I've spent a good deal of
time trying to remedy this condition, and I've concluded that it is an
internal problem in Quake and NOT my code.  It appears that when a color
change takes place Quake momentarily stops monitoring the fire button and
sometimes loses the button state.  It does not happen often, so the game
play is rarely interrupted, but if anyone has a solution for this problem,
I would like to hear from you.  Please Email me at lord@brodart.com.


A FINAL NOTE:

To use this DD source, the server should be version 1.01 Quake.  Future
versions may work with this source, but then again...  The Quake compiler
should be intended for the version of Quake being used.  I do not know the
memory requirements caused by addition of several player skins, but I venture
to guess that 10 MBs may be in order.  If people report memory problems, I
may simply reduce the number of available skins or may make a generic MDL and
and extended MDL (a superset of the generic).

Other than altering teams, I do not recommend changing the layout of the team
code.  Quake is rather particular about when certain functions and code can
and can't be performed - especially during the think processes and level
changes.  I've taken alot of care and time in laying out this code.  If you
see any necessary improvements, have any useful suggestions, or find any bugs,
please contact me (Walt) at lord@brodart.com.
