You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Some operations should potentially be executed for many entities at once to save time.
add_entity
remove_entity
add (component)
remove (component)
replace (component)
I suggest implementing add_entity, as overload to the existing function, where a count argument would be provided.
For the other methods I see two potential options.
1. OOP style
We could implement the operations as methods of a Batch object that could be returned by query. That way, the API stays slim users could do operations as follows:
We would need to be careful what happens to a batch that has been used. A suggestion would be to consume batch in functions that change the world and make it non-copyable.
I would probably not move this functionality to queries, like in the "OOP style". I find is counter-intuitive.
Also, it is probably good to have an API as close to the normal operations as possible, so your ECS style example already looks quite good. But do you really need an additional type for the batches? Why not use queries here, too?
Another question is whether it is really useful to be able to assign in this operation (as in the 2nd example) or just allow parameters for the types (as in the 1st example). In most cases, users will iterate the created batch anyway to assign components to individual entities.
How about this? It is basically just "OOP style" flipped.
for entity in world.Add[Rotation, Altitude](world.query[Position, Velocity]()):
...
What is the first line here? Just another usage example without a query loop?
world.query[Position, Velocity]().add[Colour]()
for entity in world.query[Position, Velocity]().add[Colour]():
...
Some operations should potentially be executed for many entities at once to save time.
I suggest implementing add_entity, as overload to the existing function, where a
count
argument would be provided.For the other methods I see two potential options.
1. OOP style
We could implement the operations as methods of a Batch object that could be returned by query. That way, the API stays slim users could do operations as follows:
Of course, remove_entity would return an empty iterator.
2. ECS style
We could also hand batches / filters over to add and remove etc. in the same way as an entity ID.
We would need to be careful what happens to a batch that has been used. A suggestion would be to consume batch in functions that change the world and make it non-copyable.
Any thoughts @mlange-42?
The text was updated successfully, but these errors were encountered: