Synchronizing players and game objects in a server/client multiplyer game

Question

OK guys, I have some experience with 2D game development (single player only), so that's fine no questions here.

The problem is with multiplayer games. I already read lots of other questions and articles to get my head around about peer-to-peer and server/client, and non-authoritative and authoritative game clients.

What am I trying to achieve?
Build a simple 2D multiplayer game with some physics involved and over 40 player per game, a good example is flapmmo. However my game concept will be completely different and the players and other game objects will actually interact/collide with each other.

What technologies have I chosen?
Client: Unity3d (easy to develop and cross-platform)
Server: Node.js + socket.io + express.js (easy to deploy and cheap to host)

What I have done so far:
I already have a test client and server running and the players connection/join game + spawning works just fine. Now I am stuck at how to synchronize all the objects + players.

Base on that:

1 - How do I simulate physics on the server, do I need to rewrite parts of client side on the server side using a JavaScript physics engine?

2 - Is it better to send action messages like "playerJumped" and broadcast it to the clients or send it's current position on every update (more bandwidth consumption I guess)?

3- I read the server needs to run on a lower frequency( E.g. 30hz) to better perform with latency issues. Is it FIXED_TIME_STEP that we are talking about?

Please feel free to add any other important point I should consider...
Tks

Answer 1

Interesting Question! Let me try to answer some of your points:

1 - How do I simulate physics on the server, do I need to rewrite parts of client side on the server side using a JavaScript physics engine?

Yes, essentially, thats what you would do, if you want physics on the server. You have to ask you the question: Do I need the server to validate everything the user does? In your example-game I'd say no. Of course, someone could change the client-code and cheat himself through the level, but it doesn't really matter. It would not really hurt any other player, neither does he really get a benefit from it other than 'be the king' for a bit.

No, you don't need a full-baked physics engine. Lets say you have a floor and want the player to fall, but not fall through the floor. Thats simple to realize, I'd not call this check a physics-engine. Maybe you also have walls where the player can not walk through. I wouldn't call this a physics-engine either. Only when you want objects to collide and bounce of each other physically correct you'd use a real physics-engine.

2 - Is it better to send action messages like "playerJumped" and broadcast it to the clients or send it's current position on every update (more bandwidth consumption I guess)?

This heavily depends, but in most cases you send a mixture of both. In your example-game, a 'playerJumped' wouldn't be enough because latency matters. Every single nanosecond could change the outcome heavily, so that a 1ns-to-late-jump changes the position of the player 20 seconds a lot. Thats not what you want, so you'd send 'i jumped in frame 30' or something like this. In a fixed-timestep game this would be enough to get the same result on every client. Updates every frame are in this case not needed because every client can calculate your position and would have the same outcome.

3- I read the server needs to run on a lower frequency( E.g. 30hz) to better perform with latency issues. Is it FIXED_TIME_STEP that we are talking about?

I don't understand exactly what you mean with your last sentence, i hope i got it correct. Yes, thats a fixed timestep. 30hz means 30 updates per second, which gives us a timestep of 1/30 = 33.3 milliseconds per frame. The servers frequency doesn't really matter to better perform with latency issues, what matters is how you extrapolate and how you handle late-pakets. But, the frequency matters when you have a lot of players. The server might not be able to calculate 10000 * 60hz updates per second, but it might be able to calculate 10000 * 30hz. In a few cases you don't even need a frequency. With this I mean: you don't have a running game-loop in your server, but just handle the incoming packets and distribute them to the other clients. But this - again - depends on the game you write.