I am developing a 2D multiplayer game as follow:

  • semi-authoritative server
  • handle up to 40 players per game.
  • Players and other game objects will interact/collide with each other
  • Physics like bouncing are required

Technologies I am planning to use:

  • Clien: unity3D (easy to develop + cross-platform)
  • Server: node.js + socket.io (easy to deploy and cheap to host)

Considering that most networking solutions for Unity3D are expensive and not suitable for small games/projects and UNET still under development...

By using a different physics engine on the server side like matter.js + node.js:

1- Would it affect the gameplay and the game objects synchronization?
2- Would it be impossible or very hard to provide a smooth physics experience to the player?
3- Is there any other issue I should expected to deal with?
4- Is it a bad idea?

Any peace of information will be well appreciated. tks

  • \$\begingroup\$ It's fine. The physics engine isn't deterministic anyways. You can view the client-side physics as a highly advanced "prediction" method. \$\endgroup\$ – MickLH Jan 18 '16 at 19:25

When you use two different physics engines, it will be almost impossible that they will always come to the exact same results. Large physics systems can behave quite chaotically (small changes in variables create drastically different outcomes). So considerable desynchronization will become inevitable.

The most obvious solution would be to keep the physics completely under the authority of the server: Nothing moves until the server says it does. But that will affect the game experience negatively because players will notice the lag. So you will have to use the client-sided physics engine to estimate what the server-sided physics-engine will do and then correct any differences as soon as possible.

You could have the server send the physics-state of all game-objects to the client at regular intervals and then have the client correct all physical attributes as soon as they receive them. How well this works will depend on your game (how much physics interaction you have and how chaotic it will be) and how well you can get the two physics engines to behave nearly the same.

  • 1
    \$\begingroup\$ 100% agreed. Not a good idea by the way. Better solution is don't use any physics engine at server end. Just send and receive data to particular players and handle physics and all other stuff through that data \$\endgroup\$ – Hamza Hasan Jan 18 '16 at 20:15
  • \$\begingroup\$ @Philipp what about the suggestion posted below using Box2D JS (project seems a bit dead though), would it still create drastically different outcomes because it's ported and not really the same? \$\endgroup\$ – Devester Jan 18 '16 at 22:33
  • \$\begingroup\$ @Hamza doesn't that assume trust of the client? Opening you up to cheaters \$\endgroup\$ – Richard Tingle Jan 19 '16 at 6:29
  • 2
    \$\begingroup\$ @Hasan I don't see how encryption would help. It would be encrypted by the hostile system with no other entity checking it. I'm suggesting the other player is hostile not an unknown 3rd party \$\endgroup\$ – Richard Tingle Jan 19 '16 at 7:09
  • 2
    \$\begingroup\$ @HamzaHasan I said it a thousand times and I am saying it again: The only game mechanics which are save from cheating are those which run on the server. Any security measures on the client can be hacked. Encryption is pointless because the hacker can find your algorithm and key in your client software. \$\endgroup\$ – Philipp Jan 19 '16 at 9: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.