unity-scriptdesign

Run a structured design review checking single responsibility, correct choice between MonoBehaviour, ScriptableObject, and plain C# class, explicit dependencies instead of hidden globals, and cleanup of subscriptions and timers. The output separates what to keep, simplify, and refactor.

Use ScriptableObject for authoring-time data decided by designers before Play, such as weapon damage, fire rate, or level music tracks. Use MonoBehaviour for scene instances and composition-time references cached in Awake, and plain C# classes for testable core logic.

This happens when a field has two owners, such as a public float edited by both the Inspector and a power-up script. Fix it by separating lifecycles: authoring-time values go in ScriptableObjects, runtime-mutable state uses a private backing field with a read-only property and change event.

A review should flag unnecessary Update methods, repeated Find or GetComponent calls in hot paths, avoidable allocations, and reflection during gameplay. Only real hotspots are reported, not theoretical micro-optimizations.

Yes, the lifecycle separation mirrors the ECS baking pipeline distinction between Authoring components, Bakers, and Systems. The same discipline of not mixing authoring data with runtime write-back applies directly to MonoBehaviour design.