Troubleshooting & Reference
Performance
Interpret the measured authoring and progression workloads and profile the project-specific systems that surround them.
Understand where work occurs
The core ordered flow advances on discrete lifecycle transitions. Most Manager and Chapter work is proportional to the configured Chapters or Objectives when selecting, hydrating, clearing, validating, or finding an exact ID. It does not run a global per-frame progression scan.
Some included detectors intentionally poll or receive physics every frame while incomplete: DestructionObjective scans its target array, ObjectPlacementObjective scans placement targets, TimedObjective updates a countdown, and trigger/arrival components receive Unity physics callbacks. Their cost scales with configured targets and active scene objects.
Likely project-specific hotspots
| Area | Potential cost | Mitigation |
|---|---|---|
| Large destruction/placement arrays | Linear scan each Update until complete | Use small task-local sets or an event-driven custom Objective |
| Verbose diagnostics | String allocation and Console overhead | Disable Verbose Logging and Demo observers in release |
| Material changes | renderer.material can instantiate materials | Plan project material lifecycle and avoid high-frequency Detonator use |
| Scene Objective reset discovery | FindObjectsByType during Chapter reset/step-back | Use at deliberate transitions, not every frame |
| Custom store | Backend latency on main thread | Buffer bounded operations; avoid unbounded network work |
| UnityEvents | Receiver work, not progression dispatch itself | Profile project callbacks independently |
Profile the complete gameplay path
- 1Create a Development build or use the Unity Profiler with representative content counts.
- 2Measure an idle Active Objective, its actual detector signal, accepted completion, and Chapter completion separately.
- 3Inspect scripts invoked by lifecycle UnityEvents and adapters; their work may dominate the product call.
- 4Repeat persistence hydration and ClearProgress with realistic Chapters and profile backend time.
- 5Disable diagnostics and compare release-like behavior.
Performance claims and limits
No fixed frame-time claim can describe a buyer's scene, event receivers, physics setup, or storage backend. The useful contract is algorithmic and observable: one current ordered position, bounded configured arrays, exact-key storage, and no hidden third-party update loop. Profile the project systems surrounding those boundaries.
For a detector with an unusually large or complex condition, derive from Objective and use an authoritative event rather than extending an Update scan.