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

Multiple components of the same type #26

Open
simonvpe opened this issue Jan 30, 2017 · 6 comments
Open

Multiple components of the same type #26

simonvpe opened this issue Jan 30, 2017 · 6 comments

Comments

@simonvpe
Copy link

I am trying to figure out how one would implement multiple instances of a component. Is having a component like struct MyComponent { std::vector<MyComponentImpl> impl; } the suggested way to do this or do you have any other suggestion?

@OvermindDL1
Copy link

The definition of a component storage is that an entity belongs to it, not belongs to it multiple times. I'd have the internal data store be an array or list or so depending on what is needed, or change the problem to make that not necessary (I hate hate hate allocating dynamic memory in components). But yes, your vector bit is 'fine' but not efficient. Better question is, what is MyComponentImpl and what precisely are you wanting to store?

@simonvpe
Copy link
Author

simonvpe commented Jan 30, 2017

@OvermindDL1 To describe my particular problem further; I am making a simulation environment for Magic The Gathering (the trading card game). I am modeling cards as entities with components Toughness, Power, Loyalty, ...etc. Cards also have zero or more Abilities which can be activated. When activated they spawn an entity with an Effect component, the EffectSystem then proceeds to call a function pointer on all the active Effects each process loop.

@OvermindDL1
Copy link

So it is the Abilities then? For those I'd probably make an Ability an entity that is parented to a card, just duplicate a base Ability blueprint for each one you attach.

@simonvpe
Copy link
Author

simonvpe commented Feb 1, 2017

@OvermindDL1 Yes, the Abilitiea. What do you mean by parented to? Parent as in keeping a reference to an entity? In that case, is it safe to keep Entity references between update loop steps?

@OvermindDL1
Copy link

Parent as in keeping a reference to an entity? In that case, is it safe to keep Entity references between update loop steps?

I'd have a component on the 'instanced as an entity' ability entity that holds a handle to a card entity. I'm unsure about this ECS library (I have my own) but a handle is a 32 or 64 bit in my system, where some count of lower bits is the entity index and the rest of the higher bits is the generation id to invalidate it, so it is safe in my system at least, I'd imagine it would be similar here considering this is the handle definition here: https://github.com/SuperV1234/ecst/blob/master/include/ecst/context/entity/handle/handle.hpp#L39-L40

@vittorioromeo
Copy link
Owner

@simonvpe

is it safe to keep Entity references between update loop steps?

If you are sure that the entity wasn't destroyed during the previous update step, you can refer to it through an entity_id safely.

If you are unsure about the state of the entity, you should use an entity::handle, which can be queried before access with context::alive(const handle&).

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

3 participants