HLDD–STRIDES:

A Two-Layer Documentation Framework for Instructional Serious Games

See Templates

When and why GDD comes short?

Serious games often struggle with documentation that does not fit Agile production. Traditional GDDs become outdated as development progresses, and pedagogical models stay abstract and disconnected from runtime logic. Subject-Matter Experts (SMEs) contribute essential knowledge but cannot engage with engine-level implementation.

  • Traditional GDDs are static, text-heavy and built for linear pipelines, which makes them clash with iterative SG workflows and fall out of sync with the live build .
  • Pedagogical SG frameworks map intentions but remain abstract, offering little runtime guidance or engine-ready structure.
  • SMEs provide essential knowledge through checklists and documents that do not translate directly into interactive logic, creating repeated manual conversions and limited visibility until a playable build exists.
  • As a result, production suffers from fragmented documentation, rework, poor traceability between learning outcomes and in-game actions, and weak compliance evidence in regulated domains.

Why HLDD–STRIDES works?

HLDD–STRIDES offers a two-layer documentation structure that links design intents and step-based instructional flow.

The HLDD holds stable design decisions and learning goals.

The STRIDES table structures instructional steps into a spreadsheet that can be imported directly into a game engine.

Applied in six projects across mining, healthcare and creative VR contexts, the framework reduced documentation drift, improved SME engagement and shortened iteration cycles.

The HLDD – STRIDES Framework

High-Level Design Document (HLDD)

  • A concise, stable, version-controlled central hub.
  • Captures core instructional intent, compliance anchors, and stable design principles.
  • Four key sections:
    • High Concept
    • Gameplay
    • Design Basics
    • Instructional Layer (learning outcomes mapped to standards like RETAIN or Bloom).
  • Section structure is flexible and can adapt to project needs.
  • Links to granular production details maintained in live tools (e.g., Notion, Confluence, Git, Jira).
HLDD is not only a compact GDD:

  • GDDs try to describe everything (mechanics, systems, assets, UI, tech). HLDD keeps only what must stay stable and what each member of the team genuinely needs to know.
  • HLDD separates intent from execution. GDDs collapse them into one document.
  • GDDs become obsolete once iteration begins. HLDD avoids volatile detail, links to live documents, and becomes the single source of truth for “why” the game exists.
  • HLDD is modular development friendly. Reusable mechanics, systems and interaction patterns live in their own version-controlled spaces – HLDD links to them instead of copying them, so it stays relevant across different projects and domains.

STRIDES table

  • Structures instructional steps into a format the game can run.
  • Directly editable by Subject Matter Experts, instructional designers, game designers, and game developers as a spreadsheet.
  • Each row contains
    • Step ID,
    • Task Intro (context),
    • Request (learner action),
    • If Fails (failure condition / redirect),
    • Dynamic Hint (adaptive assistance),
    • End Info (reinforcement),
    • Success (runtime condition / redirect).
  • Parsed directly into the engine – typically as CSV.
  • Optional LMS fields (SCORM/xAPI) can be included.

HLDD–STRIDES Pipeline

HLDD Creation

Game Designers / Instructional Leads define core design, the training’s intent, and learning outcomes.

STRIDES Authoring

SMEs are given the STRIDES table template. They populate the structured spreadsheet with step-based instructional content (task intros, requests, hints, failure and success conditions).

Designer Review

Designers verify sequencing and instructional logic, and match each step with the required assets and interaction logic (animations, SFX, UI elements, triggers, data structures).

Developer Implementation

The STRIDES spreadsheet is exported as CSV and imported into the engine’s data layer (e.g., Unreal DataTables, Unity via CSV-driven data assets, or CryEngine FlowGraph–ready tables).

Iteration

Stakeholders review the in-game behaviour, update the STRIDES spreadsheet as needed (then back to step 3), re-import the CSV, and the instructional flow updates instantly.

Applications & Case Studies

Developed and refined across seven real projects in mining, healthcare, AEC and creative VR, HLDD–STRIDES has evolved into a conceptual framework grounded in practical production needs.

Resources

STRIDES

Download the STRIDES template.

HLDD

An HLDD can be custom-created based on the project’s needs, ideally covering the following as a minimum.

  • High Concept – core idea, purpose, target audience, and unique features.
  • Gameplay – key mechanics, player goals, challenges, rewards, and feedback.
  • Design Basics – world, characters, interaction style, camera, and aesthetics.
  • Instructional Layer – what players learn, how learning is reinforced, engagement, replayability, and social aspects.

Modular implementation elements or fast-changing systems (UI, interactions, controllers, tools) are not embedded; HLDD simply links to their own documentation resources (such as Git, Notion, or Confluence) so they can be branched, developed, and updated independently.

 

The resrouces section is being expanded.
Please check back soon for more resources.
For any questions or comments, feel free to contact the author.

Oguz Orkun Doma, PhD

Architect and VR developer with a PhD in Architectural Design Computing, specializing in immersive experiences, level design, and virtual environments. Experienced in VR development, game design, and Unreal Engine, integrating academic research with innovative industry practices.