Skip to main content
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

PieceRole
MolcaProjectSettingsPicks the RuntimeManager prefab and GlobalSettings asset used at startup.
GlobalSettingsBag of SettingModule assets (VR catalog, execution mode, etc.).
ScenarioDataConfigScenario collections, execution/player mode, lookup by id — how runtime finds BaseScenarioData.
Other 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.
LevelType / conceptNotes
ActivityScenarioActivityListed on ScenarioManager; owns a SequenceController and root Step list; ties into activity scoring and session.
SequenceSequenceControllerAdvances the root steps (and nested children such as parallel groups).
StepStepOne unit of training logic; VR step subclasses live under VR steps in the docs nav. Completes when self and child steps complete.
AuxiliariesStep auxiliariesOptional behaviors on a step (scoring, haptics, UI hints).
Typical author flow: define scenario data → place ScenarioManager + ScenarioActivity entries in the scenario scene → assign root steps under each activity → add VR Step components for grabs, valves, teleports, etc.

​
3b. Tour: area → spot (not step-based)

Tour uses exploration, not the same activity/step graph as simulation.
LevelType / conceptNotes
SubsystemTourSubsystemRuntimeSubsystem: loads areas, teleports to spots, optional home scene.
AreaTour area and spotsOften an additive scene managed per tour data.
SpotTourSpotControllerTeleport target; may surface informational materials (tour “content” at that location).
Progress and session posting still go through the same scenario/session stack; the mode driver routes lifecycle into TourSubsystem instead of stepping activities.

​
Simulation vs tour (quick comparison)

SimulationTour
Scenario dataSimulationScenarioDataTourScenarioData
Primary runtimeActivities + sequences + stepsTourSubsystem + areas/spots
Designer mental modelOrdered tasks / checklistFree roam + hotspots
Molca CoreHeavy use of StepSteps optional only if you add custom hybrid flows