Skip to content

2026-06-30 — Visual Engine and Mission Architecture

Published mirror · Status: Decided · Promote to Captainswords.app/docs/DECISIONS.md or ADR when ready

Context

We were struggling with the visual direction and the concern that Captain's Words felt too short, too activity-based, or too hard to scale.

The conversation moved from individual activities toward a reusable architecture for missions, visual patterns, and world progression.

Major decisions

1. CaptainsWorld should be a guided top-down 2D adventure

Direction:

Guided top-down 2D adventure, not open-world RPG, not isolated worksheets.

Inspired structurally by Pokémon-style navigation, but without combat.

2. The game should be progressively open

The child starts in a limited area.

Example:

  • Harbour is accessible.
  • Lighthouse is visible but locked.
  • Boat is unavailable.
  • Fog blocks the sea route.

After enough meaningful help, the world changes and the next area opens.

3. Islands are better than cities

The world should be structured as islands/areas.

Example arc:

  • Harbour
  • Old Lighthouse
  • Whale Bay
  • Harbour Master's Station
  • Grandpa's Cove

Each island is a community with NPCs, missions, and a major transformation event.

4. The equivalent of Pokémon gyms is a major world restoration moment

Not a boss.

Examples:

  • Harbour: receive boat and captain clothes.
  • Lighthouse: light the lighthouse.
  • Whale Bay: guide whale to deep water.
  • Map Station: restore Grandpa's route.

5. Each island can be elastic

The first arc can stretch naturally.

Instead of:

Bottle → Activity → Boat → Activity → Lighthouse

It becomes:

Bottle → Harbour community → NPC missions → Harbour transforms → Boat unlocks → Lighthouse route opens

6. NPCs should be sources of problems, not fixed quest lists

Example: Fisherman

The Fisherman does not have Mission 1 to Mission 8.

He has a mission grammar:

  • knows fishing, sea, weather
  • uses nets, boats, ropes, crates, fish
  • can support repair, guide, deliver, sort
  • can generate missions based on the child's learning need

7. The Visual Engine is required

The Learning Engine chooses what the child practises.

The Story Engine explains why.

The Visual Engine decides how it looks.

The Renderer draws it.

8. The UI should use a consistent shell, not identical screens

Shared rhythm:

Meet → Problem → Focus → Interact → Transform → Reward → Continue

Three MVP UI modes:

  • Focus Object Mode
  • Progressive Object Mode
  • World Action Mode

9. The art kit is the production engine

The project should focus on creating Harbour Kit v1:

  • terrain
  • tiles
  • characters
  • props
  • prop states
  • FX
  • visual patterns

Once this kit exists, many missions can be assembled from it.

10. 2.5D is too expensive for scalable mission production

Top-down modern pixel art is a better production fit.

Major story moments can still use full-screen storybook illustrations.

Exploration and missions should use reusable top-down assets.

11. Godot may be a better renderer than Phaser for this direction

Godot gives:

  • TileMaps
  • scenes/nodes
  • AnimationPlayers
  • strong 2D tooling
  • mobile export
  • Godot MCP possibilities

However, the SDK should remain renderer-agnostic where possible.

12. SDK should support mobile later

The CaptainsWorld SDK should separate core logic from rendering so it can later power:

  • web prototype
  • Godot build
  • mobile app
  • school/admin previews

Current next action

Create Harbour Kit v1 documentation and asset production plan.

Do not build many missions yet.

First define the reusable art kit, prop states, NPC states, FX library, and mission UI modes.