Quake2 was released in December 1997, and QdQ started planning
a speed-run through it straight away. So why hasn't anything
been released yet? (As I write, it is May 1999.)
Skip to the conclusions if you don't
want to listen to us apologise and moan, and would just like
to know when the thing is likely to be done.
Changing physics
The first problem was the instability of the game itself. Quake2
underwent many version changes for the period following its
release.
New versions of the game aren't necessarily important
to us. For example, Quake1 has had a few updates, but these have
been irrelevant for our releases because they did not affect
the gameplay found in the original levels. However, the changes
made to Quake2 have regularly affected the physics of the game.
This meant that the routes and times that are possible are not
consistent across the different versions.
QdQ decided to wait for id to finish work on the game and
release a stable version before beginning proper recording,
since otherwise all our work would become outdated. The game
physics finally stabilised when v3.16 was released. There have
been further updates through to the current v3.20, but these
have not affected physics, and we are
optimistic that there will be no further changes.
No source
We record our runs level-by-level and then put the resulting
demos together in continuity to produce our final finished runs.
To do this, we need to write special recording utilities. For
Quake1 we used the game mod QdQstats.
For Quake2, we use something similar, q2timer.
Unfortunately, we needed the gamex86 source
before we could update our q2timer mod to use the eventually
stable game physics found in v3.16. Even more unfortunately,
id Software took a very long time to make this source public.
Mod authors throughout the Quake2 community were drumming their
fingers for quite a long time.
Source for v3.20 turned up in December 1998, one full year
after the release of Quake2. Until this point we were waiting
for materials from other people before we could properly begin
the project. After this, any delays have been down to us alone.
Hub system and new technology
The hub or unit system found in Quake2 greatly complicates
the recording of a continuous run in piecemeal fashion. In
particular, when one returns to a level that one has already
visited, one needs to find things in a state consistent
with how they were when one exited previously. This was difficult
to deal with, which delayed q2timer.
Also, in Quake2, continuity is precise all the way through the game.
If we improve a recording of an early section, the game
continuity will be slightly changed, and so all existing
following recordings have to be modified to take these
changes into account.
We faced the same sort of challenge in Quake1. But there,
every so often your stats are reset to some
default values. (At the start of every level, health is reset
to be between 50 and 100, and at the start of every episode
all stats are completely reset.) As a result, we were just
about able to deal with the problems by post-processing demos.
However, the route that id intended a player should take through
Quake2 has around
sixty individual sections, and continuity has to be precise across
all of them. The only way to maintain reuseability of existing
Quake2 recordings in the face of improvements to earlier parts of
the Q2dQ2 run is to log extra information about item collection
and use at the time the recordings are made with q2timer,
and then process this information later to cope with improvements.
We are very pleased to say that this system seems to work -
but it was very tough to implement! Q2timer reached a useable
state in February 1999, and our other tools began to ripen by
around April. This necessarily slow technology development rate
delayed the project a great deal.
Quake2 running politics
Since the above delays also prevented much Quake2 speed-running
from occurring, enthusiasm for and talent at Quake2 running
took rather a long time to emerge. Without effective runners,
the project slept.
There has also been a lot of debate about the issue of
strafe-jumping (known as bunny-hopping by QdQ.)
The original
Quake1 runs QdQ, QdQr and QdQlite were all recorded without
the use of this speed-up trick. It was only later in the life
of Quake1 speed-running that it began to become useful. Opinion
is still divided over whether or not it adds to the enjoyment
of watching speed-runs, though.
The effect of strafe-jumping in Quake2 is much more troublesome.
It has a much more pronounced effect, and seems to be very much
framerate dependent. Even at this stage, differences in the
quality of people's systems will mean that they are able to
take different advantage of strafe-jumps in speed-running.
This unfairness would make life difficult for Q2dQ2 since only the
players with the best machines could record the fastest times,
and those with less good machines would have little incentive
to contribute to recording. Yet without their contribution and
inspiration, the project would be much the worse.
To deal with these concerns, QdQ decided to restrict the use
of bunny-hops for Q2dQ2. We bunny-hop only when it is necessary
for us to perform a particular trick, not just to maximise
overall velocity. This is an arbitrary restriction, but it was
arrived at fairly and carefully.
A later run when machines are faster may well allow bunny-hops.
We hope Quake2 speed-running can thus evolve smoothly as Quake1
running did, with bunny-hops becoming important only as skills
and machines improve.
All of the above added up to a lot of delay, for which
we apologise. We apologise further for those parts of the
delay which were as a result of us having lives and thus not
being able to give full attention to the project every hour
of the day. Don't read that as me being sarcastic, by the way.
The commitments we make as QdQ really are very important to us!
Real life is often an annoying distraction.
The great news is that the end is in sight.
Proper work on Q2dQ2 recommenced at the end of March 1999.
As I write this two months later, we are completing the
recording of the eighth of the ten units of the game, and
are hoping to have our first complete run recorded within the
next few weeks. At this stage, the time is expected to be around
twenty minutes.
This will just be a collection of speed-run demos, of course,
and not a movie. We still have to make a formal decision in
what to release and when - but I suspect we will be keen to
make stuff available in some form as quickly as possible. You've
all been patient for far too long!
Thanks,
Anthony. (1999/05/29)
Older material
The stuff below is outdated and almost certainly includes
information that is now wrong. Still, I've kept it published
for the sake of historical context. (Anthony, May 1999.)
We're certainly looking forward to making a speed-run of Quake2. You
can be sure that Quake2 done Quick2 will come to be.
The main routes and tricks have been planned, although doubtless they'll
be tweaked and improved a lot once recording begins.
(If you want to get involved in this project, please see our
projects page for details on
how to go about doing that.)
So, why haven't we recorded anything yet?
Well... there are one or two technical complications. Here are the
issues that have led to the delay, and also some others regarding
further decisions that the QdQ group have made about Q2dQ2.
Physics in flux
With Quake, we were actually more fortunate than we ever knew. id Software
released a few versions of the game to address a few bugs and include
new features for the mission-packs, but these changes were relatively
infrequent. Basically, we just have the release version Quake v1.01,
the updated v1.06, and then v1.07 for Mission Pack #1 and v1.08 for
Mission Pack #2.
The important fact about these versions is this: the physics of the game
remained unchanged throughout. If you could use some trick or bring off
some neat move in one version, you could do the same in the other versions.
From a physics point of view then, they are all the same game.
However, the game physics and universe in Quake2 have been different
in different versions. Our choice was to wait for things to stabilise;
it took far longer than we expected it too when we made this decision,
but since a different game physics basically means one is playing a
different game, we felt, and still feel, that we need this stability
in order to make a valid run. We believe that the latest versions of
the game (from around v3.16 on) give us the stability we require, just
about. Here's a brief history. (This used to be a short document,
you know. :) )
The first few changes up to and including v3.14 have included
map bug fixes, the removal of the "jump on landing" trick, changes
to the rules about how many power-ups can be carried at one time,
and some fixes to the client-server architecture that affect the
speeds that one runs at.
These various versions of Quake2 are similar, but they can't
quite be regarded as the same game. Therefore any deviation from the
agreed-upon standard can't be acceptable as a recording for the
Q2dQ2 run, and we won't count them as "comparable."
It's a shame to have to be picky about this, but the devil hides in
the details, and we want to be sure there is a level playing field.
We would advise others running speed-running challenges
to pay attention to these issues as well.
As of v3.14, we were down to two complications. One was a slightly
freaky physics that allows one to reach higher than normal speeds
with tricks such as bunny-hopping. The use of this trick in Q2
speed-running is controversial, and has been the cause of much
debate: should a "silly" or an "ugly" trick that works be disallowed?
The other complication is that when the client framerate drops below
the 10fps that the server expects, the movement physics break. The
most noticeable effect is a big increase in player speed. At the
default minimum framerate of 5fps, the player velocity is twice what
it is normally. This phenomena is obviously easily abused, and can
cause problems even when one wants to record an honest run. Fortunately,
v3.14 provided a console variable cl_minfps that controlled
matters. Setting it to 10 removes the problems. There are more details
in a section below devoted to this phenomenon,
written when v3.14 arrived.
Zoid made various further changes to the player movement for the v3.15
release. These included the addition of QW-style control-in-the-air.
In the course of implementing this, he also fixed the bug that
allowed tricks such as bunny-hopping, and there were great sighs of
relief all round.
But alas, another less pleasant change was also made. The
cl_minfps variable was removed, and it's default value
of 5 effectively hardcoded into the unmodifiable game executable.
Since the physics are broken with this value, v3.15 becomes unsuitable
for speed-running. This problem is still current as of the latest
release at the time of writing, v3.19. (Incidentally, this version will
also return the default air physics to their original state, with less
manoeuvrability whilst airborne. This may deny us a few opportunities,
but we'll play whatever cards are finally dealt.)
However, a fix for the problem at the game.dll
level has been worked out by Nolan Pflug. Since everyone uses his
q2timer game
modification for Q2 speed-running anyway, incorporating this fix into
the mod and insisting on its use would seem finally to
solve all the problems.
So, why the current delay?
We will use Nolan Pflug's
q2timer patch
There's no displayed timer in Quake2, and no finishing times are
displayed when one completes a level. However, time is measured within
the game the same as normal. A simple DLL patch can be used to record
and display the times that runs take. We hope that it can become a
"standard" patch that anyone wanting to speed-run can incorporate into
their own game DLL.
The problem is that one needs game.dll source
code in order to update q2timer to tally with the latest
versions of the game. The most recent release of source code was v3.14,
before the bunny-hopping fix. At the time of writing, id Software's intent
is to release source once v3.20 has been finished, so our hands are
tied until then as far as recording goes.
We are working on routes and tricks currently, so we will be able to
start recording a first run as soon as the source and hence the
modified q2timer arrives. Watch the updates at the
Speed Demo
Archives for the latest news on q2timer and Quake2
speed-running in general.
Q2dQ2
will be recorded on HARD skill (skill 2)
skill 3 does exist in Quake2, and in the more recent
versions it displays as "HARD+" on the computer. However, this
skill level is not mentioned in the game documentation, and cannot be
selected through the usual game interface, only through the
console. Our overall view is that HARD is the most difficult
"official" skill level, and therefore that is the level at which the
Q2dQ2 run should be played.
This was a tricky decision to reach - there's an argument for playing
on skill 3, even though it isn't part of the game as
advertised, since that's "sort of the traditional Nightmare skill"
that QdQ have previously used. Still, overall, we think it's probably
the better option to use skill 2.
One extra factor that makes HARD+ a less attractive optiom is that
unlike on Quake Nightmare skill, monsters will never go into pain. In
Quake1, enemies went into pain the first time you hit them, and this
was an important feature of much Quake1 speed-running. You would hit a
monster once to stop it from getting in your way and blocking the
run. Losing this feature would seem to be a shame, forcing a runner to
kill more enemies rather than dodge them. Destroying every last Strogg
is an option better left as a choice in a 100% run than as an
obligation in a "pure" speed-run.
Of course, the "lite" team will be wanting to beat the game even
quicker on skill 0. The damage and power-up rules are
different on this skill, so new tricks and strategies will be
possible.
Recordings will run from a map entry to a map exit
Quake1 was a linear affair in which each map was run once. Quake2 is
different, with units (aka "hubs") of interconnected maps. QdQ built
up our Quake1 runs by recording and working on one level at a
time. The best compatible performances were joined together to make
the finished run.
We will work a similar way in Quake2. We will take the minimum length of
recording to be from when a player enters a map to when they exit it.
A run through a unit will be made up of a sequence of such recordings.
We will also make sure that there is no messing around with entity
positions when maps are re-entered - thus if we leave the entities in
a map in a certain circumstance, any future recording on that map must
proceed from that same circumstance, so all entities have a continuous
history, just as happens when playing the game normally. So the final
Q2dQ2 run will be a "proper" run through the game, just
as QdQ was.
This one is simple enough in practice. The client console variable
cl_minfps has a default value of 5. Anyone
recording a speed-run should change this value to be 10.
In version v3.14 (when this section was originally written), you could
do this by typing "cl_minfps 10" in the console,
or preferably you can enforce this automatically as well as getting
lots of other nice runner-friendly features by using Nolan's q2timer patch. Demos recorded with lower
values for cl_minfps
should be considered illegal in the same way that changing
host_framerate was in Quake1 speed-running.
Basically, the default value
for this variable allows the game physics to exhibit buggy
behaviour. You can achieve a running speed of up to twice as fast just
by changing the amount of work that your machine is doing
(e.g. by pumping up the resolution.) If you lower
cl_minfps even further, you can get even faster speeds.
This is broken. This is wrong. Basically, it is unfair and will make
any speed-run challenge pretty arbitrary and pointless unless the
value of 10 is enforced.
Having evangelised for this rule, we should take some time to explain
what's going on here. As we said, the (broken with respect to running)
default value for cl_minfps is 5. This means
that the client will run at a rate as low as five frames per game
second if the client machine isn't fast enough to cope with a faster
rate. However, the server code that handles game physics calculations
works with a fixed rate of 10fps. If it doesn't get what it is
expecting, all the calculations about the movement of the client go
wrong. The net result is that the player runs faster the slower the
client machine is processing.
This will make speed-running challenges intrinsically unfair, since
some competitors will be playing with a different top velocity. It
would cause enough trouble even if it only happened by
accident. However, since a dishonorable runner could use it
purposefully to gain even more of an advantage (i.e. break the game
physics even further) by for example upping their resolution, running
GL in software mode, or lowering cl_minfps further,
anyone adminstrating a speed challenge or league needs to explicitly
enforce the cl_minfps restriction, or everything will get
very messy.
There is a good reason for the default value of 5; on slower machines,
it will make the game appear to play more smoothly (albeit with a
completely broken physics.) The default was an understandable
compromise; it was an unfortunate one, however.
cl_minfps 10 does appear to fix all speed-physics
anomalies, and our thanks are due to John Cash for his help with this
problem. It's thus rather a shame that id removed this variable, thus
undoing the fix, in later versions. As mentioned previously, however,
some messy but tolerable hacking in the final q2timer will
enforce the fix and make the game suitable for competitive running
once more.
Notes on Quake2 tricks so far
As with most of our Quake runs since after the earliest ones, we'll
be keeping most specific tricks in-house whilst we record, rather than
explaining them all in detail and in public as we go along. We think
it adds to the enjoyment of the final run if we can give you a
"HIP3M1 moment" that catches you by surprise. But here are a few
general notes on some Q2-specific speed matters.
Knockback
In Quake1, player entities received a velocity change directly
proportional to damage inflicted. Very simple and straightforward.
In Quake2, the velocities of all entities can be affected by
damage. The calculation is more complicated. Firstly every bit of pain
comes with a separate "knockback" parameter for affecting velocities,
so the effect is no longer tied to the amount of damage done. Secondly
every entity has a mass; the bigger they are, the harder they are to
push around. The player is relatively light (200 mass units, being
female doesn't seem to affect weight.)
In general, id toned down the knockback effects of damage, so I don't
think you'll be able to bounce players with the RL, etc quite as
effectively as you could in Quake1. Because it works on everything now
though it will be plausible to knock monsters off ledges and so
forth. Also, since the toning down would have made rocket-jumping
rather pathetic, they included a special hack so that knockbacks done
to the player by their own weapons are three times as powerful as
those done to enemies. (Of course, as already mentioned, damage is
also halved in this case.) Damage from other things will tend to have
less knockback and not be so useful (which explains why e.g. the
barrels don't send you to the ceiling even though they do three times
as much normal damage as a rocket-jump.)
All this means that damage-boosted jumps will be even more complicated
in Quake2, with many layers of subtlety to getting the most out of
this sort of trick. But more complexities mean more loopholes and more
short-cuts. It's going to be
great. 
Saving power-ups
In lower skill levels, you can hoard power-ups and activate them
simultaneously. There are restrictions on doing both these things on
HARDer levels. This makes game tactics quite different on different
skills.
Diagonal running
When other forces (such as water currents) are
keeping one's speed under the limits Quake2 is imposing, diagonal
running can be effective.
Bunny hopping
This technique of jumping forward and from side to side is definitely
effective in Q2 in versions before v3.15, allowing faster velocities
than running along the
ground in a straight line. There are concerns that it might not be in
the best interests of speed-running Q2 to allow it (a la zigzagging and
bunny-hopping in Q1.)
Double-jumping
Yes, we're making lots of use of this method (and many other
related tricks) to reach otherwise inaccessible heights
and take resulting short-cuts throughout the run.
