unity-patterns

Match the pattern to the actual problem: ScriptableObjects for shared config data, C# events for one-to-many notifications, state machines for mutually exclusive states, and object pools for frequent spawning. Recommend at most 1-3 patterns and explain why simpler options are insufficient.

Use ScriptableObjects for authored configuration, shared static data, event channels, and reusable data assets. Avoid them as the default home for per-run mutable gameplay state, where plain class instances are clearer.

Prefer C# events and delegates for one-to-many notifications with clear ownership and unsubscribe points. Reserve a global event bus for cases where many systems genuinely need broad decoupled notifications, since it hides ownership and complicates debugging.

Use object pooling for frequent spawn and despawn cycles such as bullets, VFX, enemies, and UI items. Skip pooling for rare objects or simple lifetimes where instantiation cost is negligible.

Compare three implementations: a per-enemy paused flag, disabling the MonoBehaviour, or a manager-held active/frozen subset list. At large counts only the subset list avoids per-frame cost on frozen enemies, but it adds ownership complexity.

Avoid interfaces around every class without a real seam or multiple implementations. Skip state machines when a few booleans or a small command flow is enough, since the extra abstraction adds complexity without payoff.