Startup chain
MolcaProjectSettings(ScriptableObject) is resolved at load time (default asset path or Addressables key — see script).- The assigned RuntimeManager prefab is instantiated and marked DontDestroyOnLoad (RuntimeManager).
RuntimeSubsystemcomponents on that prefab register with the runtime (tour, session, fade, etc.) (Runtime subsystem).GlobalSettingsreferenced from the same project settings asset exposesSettingModuleentries — ScenarioDataConfig, optional media/modal modules, and product-specific pieces.
What lives where
| Concept | Typical location | Doc entry |
|---|---|---|
| Root settings asset | MolcaProjectSettings | Molca Project Settings |
| Living runtime singleton | RuntimeManager (prefab instance) | RuntimeManager |
| Pluggable services on runtime | RuntimeSubsystem subclasses | Runtime subsystem |
| Named config bag | GlobalSettings → SettingModule[] | Global settings |
| VR scenario catalog & modes | ScenarioDataConfig | Scenario Data Config |
VR-specific subsystems (examples)
Your RuntimeManager prefab in a VR template usually includes subsystems such as:- Tour — TourSubsystem for tour scenarios.
- Session —
ScenarioSessionManagerfor connected auth, content fetch, and session lifecycle (session loading). - Presentation — fade, player, inventory managers as needed (VR presentation docs group).
Content vs runtime wiring
- Modules (GlobalSettings, ScenarioDataConfig) answer: which scenarios exist, standalone vs connected, how to resolve ids.
- Scenario scenes answer: what happens in one scenario — ScenarioManager, activities, steps, or tour areas.
Digital Twin note
The DT SDK (_MolcaDT) uses Molca Core patterns where linked, but not the VR scenario / tour stack above. Start from DT overview and DT project layout.
Related
- Architecture — product-neutral Core placement
- VR architecture — VR layers on Core
- Platforms — which SDK applies where
- Dependency injection — resolving services after bootstrap
- VR session flow how-to — end-user flow after runtime is up