search

Trouv / bevy_ecs_ldtk

ECS-friendly ldtk plugin for bevy, leveraging bevy_ecs_tilemap
Other
687 stars 79 forks source link

System-based LdtkEntity and LdtkIntCell #47

Open Trouv opened 2 years ago

Trouv commented 2 years ago

There are two main drawbacks for using LdtkEntity and LdtkIntCell

  1. For mildly complex cases, implementing these traits manually is super verbose (many method arguments)
  2. For more complex cases, the parameters may not give you enough access to the world

Basically, these two traits are very opinionated about what the user might need when they are spawning bundles from the Entity and IntGrid layers. This can be mildly annoying. I think an ideal solution would be to use bevy systems for spawning. That way, users can define exactly what they need from the world, and can feel free to not ask for what they don't need, reducing boilerplate.

To be clear, I'm referring to users being able to write system-like functions/methods for the Entity and IntGrid registration, hooking into the spawning process. Not just normal systems that do spawning afterward. Users can do the latter now, but it does have some quirks, like their entities not spawning until the update AFTER the level spawns, or having to do some clone-fu to avoid overwriting the plugin's calculated transformation, or having to manually match for the entity identifier or intgrid value you are interested in.

Not sure how the exact implementation of this would work (probably using some dark, forbidden bevy traits like FunctionSystem). I'd like the derive traits to be at least as useful as they are now. I'm okay with the design of the macros changing somewhat as long as it's an improvement.

I don't have much of an opinion on whether LdtkEntity and LdtkIntCell should even remain traits with this change. I feel like it would probably be pushing rust's generic features to the limits to have generic trait-method parameters, but idk. I may slightly prefer that they remain traits just to make typing easier as they are passed around the plugin.

This change may result in the level-spawning system becoming exclusive. This is not ideal, but I can't really imagine an alternative. If somehow the level-spawning system can be generic over whatever the user defines in their spawning systems that they register to the app, that would probably be ideal, but it sounds impossible.

Also, not sure how exactly to pass the LDtk data to these systems (EntityInstance, LayerInstance, IntGridCell). Maybe an In parameter? A custom system param?

Simre1 commented 2 years ago

What do you think about using bevy events for this?

Whenever a level/layer/entity/intcell is added, an event with the relevant information is fired. Systems listen to these events and do the spawning.