1
\$\begingroup\$

I am researching the possibilities for a new iOS game. It's going to be a run-n-gun type platformer, and I'm looking into the possibility of co-op multiplayer.

The game itself wouldn't be very physics intensive, there will most likely be 20-30 physics bodies at any given time. For the multiplayer, I think I would have one player "hosting" and up to 3 other connecting via the Internet.

Here's my first question, are there any 2D physics engines that work over a network(preferably open source)?

My second question, Does anyone have any thoughts on using a non-networked engine (like Box2D or Chipmunk) and adding the networking component? Since there would not be very much information sent, do you think it would cause a lot of lag?

| improve this question | |
\$\endgroup\$
2
\$\begingroup\$

Your second option is how it's done. Why would your physics engine know anything about networking? That breaks OOP principles. I suggest you use Box2D. Each mobile device has a world running, but one of them is the master. The master regularly pushes and receives game state updates from the slaves, reality-checks them, and then passes them on to other slaves if the updates passed. Ideally, you only want input sent on the slave-master channel, then you don't even have to do reality checks.

| improve this answer | |
\$\endgroup\$
  • \$\begingroup\$ Yes why? Depends on what you mean with "know about networking", but a physics engine should be able to rewind and replay based on new input which happened in the past, but only now reached the server, and eventually, the clients. gafferongames.com/networking-for-game-programmers/… \$\endgroup\$ – Prof. Falken Nov 30 '12 at 14:39
  • \$\begingroup\$ The responsibility of a physics engine is to update a physics scene - nothing less, nothing more. That could include features such as rewinding, but code that deals with networking should not be a part of the physics engine (and by physics engine I mean a collection of classes such as ConvexBody, SceneManager, etc, sure you could bundle those up in the same package with NetworkManager and just call it "the engine"). Also, if you're the one that -1'd my answer, could you please give a more concrete reason for that, so I can correct it? If not, ignore this paragraph... \$\endgroup\$ – jcora Nov 30 '12 at 14:58
  • \$\begingroup\$ Yes, I downvoted, that was why I commented. I don't think "use box2d" is very helpful, at least not without additional discussion on why you might want to have (or forego completely!) state replay, and if you want state replay, how Box2D is going to help you with that. I haven't researched extensively, but I can't find any obvious way to extract and put back state with box2d. Main point: I don't think an answer without discussion about state replay is complete. \$\endgroup\$ – Prof. Falken Nov 30 '12 at 16:25
  • \$\begingroup\$ "but a physics engine should be able to rewind and replay based on new input which happened in the past" by that I mean, something which will be useful for networked games which care about lag or are not run in lock-step like strategy games often are. \$\endgroup\$ – Prof. Falken Nov 30 '12 at 16:28
1
\$\begingroup\$

In most games the physics are not synchronized as it either requires a lot bandwidth or a completely synchronized network code.

The synchronized network approach means that at the start all data is the same for all clients, and the whole game is calculated on each client in the same time steps. Just the controls the players push are transferred. If all game logic is deterministic then all games will keep in complete synchronization.

Upside of this is that this approach only needs a few kbit's to work properly, no matter how complex the game is.

Downside is that the controls of the players are delayed by the lag and that it requires a fixed time step that is the same for every player. A fixed time step also means that if one player lags all players will notice that lag.

This approach is/was used by strategy games mostly due to the large amount of units.

A quick note about determinism, floating point implementations can differ from processor to processor, so they are deterministic as long all devices you target have the same floating point implementation, if you can't be sure of it you'll need a physics library which uses fixed point math.

| improve this answer | |
\$\endgroup\$
0
\$\begingroup\$

Much like Bane said, a "Multiplayer(network) physics engine" is a physic engine running on the server side. Much like any game logic running on a server side(to prevent cheating).

To prevent lag, you can have a physics engine running per-frame on each client for fluid motion between server updates. Another engine instance running on the server updating the players less frequently for correctness and cheat prevention.

Note on latency or LAG:

There is no magic cure for lag, you simply have to optimize your code as much as possible and wait for technology to do the rest. Most latency isn't due to the amount of data you sent each sec. It actually has to do with number of milliseconds it takes that data to travel (could be distance related/ technology* related). Sending more data should not affect latency much with today's tech, because you will likely still be able to send data as frequently.

In the old days, the bandwidth and the amount of data transferred were the bottleneck as far as latency goes, the connection was so slow (4Kb), it actually needed more time to send slightly more data. That is still true today only in cases where the amounts of data transferred is very large (streaming HD content on Netflix 2.3Gig per hour). The modern connection speed can handle game data pretty well, 10-40 physical objects moving around are not going to noticeably affect performance.

For instance, if for some reason we switched from Ethernet to InfiniBand, the latency would decrease dramatically even though, it may or may not affect bandwidth.

http://en.wikipedia.org/wiki/InfiniBand

| improve this answer | |
\$\endgroup\$
  • \$\begingroup\$ No, Infiband would not mean much, if anything. Latency comes from speed of light and rounting, not switching technology. \$\endgroup\$ – Prof. Falken Nov 28 '12 at 21:53
  • \$\begingroup\$ @AmigableClarkKant I think you missed something : Read this : mellanox.com/content/pages.php?pg=performance_infiniband See the bit about latency? \$\endgroup\$ – AturSams Nov 30 '12 at 14:22
  • \$\begingroup\$ Yes, I am sure they will reduce latency in data centers and on LANs. serverfault.com/questions/61719/… And this is even ignoring the IP layer. Is Infiniband magically making IP routing faster? \$\endgroup\$ – Prof. Falken Nov 30 '12 at 14:33
  • \$\begingroup\$ @AmigableClarkKant The example I mentioned did not reflect on Internet gaming. It does not say "if we used Infiniband to create a new network or networks. :) It is just a simple example on how technology affects latency which it clearly does? \$\endgroup\$ – AturSams Dec 4 '12 at 8:56
  • \$\begingroup\$ @AmigableClarkKant Also, speed of light is about 3microseconds per kilometer. The earth's circumference is about 40,075km so getting from one place to the opposite side of the earth is about a 20,000km journey which would take light about 60,000 microseconds which are 60 milliseconds.. fiber optics take about 50% longer so lets say 90 milliseconds. There are greater problems than the limiting factor of the speed of light. Technically, doing some of the heavy lifting with infiniband or simply having shorter queues (less load) would affect the latency greatly. +not all lines are fiber optics \$\endgroup\$ – AturSams Dec 4 '12 at 9:08

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.