koobas.hobune.stream
Animation and Reliable Delta Compression State Synchronization
According to the documentation State Synchronization on an animation is not recommended. Moreover it states that Reliable Delta Compression only updates if changed.
In my level I have a simple unchanging looping animation. Simply put, my object spins in a circle. Currently I have a script where clients send a request for sync, the server sends an reply, and the client computes the current animation time-position. All done via rpc.
I would love to replace this code with Reliable Delta Compression, but since technically the animation time-position is always changing I am scared that the Network view will flood my network with unwanted updates.
So my questions are :
1) Is there any way I can test network traffic? I don't see this option in the profiler.
2) Will Reliable Delta Compression send regularly, or compute the animations state.
3) Is the manual rpc interpolation the status qua.
This is a difficult question - as is any question about networking.
Here's my opinion. You explain that your object IS ALWAYS SPINNING.
Could you let us know more about this -- specifically, (a) what is the speed it is spinning at (how many seconds for one spin) and (b) how big is the object (meters).
My opinion: just as you have observed, that object us "always changing". But, let's think about that. That's only if you think about the direction it is pointing -- true enough, the direction is always changing, constantly.
I believe you should do this:
For now, let's say it spins once every 5 seconds. In fact let's say it is "North" at 0, 5, 10, 15 and so on.
Now, for game reasons it might slightly change. So it might be north atL 0, 5, 10.1, 15.1, 20.1, 25, 30, 35, 40.
Now if you look at that sequence. Make anew value being "delta from standard".
So now the values are: 0, 0, 0,1,0,1, 0,1, 0, 0, 0, 0.
As you can see, you now magically have a value that is: pretty much the same all the time.
This usually works great when you are trying to network "cyclical" values. You're really networking now!
As a separate issue, regarding the difference between Reliable Delta Compressed and unreliable.
Note that RDC sends CHANGES ONLY but it sends it with a RELIABLE protocol.
Whereas so-called "UNRELIABLE" sends ALWAYS but it sends it with a UNRELIABLE protocol.
You can immediately see the big problem. What you really want is: CHANGES ONLY and win an UNRELIABLE protocol! Heh! (Essentially, that is how all real-time gaming networking works.)
Quite frankly - I've never found any different much between "RDC" and "UNRELIABLE" in Unity. Personally I recommend using "Unreliable".
Note that the issue I explain above the line above, is far more important - you had ego get that working first, or nothing will work! Once you do get the "cyclical-flattened-out" issue working: really you can simply TRY with a click both methods offered by Unity ("RDC" / "Unreliable") which is 10 seconds work to make a build for each - and you can simply decide what is better (I'll bet "Unreliable" -- note that Unity even thought they "say" always send, it very nicely balances the needs of all the stuff that needs to be sent around - it works pretty good.)
Your final decision - whether to use the natty "observation" method or just manually serialise data. Many developers say "the observation system is crap, just manually serialise the data." Really, I have found no difference in terms of actual performance. Yes, as a programmer it's much easier to just roll your own with the manually-serialise approach (you can more easily add elements, experiment, etc.)
Reply To Fattie
specifically, (a) what is the speed it is spinning at (how many seconds for one spin) and (b) how big is the object (meters).
The object is a 500 by 500 box in length. The spin starts on level load and loops forever. The loop is 3600 in length. The animation has a single curve (rotation.Y). It starts at 0 and ends at 360. The time period (and thus the angle) must match all machines. All machines have the same animation.
Your comparison of RDC and Unreliable is understood, but, the question is not "whats the difference", but, is the natural change to animation[animation.clip.name].time considered a "change". I assume so by your response.
HI @nventimiglia, wow that is a big box. 500 meters - it's gotta be spaceship! How many seconds does it take to rotate completely 360 degrees? (I don't understand your calculation, sorry - just tell us in seconds!)
When you say "all machines must have the same animation" - my impression is that you think it is "different" from - say - networking for a car going around a track.
But imagine this: I have a car racing game with a 1000 meter long track, lap after lap. In fact, the driver happens to be driving at a constant 120 km/h, exactly. In fact, the car must go around - exactly - in 30 seconds, right? So if you just sit there watching it for hours, what you will see is precisely "the car" going around and around exactly every 30 seconds.
So in "my" game the networking task is to in fact line-up the car at north each time (every 30 seconds) (plus, say, a few more points in the cycle), and in "your" game the networking task is to, indeed, line up the rotation at north each time. Surprisingly, it's the same!
(Footnote, I don't know whether your rotation takes a split second, seconds, or $$anonymous$$utes - slightly different thinking would apply.)
Now look here - I think what you may be thinking is "Cant I just DR it?" ... dead reckon it? if you're really really good at lining up time on more than one machine - i.e., exactly like an NTP server does - sure! You could DR it. Just set them both spinning at the correct HZ and rely on the fact it will always look the same on each machine. But that is not a particularly easy problem, in fact if you did it you'd probably end up saying "well I might as well run that great routine which lines them up, every 10 seconds or so [or whatever is relevant]" -- and indeed, that would amount to just the solution under discussion.
Re your penultimate sentence, no, not really - animations don't exist in Unity networking. Say you have a remote call that "plays an animation", that's it. Where you say: "but since technically the animation time-position is always changing I am scared that the Network view will flood my network with unwanted updates.." well it wouldn't flood it, because, it would "only happen, potentially" when you HAPPEN TO request one of your sync events...
ONLY THEN would the "do I send it or not" rules come in to play. thus, you'd decide to fire off your "sync thing" say --once every second --. nothing can be flooded, because, that's the maximum - once per second. you're in charge. So - it will only happen once per second, at most. the RDC won't even BOTHER sending anything if there is no change to the "delta" value concept. if it changes a little bit every time, then it will go off at most every second (you're the one deciding on the "second" aspect... cont)
{.. cont .. even if you let the "sync thing" run "constantly" (in an update statement) it won't flood because, at the very worst, it will do 30 hz (or whatever the frame rate is) - and once again since you're doing the "delta" approach so normally it won't bother, since it's RDC. It does not do it "whenever the value changes", which could be "an awful lot!!" -- it only does it when you request the send end of the networking - which is up to you, once every five seconds, every half-second, or, in Update, or whatever) Again Fwiw my guess is "unreliable" will be better, it's usually just plain faster - but it's a moment's work to try the two.} $$anonymous$$erry $$anonymous$$
"Facing north" is irrelevant. If the animation is at 30 seconds, it is at 30 seconds.
$$anonymous$$y solution is about a dozen lines of code. It syncs when the player enters the (parent) region. I send the current time period + the server time, and compute the position on reception of the sync rpc.
Sounds like it will be a great effect. Our long discussion may help people who are just getting to grips with this issue! Cheers, $$anonymous$$erry $$anonymous$$
