Skip to content

Workflow for working with prefab entities #1446

@alice-i-cecile

Description

@alice-i-cecile

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

Prefabs allow users to rapidly add copies of predefined entities to their game, and create variations on them.

What solution would you like?

The basic workflow would be:

  1. Create some interesting prefab entities in their own World either using its own systems, directly from code or by reading in a serialized format.
  2. Turn an entity into its component bundle.
  3. Create a new entity from that component bundle, with variations as needed.
  4. Use addition-detecting systems (or maybe State on_enter systems?) to finish initializing the entity in the main game world.

There are a few things we'd need to have this work:

  1. Multiple, interacting Worlds.
  2. A way to turn a created entity back into a bundle.
  3. A nice pattern for cloning an entity that allows you to change some of its components. If you have a bundle from 2., you could probably get away with .spawn(cloned_entity_bundle).with(modified_component), but it would need to be clear that .with is overwriting.

What alternative(s) have you considered?

Use component bundles with the struct-update Default pattern used in e.g. SpriteBundle.

This works quite well for statically defined prefabs, which can each get their own type. I'm not sure it works correctly (or naturally) for prefabs that are created dynamically or loaded from a serialized format. You would need to create new Bundles at runtime, which I'm not sure you could do.

The functionality needed all seems useful for other purposes though, and the pattern seems quite natural, so it may still be worthing pushing users towards it even if those barriers can be overcome.

Additional context

This issue ties into discussion in #255, although it doesn't actually use Scenes to accomplish its goals.

This issue was prompted by this conversation on Discord.

Multiple interacting Worlds was mentioned in #1343 for decoupling graphics and physics.

Metadata

Metadata

Assignees

No one assigned

    Labels

    A-ECSEntities, components, systems, and eventsA-ReflectionRuntime information about typesC-FeatureA new feature, making something new possibleS-Needs-Design-DocThis issue or PR is particularly complex, and needs an approved design doc before it can be merged

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions