Runtime¶
Everything that ships into a player build. One assembly, RevGaming.RevLearning.Runtime, with no editor dependency and no dependency on any particular LMS.
The shape of this folder follows one rule: content depends on the abstractions, never on a standard. Abstractions/ defines what a learning runtime can do; SCORM/ and xAPI/ implement it; WebGL/ is the only part that knows it is running in a browser. Swap the implementation and content written against ILmsRuntime keeps compiling.
Layout¶
| Folder | What lives here |
|---|---|
Abstractions/ | The public contract — interfaces, enums, and the types that cross it |
SCORM/ | SCORM 1.2 and SCORM 2004 runtimes, and the helpers that keep them honest |
xAPI/ | Statement building, serialization, and queued delivery to an LRS |
Extensions/ | Convenience methods over ILmsRuntime for the things courses do constantly |
WebGL/ | The managed half of the browser bridge, over the jslib in Plugins/WebGL |
Config/ | The runtime config asset that editor settings are synchronized into |
RevLearningRuntime.cs sits at the root and is the entry point: RevLearningRuntime.InitializeAsync(version) picks a runtime, connects it, and hands back an ILmsRuntime. It returns the stub outside WebGL, so the Editor and standalone builds work without an LMS.
What the runtime will not do for you¶
It reports; it does not decide. Nothing here infers that a learner passed because they scored well, or completed because they reached the last scene. The course decides and the runtime writes it down — which is why there is no "auto-complete" setting to find.
The two exceptions are both about not losing data rather than about judgement: a SCORM 1.2 Completed write will not overwrite a recorded pass or fail (1.2 folds success and completion into one element, so it would be a downgrade), and an out-of-range xAPI score is clamped rather than sent, because an LRS must reject the whole statement otherwise.