SCORM vs Custom API: Integrating Games with Learning Management Systems

When an educational institute hires a game developer, one of the initial inquiries in the requirements document concerns LMS compatibility. Almost invariably, the answer is affirmative, but the subsequent discussion about implementation details marks the beginning of critical engineering decisions. Our projects, spanning entities ranging from The Language Conservancy to Cambridge University Press and the BBC, consistently grapple with similar integration concerns: the game's platform, student identity verification, progress reporting, and ownership of learning records.

This article analyzes the two primary integration methods-LMS support via SCORM (the prevailing standard) and custom APIs (the adaptable alternative)-and offers practical advice on when each approach is most suitable.

The Core Problem:

Before contrasting the solutions, it's essential to define exactly what LMS integration entails: launching the game in the correct context (student, assignment, lesson), tracking student progress, transmitting test results and scores to the LMS gradebook, marking completion for subsequent content unlocking, and resuming the game at the last saved point. These five requirements are standard across all educational games. The challenge is determining which technology best fulfills these needs for your specific scenario.

SCORM: The Standard Approach

SCORM (Sharable Content Object Reference Model), maintained by ADL, is the predominant e-learning standard. Despite being released in 2001, SCORM 1.2 remains prevalent in mature e-learning systems. Major Learning Management Systems (LMS) generally support it, although the exact behavior for launch, reporting, and packaging may differ based on platform settings.

How SCORM Operates:

The LMS initiates the game within an iframe. Communication with the LMS occurs through a JavaScript API accessible via the window object. Data model elements are set and retrieved using standardized keys. In SCORM 1.2, key elements include cmi.core.lesson_status (completion state), cmi.core.score.raw (numeric score), cmi.core.score.min/max (score range), cmi.core.lesson_location (bookmark/point of resumption), cmi.suspend_data (freely structured string for game state, with a 4096-character limit), and cmi.core.session_time (session duration).

Advantages of SCORM 1.2:

- Widespread support for major LMS platforms

- Easy implementation due to a minimal API surface

- Proven stability with no changes in over two decades

- No need for backend integration as all communication happens client-side

Disadvantages of SCORM 1.2:

- 4096-character constraint on suspend_data, limiting game complexity

- Single score model, requiring aggregation or separate SCOs for multiple assessments

- Lack of detailed interaction tracking, providing only overall scores

- iframe dependency, leading to content security policy issues, cross-origin challenges, and limited use of advanced browser features

SCORM 2004: A More Advanced Version

SCORM 2004 enhances the previous standard with a more comprehensive data model and sequencing engine, addressing many of the limitations in SCORM 1.2. Key improvements include cmi.interactions (a structured array for recording individual question-level data such as type, correctness, response time, and result), support for multiple learning objectives within a single SCO, and sequencing capabilities that define prerequisite relationships between content objects.

Limitations of SCORM 2004:

- Less universal support compared to SCORM 1.2, with some older or specialized LMS systems only supporting the older standard

- More complex implementation due to the added features of the sequencing engine

- Still iframe-dependent, maintaining the same hosting constraints

- Potentially overkill for simple games with only basic completion and score reporting requirements

Custom APIs: The Flexible Alternative

An alternative to SCORM and xAPI is the custom API approach, which offers greater flexibility and control over the integration process. This method involves developing bespoke communication protocols tailored to your specific needs, allowing for more complex data structures, richer interaction tracking, and greater customization.

While it requires more development effort and maintenance, a custom API can provide a more seamless experience for both students and educators, particularly for games with intricate assessment mechanisms or detailed progress tracking.

Conclusion:

Choosing between SCORM and custom APIs for game integration depends on several factors, including the capabilities of the target LMS, the complexity of your educational game, and the specific reporting and tracking requirements. For simpler games with straightforward completion and scoring needs, SCORM 1.2 often provides a strong compatibility option with relatively low implementation effort.

For more complex games requiring detailed progress tracking, assessment tracking, and sequenced learning paths, SCORM 2004 or a custom API may be more suitable despite their increased complexity. Ultimately, it's crucial to test the chosen solution against the specific LMS platform to ensure compatibility and optimal performance.