Roadmap
From Luminids to a platform other teams can use.
Working prototypes now support the first extraction and developer workflow milestones. Next: broaden the runtime, complete authoring tools and test adoption in another studio's game.
01 Working foundations
Game systems and developer tools that work today.
Four capabilities are implemented in Luminids and two in internal tools. Four more game capabilities remain in validation.
Implemented
6 claimsWorking and tested in the setting named by the claim: saved game state or internal developer tools.
-
Each character keeps a stable identity, and that identity survives saving and loading.
Implemented Test suite, character layer
-
Each character keeps a bounded, curated record of what it has lived through, and that record changes how it develops.
Implemented Test suite, character layer
-
Two individuals share one bounded record of the history between them, written during ordinary play.
Implemented Saved pair history, evidence summary
-
What a character says is assembled from what it has actually lived, and it stays silent rather than claim something it cannot support.
Implemented Test suite, character layer
-
Internal tooling opens saved recordings and shows each character’s recorded evidence, beliefs and choices at a selected moment.
Implemented Tool evidence and scope
-
Internal tooling checks saved recordings against named rules, identifies failing records and reports when the evidence is insufficient to complete a check.
Implemented Tool evidence and scope
Being tested
4 claimsWorks in a bounded development setting and is undergoing broader validation.
-
Evidence is held per individual, and it gates what that individual is allowed to claim.
In production validation Test suite, character layer
-
A character that has come to believe something about itself reacts when the world contradicts it, remembers the day, and lets the belief go; a character that never formed the belief does neither.
In production validation The recorded run
-
Action, demonstrated in a controlled scene, validating
In a controlled scene, a character acts on a held belief about a friend, then revises it after observing a change.
In production validation Controlled scene, evidence summary
-
A character can hold an expectation, discover it was wrong, and be changed by that.
In production validation Test suite, character layer
02 Extract
The first decision kernel is extracted.
Next, extend that boundary into a reusable runtime another game can adopt.
An extracted decision kernel runs outside Luminids; the broader reusable CRI runtime remains in development.
- Extend extraction beyond the first decision kernel.
- Stabilise the runtime interface for other games.
- Qualify save, load and evidence across that boundary.
- Measure performance in another game environment.
- What it solves Another team can integrate the cognition instead of building it themselves.
03 Productise
Inspection, replay and checks now have working prototypes.
Next, complete authoring and validate the workflow with an outside team.
An internal Studio prototype inspects and replays recorded character state, with a connected game showcase for following beliefs, choices and outcomes.
An internal Bench prototype changes supported inputs to recorded decisions, recomputes the result and checks recordings for regressions.
- Add authoring for situations, actions and project goals.
- Extend intervention beyond supported recorded decisions.
- Make the workflow usable by an outside team.
- What it solves A designer can find out why a character did something, and check that a fix actually worked.
04 Integrate
Connect CRI to other teams’ games and models.
Add support for additional game environments, world adapters and model connectors.
- World adapters that connect game events, state and actions to CRI.
- Optional model connectors that let a language model express CRI state.
- CRI running in game environments beyond Luminids.
- What it solves A team can keep its own engine and model, with each character’s history held in CRI.
05 Validate
The next commercial proof is CRI being useful in someone else’s game.
We will move from customer discovery to design partnerships, external pilots and paid deployments, and then towards repeatable distribution.
Success is not Nick integrating every deployment by hand. The end state is a developer product another team can adopt and operate.
Design-partner conversations are open to studios building systemic characters.
Without Luminids-specific code underneath, another team can:
- Author Set what their characters start out knowing and believing.
- Inspect Follow one of their responses back to the evidence behind it.
- Test Change one thing, replay it, and keep the difference as a test.