Up Against The Wall!
About a month ago I wrote an article here on PlanetQuake entitled ZigZagging
Through A Strange Universe. Within it, I had a look at some of
the weird physics anomalies in DooM and in Quake, and I described one new
trick in particular, "zigzagging",
that lets you run a bit faster than normal. If you haven't already taken
a look at the article, I'd suggest you do so now, to set the scene for
ZigZagging Through A Strange Universe generated quite a lot of
interesting e-mail, as people wrote me about other odd bits and pieces
of Quake they'd noticed, and also related a few zigzagging experiences.
Most importantly, an entirely new trick for
running fast came to light as a result of several people independently
playing with the QdQvel Quake-C modification for measuring running speed.
Whereas zigzagging can increase speed by around 20%, but will murder
your fingers and keyboard, this new technique can give at least double
that speed-up, and is no more difficult to do than DooM's strafe-running
was. Now, zigzagging can be useful, especially if you learn to use
it effectively. But all but the most serious Quakers may well find
it is more trouble than it is worth. However, wall-hugging
is a different matter. If you play multiplayer and speed is ever
an issue for you, you'll want to know about this one.
But all that in good time. I'll start by looking at some of the issues
that were raised in response to the previous article.
Some people wrote to suggest answers to one or two questions I asked
about the history
as well as noting that in some ways the idea actually dates back as far
Talking of things that date back to DooM, a few people rediscovered
the mathematics behind strafe-running
and wrote to tell me all about it. Thanks, folks, but of course it doesn't
work in Quake...
Well, in fact, that's not altogether true: whilst it won't do you any
good in regular Quake, where you already run fast enough in a straight
line that taking a diagonal path would take you over
the sv_maxspeed limit,
it can be useful in some Quake variants. An example of this is found in
some of the characters have much slower speeds than others, and hence sv_maxspeed
is higher than their running speeds. Soldiers, for example, should find
diagonal running to be effective. Thanks to God Virus for that one.
With regard to the comment about speed
that I made in the previous article: although players with faster machines
will find they can swim faster in single-player games, in network play,
only the speed of the server is important and so all players on the same
server will have the same capabilities. This situation will come up again
when considering wall-hugging, and is
a result of some facts
about client and server framerates.
There is one additional strange fact about water (thanks, Rob Butler):
you don't need your head above the surface in order to breathe. You're
fine as long as any part of your body is in the air (e.g. your feet.)
The air that Quake-guy breathes is also the air that you jump through;
pretty strange too,
We really, really, really wanna zig-a-zag-ah
Zigzagging is hard to do by hand. It's very tiring, and it takes practice
to get right. As a result, it would be nice to do it automatically. In
the previous article, I suggested that aliases
for doing it were rather tricky. There are two main reasons for that. Firstly,
the effectiveness of the alias will be reliant on both the client
and server framerate
- this varies from situation to situation and from server to server. Secondly,
whilst the alias is running you can't send other commands - which means
sacrificing some of your, er, self-control.
Still, both these problems can be combatted, even if they can't be solved
Steady as She Goes
To make the client framerate a little more reliable you can momentarily
freeze it by setting host_framerate for a short period. You can't
do this for long, because the client and server will drift out of sync
and cause a disconnect. But for short bursts, it doesn't seem to cause
For example, here's something one often sees requested by keyboarders:
a totally reliable alias to perform a one hundred and eighty degree turn.
It will work in single-player or in network play.
alias turn180 "host_framerate 0.03; wait; cl_yawspeed 8000;
+left; wait; -left; cl_yawspeed 140; host_framerate 0";
There are three things to note about this, by the way
- Changing host_framerate is definitely cheating in the realms
of single-player Quake. It's also perhaps pushing the edges of the
acceptable in Net play
to do it on the client.
- The value used for cl_yawspeed presumes you are using the
"run" key (i.e. +speed
is on) and that cl_anglespeedkey is set to its default of 1.5.
Without using +speed, the figure you require is 12000 rather than
8000 (which is equal to 12000 / cl_anglespeedkey).
- You should be playing with the mouse anyway, llama!
The same idea can be applied to zigzagging. The details can get complex,
and really everybody should fine-tune their own aliases to fit their playing
style and normal display framerate. But as long as you are changing direction
at a fairly regular rate of about twenty times a second, that's the main
thing. You can inspect my own little zigzag
alias file to get an idea of how you might work things. I owe a million
thanks to Matthias Buecher for all his experimenting and investigating
into how practical this was - here's his own short, sweet, and pretty effective
alias for zigzagging:
I'm Out of Control!
alias zigzag "+moveleft;wait;wait;-moveleft;+moveright;wait;wait;-moveright";
bind h "host_framerate 0.01;zigzag;zigzag;host_framerate 0";
If you don't mind sacrificing control of the yourself for a longer period
of time, you could write an alias that zigzagged maybe fifty or a hundred
times without you having to do anything. Trouble is, you won't be able
to do anything else much, either.
You will be able to steer with the mouse (though not with the keyboard
- but of course, you already use the mouse for this, don't you?) but you
won't be able to stop going forward, or switch weapons, or jump, or start
But sometimes, this doesn't matter. If all you really care about is
getting the hell out of there because some fragger behind you is about
to finish you off, that would be an ideal time to risk letting the machine
zigzag you out of there.
The other thing is that although you can't start or stop firing, you
can carry on doing it. So if you send an +attack command
by pressing fire and then start the long zigzag alias before sending -attack
by letting go of the fire button, you'll carry on shooting all the time
that you zigzag. This variant is useful when in hot pursuit. Thanks to
Triton for this idea.
Finally on the zigzag front, John Cox wrote to me with a story about
a broken Logitech Trackman Marble trackball that did something rather like
zigzagging all the time because some of its sensors had broken off. It
was apparently very useful for racing up and down corridors, but I'm not
sure he advised wrecking your trackball for use in regular deathmatch.
Hugging the wall
That's enough looking at ways to make old and flawed tricks more useful.
Here's the new trick. To understand the way in which it works, or to get
the very last drop of utility out of it, you'll have to understand quite
a lot of technical stuff; the ins and outs of the server framerate,
between +speed and the "Always Run" option, a complicated
between various angles, framerates and client-side variables. (You might
also want to consider how far you can play around client-side before it
But although the explanation and the exact details of the trick are
painfully complex, the basic technique is ridiculously simple, and you
can go off and do it straight away:
Whilst running along a corridor, strafe into one of the walls at the same time.
You'll probably want to use dedicated keys for strafing left and right, since fine-tuning the angle you are at relative to the wall helps maximise your speed.
Credit where credit is due: the person who discovered this technique
the first, as far as I am aware, is Matt McChesney. He also built a little
testing map for checking things out in which I found very useful. Thanks,
Matt. Walter Elly and Chris Elly also wrote to us with news of it too.
I'd like to thank all three people, not least for being so kind as to write
to QdQ and thus
give us a chance to research it properly before publishing this article.
The first question to ask is: if it's something so simple, and it makes
you go quite a bit faster, wtf didn't anyone notice before they had the
to play with? One might assume that some people have known about this for
a while and wanted to keep it for themselves. Hey, if every fragger has
been beating you recently, maybe you've found your excuse, right? They
knew about this all along! Well, as the Weenie
Guide would say, maybe - but it's much more likely that you suck.
Ah well, maybe you'll have the edge again until they read this article.
I messed around a little with the previous QdQvel patch to
make it more useful for tracking how you're doing when practising all these
new version will track such things such as average and maximum velocities
so it should be easier to read and use.
Now, on average, most people find they get a speed of more than 400p/s
using this method. Normally, significantly more: anything up to a 40% speed
increase, which is about the same as the speed-up provided by strafe-running
in DooM. But depending on the circumstances, you can optimise this further
- in the most extreme conditions, I've recorded speeds almost as high as
500p/s, which is really pretty speedy.
I'll now go through the factors that have an affect on the best speeds
you can reach.
The greater the frequency with which the physics of the game are calculated
(i.e. the faster the machine running the Quake server), the faster will
be the maximum speed you can get to.
Note that this does not mean that those playing on a better machine
will have an advantage in multiplayer. Well, not any more than normal,
anyway; the smoother display and the extra precision allowed by a higher
client framerate are already very useful for players on fast machines.
But the actual physics of the game, and hence the abilities of the players,
will be equal across the server you are playing on. This is a good thing,
as one wouldn't want multiplayer Quake to become any more inequitable than
variable ping-times already make it.
It does mean that in order to get the most out of wall-hugging,
it helps to know the server
To the best of my knowledge, there isn't a general way in which to do this
from the client end.
It also does mean that in single-player competitions, a faster machine
will give you an advantage (since in this situation, you run the server
yourself, and so different people effectively have different servers.)
This is a shame, but that's the way it is, alas.
Angle to the wall
You don't need to run exactly parallel to the wall to make this trick
work; you can run at quite an angle in to it or even out from it, and the
strafing motion will still keep you tight against the wall rather than
allowing you to lose contact with your friendly accelerator.
Some angles in Quake are stored only as one of 256 different directions
around the 360 degree circle, meaning they are quantised in 1.4 degree
increments - this happens to be one such angle, so you don't have to be
as precise as you might fear to get best results. Even so, a degree or
so isn't a great margin for error, and going the wrong side of the optimal
angle will have a noticeable affect on the speed you get up to. Different
angles are optimal for different framerates and for different values of
the final variable, which is described below.
Ratio of cl_forwardspeed to cl_sidespeed
Heh, that one looks a little scary, doesn't it? I told you this
got a little bit complicated.
These two variables determine the speed your client would like to run
at in the two directions you'd expect. Of course, the server is keeping
a watchful eye on the maximum speed you can reach, so you'll have no joy
if you just increase these and expect to go faster and faster. However,
the ratio between them determines the angle you'll go at if you strafe
and go forward and the same time - and this will have an effect
on the speed-up you get from wall-hugging.
The default value for cl_sidespeed is 350p/s, and there's really
no reason why you should ever have changed it, or should ever want to change
it. Thus in the following, I'll assume that's the value it has, and so
concentrate only on changes to cl_forwardspeed.
The first thing to note is that using the "Always Run" menu
option simply sets cl_forwardspeed? to 400 to get a rough and ready
approximation of using the "run" command, +speed. You
want to use it
anyway, it has has a number of disadvantages in any case, but in particular
it will interfere with any changes you make to cl_forwardspeed.
Switch the option off and forget about it.
The second thing to note is that pressing the run key will make no difference
to the total speed you get by wall-hugging. Weird, huh? Presumably this
is because it simply doubles the speed you are trying for, and doesn't
change the angle you are trying to move in, which seems to be the important
How these variables work together
Right, having got all that straight, I can proceed to the explanation
of how all these factors inter-relate...
So, the maximum speed you can reach is dependent on server framerate.
I'll continue by presuming we've fixed this framerate at some particular
value; the other values involved will vary smoothly as it changes. Server
framerate can vary over time, although in multiplayer games with a dedicated
server it doesn't tend to vary very much, so you can get pretty good results
despite the variation, at least in principle.
You can reach the maximum speed as long as you have the right cl_forwardspeed
to match the angle you are at to the wall. This means that if you don't
want to worry about guessing angles, and just want to always run parallel
to the wall, there will be some setting of cl_forwardspeed that
will optimise results for you at any given framerate. It also means that
if you have moral
about playing with the values of your client-side variables, you can leave
them at their defaults and just try to turn at the correct angle instead.
(This is harder, though, and you don't have the same "degree"
I compiled the important values into a table
which I didn't want to clutter up this article with. Someone with nice
imaging software could probably draw a very pretty four-dimensional graph
of the results, but it isn't going to be me.
To sum up - if you're in a hurry within the universe of Quake, lean
into a wall. If you're going to be in a particular hurry in certain environments
or on certain routes, you could practise in those conditions and see how
fast you can manage (for example, practising running between the bases
in CTF and knowing where to zigzag and where to wall-hug sounds like a
good plan.) If you want to get technical, start playing with different
settings for cl_forwardspeed or different running angles to get
the best results under a variety of conditions.
And make the most of it - because both
these feature-bugs are gone from Quake2.
Comments on this Editorial? Send it to Feedback
Back to PlanetQuake