-
-
Notifications
You must be signed in to change notification settings - Fork 3.7k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Reserve Entity ID Range #11602
Comments
Possibly related: #7335 |
A problem I see with this is that it would make it very easy to increase the amount of memory being used. Currently there are a bunch of sparse sets indexed by entities' indexes, and their memory usage depends on the maximum index being used. So if for example you reserve a range of 1M entities when someone else reserves another entity they get an index bigger than 1M and those sparse sets will have to allocate space for 1M entities, even though there may exist a lot less. This could be fixed by reserving many small ranges alternated with unreserved ranges, this way both normal entities and networked entities get to use small indexes, but this doesn't mean the footgun is not there. |
Thanks for your input! I agree there is a lot of nuance to this issue, but I still think having some form of reservation capability would be useful. Perhaps the API can be constructed with this in mind. It may sound unorthodox, but it might make sense to have the API reserve a fragmented 'slice' of the full range of indices like you suggested. ie, instead of reserving |
Nevermind, I think this might be unsound since external users do not have access to |
In networking, It's fairly common to synchronize some pieces of game state. Currently, almost all networking solutions use their own
HashMap
or other indirection to map entity IDs between a client and server. While this solution generally works, it adds an unnecessary layer of complexity and makes it harder to reason about networked logic.I am proposing extending the bevy API to include a
reserve_entities()
method, or something to this effect. This would allow you to reserve a contiguous interval of entity IDs, and they would not be used by bevy. This would reduce indirection and complexity in writing networked games, and will likely have other non-networked benefits in other circumstances. The ability to have deterministic IDs is generally a useful pattern, and I think it has a lot of value in Bevy.In the coming days I will begin working on a naive approach just to get some feedback, but I would love to hear other thoughts in the meantime.
The text was updated successfully, but these errors were encountered: