![]() Ie: if the enemy already has a DamageDealt component on it, what is the projectile to do?ģ) Spawn a "Damage event" entity via indirection This seems to be the most straightforward but has the critical flaw that an entity can only be dealt damage from one other entity per frame. A later system would pattern match against the various configurations of DamageDealt and other controlling components like DamageShield or whatever to actually _apply_ the damage and subsequently remove the DamageDealt component. ![]() Maybe when the projectile reaches the enemy entity, it simply adds a new DamageDealt component onto the enemy, and configures the new component to have data that describes the damage the projectile did. Very unworkable because this is both very slow, and very inflexible.Ģ) Add DamageDealt component to the enemy The least elegant of all the approaches, each projectile simply interrogate the enemy with calls to HasComponent, and branch based on whether or not different components are present to decide what to do. Here are some partial solutions I've thought of but none seem to be really good.ġ) Giant manual if-else tree using HasComponent A system that loops for each projectile needs to do something when the projectile reaches the enemy, but I can't figure out what that might be. I can conceive of a set of components that might define a projectile, or an enemy, but I am kind of at a loss as to how to define a system that applies damage from a projectile onto an enemy in a nice flexible way. When moving to ECS land, I am having a hard time finding the right patterns that allow this kind of abstraction / indirection. We can create new types of projectiles that call ApplyDamage, and new types of enemies can be created that implement ApplyDamage. This is all well and good, nicely abstracted and flexible. The point behind the abstraction is that the projectile doesn't know or care who is on the receiving end of the damage, it just knows how to do damage. Maybe a very special enemy becomes more powerful every time it is hit with fire damage. ![]() Maybe a different enemy has periods of invulnerability. Maybe one enemy has a special shield that absorbs damage and regenerates. Putting the implementation of ApplyDamage behind an interface/virtual method allows different enemies to handle damage differently. With MonoBehaviour style I might have an IDamageable interface with a method like ApplyDamage(). The example I am going to be using for this post is the case of a projectile hitting an enemy and doing damage. When working in MonoBehaviour-style code, it is an incredibly common occurrence for the actual implementation of an action to be abstracted behind an interface/virtual method. ![]()
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |