bevyengine / bevyengine/bevy

Better entities tracking issue

Open
#18,719 0 comments 6 reactions 0 assignees View on GitHub
A-ECS C-Tracking-Issue X-Needs-SME
Dominant language
Rust
Stars
48.2k
Forks
4.8k
Avg merge
3d 16h
Merged PRs (30d)
171

Description

## Objective

I've been deep in Bevy's entity code for a few weeks now, working on remote entity reservation. Having become pretty familiar with it, there's a few areas I think we can significantly improve.

This is a tracking issues for *my* ideas here. Each one deserves discussion, but since they are separate issues, I figured a tracking issue would be better than a discussion post with disjoint comments.

## Roadmap

- [x] Remove old `alloc_at` functionality. #18148 . This was a performance foot gun for users and it made `Entities` overly restrictive.
- [x] Properly handle `u32::MAX` index entity. Right now, this is a bug in `Entities`. One solution is out here: #18704 . (But that's still up for debate).
- [x] Make generations `u32` in a new type. #19121
- [x] Make `TableRow`, `ArchetypeRow`, etc non-max. #19132
- [x] Implement remote entity reservation. #18670 is a clear winner for this IMO. It has better performance than main while offering a much more flexible interface.
- [x] Allow bulk freeing.
- [x] Try to remove atomics in remote reservation slots
- [x] Explore adding back `insert_or_spawn_batch`. See [here](https://github.com/bevyengine/bevy/issues/18054#issuecomment-2868942002) #19451.
- [x] Speed up Command entity spawning.
- [x] Remove `reserve`/pending paradigm. #19451
- [x] Remove internal use of untyped `u32`s as entity generation and index. We have types for these now!
- [ ] Support multiple allocator kinds, splitting remote and local allocators.
- [x] Implement iterator for `EntityGeneration`. #19144
- [ ] Rename some functions in the `entity` module. These have strayed a bit from their best meaning, but haven't been updated to prevent a migration guide. But I think it's worth it.
- [x] Remove the `Identifier` system. This is an ecs utility that is only used by `Entity`. But these changes make `Entity` pretty unique as far as identifiers go, and given that the identifier system is only used by entities, I think we can safely let this go to reduce complexity.
- [ ] Remove/deprecate `Entity::PLACEHOLDER`. The only possible reason to use this is as a replacement for `MaybeUninit:: uninit` that trades UB fort a logic error. But who's doing that? `Option` is better anyway for most things, and people can make their own placeholders if needed. That would make the risks more explicit.
- [ ] After allowing archetypes and tables to be unregistered, make `TableId` and `ArchetypeId` non max. If there can't be `u32::MAX` entities, there cant't be that many archetypes. Let's give it a niche for the places this is used in an option.
- [ ] Make `ComponentId` wrap entity information. This is the first step in components as entities.
- [ ] Create a custom `ComponentId` map that is an optimized `HashMap`. This would be a vec index for the first `SOME_CONSTANT` entities and then a hashmap after that.
- [ ] Create a public interface for creating custom entity allocators. This should be easy to support and would let people make allocators for grouping dense entity ids, etc.
- [ ] Allow entity ids to be reserved by default for components as entities.

Contributor guide

Open the contributing guide

Research direction

This is a broad tracking issue covering the entity module, with most roadmap items already completed and several remaining items linked to separate issues. Start by reviewing the unchecked roadmap entries and their linked discussions; there is no single change or completion criterion for this issue itself.

Written by the indexing model from the issue text.

Assessment

Tech stack
rust
Domain
game-dev
Issue type
Refactor
Difficulty
5/5
Estimated time
Over a week
Activity status
Stale
Clarity
Needs clarification
Newbie friendliness
15/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.