Multiplayer game with JavaScript backend and frontend. What are the best practices?

I'm thinking of creating a web multiplayer game in Node.js. This means I'll be using the same language in the backend and in the frontend. It would be in realtime and about 20 people max in each 'room', so I have a few thoughts:

1. How do I compensate for the delay among all users so that everyone sees the same thing the same time? I'm thinking of tracking the average ping time of each player, find the slowest one, and inform the other clients of the time (in milliseconds) they have to be delayed each one so that everyone is as synchronised as possible.

2. I'm thinking of running开发者_如何学Go the game code in the backend as well as in the frontend (since it's JavaScript on both ends) and just have an error-correction mechanism to synchronize with the 'real game' in the backend. That way the game should perform smoothly on the frontend and with only few glitches when the synchronisation happens. Also that would minimize frontend JavaScript hacking since cheaters would be synchronised down to the backend game.

3. Should I receive player actions through the socket (keypresses), inform all other clients of the other players' actions and in the mean time 'playing' the game in the backend and send synchronisation information to everyone of the entire game state every once in a while to synchronise them?

What do you think? Are there more stuff I should consider or pay attention to?

Please post any thoughts or links to documentation or articles regarding multiplayer gaming.

EDIT: These are useful:

• Gaffer on Games - Very good articles by Glenn Fiedler on multiplayer game networking and physics
• The Quake3 Networking Model

1 - is impossible. You don't know exactly how long a message will take to arrive on a client and no measurement you take will necessarily be applicable to the next message you send. The best you can do is an approximation, but you always need to assume that people will see EITHER slightly different things OR the same things at slightly different times. I'd recommend just sending the current state to everybody and using interpolation/extrapolation to smooth out the gameplay, so that everybody sees the game a few milliseconds in the past, with the delay varying both between players and over time. In general this is rarely a big problem. If you really want to buffer up some past states on the server you can interpolate between them and send different old data to different people in an attempt to sync what they see, but combined with the client side simulation and the jitter in transmission times you'll still see some differences across machines.

2 - the typical way is to run the simulation on the server, and send regular (small) state updates to clients. Clients typically run their own simulations and have a way to blend between their own predicted/interpolated state and the authoritative state that the server is sending them. All decisions other than user input should be made server-side. Ultimately the way you blend these is just a tradeoff between a smooth appearance and an accurate state so it's a cosmetic decision you'll have to make.

3 - your client should typically translate a keypress to a logical action. Your server doesn't care about keys. Send that logical action to the server and it can broadcast it to other clients if they need it. Generally though you wouldn't need to do anything here - any relevant change caused by the action will typically just change the game state, and thus will get sent out in the normal broadcast of that state.

1. This one is very hard to do, and I can see lots of problems with syncing to 'the slowest'. Can you loosen this up so the clients could be 'eventually consistent'?

2. Sounds good.

3. I would send short action events from front ends to backend, have the backend modify game state and publish game state modification events back to the clients, with much attention to only sending the necessary events out to the right subscribers. At this point you can discard any events that don't seem to match or that seem like fakes/hacks.

The best way is to keep track of all objects in only one place, namely the server. Everyone will see the information from the servers one travel time later than it "actually happens" and people's commands will take one travel to register on the server. There really is no way around this. For some applications it can be practical to simulate your own movement right away without waiting for a server response but this will undoubtedly lead to a nightmare with the timing programming and people will typically see each other "lagging around". Collision detection is all but impossible.

The net effect of this is that there will be a sluggishness from when you enter your commands until you see them actually happening but hopefully people will learn to cope with this and try to input their commands slightly earlier to compensate. With slow connections fast-paced realtime games is just impossible.

One typical approach is not to try and force all clients to run at the same framerate locked to the server... it just gets ugly. Instead, send frequent updates so clients can update whenever they receive a new update.

Normally, a client will predict how things are going for short periods, then be corrected by an update from the server. You can apply time corrections too. For example, if the server tells you "player 2 is at P travelling at velocity V" you can make some attempt to know how old that message might be based on a recent ping, and correct the position from P to P + x*D.