Physics multiplayer game

[enriqueto]

I did that recently using phaser and box2d:

http://www.miniclip.com/games/super-soccer-noggins/es/#t-l-gs1-H

does anyone know if a multiplayer version would be possible? Is there any example of something similar? 

[kevdude]

First of all, congrats on getting your game on miniclip, that's a big accomplishment!

As for a multiplayer interface, you could have a lobby where players create matches and other players can join those matches, or just have a server match players randomly.

You can write a simple WebSockets server using node.js, and transmit each player's movements to the other players. You could use a server hosting service like openshift or heroku to host the code.

 

Some examples are wilds.io that runs on multiple nodejs cores, 8 ball pool which incorporates the player match system, and of course my game BlockTanks, which is a multiplayer tank game.

Hope this helps and let me know if you have questions!

EDIT:

A similar question was asked on this post, which might help...

[enriqueto]

I think that a multiplayer box2d game is more complicated that. 

Positions of the entities are not determined by the controls but by the box2d world. For example, when a player jumps the game applies a vertical force to the player's body. The position of the player is calculated by box2d taking into account collisions with other game entities.

Position prediction or interpolation is not possible. The 2 players need to see the same in a high responsive game that runs at 60fps.

More precisely my questions are:

• Is there an example of a multiplayer game implementing a networked box2d physics system?
• Where should the box2d world run. In an authoritarian server, on one of the clients?
• How are entities positions synchronized?
• How is the information exchange minimised?

I think that the pool game uses their own physics system, which is much simple than box2d and has incorporated trajectory prediction.

[waechtertroll]

Your game is really entertaining, congrats!

In your case the problem is, that box2d physics is non-deterministic (or not-completely-deterministic). So even when two players' box2d engines get the same apply-force command at the same time, due to performance/update differences there will be marginal differences in e.g. the ball position.

My thoughts on the subject are the following possibilities (although there may be better ones):

1) Running box2d on a server might put lots of pressure on the server, depending on the number of concurrent games running, so the game might become jumpy, unless you have some dedicated servers

2) Running box2d on one of the players' machines might take pressure from the server, but put that player at an advantage, although not by much if you keep to communication small. However you'll need to update the positions each frame

3) Writing your own physics could allow you to keep the network updates minimal and process positions independently, but requires a bit of time

4) You could go "f..k exactness", run box2d on both players' machines, just send applied forces over the network, and rely on the differences being too marginal to notice

 

The synchronizing/network problem is something to tackle. I would not recommend copying all position updates every frame, but just send events to minimize traffic. Consider the following ideas as given by a physicist with a fancy for pure functional programming.

- Make your game updates at fixed fps and send a frame number/timecode with game packages. This will allow you to interpolate.

- Only send data when interaction happens that could not be predicted by physics (player moved, ball contact)

- Your data doesn't need to contain more than the physics event (integer type, 2 numbers position, 2 numbers applied force) for fast-paced stuff. More data can be exchanged after end of a match, when real-time is not much of an issue.

- If you have some time, write your own physics routines. Basically school physics is enough to jump and move a ball, and you don't need to do all that smart stuff box2d can do; you can simply hard-code borders and goal positions. Thus you can interpolate and predict everything every position. If you know e.g. the time the ball was hit and run at fixed fps you can guarantee that both players have identical behavior.

 

Just my 2 cents.