Jump to content
  • Advertisement
Sign in to follow this  
Chris Reynolds

Client-Host model appropriate?

This topic is 3159 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

I just finished a multiplayer model for my game, and I wanted to make sure it is a smart model to use before I continue. Matchmaking occurs on a server (my computer). Clients can choose to host a game, and other clients join that game. When the game starts, the host and all clients disconnect from the server and connect to the host using NAT Punchthrough. The model works like this: Clients send information to host, and the host broadcasts this information to all other players, excluding the client who originally sent it. My questions are: 1.) The game is basically a first person shooter, with possibly many players. Is it feasible to expect most (i know not all) hosts to be able to basically be the server in a game of this sort? 2.) Is this a reasonable method to send information? Thanks for any help

Share this post

Link to post
Share on other sites
For 1) It depends on what your bandwidth requirements are. afaik, COD:MW2 is limited to 12 players per team, that's 24 players. That is probably down to their worst-case scenario bandwidth usage, and what consumer broadband they are targetting (512K DSL?).

for 2) it is perfectly reasonable, provided you can fit your update into the upstream requirements of your targeted home broadband.

You can do the maths on paper, and see how it scales with the number of players.

Say a client update size is 'c'. The server state size, without considering clients if 's'.

For 'n' client in the game, the server will send s + c * (n * (n - 1)) to each clients. s + c * (n^2) if you want to ping back client updates to its proprietor. You can also make sure the clients who want to host understand the requirements for hosting games (i.e. needs at least 512mbps outstream). If someone who wants to host the game but doesn't have the bandwidth capacity to do so, then tough. He'll be dropping packets.

That is unless you can actually perform a bandwidth evaluation of the client to discover how much downstream/upstream he has. You could also ask him directly to enter his performance evaluation (some ISPs provide tools to discover the performance of your connection), and take it on good faith.

Then you can either, reject his request for hosting (if it is really bad), allow him to host only a limited number of players, or scale his server update rate.

Form experience, anything larger that 16 players (8 per team) for a FPS, is a big ask for consumer broadband. That can be mitigated by reducing the update rate (15 fps, 10 fps even), which introduces more latency of course.

if you go peer-to-peer, each peer will send (c * (n-1)) packets, the host (who is still in control of the general game state, such as scores, game flow, pickups, ect...) will send (s + (c * (n-1)), which does make hosting on broadband more feasible, however, each client will need a decent connection themselves (although client packets are in general small), and giving the client the authority to control its updates leads to hacking, cheating and exploits.

A peer to peer network is also more prone to point-to-point failures. What would happen if one peer cannot talk to another peer?

Two options : either re-route the packets through another peer, or drop one of the two from the game. To simplify, kick the peer that connected to the game last.

If you do the server-client system, I would advise to use the method as described by gaffer in his networking physics articles.

basically, send player commands, as well as the predicted position of the player from each clients, to the server.

server runs the commands on his end, check if it corresponds to his simulation, and if the results deviate from the client prediction, sends a correction packet back to the client, who then rectifies his position.

This so that the client is not completely in control of his player, but only 'simulates' and predict where the server would move the player to. That's basically client-side latency compensation, that allows for responsive controls, while keeping the server the authority to everything.

Doing that in peer to peer is obviously overkill and probably pointless. Clients will be in charge of their players.

[Edited by - oliii on October 26, 2009 1:17:47 PM]

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!