(I’m new to Coherence and only used it for about 2 days)
In my game, I have doors, gates and a variety of other objects that can change their state, but have a default state in the game. I.e. there may be thousands of these in game. I.e. what I’m looking for is that the server would be completely unaware of the object when it is loaded in its default state. However, if a player opens a door, I want that state to be propagated between all clients who come into that area. And once the door is closed, I want to delete its state from the server, while keeping the object.
I.e. there is no reason to keep thousands of door states, light states, power up positions, etc shared on the server, when no one needs it. These objects always exist, but just have a state that can temporarily change away from default.
You might consider not using CoherenceSync on these objects individually, and instead use category managers. Like a door manager which does have a CoherenceSync but has no renderable. The manager would know about all the doors and could have synced booleans for the state of the door. So to open a door a client sends a command to the manager to open door X the authority over the manager then changes the state of door X to open and that is replicated to the clients and the door opens.
This has the advantage of significantly reducing the number of sync objects but still supports tons of doors with infrequent updates.
There’s only one gotcha to what you are imagining, Dan.
Having state that only one player knows about, whatever that is, means that as soon as that player is gone information about that state also disappears, because no one had it noted down.
So it really depends on the type of game, session length etc. but in general, having a door that I (player 1) open but don’t tell anyone (not even the Replication Server!) means that that door is not really networked, but more of an offline object.
Said this, whether you want to make it an independent network entity (with its own CoherenceSync) or list its state in a manager (like Cary suggests) that’s a step two in the discussion
Happy to discuss more about this, if you share more details about the gameplay and session structure! Love these conversations that border between tech and design
@cary - Thanks, this might have the best chance. For an open world, I’m not going to know about. Is there a way to limit this information only to what is near me? Or is this more like a global event that I will receive for any door that opens in the world?
Hey, yeah, so it sounds like you have a big scene that all the clients have a copy of that you’re just trying to sync state on and not sync existence because the existence never changes. I think you could break up the space into some tree (think of an octree or BSP tree) based on areas of occlusion. Each of those spaces could have a state manager for the information that is a CoherenceSync object and you can use the area of interest system to update the state of entities just in a client’s vicinity. You’d probably want the area you’re in plus adjacent areas to be in the area of interest. You could do this by having more than one AoI that you move around.
Ciro’s comment about deleting state is important, though. The server (better termed as the state authority) over these objects never deletes the state since it has to always have the current state available in case a client moves their AoI.
