Ideas for managing the lifecycle of Unity objects gracefully

This is just a quick brain-dump of some ideas for helpful static analyzers and the means by which they may be implemented to facilitate writing robust code for Unity.

  1. Cecil-based code analyzer that looks for and complains about common sources of intermittent failure, such as (in other words, a Unity-specific “lint” tool):
    1. Keeping a reference to a Component on the same GameObject (or even a direct reference to the GameObject itself) and accessing it from OnDelete.
    2. Calling MonoBehaviour’s component access helpers (.gameObject, .renderer, etc), or general accessors (GetComponent, GetComponentInChildren, etc), things like GameObject.Find*, or even static singleton accessors on other classes from Awake or OnEnable.
  2. Assembly-rewriting (via Cecil, or maybe a static AOP mechanism of some sort) to implement certain patterns of code that are tedious to implement by hand and needlessly complicate code or force it to be forked but necessary on mobile devices:
    1. UpdateManager pattern.
    2. Some trivial cases of object pooling / reuse.

Unanswered questions:

  1. Singleton use-cases are made a bit murky by the ambiguity surrounding Unity’s handling of assembly reloading in the editor, and scene changing elsewhere.
  2. Are there events we can hook into in Mono (via callbacks on something AppDomain-related perhaps – or AOP rewriting of the Application class to add event hooks around level loading functions…) that will reliably let our singletons guard against / address the issue of scene reloads in a way that gives them deterministic ordering of OnDisable/OnEnable with respect to scene objects?

unity 241 words, est. time: 48 seconds.

« Prefab Overrides Considered Harmful Zero-Day Magento EE Cache Poisoning Attack »

Comments

Copyright © 2016 - Jon Frisby - Powered by Octopress