Handling Ownership Requests that are older than the newest requests
Hello! In our multiplayer soccer game, we are facing an issue about ball ownership which causes the ball to constantly change the owner and make the game unplayable at some times. (we are presuming that it is caused by players those have high latency)
For that matter, we came up with this idea: Keeping the ball ownership history in a realtime array with a server timestamp; if the newest one is older than the last element in the array; we just simply ignore that and keep the last owner. This may also fix the problem with "real quick" ownership changes which often happen when there are too many players around the ball.
So, the question is whether Normcore already applies this technique without any hassle from the client (like ignoring the ownership requests that are older than the newest request) or it performs the request no matter which time did it happen. Is that so, it will invalidate the idea we came up with, it won't make too much sense.
What do you guys think about it? Maybe you have a better idea that resolves the issue way easily; we'd much appreciate it. Thanks in advance!
5 Replies
Hi @mstfmrt07. I'm kapa.ai, your friendly support bot. I will try to answer your question by searching through the knowledge base. :wave:
----------------------
Normcore doesn't inherently handle the situation you're describing. It doesn't keep a history of ownership requests or compare timestamps to ignore older requests. Instead, it operates on a first-come, first-served basis. When a client calls
RequestOwnership(), the server will approve this request unless a parent RealtimeView is already owned by another client. However, this can be controlled with the preventOwnershipTakeover flag. When this flag is true on any model, the server will deny any client’s attempt to change the ownership of an object in that model unless it has no owner [source (https://normcore.io/documentation/room/ownership-and-lifetime-flags#prevent-ownership-takeover-of-a-realtimeview)].
However, Normcore does provide tools that you can use to implement your own solution. For example, you could use the RealtimeView's RequestOwnership() and ClearOwnership() methods to manage ownership manually. You could also use the RealtimeView's isOwnedLocallyInHierarchy property to check if the current client owns a particular object [source (https://normcore.io/documentation/realtime/realtimeview#ownership)].
One possible solution to your problem could be to implement a cooldown period after an ownership change, during which no other client can request ownership. This could help prevent rapid ownership changes when many players are near the ball. You could implement this using Unity's Time.time to keep track of when the last ownership change occurred and ignore any requests that occur during the cooldown period.
Remember that any solution you implement will need to take into account the fact that Normcore synchronizes changes at 20hz and sends the latest state. If you change something and then change it back immediately, nothing will be sent to the server [source (https://normcore.io/documentation/realtime/common-questions#im-calling-requestownership-setting-the-position-of-a-transform-and-then-immediately-calling-clearownershipbut-nothing-happens-how-can-i-fix-this)].
I hope this helps! Let me know if you have any other questions.
----------------------
Note: you can ask me a follow up question by @ mentioning me again :speech_balloon:
----------------------<@208292457979314176> kapa.ai is still learning and improving, please let us know how it did by reacting below
@Max what do you think about that?
you’ll want to write a system for deterministically simulating the ball
the collection of ownership swap events isn’t going to know about “newer” events because they haven’t arrived yet from the server
it would only be able to know if the local client took it over more recently and the ownership system already handles that case
Hi! I'm interested in this thread since my game also involves interactions with rigid bodies. @Max , you're suggesting handling the physics manually instead of a rigid body, right? I mean, code the ball as a kinematic body and handle it's velocity in a predictable way, isn't it? I did not consider that option but if you don't need very realistic physics might be a good one.