Jump to content
  • Advertisement
Sign in to follow this  
grill8

Questions about topologies for game networking.

This topic is 3173 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

Hello, I have some questions about topologies for game networking. I would like my game engine to support multiplayer capabilities (multiple users in the same universe) but know basically nothing about topologies in this design. I know a bit about Sockets and basic networking capabilities but have some questions. I would like the engine to be diverse enough to handle 2 player or multiplayer games but really do not know where to learn about this topic or how to begin design of the networking along these lines. I guess my questions are ... Question 1) How are topologies on this topic generally handled? Question 2) What types of processing are generally handled server side and what is handling client side? Question 3) Where do I find information on this topic? Question 4) Is Boost.Asio the way to go on this topic? Question 5) What suggestions/tips would you have for a newbie to multiplayer networking? Thank you for your help. Jeremy

Share this post


Link to post
Share on other sites
Advertisement
Quote:
Original post by grill8
Question 1)
How are topologies on this topic generally handled?
You have two basic choices: peer-to-peer, or client-server.

Peer to peer suffers from higher bandwidth requirements, greater latency, and can be vulnerable to various artefacts and cheating due to the lack of an authoritative server.

Client server puts greater processing and bandwidth requirements on the server, but eases the load on the client. Because the server is able to be authoritative, it is easier to keep the game world consistent and prevent cheating.
Quote:
Question 2)
What types of processing are generally handled server side and what is handling client side?
Generally, in order to prevent cheating, the server handles all processing and simulation, while the clients act as dumb terminals, just handling input and rendering.
Quote:
Question 3)
Where do I find information on this topic?
The Forum FAQ is a good place to start.

Share this post


Link to post
Share on other sites
Thank you for your help.

Based on what I hear and know I am making the following assumptions and would greatly appreciate hearing input as to their validity.

Assumption 1)
For a SINGLE world with multiple players you would use client -> server topology with (as you say) all simulation processing being handled on the server (physics, AI etc.) and the clients performing only input/rendering.

Assumption 2)
For a MMO world (MASSIVE world, i.e. World of Warcraft) you would need to share the server side processing across multiple servers. Physics for a world of that size could not be handled on a single server. You would still use client -> server but the server end would be shared across multiple servers.

Assumption 3)
For an application which spawns multiple instances of the same world (i.e. a game which takes ... say ... 20 players but there may be 100 games (of 20 players) happening simultaneously, you would use client -> client networking where the processing is all happening on the clients ends.

Thank you for your help.
Jeremy

Share this post


Link to post
Share on other sites
Quote:
Original post by grill8
Assumption 1)
For a SINGLE world with multiple players you would use client -> server topology with (as you say) all simulation processing being handled on the server (physics, AI etc.) and the clients performing only input/rendering.
In general yes (though there are exceptions, see my answer to #3).
Quote:
Assumption 2)
For a MMO world (MASSIVE world, i.e. World of Warcraft) you would need to share the server side processing across multiple servers. Physics for a world of that size could not be handled on a single server. You would still use client -> server but the server end would be shared across multiple servers.
Pretty much.
Quote:
Assumption 3)
For an application which spawns multiple instances of the same world (i.e. a game which takes ... say ... 20 players but there may be 100 games (of 20 players) happening simultaneously, you would use client -> client networking where the processing is all happening on the clients ends.
Generally, in each 20 player game, one player will be designated as the 'server', and the rest as 'clients'. This allows all the benefits of client-server, without the costs of maintaining dedicated servers. On the flip side, it requires the player hosting the game to have a fairly decent computer and internet connection.

Now, some games do use a peer-to-peer scheme, where every client runs the *entire* simulation, and are carefully engineered to keep their simulation in perfect sync with that of every other client. Needless to say, this is complicated to develop, but if you can afford the latency, it can be a very viable technique. I would suggest you peruse a very nice article on this technique, at your leisure.

Share this post


Link to post
Share on other sites
A very good read.

Thank you for your help.

Question)
If using one client also as the server, would you recommend querying all clients hardware (In DirectX the DirectX caps) for the BEST possible hardware and then using that client also as the server? Seems reasonable.

Jeremy

Share this post


Link to post
Share on other sites
That can be one factor in choosing which client to have host. Though you might want to focus more on the available CPU and RAM. Keep in mind that one client may have nice quality hardware, but running the game with settings so high that it runs really slow. Some people actually do love their pretty effects "that much".

A more important and reliable factor is available bandwidth (do a quick measure of bandwidth before choosing) and their latency to the other clients. Ideally, you want the client that has the lowest latency to all other clients. For example, imagine the world was one-dimensional and your clients were laid out like:

AB.....................C.D.E.F.G.H

A and B will have a low latency to one another, but high latency to everyone else. D or E would probably be the ideal server (all other factors aside) since they would have a good ping to the others, but not try to help out A and B so much that it cripples everyone else.

Share this post


Link to post
Share on other sites
Quote:
Original post by grill8
A very good read.

Thank you for your help.

Question)
If using one client also as the server, would you recommend querying all clients hardware (In DirectX the DirectX caps) for the BEST possible hardware and then using that client also as the server? Seems reasonable.

Jeremy


That's difficult. This could involve some sort of server migration, which is a PITA.

a game 'server' is usually called a game host, versus the game clients. Servers usually denote either back-end systems such as matchmaking servers, stats servers, or dedicated game hosts, usually hosted by big server farms with loads of bandwidth. A game hosted on a home connection will need a lot of bandwidth to run, say, a Left For Dead or Team Fortress 2 server.

The problem with home connection is that they are designed more as a user, receiving data from providers. So they usually have poor upstream bandwidth, which makes them unsuitable for hosting bandwidth-hungry games. That's where peer-to-peer comes in, by spreading the workload and upstream bandwidth requirements to all game users. A lot of the bandwidth is used up by player state broadcasts, so in theory, each player could have control over his local player, and be responsible for sending their player updates to every other peer in the game, but that's 1) very open to cheats, and 2) each client MUST have an established connection to every other peer, and with the internet, that's not 100% guaranteed (router issues, ISP issues, ect...). It's a lot of hassle really.

A 'game' is usually named a 'session', a session is basically a self-contained game environment (a game instance), with a list of connected users sharing the same game state.

A game session is advertised on the matchmaking servers (basically, a database of game sessions currently running around the world). If you run a SystemLink session, you don;t actually need a matchmaking / advertise server, you can use a broadcast socket to discover all games running in the LAN (but you cannot do that on the internet!).

In game menus, a player decides if he wants to host a game, or search for a hosted session.

when he decides to host a game, he creates a session that is advertised through matchmaking servers ()battle.net, arena.net, ect...), so other players can find his session and join him.

If he instead decides to join a game in progress, he queries the matchmaking servers for a suitable game session he can join, then joins that session, by sending a join request to the game host. Then all sorts of hand-shaking / verifications are performed by the game host to accept that player into the game session.

Once the player is in the game, the game host broadcasts the game state to all the clients. The clients in return regularly send their inputs to the game host, so the host can move the player around in the game.

The clients also perform lag compensation and client-side prediction to remove lag in the controls (since the player is controlled authoritatively by the game host).

It's all in the FAQ. Look for Beej's networking Socket tutorials, Gaffer's networking articles, and Source networking docs.

If you wish to use a third party library to do all the dirty work, look at RakNet. You will also need to make a choice between UDP and TCP/IP sockets, the pros and cons are also in the FAQ.

Share this post


Link to post
Share on other sites
Sign in to follow this  

  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

Participate in the game development conversation and more when you create an account on GameDev.net!

Sign me up!