Entity System & Character Controller

Goal

I wanted to build a flexible system to manage players, enemies, and allies under a single framework.

Solution

I setup a powerful Entity base class to serve as the foundation for all character-like objects in the game. To manage behavior, each entity maintained its own internal state machine. I used C# Action events as interaction hooks within the Entity class. This allowed dynamic behavior to be added or extended without modifying the core entity logic. This Open-Closed approach created a modular and decoupled workflow, making the system more flexible and easier to maintain.

The Evolution of Entity State Machine States

My goal was to create designer and editor friendly states but my original approach had many flaws.

Iteration 1: Pure C# State Classes

Problems:
1. All variables lived in the massive Entity-inherited class, breaking encapsulation.
2. The inspector became very cluttered, making certain variables hard to find.

To solve these problems, I had to move variables and methods to their individual states, utilizing the Single Responsibility Principle. I turned the states into Monobehaviours for serialization and editor collapsible components.

Iteration 2: Monobehaviour State Components

Problems:
1. Huge memory overhead for each state since every entity carried 5+ states that do not fully use the functionality of Monobehaviours.
2. Every derived entity prefab needed manually added required state components, including ones from the super class.

To address the Monobehaviour overhead, I reverted the states back to pure C# classes, but with serialization instead. This made designer and editor friendly collapsible dropdown config menus that looked very neat in the inspector.

Final Iteration: Serialized Pure C# States

Remaining Challenges:
1. Inheritance conflict: Serialized inherited states would show as duplicates in the inspector.
2. Needed a custom editor script to clean up the inspector.

Outcome

While there are still problems with my current implementation of Entity states, it does the job that it needs to for this project. I'm already happy that I was able to decouple state logic, balance memory, and improve editor usability while building a powerful and scalable entity framework.

Status Effect System

Goal

I needed a system that could apply and manage buffs, debuffs, and passive effects for both players and enemies. These effects needed to be modular, time-based, and optionally stackable.

Solution

I designed a modular component called EntityStatusEffector, which could be added to any entity. Status Effects were implemented as ScriptableObjects using a shared base class: StatusEffectSO. I also made two major subclasses for different timing behaviors, duration-based and tick-based. Each status effect inherited behavior through many lifecycle methods, giving me full control in a designer-friendly ScriptableObject format. This utilized the Strategy pattern, avoiding spaghetti code that would result from a large switch statement.

Limitations

Effects are stored by type, meaning each entity can only hold one instance of a given effect. This means that you can't reuse the same effect type, but with different configs, on one entity unless explicitly stacking and overriding.

Outcome

This system powered many unique passive abilities in the game, especially from our Aspects system. Effects could be added or removed dynamically during runtime. Designers could also easily tweak the configurations of these ScriptableObject status effects through the inspector.