gamedevlists-general

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

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

> I am looking for information on approaches to networking games 

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?  It would be 
tough to do a definitive survey on this.  Also, what types of games are 
we talking about here?

There are at least two trade books I've seen on the subject of 
networked games.  The first is "Multiplayer Game Programming" by Todd 
Barron.  I didn't like this book at all -- it doesn't discuss any form 
of networking that would be realistically used in a modern game today, 
and spends a significant amount of time on things unrelated to 
networking and multiplayer.

There is another book out called "Developer's Guide to Multiplayer 
Games" by Andrew Mulholland and Teijo Hakala:

http://search.barnesandnoble.com/booksearch/isbnInquiry.asp?
isbn=1556228686

It looked significantly more promising to me, but since I haven't 
actually read it (and the price seems exhorbitant) I can't really 
comment.

All that aside, if it's a short lecture, you're probably not going to 
have time to get into any detail, so the general survey stuff you might 
find at Web sites may be good enough.

Brian

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

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

[Mads B. D. <ma...@ch...>]

On Sun, 22 Sep 2002, brian hook wrote:

> > 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, 

I am not - I am getting back to a subject I have been away from for a 
while :-).

> you may not be comfortable trying to distill a bunch of knowledge that 
> you're not intimately familiar with into such a reduced timeframe.

That is absolutely true. I will not be doing that, but I need to make sure 
I am not talking nonsense.

> 
> > 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.

OK. Do you have references to someone discussing this?

> 
> 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.

I am aware of that. Although not in the detail I would like.

Thanks,

Mads

-- 
Mads Bondo Dydensborg.                               ma...@ch...
Value your freedom, or you will lose it, teaches history. "Don't bother us
with politics," respond those who don't want to learn.

        - Free software proponent, Richard M. Stallman

[GD-General] Basic questions regarding networking games...

[Colin F. <cp...@ea...>]

2002 September 23rd
Monday

I have a few questions, but first I'll provide a hypothetical
context:


INTRODUCTION:
=============

  Let's say you have a small multiplayer game, and let's say
you want it to run on a LAN.  Let's say you start the server,
and later a client starts up, but the client doesn't know 
the IP of the server.

  Now let's say that the server has a preferred range of ports,
say: 32000, 32001, 32002, 32003, 32004.  (Only one available
port is actually used by the server, but the server will 
attempt to acquire a port from the range above, and clients
will know that a server could be running on one port within
this range.)

  The client can do a UDP broadcast on the subnet, say
192.168.1.255, to each of the ports in the preferred port range
of the server.

  The server can respond when it gets the client query.


QUESTIONS:
==========

  [A] For *Internet* games I assume service WWW sites like GameSpot,
etc, advertise the IP's and ports of game servers -- or you
can indicate the IP and port number of your server through
any other means (phone call, e-mail, chat, etc).

  QA1: Is this the dominant way to discover *Internet* games?



  [B] For Internet games the port(s) can be fairly arbitrary
(anything above 1024 and below 65536, right?), but for 
convenient "discovery" of servers on a LAN it might be nice
to have a few preferred port candidates to try -- instead
of broadcasting to all 64000 ports in a brute-force search.

  QB1:  How might one select "default" port ranges for the
convenience of LAN clients searching for servers?

  QB2:  Might a server on a LAN advertise itself periodically,
like once per second?...Perhaps only during the "join" phase of
a game (if players can't just jump in at any time)?
This sounds pointless when clients can essentially do
the queries as needed, but maybe when the server is on
a totally random port (but advertises itself on a known
port), it might make it easier for clients to discover
the server (just by listening on a known port for the
unsolicited broadcasts of the server).



  [C] Some applications have one "well-known" port for
initiating sessions and create ports for handling those
sessions.

  QC1: Sorry for my ignorance, but do you think it's okay
to have all clients send UDP to the same server port
for processing?  (So each UDP packet has a "Client ID"
to demultiplex the packets.)

  QC2: Even if all UDP traffic can go to a single server
port, do you think there might be some benefit to having
a seperate port that is strictly for joining the game?
(The "real" game might be some RANDOM port, but the
service for joining the game might be on the "well-known
port range".)

  QC3: To your knowledge, do many first-person shooter
deathmatch games just feature a single UDP port for
all game-related traffic?


I basically want to learn from the experience of others
regarding the basic mechanics of "discovering"
servers (Internet and LAN), choosing port(s), and 
choosing a total number of used ports for a single server.

--- Colin
cp...@ea...

Re: [GD-General] Basic questions regarding networking games...

[Tom H. <to...@3d...>]

At 02:23 PM 9/23/2002, Colin Fahey wrote:
>   [A] For *Internet* games I assume service WWW sites like GameSpot,
>etc, advertise the IP's and ports of game servers -- or you
>can indicate the IP and port number of your server through
>any other means (phone call, e-mail, chat, etc).
>
>   QA1: Is this the dominant way to discover *Internet* games?

No. The dominant way is to use a lobby server. GameSpy provides a generic 
interface for different games to use, and it's supported by just about 
every game out there these days. It used to be that every game made their 
own lobby server protocol in addition to GameSpy, but I wouldn't be 
surprised if they've all shifted to GameSpy only at this point. This is 
probably more true for FPS games than other genres.

>   [B] For Internet games the port(s) can be fairly arbitrary
>(anything above 1024 and below 65536, right?), but for
>convenient "discovery" of servers on a LAN it might be nice
>to have a few preferred port candidates to try -- instead
>of broadcasting to all 64000 ports in a brute-force search.
>
>   QB1:  How might one select "default" port ranges for the
>convenience of LAN clients searching for servers?

In practice, each game sets up a default range of ports (or only a single 
port in many cases). These ports should be different from game to game, but 
even if they're not you're still OK. Remember, getting the port is only 
part of the process ... if the traffic sent back and forth doesn't match, 
then you're not running on a valid server. The ports can typically be 
changed by the end-users in one way or another if they have to resolve 
"bad" conflicts (another application crashes or behaves badly when it gets 
a packet it doesn't recognize ... this should be very rare).

>   QB2:  Might a server on a LAN advertise itself periodically,
>like once per second?...Perhaps only during the "join" phase of
>a game (if players can't just jump in at any time)?
>This sounds pointless when clients can essentially do
>the queries as needed, but maybe when the server is on
>a totally random port (but advertises itself on a known
>port), it might make it easier for clients to discover
>the server (just by listening on a known port for the
>unsolicited broadcasts of the server).

It is much better for the clients to broadcast a packet that says, "If 
you're a server, send a response back please" than it is for the servers to 
periodically pulse out a heartbeat. You also need the ability to enter an 
IP address by hand for networks that have disabled broadcast.

>   [C] Some applications have one "well-known" port for
>initiating sessions and create ports for handling those
>sessions.
>
>   QC1: Sorry for my ignorance, but do you think it's okay
>to have all clients send UDP to the same server port
>for processing?  (So each UDP packet has a "Client ID"
>to demultiplex the packets.)

Yes. This is the preferred way to do it for the relatively small number of 
users in these types of games. Larger games (MMP) may do better to spread 
the traffic over multiple ports, but that's going to be heavily dependant 
on the OS and such. Fortunately, you're not asking how to build a MMP 
networking system ;)

>   QC2: Even if all UDP traffic can go to a single server
>port, do you think there might be some benefit to having
>a seperate port that is strictly for joining the game?
>(The "real" game might be some RANDOM port, but the
>service for joining the game might be on the "well-known
>port range".)

I don't see what the benefit would be, and it would only seem to make 
things more difficult for . It's useful to have the lobby server traffic on 
a different port than the game server port, but unless you're doing 
something painful in the authentication, there shouldn't be any reason to 
break it off.

>   QC3: To your knowledge, do many first-person shooter
>deathmatch games just feature a single UDP port for
>all game-related traffic?

I can't speak for all FPS games, but the one I've worked on did ;) I'm 
under the impression that all the others do it that way as well.

>I basically want to learn from the experience of others
>regarding the basic mechanics of "discovering"
>servers (Internet and LAN), choosing port(s), and
>choosing a total number of used ports for a single server.

1. Use GameSpy for a lobby server for internet play.
2. Use a broadcast packet from the client on a known port to discover 
servers for LAN play.
3. Use a single (different) UDP port for all authentication / gameplay traffic.

There is one option to consider ... include authentication of CD keys as 
part of the lobby server functionality (I think this is how Q3A works, but 
it's been a while).

Tom

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

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

> > 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.
> 
> OK. Do you have references to someone discussing this?

Unfortunately, no, you'd probably have to dig up documentation on the 
protocols from various mod sites and then diff between them manually.  
The information I have is based on recollections and discussions I've 
had, but it's not "secret" stuff by any means.

The Q2 source code is open source, so that's easy enough to sort out, 
but if this is about multiplayer gaming in general, then you probably 
don't want to get into such domain (or game) specific knowledge.
 
> I am aware of that. Although not in the detail I would like.

Well, here's the issue, I guess -- if there was a good single 
reference, you wouldn't have to lecture, you could just redirect them 
to a URL =)

-Hook

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

[Matt N. <mat...@ni...>]

You might find the article "Distributing Object State for Networked =
Games Using Object Views" interesting:

http://www.gamasutra.com/resource_guide/20020916/lambright_01.htm

Matt.

---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.380 / Virus Database: 213 - Release Date: 24/07/2002
=20

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

[Mads B. D. <ma...@ch...>]

On Sun, 22 Sep 2002, brian hook wrote:

> > I am looking for information on approaches to networking games 
> 
> 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.

> It would be 
> tough to do a definitive survey on this.  Also, what types of games are 
> we talking about here?

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


> There is another book out called "Developer's Guide to Multiplayer 
> Games" by Andrew Mulholland and Teijo Hakala:
> 
> http://search.barnesandnoble.com/booksearch/isbnInquiry.asp?
> isbn=1556228686
> 
> It looked significantly more promising to me, but since I haven't 
> actually read it (and the price seems exhorbitant) I can't really 
> comment.

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

> 
> All that aside, if it's a short lecture, you're probably not going to 
> have time to get into any detail, so the general survey stuff you might 
> find at Web sites may be good enough.

its 2*45 minutes, so, won't really get into detail, but I would like to be 
sure that the stuff "I once knew" is not totally outdated today. (Are 
games doing anything particulary more advanced than 
QuakeWorld/Quake2/Quake3 today?)

Mads

-- 
Mads Bondo Dydensborg.                               ma...@ch...
Saying you're trying to fix all the holes in IE is like saying you mean to
turn a sieve into a bowl.
            -- /. comment