1

I am making a game in which the player character can gain traits that change how their character behaves in my world model or add functionality to it. For example, the character might gain the "feather" trait that changes how fall damage is calculated or the "strong" trait that means the player can now pick up items that were previously just part of the scenery.

I have been hard coding traits in their relevant classes and switching a boolean to change behavior when they come into play, but it is getting rather unmanageable as my trait list grows.(I am also missing out on a lot of the emergence I was hoping to get) There must be a more scalable and decoupled way of doing this.

How would you code such a feature where code behavior changes or expands at runtime? If you are not inclined to do my work for me, which programming patterns would you use to achieve this kind of behavior?

Vaillancourt
  • 16,325
  • 17
  • 55
  • 61
Althis
  • 139
  • 4
  • 2
    Entity component system – Bálint Mar 17 '17 at 10:32
  • The title is fine IMHO, I knew at a glance what you sere talking about. – Quentin Mar 17 '17 at 14:23
  • Objects in the entity component pattern are initialized at runtime, but once created the pattern doesn't describe how to change the objects at runtime, or add new functionality to it. – Althis Mar 17 '17 at 14:53
  • Single- or multiplayer? – Stormwind Mar 17 '17 at 16:08
  • It is a single player game. Is that relevant? – Althis Mar 17 '17 at 16:42
  • Are the traits entirely boolean nature? I.e. it's a matter of have vs. have-not, for each trait? Or are there degrees of having or not having, e.g. not feathered (0), slightly feathered (1), or heavily feathered (2)? – Engineer Mar 18 '17 at 17:53
  • The Entity Component pattern is just fine for this: just that as traits change you disconnect the component (remove its event listener and GC it) and attach a new component in its place. – Draco18s no longer trusts SE Mar 18 '17 at 22:16
  • but once created the pattern doesn't describe how to change the objects at runtime Given that an entity is pretty much just a list of components, you just need to implement that list with a mutable data structure so that you can add and remove items from the list. – jhocking May 19 '17 at 19:04
  • ECS is a terrible way to implement this, btw. That just leads to either (a) explosions in the number of components, or (b) spaghetti code in systems that are just checking components for tags. e.g., for "feather", you don't want your physics system saying if entity.has_component(feather) then gravity = world.gravity * 0.1 which deeply encodes the knowledge of "feather" into physics, you want to say gravity = apply_buffs(entity.buffs, world.gravity). Which can be modified per-frame by scripts, cool-downs curves, etc. - stuff that is overly complex via just adding/removing components. – Sean Middleditch May 19 '17 at 21:47

0 Answers0