Documentation Index
Fetch the complete documentation index at: https://docs-unity.molca.id/llms.txt
Use this file to discover all available pages before exploring further.
This page describes how VR training content is structured in the Molca VR SDK: configuration modules, scenario data and runtime, then either activities and steps (simulation) or tour areas and spots (tour). It complements VR architecture with a content tree.
Product: Molca VR SDK (_MolcaSDK/_VR). Molca Core supplies Step and SequenceController; the Digital Twin SDK does not use this scenario model (DT overview).
End-to-end hierarchy
Dependency direction: modules register where scenarios live and how the app boots; scenario data selects simulation vs tour and is referenced by ScenarioManager; simulation drives ordered activities and steps; tour drives TourSubsystem (areas and spots), not the sequence graph.
1. Modules and settings
| Piece | Role |
|---|
| MolcaProjectSettings | Picks the RuntimeManager prefab and GlobalSettings asset used at startup. |
| GlobalSettings | Bag of SettingModule assets (VR catalog, execution mode, etc.). |
| ScenarioDataConfig | Scenario collections, execution/player mode, lookup by id — how runtime finds BaseScenarioData. |
SettingModule types may appear in the same bag for media, modals, or networking; ScenarioDataConfig is the one most authors touch for which scenarios exist in the build or after a content fetch.
Together, these are the module layer: they are not gameplay sequences themselves, but they wire the app to scenario assets and session behavior.
2. Scenario (asset and runtime)
- Asset:
BaseScenarioData in Scenario/Data/ — concrete types include SimulationScenarioData and TourScenarioData (see VR architecture glossary).
- Runtime: ScenarioManager holds
scenarioData, activities (used for simulation), timers, pause, and session hooks.
- Branching: Scenario mode drivers implement simulation vs tour lifecycle (
SimulationScenarioModeDriver vs TourScenarioModeDriver) so the manager stays a single orchestration point.
Simulation scenarios attach time limits and activity lists on the data side where applicable; tour scenarios pair with TourSubsystem for world navigation.
3a. Simulation: activity → step
Simulation training is sequential: users complete activities, each backed by a Molca Core sequence.
| Level | Type / concept | Notes |
|---|
| Activity | ScenarioActivity | Listed on ScenarioManager; owns a SequenceController and root Step list; ties into activity scoring and session. |
| Sequence | SequenceController | Advances the root steps (and nested children such as parallel groups). |
| Step | Step | One unit of training logic; VR step subclasses live under VR steps in the docs nav. Completes when self and child steps complete. |
| Auxiliaries | Step auxiliaries | Optional behaviors on a step (scoring, haptics, UI hints). |
3b. Tour: area → spot (not step-based)
Tour uses exploration, not the same activity/step graph as simulation.
| Level | Type / concept | Notes |
|---|
| Subsystem | TourSubsystem | RuntimeSubsystem: loads areas, teleports to spots, optional home scene. |
| Area | Tour area and spots | Often an additive scene managed per tour data. |
| Spot | TourSpotController | Teleport target; may surface informational materials (tour “content” at that location). |
Simulation vs tour (quick comparison)
| Simulation | Tour |
|---|
| Scenario data | SimulationScenarioData | TourScenarioData |
| Primary runtime | Activities + sequences + steps | TourSubsystem + areas/spots |
| Designer mental model | Ordered tasks / checklist | Free roam + hotspots |
| Molca Core | Heavy use of Step | Steps optional only if you add custom hybrid flows |
