Slick Forums

Hi appel, it's me again!!

I was wondering if there is an easy way to disable a component on an entity so this entity is not being processed in the corresponding system. For example, disable vulnerability (or HealthComponent) for a while to make an entity invulnerable. Removing the component and adding again would mean I have to hold the component in some place while it is "removed".

Possible solutions in mind:

* Having an extra component named InvulnerableComponent and, when processing the DamageSystem see if the entity has the InvulnerableComponent (and/or if it is enabled too).

* Modify my HealthComponent to hold a boolean vulnerable (enabled) and do not process it when processing the DamageSystem if it is false.

* Extract that logic to another class named Health or Whatever and hide there the fact that the object is invulnerable in some way (maybe an internal field or maybe different implementations) and when the DamageSystem says health.doDamage(50120401204120) the health class says "hahahah, in your dreams baby!! I am invulnerable!! damn.. that is supposed to be a secret". (I think I like this one)

* Remove the component and hold it on some place (wakale!) and then adding it again.

If there is no easy way to enable/disable a component, which of the previous solutions do you think it should be the most appropriate?

Thanks in advance.

_________________

I would not remove HealthComponent, because you might be rendering health status somewhere, like of a temporary invulnerable unit in a RTS game.

I would favor the InvulnerableComponent, which could also contain a timeout for the invulnerability feature.

Problem with having it as a InvulnerableComponent is that the HealthSystem/DamageSystem would need to check for it, and thus have knowledge of this feature.

But I'd start with that and see how it works and feels.



Also, components are only supposed to have getters/setters for data, they are not meant to have logic, like responding with some message.

An alternative to Appel's suggestion would be to have a boolean check HealthComponent.isInvulnerable() in your HealthSystem.

Yeah, I end adding a resistance field to the HealthComponent and adding an InvulnerableComponent, so when the InvulnerableSystem detects the invulnerable component it sets HealthComponent resistance to the maximum.

@appel, when I said about health.doSomething I wasn't talking about the component itself but another class external to the HealthComponent. An example:

HealthComponent
- Health

And having different implementations of the Health class (or even interface).

@both

Thanks for the answers

_________________

The InvulnerableComponent approach can get bad if you have a lot of player status on the game and add a Component for everyone because of the 64 bit limit, doesn't it?

True.

Could'nt the 64 system limit be fixed by using something like a BigInteger? You dont need a very large game before it becomes a problem.

It's easy to solve, I already had BitSet, but used long instead due to performance reasons.

Running the EntitySystem.change() check takes:
- Using BitSet takes 14227423 nanoseconds. (14 ms)
- Using long takes 564766 nanoseconds. (0.56 ms)

BitSet is 25 times slower.

I assume BigInteger would be similarly slow as BitSet.

Better go with StatusComponent, with a type attribute with a lot of enums then

I'm trying to run EntitySystems in separate threads but I can't get it to work. I believe the problem is with world.loopStart().

This would be a very nice enhancement to your EntitySystem framework.

What I am doing is spawning threads that each contain their own EntitySystem and process it.

I'm not getting very far.. I have world.loopStart() and world.setDelta() in their own thread.

Maybe a way to check if loopStart has been called or if the loopStart method has already performed its function would help with making the library asynchronous.

Edit: I made my own World obj extending World and did this manually. Will post a follow up of my results later.

Edit2: IntervalEntitySystems are giving me problems... they don't execute right. Must be the way they are handled internally?

That sounds like you are going to have a bunch of threads competing for resources.

_________________
My Github - https://github.com/warmwaffles

You are right it uses too much CPU on my dual core (almost 100% which is both cores lol). So the ability to skip a entitysystem that is still being processed would be more ideal. And I can do that myself without needing any changes to Artemis.

Amazing what a temporary break from coding can do to refresh your perspective.

Very nice framework!

I'm working on porting it to C++ right now.

You should go for lockstep mode.

In lockstep you process the systems in parallel, but setting delta and loopStart should be done before the parallel processing starts.

You can achieve this by using cyclic barriers (CyclicBarrier in Java).

So, main thread:
1. Sets delta and loopStart.
2. Initiates cyclicBarrier that executes all threads to process the systems.
3. Waits for cyclicBarrier to complete.
4. Done, and restart loop.


I could also instead of having each system as it's own thread, have a pool of workers that equals to the number of cores on your machine, and have it consume jobs from a system pool. So, just good old Producer-Consumer pattern here, where processing a entity system is a job.

Let me know how that goes, and I'll add it to the "ports" list.