I would still like to have a comment on the code I posted.
Then I guess I'm on the right pad by reading Avoiding the Blob since that is pretty much what I am creating, I document and structure it very well but it remains a blob.. Sometimes I am giving some code it's own place but it pretty much stays in the realm that many people call the blob. But the article about avoiding it stretches it far, I mean it has a separate component for health, this might be great for a asteroids clone but is it still common sense for "deeper" games?
Should I be creating a Interfaces / components for each and every stat or does it make more sense to combine it? I would say the latter but I still might be thinking in "blobs". Anyway while soaking up all the information regarding this I am presented with 4 options:
- Using Map<K, V> to store various data. This seems the most simplistic but is kinda error prone since I need to provide strings manually.
- Using a single interface Entity that holds a ton of things. This really seems wrong to me, yet the article uses it for the Asteroids game.
- Using a interface for each functionality. This could mean interface Health that implements the methods regenerate(int amount) and damage(int amount). But I still have to define these methods in the class it belongs too and thus generating a blob again. I could of course have these as normal classes instantiated within my creatures.
- A full component system like Unity uses. Where I use a component manager for each object and access these components by someObject.getComponent("componentX") but that seems like overkill for anything other then a engine to me.
So I guess I have to go with option 1, what was suggested earlier by Krohm. Or with 3 but make the "components" there own accessible classes from the entity holding it. I have been looking for examples but have not found any yet. If anyone can point me to some examples, preferably C# or Java, I would much appreciate it. For now I will prototype both options and play with the idea.