Nathan Mates's .plan Archives .plan Archives from January 1999.

[visi.com] 
Login name: nathan    			In real life: Nathan Mates
Directory: /home/nathan             	Shell: /bin/tcsh
Plan:

So, let me say what I can, now. BZ1's network model (which I had nothing to do with-- I joined the BZ2 team after BZ1 shipped) sent positions, velocities, etc of all objects in the world, and in a big firefight (lots of ordinance going off), it had to prioritize packets, and could drop some lesser-priority packets in order to keep bandwidth reasonable.

For BZ2, in talking with the lead programmers and producer, all of the BZ1 network source code was scrapped. Deleted, removed, it's gone. An entirely new setup of what to send, and when to send it was specced out, and implementing it has mostly been my job.

Battlezone has certain networking requirements, in that it such code *must* run within the confines of the existing engine. Thus, certain other parts of the code put requirements as to what must be communicated. Unlike most First Person Shooters (FPSs), we can have a ton of AI running. [Most FPS's AI is "run at player while firing guns."] Unlike most Realtime Strategy games (RTSs), which have a lot of AI running, we've also got a first-person set of movement. [I believe most RTSs only need to communicate your commands to units, which 99% of the time are at most one command per second.] Thus, a network model designed for either of those just won't cut it, as we're really a hybrid between FPS and RTS.

What I will say right now is that BZ2's network model is not like BZ1, and doesn't need to send positions constantly (or at all after joining). It sends data at a higher level than raw positions. Before my compression of data, BZ2 sends the same amount of data if sitting around doing nothing or if in a firefight. Compression is a wonderful thing, and does do a better job when you do nothing. Those programmers reading between the lines should be able to figure out what we're doing by my description above, but we've got some neat things on top (mostly done by Brad, lead programmer) that'll smooth out the user's experience.

With all of the compression, let me just say that I'm pretty happy with the bandwidth actually used by the game, and leave it at that. In my professional game programmer's career, I've worked on several console titles (see my homepage at http://www.matesfamily.org/ for names, etc), and have a real bit and byte reducing mentality. The fewer bytes BZ2 needs to send at any time, the better it'll do on slow networks.

Also, BZ1 used Activenet, a set of protocols developed internally at Activision for TCP/IP, IPX, and direct modem connections in their games. BZ2 replaces that with MS's DirectPlay, which supports all of those instead. As to anti-cheating, the way BZ2 works in a net game, most cheating should result in the cheater's machine being desynchronized pretty quickly. There's no reason they should be around after that. [In thinking about it, there's another round of possible hacks that the scheme wouldn't be able to detect (no, I'm not going to spell them out for the bleeping cheaters), but have bounced ideas off others for ways to detect them.]

Stuff on my to-do list on whiteboard:

- DLL 'shared' ram block
- Cleanup DLL code to Brad's new spec
- Shell Integration of network layer to UI
- Test dynamic joining with new physics, >2 machines

Totally unrelated to BZ2... games I'm playing at home right now: Might & Magic 6 (2nd time thru... while monotonous towards the end with thousands of monsters to kill, it's got some kind of appeal to me), Starcraft + Broodwars (singleplayer missions). Games recently played: Fallout 1 & 2, Final Fantasy 7, Worms2, Curse of Monkey Island, and a few others.