PR #180 added many convenience methods for accessing field data on entities and levels, but the field_instances example remained the same. This PR completely rewrites the field_instances example, mostly for the sake of demonstrating a small piece of the new API. It doesn't show how to access every possible field type, as such an example would be huge.
It also improves the example in general, mostly by trying to make it resemble an actual use case. The "game" it resembles is some sort of dungeon crawler that has a bat enemy. These bat enemies have fields defining their name, health, what equipment they might drop, and their "mother" (they all have the same mother - the bat named "boss"). No game logic is built around this - but all of these fields are stored in components in some form. In particular, the mother field handling provides an example of how a user might achieve a bevy relation from an LDtk entity reference.
Closes #181 Closes #165
PR #180 added many convenience methods for accessing field data on entities and levels, but the
field_instancesexample remained the same. This PR completely rewrites thefield_instancesexample, mostly for the sake of demonstrating a small piece of the new API. It doesn't show how to access every possible field type, as such an example would be huge.It also improves the example in general, mostly by trying to make it resemble an actual use case. The "game" it resembles is some sort of dungeon crawler that has a bat enemy. These bat enemies have fields defining their name, health, what equipment they might drop, and their "mother" (they all have the same mother - the bat named "boss"). No game logic is built around this - but all of these fields are stored in components in some form. In particular, the mother field handling provides an example of how a user might achieve a bevy relation from an LDtk entity reference.