Re: [GD-General] Information on approaches to networking games

[brian h. <bri...@py...>]

> > That's awfully broad.  What do you mean by "approaches"?  As in 
overall 
> > architecture, specific communication protocols, compression and 
> > prediction methods, or something else or all of the above?  
> 
> All of the above with a weight on architecture.

I'm not the most qualified to speak on this, but here's some food for 
discussion/thought:

- pretty much everyone uses UDP.  TCP simply doesn't work over the net 
for real-time 3D graphics if you're trying to achieve low latency.

- compression is a necessity if you want to minimize bandwidth.  You 
can do a per-packet compression using something like LZW or arithmetic 
coding; you can also do application level delta-compression where you 
only send over the changed state.  And you can also do quantization.  
And, of course, you can do a mix of all of the above.

- encryption is a necessity if you're worried about hacking.  You can 
never trust the client.

- the most common architecture today as far as I know is client-
server.  It's possible some games continue to use peer-to-peer (I 
imagine this is like with RTS style games?), but as a rule client-
server is the model that is the de facto standard.

> Realtime mostly, but also, as discussed here recently, discussion on 
> combining offline and online gameplay.

Once again, this is awfully broad.  There are many genres of real-time 
games that have radically different requirements -- first person 
shooters; role-playing games; real-time strategy games; flight sims; 
etc.  The mix of hard updates and client side prediction will also 
drastically change depending on the game's genre.

> OK - if someone else knows it I would like to hear about it. It does 
not 
> look particulary advanced from the index. 

As I said, with 90 minutes I don't think you'll have time to get into 
advanced stuff.  And honestly, if you're just now learning this stuff, 
you may not be comfortable trying to distill a bunch of knowledge that 
you're not intimately familiar with into such a reduced timeframe.

> sure that the stuff "I once knew" is not totally outdated today. (Are 
> games doing anything particulary more advanced than 
> QuakeWorld/Quake2/Quake3 today?)

Given that those three games did networking fairly significantly 
differently, I'd be hesitant to group them together.  Their only major 
commonality is that they're UDP based; delta compress; and are client-
server.  The implementation of reliable communication was altered 
drastically from Quake2->Quake3, and delta state compression was 
radically altered from QW to Q2.

However, I would submit that Quake3's networking model is probably a 
pretty good reference for first person shooters.  But it probably would 
not be the ideal model for a real-time strategy game or RPG.
-Hook