unity-lifecycle

Unity Lifecycle & Execution Order -- Correctness Patterns

Prerequisite skills: unity-scripting (MonoBehaviour lifecycle, coroutines), unity-foundations (GameObjects, components)

These patterns target initialization bugs, null reference exceptions from destruction timing, and subtle editor-vs-runtime differences that cause "works in editor, fails in build" issues.

---

PATTERN: Fake-Null Trap (?. and ?? on Destroyed Objects)

WHEN: Null-checking Unity objects that may have been destroyed

WRONG (Claude default):

// C# null-conditional and null-coalescing bypass Unity's == override
myComponent?.DoSomething();          // May call method on destroyed object!
var fallback = myComponent ?? other; // May return a destroyed "fake-null" object!

RIGHT:

// Unity overrides == to return true for destroyed objects
// Always use == null or implicit bool conversion
if (myComponent != null)
    myComponent.DoSomething();

// Or use the implicit bool operator (equivalent to != null for UnityEngine.Object)
if (myComponent)
    myComponent.DoSomething();

GOTCHA: When Unity destroys an object, the C# reference still exists but Unity marks it as "fake-null". The == operator is overridden to handle this, but ?., ??, is null, and is not null use the C# native null check and see a valid (non-null) reference. This is the #1 source of MissingReferenceException. Pattern matching (obj is MyType t) also bypasses the override -- use if (obj != null && obj is MyType t).

---

PATTERN: Destroy is Deferred

WHEN: Destroying objects and accessing them in the same frame

WRONG (Claude default):

// Expecting immediate removal
Destroy(enemy);
enemies.Remove(enemy); // enemy still exists this frame
Debug.Log(enemies.Count); // Count is correct, but enemy is "alive" until end of frame

// Iterating and destroying
foreach (var e in enemies)
    if (e.health <= 0)
        Destroy(e.gameObject); // Modifying collection during iteration = crash