Component Design in Component Based Game Engine

Started by
31 comments, last by phiwer 10 years, 11 months ago

Would you share the same VillageComponent between Players and the actual Village entity, or would you suggest creating a different component with the sole task of explaining that a player is present in a village (e.g. PlayerInVillageComponent)?

I would question the need for a "Village entity" ;-). What would this entity exist for?

"task of explaining that a player is present in a village" -> I wouldn't make a different component for this. But I don't really know what this is. Is this a blob of text that pops up whenever a player enters a village?

No villages are more important than just describing if a player is present or not, that was why I thought they would make good entities. :)

Let's make the assumption that a village is something that ought to be an entity just for sake of argument. Then having a duplicate village component doesn't seem optimal, but if it's there only describe a position of the player, then I'd understand your point of not having it be an entity. Was this your point as well?

Advertisement

Let's make the assumption that a village is something that ought to be an entity just for sake of argument. Then having a duplicate village component doesn't seem optimal, but if it's there only describe a position of the player, then I'd understand your point of not having it be an entity. Was this your point as well?

I think my point was just to reconsider whether it needs to be an entity (since it doesn't necessarily need lists of children buildings and players).

But if there are other attributes it has (such as... I dunno... name? population limit? ), then it can make sense to be an entity. In that case maybe I would have a VillageDescriptorComponent for the village entities (containing all the innate info about the village), and a VillageIdentifierComponent to identify things that are in that village (and perhaps the village entity itself would have one of these too).

What sorts of "innate village data" do you think would be part of a VillageDescriptorComponent?

Let's make the assumption that a village is something that ought to be an entity just for sake of argument. Then having a duplicate village component doesn't seem optimal, but if it's there only describe a position of the player, then I'd understand your point of not having it be an entity. Was this your point as well?

I think my point was just to reconsider whether it needs to be an entity (since it doesn't necessarily need lists of children buildings and players).

But if there are other attributes it has (such as... I dunno... name? population limit? ), then it can make sense to be an entity. In that case maybe I would have a VillageDescriptorComponent for the village entities (containing all the innate info about the village), and a VillageIdentifierComponent to identify things that are in that village (and perhaps the village entity itself would have one of these too).

What sorts of "innate village data" do you think would be part of a VillageDescriptorComponent?

Basically villages can fight one another, so some sort of track record would be needed (wins/losses etc). Also the current standing against other villages (bad standing/good standing etc), but this isn't really something that would be suitable for the VillageDescriptorComponent.

This topic is closed to new replies.

Advertisement