This is the beginning of new series of articles about Kreedz physics. I have to warn you that these articles are not designed for beginners. It is assumed that you are familiar with Kreedz techniques and have basic knowledge of programming (variables, functions, cycles, conditional operators) and linear algebra (vector addition, matrix multiplication, scalar and vector product of vectors).


Some time after we created KZ-Rush community with lxr in early 2016, I had an idea to write a special article for the site that would tell why it is possible to make strafes in CS at all. At that time, there was already a tutorial on Kreedz from Xtreme-Jumps and its translation from Unique-KZ, which is still being copied from forum to forum. Some assumptions were made there about how kz techniques work in CS. And in 2016 some notes by Arkshine from the alliedmods scripters forum were discovered, and there relying on code he found significant misconceptions in the tutorial.

We will act in a similar way and will rely on the code, at that open sorce of HLSDK will be enough but then we'll have to switch to the code from ReGameDLL and ReHLDS. As you can guess, this will not be a material for beginners, but this does not mean that we have forgotten about them. We plan to make a separate cycle about the basics in the video format. But before you teach someone, you need to thoroughly understand the topic yourself, right?

The article that was published then was called "Strafe physics", and it is basis for things that will be discussed further. For two years I have reworked its structure several times, and its different versions were copypasted in several places, including here, in guides. In the comments on the site Lt.RAT posted his graphics from MATLAB on the same topic, and this prompted me to repeat his calculations, so now you will see the updated version with 3D graphics. All the rest of the material will also be a pure exclusive, so fasten your seat belts :)


The goal of this series is to give a fairly deep understanding of the physics of movement in Counter-Strike 1.6. The entire foundation was laid by the developers back in Half-Life, created on the GoldSrc engine, the progenitor of which in turn was the Quake engine (you can see the full tree here). In many engines generated by Quake, it is possible to accelerate through the use of the strafe buttons (i. e. buttons that move you aside, sideways). In Half-Life, this acceleration has become significantly dependent on how the player turns the mouse during the strafe.

Open source Half-Life SDK (development tools) led to the emergence of a variety of mods, in particular a multiplayer mod Counter-Strike 1.0 in 2000. Then there were several updates, and after the version of CS 1.3 developers introduced a number of parameters that limited the enormous speeds that could be achieved using strafe during a series of jumps made in a row. In the final version of CS 1.6 it turned out that it is possible to counteract the imposed restrictions, but this requires certain skills. The following games CS:Sourse and CS:GO were already created on the basis of the Source engine (derived from GoldSrc), which constrained the player’s movements even more, making the use of CS 1.6 techniques extremely ineffective.

Thus CS 1.6 is the golden mean where overcoming the limitations of the engine is possible, but difficult enough to arouse the interest of players.


The game engine is a rather broad concept. It includes physics engine, resource manager, graphical and network interfaces, etc.

Frame is the tick of the game engine. The familiar FPS (frames per second) concept in CS 1.6 means not just the “number of frames per second”, but the “number of engine ticks per second”. The normal FPS value is 100. This means that 100 times per second the game engine processes the player's actions and performs certain calculations, updating the position, speed and many other parameters. Besides, a frame is formed at each tick that waits until the monitor displays it. If you played on a monitor with a refresh rate of 60 Hz (the picture changes 60 times per second) and the game ran with 60 FPS, then the delay between the formation of frame by the engine and its display on the screen could be up to 1/60 of a second. If the FPS is increased to 100, then:

1. we get a more actual picture, since the monitor displays the last frame created by the engine;
2. the engine perceives our keystrokes and mouse movement more often, that is, the game’s “responsiveness” increases.

The following picture will help us demonstrate the reduction of delays:


As you can see, some frames of the engine are simply lost. If we took a monitor with a frequency of 100 Hz, then ideally we would see each formed frame. At the same time, the picture would visually become smoother, although this would not affect the mechanics of the game.

By the way, why it is exactly 100 FPS, maybe more would be better? Most likely, the developers simply used the maximum frequency, which was supported by monitors back then. In addition, using high values would be not fair to players with weak computers, because in CS 1.6 all actions depend on the FPS.

You can see how much FPS your computer is capable to gain in CS 1.6. Before the update of 2013, it was enough to go into developer mode (developer 1 command) and set very high fps_max value. The legal value of 100 FPS corresponded to fps_max 101. You could set more, but with developer 0 nothing would have changed.

After the update, everything became a little different. Now the developer mode does not help, instead a special command fps_override 1 appeared. However, there is an important point - with fps_override 0 the maximum FPS value was not 100, but 100.5. At the same time to get exactly 100 you need to use fps_max 99.5. The change of legal values ​​in Kreedz led to the fact that during all these years there were a lot of players who recorded demos with fps_max 101, and they turned out to be illegal, since they gave 100.5 FPS. So be careful, check your FPS with the command net_graph 1.

CS 1.6 was created on the GoldSrc engine, which was originally developed for Half-Life, so the graphic part of the engine is adapted to small enclosed spaces. In the open spaces, the creators of the Half-Life levels used various tricks, creating many turns and partitions that did not allow the player to see too many objects at the same time. Eventually computers became more powerful, and the creators of CS 1.6 maps (mappers) began to afford more and more open and detailed spaces. However, the abuse of such practices led to the fact that on some maps even the “average” modern computers cannot support a stable 100 FPS. We try to avoid such maps and recommend all mappers to take into account this important feature of the engine.