1
\$\begingroup\$

I am trying to create an 2d html5 open word (the sprite does not have any fancy flare, just shapes around) with only maximum of 10 player at once. My question is how to create a seamless join for new player join when 5 others have already started roaming in the world? in the other words, how to maintain synchronization for a new player for all updates that is happenning in new world.

I know pub sub can do the trick but it is very wasteful to catch up from start of the queue. How can a new player get a refresh of the current state and continue to stream from movement from other exisitng player? Thanks.

\$\endgroup\$

2 Answers 2

Reset to default
1
\$\begingroup\$

The typical way to do this is to send the new player the current state of the world / simulation, and then make sure and send any new events to them (even while they load into the map, to be processed when they are done loading) so that they are sure to be up to date.

If this doesn't work for your needs for some reason though, let us know, since different game requirements have different "best answers" to this.

\$\endgroup\$
4
  • \$\begingroup\$ Hmmm. I kinda of get the idea. So, I have created a datastore that keep all the current state but this state (which is just x and y position) is always being updated all the time by multiple client. Where do you pick as current state? \$\endgroup\$
    – user642318
    Commented Jul 18, 2015 at 5:14
  • \$\begingroup\$ Pick whatever is most recent, then make sure and include that player in all the messages that would update state from that point on, to make sure that they have all the same information they should have. You just want to make sure there are no gaps and no lost information. Using incrementing ids would be great for this, for knowing where the cut off point is, if that makes sense in your situation (: \$\endgroup\$
    – Alan Wolfe
    Commented Jul 18, 2015 at 5:21
  • \$\begingroup\$ @user642318 You should have an authoritative current state on the server, because otherwise you can't have the server manage the game mechanics. When you let the client manage the game mechanics without the server supervision, the clients can cheat as much as they want. This is especially a problem in HTML5 games because the browsers developer tools are right at your players finger tips and you can't do much to limit what they can do with it. \$\endgroup\$
    – Philipp
    Commented Jul 18, 2015 at 10:37
  • \$\begingroup\$ That's not strictly true, but it can be a problem if you don't account for it. A way to get around that is what is done in typical lock step simulation games. Have each player send a hash of their game state and then if there is a mismatch of hashes, use majority rule to kick the minority, or other strategies. \$\endgroup\$
    – Alan Wolfe
    Commented Jul 18, 2015 at 13:53
0
\$\begingroup\$

Most of the time, the size of the world doesn't matter as much as the number of players. For just 10 players, you can get away with a lot of things.

Unless the world changes, syncing game states would be trivial. You could just have every player send their properties (i.e. position, rotation, health, etc.) to all the other players.

If the world changes, there is the issue of determining what the state of the world is. You could have one player be the "Master" of the game and have the final say of what's what in the world. When a new player joins, the new player requests the world state from the master client.

The cleanest way would be with an authoritative server but an authy server is more difficult to develop and manage than just giving that authority to a client.

\$\endgroup\$
1
  • \$\begingroup\$ Having the clients send their position and health to the server is really bad advise, because it makes it really easy to cheat. Especially in Javascript games where every user has a debugger and javascript shell just a hotkey away. A good online game should have an authoritative server where the server tells the clients how much health they have and only takes requests to perform actions which can be denied. And an authoritative server is usually far easier to implement than having a client take the role. \$\endgroup\$
    – Philipp
    Commented Apr 18, 2016 at 8:47

You must log in to answer this question.

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