15
\$\begingroup\$

When designing a networked multiplayer-game where one player hosts and others connect, there are two strategies I'm aware of:

  • Have the host-player's game be the authority, with all other players as dumb-clients trying to catch up with the current game-state. In the code, there will have to be lots of special cases, depending on if the current player is the host or not.
  • Make the host a dumb-client like everyone else by running a hidden dedicated server on another thread. The dedicated-server will be the authority, and the host will connect to it like everyone else (through localhost).

What are the advantages/disadvantages of each of these? Which is used most often (or does it vary by game type/size)?

Improve this question
\$\endgroup\$
1
  • \$\begingroup\$ The first case you are describing can be one form of P2P networking(with one authoritative client) and its usually much more complex, and harder to implement and maintain. \$\endgroup\$
    – akaltar
    Dec 24, 2013 at 1:29

2 Answers 2

Reset to default
13
\$\begingroup\$

The dumb-client approach is best from a pure design point of view- it heavily limits the amount of different code you need between host and clients, and allows the server to run asynchronously. The downside is that the host's machine requires extra resources- but I guess it always did.

Improve this answer
\$\endgroup\$
8
\$\begingroup\$

Between these two options the dumb-client approach is certainly best for the reasons DeadMG mentions.

There is another option which is make every client an authority, it has the advantage of the dumb-client that all peers share the same code. The other advantage is that it might be a lot more fair if you set the right rules because no one has the 0-lag-to-server advantage.

This can ofcourse be rather tricky to implement depending on the game type. Your protocol will have to deal with solving conflicts between peers, probably using some kind of ownership scheme. Leaving only the conflicts where 2 peers claim ownership of the same game object.

Googling Peer-2-Peer multiplayer protocols might give you some more details about this approach.

Improve this answer
\$\endgroup\$
10
  • 1
    \$\begingroup\$ gamedev.stackexchange.com/questions/3887/… Here's some more info :) \$\endgroup\$
    – michael.bartnett
    May 28, 2011 at 0:30
  • \$\begingroup\$ Interesting. That post claims that this is how "most strategy titles" implement networking. Is this really true? Is this how eg. Command and Conquer and Starcraft work? \$\endgroup\$
    – BlueRaja - Danny Pflughoeft
    May 28, 2011 at 2:10
  • \$\begingroup\$ @BlueRaja, this is how Starcraft works, yes. In Starcraft there is no authority at all. Warcraft III and Starcraft II have more centralised message exchange model, lag and disconnect handling, but fundamentally the same in that each client hosts its own game state. \$\endgroup\$
    – Rotsor
    May 28, 2011 at 7:24
  • \$\begingroup\$ The other advantage of this networking model is that it allows to support large consistent shared world state with minimal synchronisation traffic. \$\endgroup\$
    – Rotsor
    May 28, 2011 at 7:27
  • \$\begingroup\$ The largest disadvantage of this model is its inherent vulnerability to "maphacking", that is revealing some game state data the player can't normally see. \$\endgroup\$
    – Rotsor
    May 28, 2011 at 7:31

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .