Skip to content

CaptainsWorld SDK

Published mirror · Source of truth: Captainswords.app/docs/CAPTAIN_ENGINE_V1.md · docs/CAPTAIN_ENGINE_ROADMAP.md

Purpose

The CaptainsWorld SDK is the reusable foundation for Captain's Words, Captain's Numbers, and future learning products.

It should separate learning logic, story logic, mission generation, visual composition, and rendering.

The SDK should make it possible to generate many distinct learning experiences without manually designing every screen from scratch.

Core architecture

CaptainsWorld SDK

├── Learning Engine
│   Decides what the child should practise.
│
├── Story Engine
│   Decides why the child is practising.
│
├── World Engine
│   Tracks where the child is and what has changed.
│
├── Mission Engine
│   Creates the problem to solve today.
│
├── Visual Engine
│   Decides how the mission should look and feel.
│
├── Scene Compiler
│   Assembles mission data into a playable scene definition.
│
└── Renderer
    Draws the scene and handles input.

Important principle

The renderer should be as dumb as possible.

The renderer should not decide:

  • what the child practises
  • why the mission exists
  • which NPC gives the mission
  • what the reward is
  • what story unlocks next

The renderer should only receive a compiled mission scene and render it.

Example

The player sees:

Help the Fisherman repair his torn net.

The system sees:

{
  "location": "harbour",
  "npc": "fisherman",
  "verb": "repair",
  "learningSkill": "missing_letter",
  "visualPattern": "repair_object",
  "uiMode": "focus_object",
  "missionProp": "fishing_net",
  "propState": "broken",
  "successState": "repaired",
  "fx": ["letter_fly", "stitch", "sparkle"],
  "reward": "harbour_trust"
}

SDK to mobile

The SDK should be designed so that the core engines are platform-agnostic.

This means the same logic can power:

  • web prototype
  • Godot desktop build
  • Godot iOS/Android app
  • future native mobile app
  • school dashboard previews
  • admin mission preview tools

The SDK should not assume mouse input only. Mission interactions should be touch-friendly from the beginning.

Renderer options

Current preferred direction:

  • Godot for the interactive game renderer.
  • Godot MCP for Cursor-assisted scene creation and iteration.
  • Core logic kept separate so that the SDK is not locked to Godot forever.

Why this matters

If the SDK is built correctly, CaptainsWorld can scale by adding:

  • new islands
  • new NPCs
  • new mission props
  • new learning skills
  • new visual patterns

without rebuilding the entire product.