Re: Audio Games with Rust?
@10
if they have complex query stuff that's different, but I couldn't find such things on a cursory skim of the docs. Their tutorial isn't showing me something more complicated than what I could accomplish with a for loop and indeed their section on queries seems to be saying "well you chose not to write the loop yourself, here's how you deal with the fact that you needed to" , but maybe there's more stuff in there somewhere. You could ideally take this as far as sql-like _expression_ indexes without overly much work.
I don't need to be sold on an ECS and, since my goal is an MMO or at least an MMO engine, it's also kind of the only way. They also naturally solve networking. I'm just really still not getting what bevy specifically brings to the table that I couldn't get by just writing normal for loops and bringing in rayon and calling them systems. perhaps this time in 6 months it's going to offer a bunch of stuff it doesn't now, or perhaps their docs are just very meh, but at the moment the parts I'd care about for an audiogame are documented in a "we offer the minimum set of features possible, isn't that amazing?" way and if there's more it's not immediately obvious to me.
@11
To offer a concrete example that I will probably use, suppose you want to maintain a relationship like muds do, where things can be inside other things. I might do the following component:
struct parent {
pub id: EntityId,
pub index: usize,
}Then the purpose of the Relationship system would be to observe changes and maintain the tree with whatever you want to use to maintain the tree, and it would/could offer an API to anything else that wants to reach out to it and ask "what are all the children of the town square". Put another way, the components are authoritative: if you change the component that change has to propagate promptly to everything else. But nothing stops you from letting systems have backchannels to each other for readonly access, and any system that wants can store secondary data like Synthizer handles to reflect components onto the external universe.
So for example the relationship system might offer a sort function, which takes an entity and sorts its children, but what this is actually doing under the hood is using the relationship system's internal state to find the entities that need to be sorted, then reaching out to the actual component store and changing them there and letting the changes reflect back in via whatever your observer API is after the fact.
Nothing stops you from sticking handles to external resources in components either, i.e. the component might be the instantiated physics thing from your physics library, and if it's something like a huge map array, nothing stops you from having another level of indirection to something else that holds the 10 megabyte tilemap for whenever you need to grab a pointer to it.
Mind you the above is predicated on having a good observer story, which you can get from most ECS libraries and which isn't overly hard to write yourself, but if you don't have it then what I proposed is that the relationship does a for loop over 10m entities every frame. Which isn't what I'm saying at all, to be clear.
-- Audiogames-reflector mailing list Audiogames-reflector@sabahattin-gucukoglu.com https://sabahattin-gucukoglu.com/cgi-bin/mailman/listinfo/audiogames-reflector
