bevyengine / bevy

A refreshingly simple data-driven game engine built in Rust
https://bevyengine.org
Apache License 2.0
36.05k stars 3.56k forks source link

Clone-able ECS storage #3703

Closed james7132 closed 2 years ago

james7132 commented 2 years ago

What problem does this solve or what need does it fill?

To allow easier duplication of entities (spawning copies of a template) and copying of entire Worlds for subapps/worlds and rollback networking, having a dedicated storage for clone-able components is likely required.

What solution would you like?

Either an API that conditionally allows cloning a Table or SparseSet (iff all contained components are Clone), or a separate storage format that keeps only the Clone-able components of entities that are implement Clone and Send, and supports trivially moving/cloning/replacing this storage from World to World while maintaining entity identity.

What alternative(s) have you considered?

Manually copying individual components from World to World. May cause entity identity instability.

Additional context

The main need for something like this is to allow for creating World snapshots at a given moment in time for rollback networking, and support restoring it at a later time.

For this to be correct, entity IDs must be stable across saving and loading these snapshots, or any entity references in components recorded in each snapshot may become invalid.

alice-i-cecile commented 2 years ago

Related to #1515.

james7132 commented 2 years ago

Closing this as there are workarounds that don't require archetypal Clone-safety. For rollback netcode, generic systems seem to work fine given a guaranteed Clone bound on the components or resources.