Doom-Ed

Several people have mentioned an existing anti-cheat QW proxy that
should also be applicable to modified versions:

http://www.students.tut.fi/~zibbo/qizmo/

I have been playing a lot of Q3 on a 28.8 modem for the last several days.

I finally found a case of the stuck-at-awaiting-gamestate problem that
turned out to be a continuous case of a fragment of the gamestate getting
dropped. I have changed the net code to space out the sending of the
fragments based on rate.

Note that there have been a few different things that result in stuck
at gamestate or stuck at snapshot problems. We have fixed a few of them,
but there may well still be other things that we haven’t found yet.

You can still have a fun game on a 28.8 modem. It is a significant
disadvantage, no question about it, but you can still have a good game if
you play smart. If there is someone that knows what they are doing on a
server with a ping in the low 100s, there won’t usually be much you can
do, but a skilled modem player can still beat up on unskilled T1 players…

Make sure your modem rate is set correctly. If you have it set too high,
large amounts of data can get buffered up and you can wind up with multiple
seconds of screwed up delays.

Only play on servers with good pings. My connection gives me a couple dozen
servers with mid 200 pings. 56k modems often see servers with sub 200 pings.
If you ignore the ping and just look for your favorite map, you will probably
have a crappy game.

If you have a good basic connection to the server, the thing that will mess
up your game is too much visible activity. This is a characteristic of the
number of players, the openness of the level, and the weapons in use.

Don’t play on madhouse levels with tons of players. None of the normal Q3
maps were really designed for more than eight players, and many were only
designed for four.

Don’t play in the wide open maps unless there are only a couple other
players. Four very active players in a wide open area are enough to bog
down a modem connection.

I just implemented “sv_minPing” / “sv_maxPing” options so servers can restrict
themselves to only low ping or high ping players. This is done based on the
ping of the challenge response packet, rather than any in-game pings. There
are a few issues with that — a LPB may occasionally get into a HPB server
if they happen to get a network hiccup at just the right time, and the number
used as a gate will be closer to the number shown in the server list, rather
than the number seen in gameplay. I would reccomend “sv_minPing 200″ as a
reasonable breakpoint.

There are a number of people upset about the Quake 1 source
code release, because it is allowing cheating in existing games.

There will be a sorting out period as people figure out what directions
the Quake1 world is going to go in with the new capabilities, but it
will still be possible to have cheat free games after a few things get
worked out.

Here’s what needs to be done:

You have to assume the server is trusted. Because of the wau quake
mods work, It has always been possible to have server side cheats
along the lines of “if name == mine, scale damage by 75%”. You have
to trust the server operator.

So, the problem then becomes a matter of making sure the clients are
all playing with an acceptable version before allowing them to connect
to the server. You obviously can’t just ask the client, because if it
is hacked it can just tell you what you want to hear. Because of the
nature of the GPL, you can’t just have a hidden part of the code to do
verification.

What needs to be done is to create two closed source programs that act
as executable loaders / verifiers and communication proxies for the
client and server. These would need to be produced for each platform
the game runs on. Some modifications will need to be done to the
open source code to allow it to (optionally) communicate with these
proxies.

These programs would perform a robust binary digest of the programs they
are loading and communicate with their peer in a complex encrypted
protocol before allowing the game connection to start. It may be
possible to bypass the proxy for normal packets to avoid adding any
scheduling or latency issues, but it will need to be involved to some
degree to prevent a cheater from hijacking the connection once it is
created.

The server operator would determine which versions of the game are to
be allowed to connect to their server if they wish to enforce proxy
protection. The part of the community that wants to be competetive
will have to agree to some reasonable schedule of adoption of new
versions.

Nothing in online games is cheat-proof (there is allways the device
driver level of things to hack on), but that would actually be more
secure than the game as it originally shipped, because hex edited patches
wouldn’t work any more. Someone could still in theory hack the closed
source programs, but that is the same situation everyone was in with
the original game.

People can start working on this immediately. There is some prior art
in various unix games that would probably be helpfull. It would also
be a good idea to find some crypto hackers to review proposed proxy
communication strategies.

The Q3 game source code is getting pushed back a bit because we had to do
some rearranging in the current codebase to facilitate the release, and
we don’t want to release in-progress code before the official binary point
release.

We still have a Christmas present for the coders, though:

http://www.idsoftware.com/q1source/

Happy holidays!

Anna Kang left Id a couple weeks ago to found her own company -
Fountainhead Entertainment.

It wasn’t generally discussed during her time at Id, but we had been going
out when she joined the company, and we were engaged earlier this year.
We are getting married next month, and honeymooning in Hawaii. At her
thoughtful suggestion, we are shipping a workstation out with us, so I don’t
fall into some programming-deprivation state. How great is that?

Now that Q3A has shipped, the official winner of her Id Software figurine
chess set contest is Rowan Crawford for his prose and art.

An honorable mention goes to Reine Hogberg and Peder Hardings for their Q3A
Blair Witch Project. They will receive silver Q3A medallions.

WANTED: Independant OpenGL conformance nazi

I think there is a strong need for a proactive, vendor-neutral
OpenGL watchdog, or even a small group, especially in the linux space.

I have been working on the utah-GLX team for quite a while now, and while
I have been very pleased with the results, I would like to see more effort
spent on doing things as right as possible. Because the developers (me
included) are basically just doing the work in their spare time, testing
usually only consists of running their favorite OpenGL application, and a
few of the mesa demos, or some of the xscreensaver hacks.

Recently I did the initial bringup of a RagePro driver on linux, and I was
much more conscious of the large untested feature space, and the tunnel
vision I was using to get it to the point of running Q3.

What we need is someone, or a group of someones, who can really exercise
different implementations through all corners of the OpenGL specification
and provide detailed lists of faults with minimal test cases to reproduce
the behavior.

In most cases, the bugs could then be fixed, but even if it is decided that
the incorrect behavior is going to stay (to avoid a software fallback in a
common accelerated case), there would be clear documentation of it.

I consider performance on the matrox driver right now to be “good enough”.
There is definately more performance oriented work going on, but given a
choice of tasks to work on, I would rather improve quality and coverage
instead of kicking a few more fps out of Q3.

One of Alex St. John’s valid points was that “The drivers are always broken”.
There are a lot of factors that contribute to it, including fierce
benchmarking competition causing driver writers to do some debatable things
and diminish focus on quality. With open source drivers, some of those
factors go away. Sure, it is nice to beat windows drivers on some benchmarks,
but I wouldn’t let pursuit of that goal introduce dumb things into the code.

Some of the windows IHVs have good testing proceedures and high quality
drivers, but even there, it would be nice to have someone hounding them about
things beyond how well quake releated games run.

The same goes for Apple, especially now that there is both ATI and 3dfx
support.

Conformance would be my primary interest, but characterizing the performance
of different drivers would also be usefull, especially for edge cases that may
or may not be accelerated, like glDrawPixels.

On linux right now, we have:

The traditional fullscreen 3dfx mesa driver
The DRI-GLX based banshee/voodoo3 driver
The utah-GLX matrox G200/G400 driver
The temporary utah-GLX nvidia driver
The newly born utah-GLX ATI Rage Pro driver

If anyone is interested, join the developer list off of:
http://glx.on.openprojects.net/

Doing a proper job would require a really good knowledge of the OpenGL
specification, and a meticulous style, but it wouldn’t require hardcore
registers-and-dma driver writing skills, only basic glut programming.

If someone does wind up developing a good suite of tools and procedures and
gives one of the drivers a really good set of feedback, I would be happy to
provide extra video cards so they could beat up all the implementations.