Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Querying for multiple components at once #5

Open
pmrv opened this issue Mar 14, 2014 · 11 comments
Open

Querying for multiple components at once #5

pmrv opened this issue Mar 14, 2014 · 11 comments

Comments

@pmrv
Copy link

pmrv commented Mar 14, 2014

Especially in the EntityManager.{pairs_for_type,components_for_entity} methods. As in

for entity, (instance1, instance2, …) in entity_manager.pairs_for_type (Component1, Component2, …):

or

instance1, instance2, … = entity_manager.component_for_entity (entity, Component1, Component2, …)

The former would only return entities and pairs which possess all of the given components.
The latter could still raise ecs.exceptions.NonexistentComponentTypeForEntity for the first component it failed to fetch for the entity.
I am often running into situations where I iterate over entities with a certain component but also need to fetch a couple of other components for that entity (though I am quite new to ECS and maybe I am just designing my components wrong) and being able to do this in one step would simplify stuff and make it "nicer".
Is something like this planed or would you accept patches implementing that?

@benmoran56
Copy link

Hi guys, is anyone still interested in working on this? I've been using Marcus Von Appens EBS for a while, but was curious to try ecs. EBS does have a method for querying component sets, which is what a lot of my Systems use.

If noone is working on this right now, I'd love to give it a shot.

@pmrv
Copy link
Author

pmrv commented Jun 28, 2015

@tivek and I both implemented versions of this here and [here](ponderstibbons/ecs at multi_query_separate_functions), see also the
discussion in #8. In the end it's just that nobody got around to write
benchmarks for it, so we could test the performance against each other.

@benmoran56
Copy link

Thanks for the response! I guess I would have noticed that if I had looked through things a bit more first...
It looks like you guys already did what I would have done. From reading the other thread, it sounds like @tivek already had some benchmark code together that he was going to clean up, but that was the last post... I'm not great with writing benchmarks, but I might try testing these out with some tiny pysdl2 projects.

@tivek
Copy link

tivek commented Jul 7, 2015

... I got completely derailed by Outside Circumstances (TM) and unfortunately did not work with ECSs in Python for a while. I will try to get my old benchmark in usable form. Worst case I will just share it as is on gist.

@benmoran56
Copy link

Sorry to poke, but any free time to work on this? I'd be interested in seeing what you have, even if you don't have time to clean it up.

@baudren
Copy link

baudren commented Aug 14, 2015

@tivek, I am also interested in this! It would be great if you could simply share it as-is. Thanks in advance,

@benmoran56
Copy link

@tivek, I've been playing around with your version from your fork and it works well. Having the multiple component query really simplifies System writing a lot. Even if it's slower than the single component query, it negates the need for doing second (or third) component queries in the systems, so it's potentianlly saving a bit of wasted code there.

@benmoran56
Copy link

@tivek @ponderstibbons I made a new version of pairs_for_types that uses set().intersection() instead of a bit mask. I based it on your older integer entity code @tivek, without the bit mask additions. It appears to be about twice as fast for ~2000 entities. It's still much slower than a single component query, but that's unavoidable due to the need to check if an entity has all the component types. Even so, it might be fast enough already. I'm sure it could be made faster though.

My fork is here:
https://github.com/benmoran56/ecs/blob/master/ecs/managers.py

I also merged in a few other pending things that made sense. Hopefully these things can make it back into the main branch.

@tivek
Copy link

tivek commented Dec 17, 2015

I am sorry to have gone under the radar. My original python ecs test code is nowhere to be found (uh...) and I admit to the sin of procrastination in getting it operational. @benmoran56, good to hear. I have started to implement a similar idea in C++ (no bitmasks, query by set algorithms, sets as sorted arays), with the twist that linear traversion through more than one component array is naturally using parallel prefetch. Preliminary tests are promising. This time I am even going to have real benchmark code to prove it ;)

@benmoran56
Copy link

Sounds nice @tivek. I made a very crude benchmark script already (found in the root directory of my fork). I'll probably continue making that into an actual benchmark. Then I can see if any additional speedups are possible. I already pulled the ecs example @SpotlightKid made. Maybe the benchmark could end up as just another example, that can both help with development and also show users what the capabilities are.

@benmoran56
Copy link

Hi @tivek, @ponderstibbons , @SpotlightKid,

I got a bit impatient with waiting for Sean to find time to work on this. I wrote my own ECS, found here: https://github.com/benmoran56/esper

The API is very similar to ECS, but the database design is different (Entity IDs are the primary key now). This makes it a bit slower for single component queries, but dual/triple component queries were must faster to implement because lots of checks are avoided. It was different enough from ECS that I thought it was worth fleshing out. I've actully taken a lot of ideas that were floating around here, such as your Entity IDs as intergers, @tivek. I'm happy with it, and am using it in my own projects. I would love any feedback of course!

(Oh, and there is a benchmark and example code for PySDL2 and Pygame).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants