Hi..., I''m working on the multiplayer part of my game, and, well, i''m looking for some implementation ideias. I have two options for the multiplayer game, one person creates a server, and clients can connect directly to it trough the ip, or any person creates a game, and at the same time his IP is forwarded to a fixed IP server, that will hold all IP''s of all people playing trough the net. When someone choose join a net game, his game will connect to this fixed server, and will download the list of all servers created. Now.. my problem! Should the client download the list , and check if the list of servers is actual ? I think i need to do this, to get the ping to all the servers..., how does all games control their games ? When we want to join a game, we get a huge list of active games, with everything., Is my ideia any close to this ? thanks, Bruno

HI.

Firstly, what kind of game are you working on, this has an inpact on the net code model you use.

It sounds to me like you wish to make a Half-Life style system (where you are presented with a list of game servers to use).

If this is the case, you need to look in to making your application lobbyable. You should looking in to Direct Play 8 (It's pretty fast, and deals with all the things that you won't want to, including lobbying).

You will want a fixed IP Server which will list all the game servers. Clients then retrieve the list from the central server, choosing a game server to play on. When in game, a peer to peer system can be used, though depending on the game you might be better off using a client server model for this. The advantage to this method (to answer your question!) is that it enables you to take information and store it on the central server. Clients can then get a read out of pings and player etc. Use the Central server to mangage game servers, which includes ensuring that the server still exists.

In short - Someone will set up a game server. The IP of this machine will be sent to a central server (there can be many central servers, Gamespy for instance). Clients connect to a central server to get a list of currently running games, and are forwarded to the IP of the game server they wish to play on.

I hope this is informative enough,

Dachande

PS I have no doubt you already knew about many of the subjects covered here, I thought I'd bulk it up a bit

[edited by - dachande on July 10, 2002 12:07:18 PM]

I understand most of what you have said, what i don't is where or how do you get the ping from a server!
When i connect quake3 for example, and the game display's me a list of active servers, who is sending me that list ? It's a fixed IP adress, probably from ID or GameSpy or something like that., but they cannot send me the ping from my computer to those servers,so, what happens then ? I get a list of ip's and my game will connect to all of the ip's of the list, to get the ping ? Somehow, this doens't look like a good ideia....

[edit].., my game is a fps

Bruno


[edited by - Bruno on July 10, 2002 3:45:03 PM]

Actually that is quite simply how it works.

* You connect to a master server list.

* You retrieve a list of servers (possibly specifying a server side filter.)

* You then ping each server. This "ping" can either be a full-blown ICMP request or a simple ECHO request to the server. If it is an ICMP request the ping you receive and the ping you get when you connect to the server might not be the same.

The reason is that ICMP requests are handled at the driver level and are unencumbered by how slow your game server is processing messages from clients. This creates an issue for clients because they think they are connecting to a fast server but instead are joining a server that is struggling to stay ahead.

It is better to send a UDP packet to the server requesting an ECHO back. When the server receives this data it will encode the store the time the message was received. When the server gets around to processing the message it then takes another time sample and calculates the difference. It sends this difference back to the user as part of the "ECHO" response.
The client then takes the time that it sent the packet and calculates the actual latency of the route to the server AND the latency of the server itself. You can then display the route''s latency and the server''s latency to the client.

BTW I believe most servers just echo back the request immediately and therefore you only see the route''s latency.


Dire Wolf
www.digitalfiends.com