Future games

Zigzagging and wall-hugging manage to break the physics of Quake, but what about the game that will be occupying the time of a great deal of many of us very soon, Quake2?

Since these techniques are the result of engine bugs, we thought id ought to at least know about them, and sent e-mail to bugs@idsoftware.com to explain about the situation. As it happens, we probably didn’t need to bother. Judging from the first Quake2 demo, there was a change to the way the maximum speed limits are imposed made during the movement of the game physics from the very centre of the engine into the new game.dll. The console variable sv_maxspeed seems to have disappeared entirely, and neither zigzagging nor wall-hugging appear to have any effect in the demo. A good thing, probably.

Quite a few people have complained that rocket-jumping is not so easy in q2test.exe. I’m guessing this is a combination of a lack of precision control because of the very low input sampling rate used in the demo (it takes input as if you had only a ten fps framerate), and the fact that the side-mounted weapons only hit the crosshair target “at infinity.” So when firing at something very nearby (e.g. the floor with a rocket ) you probably won’t hit it where you expect too. The solution is either to relearn your close-up aiming skills, and/or to wait for the real game, which should have both the normal more frequent input sampling, and also an option to use centre-mounted weapons.

There was one other related matter. John Carmack published his work log a few weeks back, and one of the entries in it for September 7th made me smile:

[trinity] track and field style faster running?

Ironic that he’s considering adding this into the next-generation engine as a proper feature when it seems to be in the Quake engine already as a bug… 

https://web.archive.org/web/20010520182743fw_/http://www.planetquake.com:80/qdq/wallhug/future.htm