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 is an unofficial documentation for the physics governing the Half-Life universe. There have been many very comprehensive wikis for games in the Half-Life series, such as the Half-Life Wikia and the Combine OverWiki. These wikis focus on the storyline and casual gaming aspects of the Half-Life series video games. There is also a wiki for the practical speedrunning aspects of these games, namely the SourceRuns Wiki, though it has been virtually abandoned with little to no updates. Despite the wealth of strategy guides available for Half-Life, it is almost impossible to find documentations describing the physics of the game with a satisfying level of technical accuracy.

Knowledge about the physics of Half-Life is important for developing tools for Half-Life TAS production and for the process of TASing itself. Highly precise tools are required to exploit the in-game physics to the fullest extent. Perhaps more importantly, developing an understanding and intuition for Half-Life physics is vital in producing a highly optimised TAS for the game and resolving tricky physics issues arising out of speedrunning.

Thus, this documentation strives to detail all aspects of the physics in a way that would help any curious minds to gain a much deeper appreciation for Half-Life and its speedruns. The potential tool developers will also find this documentation a helpful guide. This documentation aims to serve as a definitive reference material for Half-Life physics.

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 this monumental single-segment run was published in 2011 by quadrazid. I sought to understand how every trick in the run worked, which necessitated the study of the physics of the entire 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 many situations, but the simplified explanations will fail under some 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 stated clearly.

How did you create this documentation? We experimented with many different tools, including LaTeX, but ultimately settled on reStructuredText with Sphinx in combination with pre-rendered MathJax. Sphinx is a really good 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, the loading times of pages can be dramatically reduced.

Notations Used

One of the most important mathematical objects in discussions of Half-Life physics is the Euclidean vector. All vectors are in either or , 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 , it has an component and a component. A vector in 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

Contact

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

Contents