Unity3D游戏Actor架构下Component Driven Design的组件通信方案问询

Hey there! Since you're already building your Unity game with a component-driven Actor architecture, figuring out clean component communication is key to keeping your code maintainable and scalable. Let’s walk through the most common approaches, along with their pros, cons, and Unity-specific examples to help you decide what fits your project best.

1. Direct Component References #

This is the simplest, most straightforward method—great for tight, well-defined relationships between components on the same Actor.

How it works: #

Use GetComponent<T>() (or assign via the Inspector) to grab a direct reference to another component, then call its public methods or access public properties directly.

Example: #

// In your AttackerComponent
public class AttackerComponent : MonoBehaviour
{
    // You can assign this in the Inspector instead of using GetComponent
    [SerializeField] private MovementComponent _movementComp;

    void Awake()
    {
        if (_movementComp == null)
            _movementComp = GetComponent<MovementComponent>();
    }

    public void InitiateAttack()
    {
        // Tell the movement component to stop while attacking
        _movementComp.SetMovementSpeed(0f);
        // Trigger attack logic...
    }
}

Pros: #

• Super simple to implement and debug
• No extra overhead (fast performance)

Cons: #

• Creates tight coupling between components—changing one might break the other
• Hard to reuse components across different Actor types if they rely on specific other components

2. Unity Events or Custom C# Events #

Events are a fantastic way to decouple components. Instead of one component directly calling another, it broadcasts an event that other components can choose to listen to.

How it works: #

Define events in a component that "broadcasts" state changes or actions. Other components subscribe to these events to react when they fire.

Example with UnityEvent: #

// In AnimationComponent
public class AnimationComponent : MonoBehaviour
{
    // Expose events in the Inspector for easy setup
    public UnityEvent OnAttackAnimationCompleted;

    // Called by an Animation Event in your attack clip
    public void NotifyAttackAnimFinished()
    {
        OnAttackAnimationCompleted?.Invoke();
    }
}

// In AttackerComponent
public class AttackerComponent : MonoBehaviour
{
    private AnimationComponent _animComp;

    void Awake()
    {
        _animComp = GetComponent<AnimationComponent>();
    }

    void OnEnable()
    {
        // Subscribe to the event when the component is enabled
        _animComp.OnAttackAnimationCompleted.AddListener(OnAttackFinished);
    }

    void OnDisable()
    {
        // Always unsubscribe to prevent memory leaks
        _animComp.OnAttackAnimationCompleted.RemoveListener(OnAttackFinished);
    }

    private void OnAttackFinished()
    {
        // Resume movement or reset attack state
        GetComponent<MovementComponent>().SetMovementSpeed(5f);
    }
}

Pros: #

• Low coupling—components only depend on the event signature, not each other
• Flexible: multiple components can listen to the same event
• Easy to set up via the Inspector with UnityEvent

Cons: #

• Slight performance overhead compared to direct references (negligible for most games)
• Requires remembering to unsubscribe from events to avoid memory leaks

3. Interface-Based Communication #

Using interfaces lets you define a contract for functionality, so components can interact without knowing the exact implementation of the target component. This is perfect for reusing components across different Actor types.

How it works: #

Define an interface that outlines the methods/properties a component should expose. Have your functional components implement this interface, then other components can interact with them via the interface.

Example: #

// Define the interface
public interface IMovable
{
    void SetMovementSpeed(float speed);
    void Move(Vector3 direction);
}

// MovementComponent implements the interface
public class MovementComponent : MonoBehaviour, IMovable
{
    [SerializeField] private float _baseSpeed = 5f;
    private float _currentSpeed;

    public void SetMovementSpeed(float speed)
    {
        _currentSpeed = speed;
    }

    public void Move(Vector3 direction)
    {
        transform.Translate(direction * _currentSpeed * Time.deltaTime);
    }
}

// AttackerComponent uses the interface instead of the concrete class
public class AttackerComponent : MonoBehaviour
{
    private IMovable _movable;

    void Awake()
    {
        _movable = GetComponent<IMovable>();
    }

    public void StartAttack()
    {
        // We don't care what component implements IMovable—just that it can stop moving
        _movable.SetMovementSpeed(0f);
    }
}

Pros: #

• Extremely flexible—swap out implementations (e.g., replace MovementComponent with FlyingMovementComponent) without changing dependent code
• Low coupling, high reusability

Cons: #

• Adds a bit of extra boilerplate code with interface definitions
• Requires ensuring the target component implements the interface (runtime errors if not)

4. Global Event System/Message Center #

For cross-Actor communication (e.g., a player taking damage triggering a UI update), a global message center lets components broadcast and listen to events across the entire game.

How it works: #

Create a static class to manage global events. Components can subscribe to these events or trigger them without needing direct references to each other.

Example: #

// Static global event center
public static class GameEventHub
{
    public static event Action<Actor> OnActorDamaged;

    public static void TriggerActorDamaged(Actor damagedActor)
    {
        OnActorDamaged?.Invoke(damagedActor);
    }
}

// In HealthComponent (on any Actor)
public class HealthComponent : MonoBehaviour
{
    private Actor _owner;

    void Awake()
    {
        _owner = GetComponent<Actor>();
    }

    public void TakeDamage(int damageAmount)
    {
        // Handle damage logic...
        GameEventHub.TriggerActorDamaged(_owner);
    }
}

// In UIDamagePopupComponent (anywhere in the scene)
public class UIDamagePopupComponent : MonoBehaviour
{
    void OnEnable()
    {
        GameEventHub.OnActorDamaged += ShowDamagePopup;
    }

    void OnDisable()
    {
        GameEventHub.OnActorDamaged -= ShowDamagePopup;
    }

    private void ShowDamagePopup(Actor damagedActor)
    {
        // Spawn a damage popup above the damaged Actor
        Debug.Log($"Showing damage popup for {damagedActor.name}");
    }
}

Pros: #

• Complete decoupling—components don't need to know about each other at all
• Perfect for cross-scene or system-wide events

Cons: #

• Can become hard to debug if events are overused (too many global events make tracking flow difficult)
• Risk of memory leaks if components don't unsubscribe properly

• For same-Actor component communication: Start with direct references (simple) or Unity events (slightly more decoupled). Use interfaces if you plan to swap components later.
• For cross-Actor communication: Use a global event system or interfaces (if the interaction is between specific Actor types).
• Prioritize low coupling for components you plan to reuse across multiple Actor types—interfaces or events are your best bet here.

内容的提问来源于stack exchange，提问作者Erotokritos Vallianatos