1
\$\begingroup\$

So I'm working on a game where squads of varied units would explore, fight, trade and build on an overworld map. Combat would be automated more or less, and happen on the overworld. Basically, something like Mount&Blade but without the real-time hack and slash combat.
enter image description here

I'm using an ECS architecture, and even in MVP stages I'm running into confusion: Should each unit be an entity in the grand entity pool, with an ID pointing to the squad it belongs to? Or should they be in an array of units in the squad entity?

When they start having items, should every dagger and boot be part of a gigantic entity pool, or only exist inside units and inventories?

When it'll come to skills and enchantments, buffs... will a "+10% damage" buff float among houses and squads and knives and forests in the entity pool, or will it be part of a buff array?

If it helps

I'm using Javascript with a homemade ECS, for fast and shareable iterations, and for learning purposes too.

Improve this question
\$\endgroup\$
2
  • \$\begingroup\$ Your ECS: your rules. Put it where you like it best. If you later decide you don't like it there, put it somewhere else. No ECS police will arrest you for making a choice that wasn't the "true" way. Have you observed a concrete problem with your preferred strategy that you need outside help to solve? \$\endgroup\$
    – DMGregory ♦
    Oct 8, 2019 at 0:13
  • \$\begingroup\$ My issue with "your code, your rules" answers is that I don't know the implications of each approach. The answer I did get helps me identify that "everything is an entity" is the right answer for me. \$\endgroup\$
    – Hypergardens
    Oct 10, 2019 at 10:18

1 Answer 1

Reset to default
2
\$\begingroup\$

As a general disclaimer and as DMGregory already stated it: The rules of ECS are not written in stone. Doing it on way has benefits, doing it another way has some others. So, you need to know, what either approach does for you.

So, as i don't know your code, i can only theorize what doing it one way would do compared to another. As you should remember, systems only go other components and not necessarily over every single entity you got. And for the most part, entities don't hold values, but as said in the first paragraph, that is not set in stone.

Units are Entities, Squads are Components

If your entities are units and your squads are some sort of component, then you only iterate over the Units you need for certain actions. If a squad is travelling and nothing happens, you don't need to check for the stats of every single unit of that squad. Also, it would be easier for every single entity to have different equipment.
Negatively is that you got way more entities and it seems that individuals don't really matter except for only a few instances.

Squads are Entities, Units are Components

If Squads are units, you only have so many components for those to iterate over, except if you got one Unit component for every Unit in that Squad.
Only when individuals are to be requested, it can get complicates as a Unit does not really have a well defined id.

Squads are Entities,Units are Entities, EVERYONE IS AN ENTITY

Why not both. Squads are Entities that have a Units component with the ID of every single Unit, that are also Entities.
This way you have some more entities, but that's just a slight draw back.

Improve this answer
\$\endgroup\$
8
  • \$\begingroup\$ Thank you for the answer that shows me some alternatives and consequences, rather than just "your code, your rules". For example, if I have five somewhat customisable units (that each have visibility and speed) in a squad, whose visibility is determined by the sum of their vis, and the speed by the slowest unit, Everything Is An Entity would be preferrable, right? \$\endgroup\$
    – Hypergardens
    Oct 10, 2019 at 10:19
  • \$\begingroup\$ Also I think I misunderstood ECS somewhat, "squad" shouldn't be a component so much as "unitContainer" should be, since towns and armies and ships can all "contain units". And unit containers may move or not on the map, so they're all entities for now. Thanks! \$\endgroup\$
    – Hypergardens
    Oct 10, 2019 at 10:21
  • \$\begingroup\$ @AlexMitan I would say "it depends". Should your towns and armies contain 1.5 Squads? Possible, but unlikely. So you should call them "squadcontainers". If cities are there to refill squads, while several squads can be stationed in them, or ships can transport 300 units, unrelated to the amount of squads, then you should still think of the possibility of 3.5 Squads in a ship. This would make it a "squadContainer" and a "unitContainer". So yes, just make them Entities with different components to reflect their capability. \$\endgroup\$
    – PSquall
    Oct 10, 2019 at 10:31
  • \$\begingroup\$ no, no. Towns and armies would BE squads, as in they would have 0 to 50ish units residing in them, fighting, producing things and maybe moving. It's not a setting where people travel alone, nor is it a setting where armies of 500 identical units really exist. \$\endgroup\$
    – Hypergardens
    Oct 10, 2019 at 10:38
  • \$\begingroup\$ @AlexMitan Thats what i ment. Armies should contain a certain amount of squads, not units. Why should an Army care if they have 400 or 401 Units in it? But maybe they can only organzie 20 Squads. Cities on the other hand dont care, how many squads are in then, but they can only support 400 units. \$\endgroup\$
    – PSquall
    Oct 10, 2019 at 10:50

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .