Quake (id Software's engine source, WinQuake 1.09 and QuakeWorld, with the 1.01 QuakeC)

id Software's released Quake engine source numbers its single-player engine, WinQuake, as version 1.09 (VERSION in quakedef.h); the readme calls the release "the complete source code for winquake, glquake, quakeworld, and glquakeworld" and says the original DOS version "should also be buildable from these sources, but we didn't bother trying". quake/source-version

Value: 1.09

Every engine claim here reads WinQuake's code unless it names QuakeWorld. The 1996 DOS executable is not in the release, so a claim holds for it only as far as the two share code.

Cited by: Quake

Quake's host runs a frame only once at least 1/72 second has passed since the last, so the game steps at most 72 times a second; each frame's time step (host_frametime) is the real time since the last frame, clamped to 0.001–0.1 second, unless host_framerate fixes it, and a time demo skips the 1/72 wait. quake/frame-time

Value: 72 frames/s

Every rate below (acceleration, friction, gravity) is per second, times this step.

Cited by: Quake

Each Quake server frame reads every client's move and runs SV_ClientThink, which applies friction and acceleration, before SV_Physics, which runs the QuakeC PlayerPreThink (where the jump is), then gravity and the move; SV_ClientThink reads the on-ground flag the last move left, does nothing for a dead player or one with movetype none, and hands a water jump and a player at water level 2 or more (unless noclipping) to the water code. quake/frame-order

The order matters for jumping: see quake/hop-friction. SV_WalkMove clears the on-ground flag and sets it again only when its move ends on a floor (quake/hop-friction cites the lines).

On the ground, Quake's SV_UserFriction takes the horizontal speed and lowers it by frame time × friction × the larger of the speed and sv_stopspeed, to no less than 0, scaling all three velocity axes by the same factor; sv_friction defaults to 4 and sv_stopspeed to 100, and when a trace 16 units ahead along the motion finds no floor within 34 units below the feet, the friction is multiplied by edgefriction (default 2). A standing player is left alone. quake/ground-friction

About: Quake Running

{
 "sv_friction": 4,
 "sv_stopspeed": 100,
 "edgefriction": 2
}

Above 100 units/s the loss is proportional to speed (4 per second, an exponential fade); below it, a constant 400 units/s². Note the edge cvar's console name is edgefriction, not sv_edgefriction.

Cited by: Quake

Quake builds the wish velocity from the forward and side moves along the view's forward and right vectors (zero vertical for a walking player), caps its length at sv_maxspeed (default 320), and on the ground runs friction and then SV_Accelerate: if the speed along the wish direction is under the wish speed, it adds sv_accelerate (default 10) × frame time × wish speed along that direction, no more than the shortfall. quake/ground-accelerate

About: Quake Running

{
 "sv_accelerate": 10,
 "sv_maxspeed": 320
}

The test is on the speed along the wish direction, not the whole speed: a sideways velocity doesn't stop the push. The same test, with a cap, is the root of quake/air-accelerate.

Cited by: Quake

Quake's keyboard moves are cl_forwardspeed and cl_backspeed 200 and cl_sidespeed 350, doubled by the run key (cl_movespeedkey 2.0), and the menu's "always run" sets forward and back to 400. Computed from these and the 320 cap: walking forward wishes 200, while a strafe alone (350), a walk with a strafe (√(200² + 350²) ≈ 403), and any run all wish 320. quake/move-speeds

About: Quake Strafe-running

{
 "forward": 200,
 "side": 350,
 "run": 2,
 "cap": 320
}

So on the ground a strafe adds speed only to a walk (320 against 200, 1.6 times), and none to a run, which the cap already holds at 320. Mouse and joystick moves add to the same command; they are not read here.

Cited by: Strafe-running

Computed from the friction and acceleration rules, not measured: because acceleration (10) outpaces friction (4), a Quake player on flat ground settles at exactly the wish speed, 320 units/s at a run; at the 72-frame rate a run from rest reaches it on frame 10 (0.14 s), and letting go from 320 comes to rest after 39 frames (0.54 s). quake/ground-speed

About: Quake Running

Value: 320 units/s

A slower frame rate changes the frame counts but not the settled speed. Over a ledge the friction doubles to 8, still under 10, so the settled speed holds there too.

Cited by: Quake

In the air, Quake's SV_AirAccelerate takes the wish velocity's direction and length, caps that length at 30, and adds speed along the wish direction only while the velocity's component along it is under 30: the push is sv_accelerate × the uncapped wish speed (up to 320) × frame time, cut to the shortfall below 30. There is no friction in the air. quake/air-accelerate

About: Quake Strafe-running

Value: 30 units/s

The cap limits only the speed along the wish direction, so a velocity pointing elsewhere gets the full push. The commented-out line above the live one is id's own.

Cited by: Quake, Strafe-running

Computed from SV_AirAccelerate, not measured: with a wish speed of 320 the push can reach 10 × 320 × frame time (44.4 at 1/72 s, more at longer frames), so a frame lifts the velocity's component c along the wish direction to 30 whenever c is between −14.4 and 30, and the new speed is √(v² + 900 − c²) for speed v. That is largest with the wish at 90° to the motion: each frame then adds √(v² + 900) − v, 1.40 units/s at 320 and 0.90 at 500, and turns the motion by atan(30/v), 5.4° per frame at 320. At 72 frames a second that is about 101 units/s gained per second at 320. quake/air-strafe-gain

About: Quake Strafe-running

Value: 1.4 units/s per frame at 320

Holding a strafe key alone gives a side move of 350, capped to 320, so a player in the air gains by turning the view to keep the strafe at right angles to the motion. A wish speed under 216 at 1/72 s would make the push, not the 30, the limit.

Cited by: Quake, Strafe-running

Quake's jump is QuakeC (1.01's client.qc): each frame PlayerPreThink calls PlayerJump while the jump button is held and otherwise sets FL_JUMPRELEASED; on land (water level under 2, not in a water jump), PlayerJump acts only when the player is on the ground and has released the button since the last jump, then clears both flags and adds 270 to the vertical velocity. Holding the button never jumps twice. quake/jump

About: Quake Jump

Value: 270 units/s

The jump adds to the vertical velocity rather than setting it. In deeper water the same button swims up at a set speed instead (100 in water, 80 in slime, and 50 otherwise).

Cited by: Quake

Computed from the jump and gravity, ignoring frame steps: a Quake jump from flat ground at the default gravity of 800 rises 270² / (2 × 800) ≈ 45.6 units and lands after 2 × 270 / 800 = 0.675 seconds. quake/jump-arc

About: Quake Jump

Value: 45.6 units

On E1M8, with gravity 100, the same jump would rise eight times as high, about 365 units, by the same arithmetic.

Quake's gravity is the cvar sv_gravity, defaulting to 800, and each level's QuakeC worldspawn sets it to 800 again, or to 100 on E1M8; every frame a walking player is not in water (water level 2 or more) or a water jump, SV_AddGravity takes the entity's gravity field (1 when unset) × sv_gravity × frame time off its vertical velocity, on the ground as well as in the air. quake/gravity

About: Quake Gravity

Value: 800 units/s²

The gravity field is looked up by name, so a mod's QuakeC can give an entity its own scale.

Cited by: Quake

Because Quake runs friction in SV_ClientThink before the QuakeC jump in PlayerPreThink, and the on-ground flag is set by the walking move when it ends on a floor, a jump can come no sooner than the frame after landing, and that frame takes ground friction first: computed, a hop loses 4/72 of its horizontal speed (5.6%) at 72 frames a second above 100 units/s, or 8/72 (11.1%) when no floor lies within 34 units below a point 16 units ahead. quake/hop-friction

About: Quake Bunny hopping

Value: 5.6 % per hop at 72 frames/s

The ground frame also runs SV_Accelerate, which can add up to 10 × 320 / 72 ≈ 44 units/s at right angles to a fast motion, so a strafing hop loses less than the friction alone. The jump also needs the button released and pressed again (quake/jump). Compare QuakeWorld, quake/qw-hop-friction.

Cited by: Bunny hopping, Quake

QuakeWorld's pmove.c checks the jump before friction: PlayerMove calls JumpButton, which clears onground, and then PM_Friction, whose ground friction runs only while onground is set, so a QuakeWorld hop on its first ground frame loses no speed to friction, where WinQuake's takes one frame of it (quake/hop-friction). Both still need the button released between jumps, and both add 270. quake/qw-hop-friction

About: Quake Bunny hopping

QuakeWorld's friction also uses the full 3D speed where WinQuake's uses the horizontal speed.

Cited by: Bunny hopping, Quake

QuakeWorld's PM_AirAccelerate keeps WinQuake's air rule unchanged: the wish speed capped at 30 for the shortfall test, and the push from the uncapped wish speed × acceleration × frame time; it adds only an early return for a dead player or a water jump. quake/qw-air-accelerate

About: Quake Strafe-running

QuakeWorld takes its frame time from each command's milliseconds (pmove.cmd.msec), so the per-frame gain in quake/air-strafe-gain applies per command there.