new example: multiple sprites, one parent entity

[awwsmm]

trafficstars

Objective

• Rendering multiple sprites in a single parent entity is a common beginner problem

Solution

• Create an example (following @cart's advice on Reddit) showing how to create a parent entity which contains multiple sprites

[awwsmm]

https://github.com/bevyengine/bevy/assets/29188350/149379ed-13bd-4e9d-b760-975b134a1e91

Screen capture showing the parent entity moving around the window in response to the user pressing the arrow keys

[IceSentry]

I'm not sure the name of the example is correct. It's mostly showing how to use bevy_hierarchy in 2d. It's using mulitple entities, not just one.

[awwsmm]

I'm not sure the name of the example is correct. It's mostly showing how to use bevy_hierarchy in 2d. It's using mulitple entities, not just one.

What would you suggest instead? I was aiming at searchability (see the linked Reddit thread). Beginners (like me) will wonder "how can I use multiple sprites inside a single entity?" That's how I ended up on the current name.

[awwsmm]

could you add instructions on screen to use the arrow keys?

Done!

[IceSentry]

@awwsmm

Why would you prefer input handling inside the system itself? Just for readability? There are other examples already which use const generics. virtual_time, for example

The main reason for me is that it breaks up the logic in muliple places instead of having everything co-located. It adds runtime logic to setup code that is otherwise not about runtime. It makes it harder/impossible to configure the buttons/values at runtime. It's also a bit unconventional compared to almost all other examples (I would have had the same criticism for the virtual_time example) and uses more advanced features that beginners might not be familiar with. It's not a huge deal, and I guess for an example it doesn't matter, but that's not something that would scale well outside of a simple example.

What would you suggest instead? I was aiming at searchability (see the linked Reddit thread). Beginners (like me) will wonder "how can I use multiple sprites inside a single entity?" That's how I ended up on the current name.

I don't really have a suggestion. To me the issue is more about bevy_hierarchy not being obvious or easily discoverable. It seems to me like it should be a github discussions with an answer so it's easily googleable. The example itself seems redundant since the hierarchy example already essentially does the same thing.

[awwsmm]

@awwsmm

...

What would you suggest instead? I was aiming at searchability (see the linked Reddit thread). Beginners (like me) will wonder "how can I use multiple sprites inside a single entity?" That's how I ended up on the current name.

I don't really have a suggestion. To me the issue is more about bevy_hierarchy not being obvious or easily discoverable. It seems to me like it should be a github discussions with an answer so it's easily googleable. The example itself seems redundant since the hierarchy example already essentially does the same thing.

Updated both of these examples (hierarchy and multiple_entities_one_sprite) to refer to one another in their doc comment at the top of each file.

[awwsmm]

Bump @mockersf

[mockersf]

Could you rename the example (and everywhere it's mentioned) to "multiple sprites, one parent entity?

Saying "one entity" is misleading otherwise

[awwsmm]

Could you rename the example (and everywhere it's mentioned) to "multiple sprites, one parent entity?

Saying "one entity" is misleading otherwise

Done

[mgi388]

@awwsmm

Why would you prefer input handling inside the system itself? Just for readability? There are other examples already which use const generics. virtual_time, for example

The main reason for me is that it breaks up the logic in muliple places instead of having everything co-located. It adds runtime logic to setup code that is otherwise not about runtime. It makes it harder/impossible to configure the buttons/values at runtime. It's also a bit unconventional compared to almost all other examples (I would have had the same criticism for the virtual_time example) and uses more advanced features that beginners might not be familiar with. It's not a huge deal, and I guess for an example it doesn't matter, but that's not something that would scale well outside of a simple example.

What would you suggest instead? I was aiming at searchability (see the linked Reddit thread). Beginners (like me) will wonder "how can I use multiple sprites inside a single entity?" That's how I ended up on the current name.

I don't really have a suggestion. To me the issue is more about bevy_hierarchy not being obvious or easily discoverable. It seems to me like it should be a github discussions with an answer so it's easily googleable. The example itself seems redundant since the hierarchy example already essentially does the same thing.

I agree that this seems more or less the same as examples/ecs/hierarchy.rs except the hierarchy one is a more useful example in my opinion for these reasons:

1. It shows the child entity moving independently of the parent, but the example in this PR visually just looks like one sprite
2. The hierarchy example is commented well to explain to users what's going on

If this example is merged, looks like there are still instances of @mockersf's issue that need fixing:

Could you rename the example (and everywhere it's mentioned) to "multiple sprites, one parent entity?

E.g. https://github.com/bevyengine/bevy/pull/13050/files#diff-2e9d962a08321605940b5a657135052fbcef87b5e360662bb527c96d9a615542R553