📝ECS architecture allows great flexibility in defining entity types

top

Entity Component System (ECS)

OOP hierarchies make it hard to quickly create complex classes by re-combining multiple aspects (that often happens in games).

Examples when OOP hierarchies fall short:

• A common example is modeling items in a game. Imagine you have Weapon and Armor classes. Then you want to add a bash attack to a shield, so shield now becomes both Weapon and Armor.

• Another example is elemental weapons. You can add FieryWeapon and IceWeapon that deal fire and ice damage respectively, but later in the game you want to add a sword that deals both fire and ice damage. You can’t really inherit both FieryWeapon and IceWeapon as they have the same interface, so one of them would take precedence and cancel the other.

ECS solves this by making all these aspects into their own components: Weapon, Armor, IceDamage, FireDamage. Then shield becomes [Armor(defense=5), Weapon(damage=5)] and fire-ice sword becomes [Weapon(damage=10), FireDamage, IceDamage]. Entities and components are just data and it’s up to systems how to interpret it.

ECS allows to easily create new entity types by recombining existing components.

ECS also allows adding components dynamically. So if the player enchants their weapon to fire damage, you can simply add that component dynamically.