Half-Life Physics Reference

Caution

This documentation is work in progress! Some parts may be incomplete, and others may be bleeding edge research.

_images/gordon-scientist.jpg

This document serves as an unofficial technical reference for the physics governing the Half-Life universe. While the community has produced very comprehensive resources for games in the Half-Life series, such as the Half-Life Wikia and the Combine OverWiki, these wikis primarily prioritise narrative lore and casual gameplay. The SourceRuns Wiki, which addresses the practicalities of speedrunning, has fallen into disuse, leaving a void in technical documentation at the level of mathematics and code. Despite the abundance of strategy guides, there remains a distinct lack of resources that describe the game’s underlying physics with a satisfying level of rigour.

Understanding the mechanics of Half-Life is essential for the development of tool-assisted speedruns (TAS) utilities and the execution of the runs themselves. Exploiting the engine to its fullest extent requires high-precision tools, but perhaps more importantly, it requires a deep intuition for how the game processes various complex mechanics such as Strafing, Nuking and headshots etc. Developing this understanding is vital for optimising routes, along with problem solving and troubleshooting tricky physics issues that arise during speedrunning.

Thus, this documentation strives to detail all aspects of the engine’s physics to provide curious minds with a much deeper appreciation for the technical side of Half-Life and the breathtaking speedruns produced by multiple generations of the community over the years. Whether you are a tool developer seeking a guide or a runner looking to master the game’s inner workings, this material aims to be your primary reference.

Frequently asked questions

Who are you? I’m someone who played Half-Life as a kid and became deeply fascinated by its physics much later when quadrazid published this monumental single-segment run was published in 2011. My drive to understand how every trick in that run functioned necessitated a deep dive into the physics and mathematics of the engine game.

Would I be able to understand this documentation? It depends on how much mathematics and programming you know. You are assumed to have an intermediate level of understanding of the latest Half-Life SDK, and have it available at all times when you need to reference it. By extension, you are assumed to be proficient in C or C++. Since this documentation is heavy in mathematics, you are assumed to be fluent in vector algebra and some linear algebra, along with a high proficiency in trigonometry. Some knowledge of calculus is also assumed.

Couldn’t you write this documentation in a simpler way? Our goal with this documentation is to describe the physics of Half-Life as precisely as possible. Many of the concepts in Half-Life are highly intricate and precise. Attempts to simplify these concepts may help in general play and manual speedrunning, but the simplified explanations may fail to account for the edge cases. It is often these edge cases that we seek to exploit in a TAS. A quote often attributed to Albert Einstein sums this up aptly:

“Everything should be made as simple as possible, but no simpler.”

Are the equations made up from thin air? We do not conjure up any equation based on conjectures or guesswork, unless clearly stated otherwise. All equations and mathematics in this documentation are ultimately derived from the Half-Life SDK or the reverse-engineered engine code. Empirically derived equations will also be explicitly identified as such.

How did you create this documentation? We experimented with various tools, including LaTeX, but ultimately settled on reStructuredText with Sphinx in combination with pre-rendered MathJax. Sphinx is an exceptional system for generating highly structured documentations. In fact, it is used to document most Python modules, including the heavy hitters like numpy, requests, etc. In addition, reStructuredText is the most extensible and structured markup language that is not LaTeX, rivalled only by AsciiDoc or AsciiDoctor. For mathematical typesetting, MathJax is by far the most mature for the web which runs well on many browsers. Prominent sites such as MathOverflow use it. By pre-rendering MathJax, we have significantly reduced page loading times.

Notations Used

One of the most important mathematical objects in discussions of Half-Life physics is the Euclidean vector. All vectors are in either ℝ2 or ℝ3, where ℝ denotes the real numbers. This is sometimes not specified explicitly if the contextual clues are sufficient for disambiguation.

All vectors are written in boldface like so:

𝐯

Every vector has an associated length, which is referred to as the norm. The norm of some vector 𝐯 is thus denoted as

‖𝐯‖

A vector of length one is called a unit vector. So the unit vector in the direction of some vector 𝐯 is written with a hat:

ˆ𝐯=𝐯‖𝐯‖

There are three special unit vectors, namely

ˆ𝐢ˆ𝐣ˆ𝐤

These vectors point towards the positive 𝑥, 𝑦 and 𝑧 axes respectively.

Every vector also has components in each axis. For a vector in ℝ2, it has an 𝑥 component and a 𝑦 component. A vector in ℝ3 has an additional 𝑧 component. To write out the components of a vector explicitly, we have

𝐯=⟨𝑣𝑥,𝑣𝑦,𝑣𝑧⟩

This is equivalent to writing 𝐯 =𝑣𝑥ˆ𝐢 +𝑣𝑦ˆ𝐣 +𝑣𝑧ˆ𝐤. However, we never write out the components this way in this documentation as it is tedious. Notice that we are writing vectors as row vectors. This will be important to keep in mind when we apply matrix transformations to vectors.

The dot product between two vectors 𝐚 and 𝐛 is written as

𝐚⋅𝐛

On the other hand, the cross product between 𝐚 and 𝐛 is

𝐚×𝐛

We do not use the prime notation as in 𝑥′ to mean 𝑑𝑥/𝑑𝑡. Generally, the prime version of a variable denotes the next state of the variable, whatever “next” may be. If we intend to notate differentiation, we always write out 𝑑𝑥/𝑑𝑡 explicitly.

Contact

This documentation is currently a one-man project. Contact me.

Contents