Hello.
My understanding is that the Corona SDK engine uses Box2D for Physics which is not deterministic.
Can anyone suggest how to handle physics in a multiplayer environment for Corona?
Not sure where to start.
Thanks in advance.
actually it IS deterministic – assuming you use the “proper” definition of determinism. given EXACTLY the same conditions it’ll produce exactly the same results, there is no randomness involved. however, change those conditions even marginally, and you could produce drastically different results.
that is, say you start with an empty world, always populated the same, always stepped with fixed time steps (and etc - everything else “THE SAME”) - you can “prove” to yourself that you’ll continue to get the same results over and over, ad infinitum.
the problem is, those conditions are extremely sensitive. in theory you could set up a sim, step it forward some N times, record all (and i mean ALL) values (positions, velocities, etc) exactly, write them to a text file, then later resume the sim at that moment from the text file. (perhaps similar in concept to whatever sort of network multiplayer sync you might have in mind)
but it won’t work in practice. not only do you not have easy access to ALL of the varying parameters (fe, what is the current inertia of a spring joint?), you’ll also find that simply converting floats to strings and back can introduce enough error to materially affect the sim.
it’s like the butterfly-flapping-wings affecting weather analogy: the sim is so sensitive to initial conditions that it may appear to non-deterministic, though it is. “deterministic chaos”, so to speak.
Thank you for your explanation…very helpful. I’m assuming that, although it is deterministic, I am not realistically going to be able to repeat the physics in a multiplayer environment.
I’m wondering what approach could work with these things in mind? I’m assuming that there are games produced using the Corona SDK that work in a multiplayer environment…I’m wondering what approach they used to make it work? How do they sync physics with each client over the server? Any suggestions?
Hi.
If you’re up for some reading, there’s a bunch of material here: Networking For Game Programmers and Networking Is Hard
You can and can’t do this.
You can’t if you expect to be able to start the same process on two devices, let them run, and expect to get the same end-results.
You can, if you correct along the way. This is how most multi-player games work. For example, in a client-server based MP game, the server is in charge of all objects in the world. Clients execute code to move and update objects, but as time progresses, the server gives updates to the clients and the clients must correct any local deviation from the server’s world view.
Now, if this sounds complicated…well it is and can be. However, do not fear. You really need to be asking yourself:
-
What parts of the MP game must be exactly the same and which parts do not need to be the same. Ex: Player position yes. Particle effects, not so much.
-
How do I achieve synchronization? Am I going to implement a master-server architecture or some peer-to-peer model?
-
Probably should have asked first, “Do I really have the chops to make an MP game? Maybe I’d be better served making some SP games first.” This is not a dig. I think folks see games and want to make them, but if you’re new this may be a big stretch. That said, if you want to do it for fun and learning: Awesome!
Take a look at M.Y. Developers autolan module and the PONG game that comes with it. This is a ‘start’ on MP via a master-server set-up. Yes, it is only Dual Player (DP), but the principles are the same.
http://www.mydevelopersgames.com/AutoLAN/
_ Way Beyond Warning: _ If you really want to dig into this, try reading this OLD article: http://gamedevs.org/uploads/tribes-networking-model.pdf It talks about the old game ‘Tribes’ and how they solved MP. This is way beyond Corona and Lua, but it will give you some insights into yet another way to solve this problem. You can even look at the code if you are doing this for learning about MP networking. Look on gitHub for Torque 3D.
I forgot to mention some key points. At the end of the day (after you’ve determined what you need to track and update and what you don’t), you are often killed by two things:
- Too much data to move across the network. Latency and bandwidth will make the game stagger. (Not related to game engine/sdk). You’ve got to be highly efficient when sending updates. This is why the Tribes model was so brilliant. It could compress updates and only send the parts that needed to be changed. i.e. it always sent minimal update packets.
- To many calculations and too much work to make a low powered mobile device the master for game with many clients.
Back in the day… when I was a programmer for a multi-player game networking company, we solved this problem in a very simple way. The device’s app was a dumb graphics terminal. The server in the middle ran the game, enforced the rules, and told the clients what the state of the world was. So basically if I want to move my player, it generates a request to the server saying “Move me here” or “attack that player”. The server would resolve the action and then broadcast the results to all connected clients that needed to know about the results.
Of course this requires dedicated servers than you can run long running processes that can accept highly optimized TCP/IP - UDP traffic.
Now many people use a server as just a pass through broadcaster and lets the app do all the work, but it seems much harder (and susceptible to hacking) to keep the worlds in sync.
Having done this to some extent myself (my game is turn-based so things are much simpler than if it were realtime), some conclusions:
The most important point: However you approach it, it’s not going to be simple. Multiplayer network programming is complex.
You have several options, depending on your requirements:
- Have the physics engine entirely server-side and let the server inform the apps about the position of things in the world.
Difficult to hack, but requires you to implement a server-side physics engine, and requires low latency to keep clients in sync with the server (mobile networks usually have high latency)
-
Have the physics engine both on the server and the client, and periodically sync. Difficult to hack, and more tolerant to high latency, but susceptible to desync between server and client. Requires you to implement a server-side physics engine and a complex sync algorithm.
-
Have the physics engine on one client, and sync other clients according to it. Does not require you to implement a server-side physics engine. Trivial to hack. Can be tolerant to high latency or not, depending on whether you let other clients do their own calculations (as in #2) or treat 1 client as “the truth” (as in #1)
I went with option #3 for my game. In this case, since you’re not building a physics engine, the sync algorithm is the most complex part.
@Memo,
Hey! That’s kinda brilliant! I like that idea.
I like the 3rd option as well.
One thing I was thinking is to record the position of each object each frame of the animation and then simply send that data to the other client when the animation is complete. Another benefit is to allow the game to replay the last shot.
Is there a simple way to capture the physics animation for playback? I guess I could simply update a table when onEnterframe fires… Hoping there is a better solution.
actually it IS deterministic – assuming you use the “proper” definition of determinism. given EXACTLY the same conditions it’ll produce exactly the same results, there is no randomness involved. however, change those conditions even marginally, and you could produce drastically different results.
that is, say you start with an empty world, always populated the same, always stepped with fixed time steps (and etc - everything else “THE SAME”) - you can “prove” to yourself that you’ll continue to get the same results over and over, ad infinitum.
the problem is, those conditions are extremely sensitive. in theory you could set up a sim, step it forward some N times, record all (and i mean ALL) values (positions, velocities, etc) exactly, write them to a text file, then later resume the sim at that moment from the text file. (perhaps similar in concept to whatever sort of network multiplayer sync you might have in mind)
but it won’t work in practice. not only do you not have easy access to ALL of the varying parameters (fe, what is the current inertia of a spring joint?), you’ll also find that simply converting floats to strings and back can introduce enough error to materially affect the sim.
it’s like the butterfly-flapping-wings affecting weather analogy: the sim is so sensitive to initial conditions that it may appear to non-deterministic, though it is. “deterministic chaos”, so to speak.
Thank you for your explanation…very helpful. I’m assuming that, although it is deterministic, I am not realistically going to be able to repeat the physics in a multiplayer environment.
I’m wondering what approach could work with these things in mind? I’m assuming that there are games produced using the Corona SDK that work in a multiplayer environment…I’m wondering what approach they used to make it work? How do they sync physics with each client over the server? Any suggestions?
Hi.
If you’re up for some reading, there’s a bunch of material here: Networking For Game Programmers and Networking Is Hard
You can and can’t do this.
You can’t if you expect to be able to start the same process on two devices, let them run, and expect to get the same end-results.
You can, if you correct along the way. This is how most multi-player games work. For example, in a client-server based MP game, the server is in charge of all objects in the world. Clients execute code to move and update objects, but as time progresses, the server gives updates to the clients and the clients must correct any local deviation from the server’s world view.
Now, if this sounds complicated…well it is and can be. However, do not fear. You really need to be asking yourself:
-
What parts of the MP game must be exactly the same and which parts do not need to be the same. Ex: Player position yes. Particle effects, not so much.
-
How do I achieve synchronization? Am I going to implement a master-server architecture or some peer-to-peer model?
-
Probably should have asked first, “Do I really have the chops to make an MP game? Maybe I’d be better served making some SP games first.” This is not a dig. I think folks see games and want to make them, but if you’re new this may be a big stretch. That said, if you want to do it for fun and learning: Awesome!
Take a look at M.Y. Developers autolan module and the PONG game that comes with it. This is a ‘start’ on MP via a master-server set-up. Yes, it is only Dual Player (DP), but the principles are the same.
http://www.mydevelopersgames.com/AutoLAN/
_ Way Beyond Warning: _ If you really want to dig into this, try reading this OLD article: http://gamedevs.org/uploads/tribes-networking-model.pdf It talks about the old game ‘Tribes’ and how they solved MP. This is way beyond Corona and Lua, but it will give you some insights into yet another way to solve this problem. You can even look at the code if you are doing this for learning about MP networking. Look on gitHub for Torque 3D.
I forgot to mention some key points. At the end of the day (after you’ve determined what you need to track and update and what you don’t), you are often killed by two things:
- Too much data to move across the network. Latency and bandwidth will make the game stagger. (Not related to game engine/sdk). You’ve got to be highly efficient when sending updates. This is why the Tribes model was so brilliant. It could compress updates and only send the parts that needed to be changed. i.e. it always sent minimal update packets.
- To many calculations and too much work to make a low powered mobile device the master for game with many clients.
Back in the day… when I was a programmer for a multi-player game networking company, we solved this problem in a very simple way. The device’s app was a dumb graphics terminal. The server in the middle ran the game, enforced the rules, and told the clients what the state of the world was. So basically if I want to move my player, it generates a request to the server saying “Move me here” or “attack that player”. The server would resolve the action and then broadcast the results to all connected clients that needed to know about the results.
Of course this requires dedicated servers than you can run long running processes that can accept highly optimized TCP/IP - UDP traffic.
Now many people use a server as just a pass through broadcaster and lets the app do all the work, but it seems much harder (and susceptible to hacking) to keep the worlds in sync.
Having done this to some extent myself (my game is turn-based so things are much simpler than if it were realtime), some conclusions:
The most important point: However you approach it, it’s not going to be simple. Multiplayer network programming is complex.
You have several options, depending on your requirements:
- Have the physics engine entirely server-side and let the server inform the apps about the position of things in the world.
Difficult to hack, but requires you to implement a server-side physics engine, and requires low latency to keep clients in sync with the server (mobile networks usually have high latency)
-
Have the physics engine both on the server and the client, and periodically sync. Difficult to hack, and more tolerant to high latency, but susceptible to desync between server and client. Requires you to implement a server-side physics engine and a complex sync algorithm.
-
Have the physics engine on one client, and sync other clients according to it. Does not require you to implement a server-side physics engine. Trivial to hack. Can be tolerant to high latency or not, depending on whether you let other clients do their own calculations (as in #2) or treat 1 client as “the truth” (as in #1)
I went with option #3 for my game. In this case, since you’re not building a physics engine, the sync algorithm is the most complex part.
@Memo,
Hey! That’s kinda brilliant! I like that idea.
I like the 3rd option as well.
One thing I was thinking is to record the position of each object each frame of the animation and then simply send that data to the other client when the animation is complete. Another benefit is to allow the game to replay the last shot.
Is there a simple way to capture the physics animation for playback? I guess I could simply update a table when onEnterframe fires… Hoping there is a better solution.