I'm developing an exploration-based platform game in which from the start there were plans about including local multiplayer support, but recently I've been considering an online multiplayer mode, mainly because in local multiplayer, because I think it'd make players loose too much visibility to be worth it, I don't want to split the screen between players. It'd be akin to Spelunky.

But I really want for players to be able to explore rooms independently just as much as cooperatively (in the style of Kirby & the Amazing Mirror, for GBA), and online multiplayer would solve this problem of local multiplayer, but I've been wondering what exactly I could do about synchronizing the states of mob between the clients whenever the players are in different rooms. For example, what do I do when a player enters a room in which players were already meddling with the monsters and the evironment, how do I update him with everyone's states?

This question and its answers suggest that I keep a host which is constantly updating the various rooms with players and from them I can provide each client with only the significant data, but what significant data do I need to send my players? Before multiple rooms all that I needed to send was input and random numbers (not much, my game has fixed timesteps), but now I need to send the whole data of entities? After all, each creature has plenty of variables that influence in its AI and physics, as I'm dealing with a platformer.

What are the alternatives?


When you have a multiplayer game, you have to be aware that the players are able to cheat with everything that is computed locally. When you want the game to be fair, you have no other option than to move all game mechanics (movement, mob AI, collision detection, damage calculation, ..., ... ) to a central server.

But let's assume that the community around your game is 100% free of cheaters and trolls, so no hacker feels like developing cheats (this assumption is likely very wrong when the community around your game grows beyond 100 people).

Under this assumption you could let each player play on their own and as soon as one or more players get near each other, the clients automatically elect a host. It should be the one of them with the lowest average latency to all other players who is not behind a NAT firewall. The host calculates all game mechanics and sends the results to the client(s). Note that when all clients are behind NAT, no multiplayer is possible without a centralized server.

The host doesn't need to inform the clients about the internal state of objects. It only needs to send the external state: What's the object, where is it and what is it doing right now. "Objects" in this context are everything that has a visible state: mobs, interactive objects and player-characters. Sometimes, though, it might be useful to keep clients informed about certain details of internal states, when these details are useful for client-sided prediction of actions to make the game appear less laggy (when clients know a certain mob will turn around as soon as it reaches a certain point, they can do that before receiving that information from the server).

  • \$\begingroup\$ I could very well make a central server program, but it'd be a bit overkill for when the max number of players that I want in my game are 4. "Host electing" already seems like the best plan. :) Also, I think I have no way around sending the entire data of objects, even if it will be tiresome to implement specific methods for each class, but there are plenty of variables that are important in deciding the mob's state. \$\endgroup\$ – Mutoh Apr 1 '14 at 2:19

You will send the entire state of the given simulation to any player who joins. That does not mean you need to send the entire representation of the host/server representations, but you do need enough that the client can accurately render and interact within the simulation. This might include things like:

  • Sprites
  • Names
  • Position
  • Velocity
  • Bounding sizes
  • Statistics (useful if you want to show information on a mobile)

Some information is not as useful to a client, such as:

  • Damage computations and formulas (the server can do most of these)
  • State that is only used on the server side

That being said, once you have sent the states you will continue to need to send deltas. That is, send changes that have occurred to your mobile from list 1 so that the clients may stay accurate.

  • \$\begingroup\$ This actually wouldn't be very bad. I could, instead of having each client process the game normally but with input sent from a server, just update each mob with states provided from the server in each frame. This could be actually even more lightweight for the client than the previous idea. \$\endgroup\$ – Mutoh Apr 1 '14 at 2:22

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.