Ok guys ive found that networking physics so i can see the other players physics(on a car!) and they can see my cars physics is a pain!Can anyone give me some advice on how to do this.Currently i have it so when you are playing you can see the physics of your car but everyone else you are playing with is just the model of the car moving around.Now fun!
I could animate the other players car i see but how realistic is that?There is no way for me to animate suspension force,all that.How am i spose to know what a car will experience at all times.So how can i network physics so i can see their physics and they can see mine?
Networking Physics???
-
xtremegames
- Posts: 17
- Joined: 02 Jan 2011, 01:06
- Location: US
-
ThomasLund
- Posts: 1297
- Joined: 14 Mar 2008, 07:52
- Location: Sweden
Tyler - as written on the Unity forums. Dont do networked physics unless you really really know what you are doing.
You can run physics on the server side - and then all clients need to incorporate physics emulation.
Or you can run physics on the individual client for the truck (in your case) and send over key results together with the transform. And the remote representation will emulate physics.
You dont _have_ to run physics to make it look nice. Its just a bad design which will not work - especially if you are simply looking to animate a suspension going up/down.
So - since I suspect you are not 100% certain what I even mean:
Extend the protocol. So you not only send a tranform (position+rotation) of the truck, but also where e.g. the suspension is for each wheel. Its a single value and super easy to animate it going up/down. You can also send over other key values if needed - rotation speed of each wheel, rotation angle of steering wheels and so.
Once you receive these values and need to show them on your remote avatar models - simply interpolate the rotation or up/down movement of the suspension.
Very easy, very simple, not 100% accurate but much much much simpler than trying to keep individual physics simulations in sync over network with lag.
You can also simply - for the remote avatar - not send suspension settings, but just raycast locally to position each wheel so it looks nice. And you should be able to calculate the correct rotation speed of a wheel pretty easily.
But as I said - networked physics is possibly _the_ hardest thing to do, and its not simply drag/drop. And in 90% of the cases, you dont need it in the first place if you think about it.
Just my oppinion...
/Thomas
You can run physics on the server side - and then all clients need to incorporate physics emulation.
Or you can run physics on the individual client for the truck (in your case) and send over key results together with the transform. And the remote representation will emulate physics.
You dont _have_ to run physics to make it look nice. Its just a bad design which will not work - especially if you are simply looking to animate a suspension going up/down.
So - since I suspect you are not 100% certain what I even mean:
Extend the protocol. So you not only send a tranform (position+rotation) of the truck, but also where e.g. the suspension is for each wheel. Its a single value and super easy to animate it going up/down. You can also send over other key values if needed - rotation speed of each wheel, rotation angle of steering wheels and so.
Once you receive these values and need to show them on your remote avatar models - simply interpolate the rotation or up/down movement of the suspension.
Very easy, very simple, not 100% accurate but much much much simpler than trying to keep individual physics simulations in sync over network with lag.
You can also simply - for the remote avatar - not send suspension settings, but just raycast locally to position each wheel so it looks nice. And you should be able to calculate the correct rotation speed of a wheel pretty easily.
But as I said - networked physics is possibly _the_ hardest thing to do, and its not simply drag/drop. And in 90% of the cases, you dont need it in the first place if you think about it.
Just my oppinion...
/Thomas
-
belltzaser
- Posts: 5
- Joined: 03 Dec 2010, 06:39
To avoid cheating, you can easily implement boundery checks on the server, but try to limit that. Keep physics for cosmetic purposes (raggdoll, shocks on wheels etc) on the clients. The server should only be concerned on boundery checks and collission (eg. Dont drive through walls, collission with another car, weapon hits etc) if you want to go that route. You cannot expect the server to cope with multiplayer, and minute physical reactions at the same time, it will bog down to a halt since a lot of resources are used.
I am busy incorporating a very crude physics system in java classes in my free time. It consist of basic physics between spheres, boxes and conves hulls. For shooting games i am also working and optimizing a raycast function, and all with vector3 support. In the future i might update the FPS example using my classes and release it as an example for free.
I am busy incorporating a very crude physics system in java classes in my free time. It consist of basic physics between spheres, boxes and conves hulls. For shooting games i am also working and optimizing a raycast function, and all with vector3 support. In the future i might update the FPS example using my classes and release it as an example for free.
-
ThomasLund
- Posts: 1297
- Joined: 14 Mar 2008, 07:52
- Location: Sweden
Yeah - there is also the hybrid solution of having physics on the wheels as usual, but not the car itself for the transform. If set to kinematic and updated via the transform that is received, the suspension should run nicely.
But one thing is for certain - the scripts you use for the player controlled car are NOT the same as the remote avatar ones.
/Thomas
But one thing is for certain - the scripts you use for the player controlled car are NOT the same as the remote avatar ones.
/Thomas
-
xtremegames
- Posts: 17
- Joined: 02 Jan 2011, 01:06
- Location: US