Clients visibility

[Shatur]

Description

It's a prototype of my recent idea about visibility management. Please note, that it's a quick and dirty prototype, I just wanted to showcase the idea.

The idea is simple. When you configure server plugin, you set visibility policy based on your game. Then you can control visibility using ClientVisibility struct obtainable from ClientInfo. ClientVisibility is an enum with fields based on policy:

• ClientVisibility::All: stores only single boolean to check if client just connected.
• ClientVisibility::Whitelist / ClientVisibility::Blacklist:
  • A list of entities with a boolean value for each one if it was just added.
  • A set of removed entities from the list above.

When we collect changes, we also check if an entity visible or just became visible for specific client (can be optimized, see below).
When we collect removals, we additionally iterate over just hidden entities.

TODO:

• Discuss the design itself.
• Optimizations.
• More docs.
• Tests.

Advantages

• No performance cost if game doesn't need visibility management at all.
• Lower cost compared to Rooms #15 if game need one room per entity.
• Extensible, more high level API like Rooms #15 can be implemented on top of it.

Disadvantages

• If your game benefit from managing visibility for group of entities, the API will fill more barebones compared to the proposed rooms API.

Optimizations

• I create a boxed iterator for despawns. Can we use different API to avoid this allocation?
• I do an entity lookup for each component. Can I cache the lookup using an Option? Or maybe restructure the loop? Not specific to the idea itself, same would be about rooms API.
• For blacklist option I iterate over each entity. Maybe I can use a separate storage for just added entities? But it will add an extra lookup for getting visibility (to check if an entity was just added or not).

[UkoeHB]

Efficiency and code clarity comments. I think this direction is promising, I will work on a Rooms design that can be layered on top.

[codecov-commenter]

Codecov Report

Attention: 25 lines in your changes are missing coverage. Please review.

Comparison is base (316dc3c) 89.81% compared to head (6021346) 89.30%.

Files	Patch %	Lines
src/server/clients_info/client_visibility.rs	85.49%	19 Missing ⚠️
src/server/clients_info.rs	82.85%	6 Missing ⚠️

❗ Your organization needs to install the Codecov GitHub app to enable full functionality.

Additional details and impacted files

@@            Coverage Diff             @@
##           master     #174      +/-   ##
==========================================
- Coverage   89.81%   89.30%   -0.51%     
==========================================
  Files          19       20       +1     
  Lines        1247     1412     +165     
==========================================
+ Hits         1120     1261     +141     
- Misses        127      151      +24     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

[Shatur]

I feel like we should rename it into ClientState and the parent struct into ClientsState.
But I think it's better to do as part of a separate PR.

[UkoeHB]

Maybe: ClientCache for the parent struct, then ClientState for the per-client struct. ClientsState is pretty awkward.

[UkoeHB]

It took me a while to figure out you were handling the 'lost visibility' vs 'don't have visibility' distinction separate from EntityState.

[UkoeHB]

Making progress :)

On the other hand, I have not much progress on the Rooms abstraction if you want to give it a try. I think it can be done with one custom SystemParam (instead of an entity component) called RepliconRooms with this core API:

• rooms.join(client id, room id)
• rooms.leave(client id, room id)
• rooms.add_entity(entity, room id)
• rooms.remove_entity(entity, room id)

I'm not sure how to integrate it with events. Maybe a bespoke solution is required (a distinct events API that wraps bevy_replicon, like RoomWriter or some such).

[UkoeHB]

Getting closer :)

[UkoeHB]

Good work! I think it's ok to merge this, but let's wait to release it until a Rooms implementation is solidified.

[Shatur]

Okay!