koobas.hobune.stream
Synchronize Cannonballs(networking)
Hi, If you just instantiate a rigidbody cannonball via RPC on all clients, it is not guarenteed that it lands on the same spot on all machines, because auf the unstable physic engine. What do you do in this case? Synchronize the rigidbody.position and rotation(maybe even velocity) as well on all the clients every frame, as you would do it with the player characters? Wouldn't that waste too much bandwidth?
one of your iPads is the server of the game
run normal physics on that. throw the ball on that one.
of course, use the "normal" "correct" RPC call - the one that only sends messages to ONE client
{Note -------- Unity also offers a "send this message to everyone!" version of RPC. This "send to everyone" version of RPC is useless for conventional networking, it seems to be just a novelty. In conventional networking where the "hub" server is in control, and that server tells the various clients what to do, of course you individually talk to each person-X in different ways. Never use "network instantiate" or the strange "talk to everyone" version of RPC.}
on the client, just puppet the position of the ball - it's only a line of code really
RT $$anonymous$$P networking is NOT REALLY THIS EASY, but it will get you going. To do it like in Real Racing, you have to sort of use almost what you could call an AI system to continually guesstimate where everything is. But before you can begin to work on concepts like that, totally master just puppeting the positions. Good luck!
Hi, thanks for your answer :). I don't really know what you mean with the correct RPC call? Can you make an example? You wrote that the RPC call should only send to one client, but all clients need the correct position of the ball. With puppet you mean just sync the position of the two balls over the network every FixedUpdate?
look at teh RPC manual page, use the form at the BOTTO$$anonymous$$ of the page. cheers
I avoid the physics engine like the plague because of issues like this. If you can I would suggest coding the movement yourself. If not, operate the original on the computer/server that spawned it. And create a separate network object, that is tied to the original. Use RPC updates from the original every FixedUpdate to orient the network one. Use Network.isMine check to delete the the extra one from the originating computer/server. It should be relatively inexpensive to send a single transform's worth of data at that rate. I've used this Shadow entity setup before to great success.
Good Luck!
Hi, thanks for your answer :). Is it also okay to just sync the position with OnSerializeNetworkView ins$$anonymous$$d of using an rpc? But when you just sync the position, the cannonBall stutters from one position to the next. So do you also apply a lerp from the current position to the new received one? I just tried this but then the position is not correct.
Probably lol, as with anything, testing is required.
The stuttering is due to the network send-rate. ($$anonymous$$ost likely)
Edit->Project Settings->Network Click
In the inspector should be a variable called "Sendrate"
For online games I suggest this baby cranked up to at least 40. That should quell the beast for the most part. If that doesn't clear it up you could setup a smoother setup like lerp (I'd probably use transform.Translate directly, never trusted lerp that much.) that will buffer the shadow entity, but it will misreport slightly behind on all the cannon-ball clients. Its really up to you how accurate it needs to be. $$anonymous$$illiseconds/inches don't really matter to your average game.
Also if this clears things up, I would appreciate a thumbs up. Been working to increase my standing. :)
The best thing to do is increase the size of your objects a little so the little difference will not matter much. Then synchronize rigidbodies if you really want to use rigidbodies for that. The best way to handle it is using a diterministic formula yourself instead of using the rigidbody because your main problem is that different players will do the instantiate in different times so their results will be different (objects moved in different amounts in clients). The rigidbody's inaccuracy is a few decimals after the decimal point in the float number so it's not the main problem, if you use a formula of your own, then after instantiation you can see how much time you are back from server and then move the canon based on that. If you delay your clients behind server for 100 miliseconds or so, then you should not have much problems.
For now focus on making it work either with rigidbody synching or any other method and later on optimize it after you really find out the experience that you want.
