#Storing and retrieving entity data

34 messages · Page 1 of 1 (latest)

whole trout
#

Anyone have any ideas for the following:
I want to present a list of building types the player can construct in the various menus in my game (colony sim).
So I need basically "metadata" on various entity types the player can construct.

My original hope was to have this metadata baked into the entity definitions themselves, for example using the Name component, and perhaps using a Buildable component with the building costs etc, that I could then present in the menu.

But this seems a bit heavy, as I would have to construct the entity to get the data out of it, meaning having to create all the entities just to get the names and building costs to show in a menu.

What would be a good way to store this data basically? Some kind of data structure that would enable me to create entities when needed, but also have metadata available to me about them easily?

(my original thought was sort of "prototype" entities that I would create one for each type - this KIND of worked but ended up being tricky because Bevy as of currently doesn't have entity cloning, so I couldn't use the prototypes easily for creating the concrete types later - note this IS possible but with my skillset I had a hard time with this approach, and couldn't find anyone else talking about doing the same, so I'm sure there is a better way)

glossy pond
balmy ember
#

for the structure to hold the types of building and their conditions i would build a Resource, for the prototypes i would build Scenes for each prototype

whole trout
whole trout
glossy pond
#

That's one way to author scenes, sure

#

Another way you can author them is to use something like Blender/blenvy, or Blender/gltf scenes

#

You can export any entities in a World to a scene, so if you're using one of the bevy editors or your own based in bevy, it can be easy to author them like godot scenes

#

Scenes are super powerful but they're hard to work with, I think it really depends on how complex your needs are

#

They seem kinda overkill for single-entity spawning

whole trout
#

I guess i-can't-believe-it's-not-bsn would basically fill the same need in a different way?

#

Hmm, possibly yeah

glossy pond
#

Yeah I think they address a similar need

#

I'm just starting to play around with bsn but I'm hoping to replace some of my scene based stuff with Templates

whole trout
#

I was also looking at https://github.com/Leafwing-Studios/leafwing_manifest/ courtesy of @ornate socket , it looks like almost exactly what I need, but one thing I think that is different to how I'd like is that I don't necessarily want to have to divide my different types of objects so strictly into different categories.

In my mind I'd be able to add functionality to any kind of entity by adding a component to it, this requires me to define what category each entity belongs to in a more coarse way.
(like what if I have an OakTree bundle that is just a Plant component etc, but later on I decide that uh, the settlers can build them as well, then I'd have to move this particular item into a "Buildables" manifest type, right?)

I might misunderstand some of how to think about using this crate though

#

For reference I'm coming from Godot, and it is confusing me that Bevy is called a "data driven" framework, but I'm not finding almost any data-driven ways to do stuff (data is in plain old data from files), almost all examples use code based solutions for defining the data itself. Except like leafwing-manifest! (Even i-can't-believe-it's-not-bsn it doesn't fill the need for various bits of data referencing each other from across files)

In Godot I would define all of these as Resource files which are plain data, and it would allow me to dynamically create my objects from data, which use other Resource files which are also just plain data etc.

I'm saying this just because I feel like I'm in crazy land and I can't find clean ways to approach this and I feel like either I'm missing something very obvious (very possible!!), or maybe people aren't making this sort of thing in Bevy yet and most games out there are just more simple?? (I don't think I'm doing anything special though so I doubt that!)

I've seen one game in #showcase that obviously has a lot of of different types of stuff going on in it (the project by @paper nest)

paper nest
#

In computing, data-oriented design is a program optimization approach motivated by efficient usage of the CPU cache, often used in video game development. The approach is to focus on the data layout, separating and sorting fields according to when they are needed, and to think about transformations of data. Proponents include Mike Acton, Scott M...

#

I think, in Bevy terminology, what you referring to is called "Asset Driven"

#

so yeah, your understanding is correct, most of the functionality in Bevy as of now is code driven and not asset driven

whole trout
#

And thank you for the link much appreciated!

ornate socket
#

Yeah, "data driven" is the standard industry term, but it kinda sucks :p

#

Confusingly close to "data-oriented", and generally vague

#

So the Bevy community has slowly drifted to "asset driven"

whole trout
#

In a sense I wouldn't really mind necessarily having things in Rust either, I'm just also having a bit of a hard time finding a good architecture for that
(except Enums all the way down, which might just be good enough for me for now, I'm definitely considering it and trying it out as well!)

#

It's just been the lack of resources on this topic that has made me feel like I've been on a wholly wrong path 😄 And I suppose I lack the skills to choose a direction confidently without some prior art to look at

#

Anyway, gonna study bevy_asset_loader as well and see where that takes me!

ornate socket
#

Yeah, from what I've seen the two good options are "asset-driven + tooling" and "pure Rust with far too many enums"

whole trout
#

FWIW I was able to make progress with this to something I'm happy with for now:

  • I have an enum item ID per entity type
  • I have an EntitySpawner(HashMap<ItemId, fn(&mut commands)>) resource into which I can add various entity types from different parts of the code base and their spawn functions.
  • I kept my idea of entity prototypes, so that I can don't have to have a separate idea for "entity metadata" for things such as building costs etc
  • Just instead of trying to clone the prototypes into "concrete" types for example when constructing a building, I can just spawn a new entity of the same ItemId with the EntitySpawner
#

I'm fine with this not being asset based, my problem was just not wanting to make complex systems for entity metadata, and also not having enum structures that are too complex and all over the code base.

#

We'll see how well it works but so far it seems to be nice to use!