Core purpose
A gamebook is not a visual-novel engine. It is a digital model of traditional interactive fiction: a reader reads a chapter, chooses an option at its end, and then goes to another chapter. Multiple routes can converge or reach different endings.
Ordinary content structure continues to manage chapter content and editorial order. GameContentStructure overlays a playable directed graph, and a Journey records the immutable path each reader actually takes.
Established design
- Use a content-structure node’s stable occurrence identity as a graph node, not a reusable chapter ID.
- Make every choice a stable directed edge whose source and destination are not rewritten in place.
- Record the selected choice, time, and arrived node in each journey step; point a journey to its current path end.
- Let journeys share prefixes without copying history.
- Handle content changes with stable IDs, retirement records, and local invalidation—not an invented book-wide version ID.
First-phase product boundary
The first phase covers only acyclic chapter graphs, choices, branching, convergence, and endings. It excludes variables, conditions, scripts, combat, resource management, and a visual-novel runtime. If these capabilities become appropriate later, their need must be demonstrated with new, distinct fields and product rules rather than turning Gamebooks into a general-purpose game engine.
Not yet implemented
An author-facing graphical editor, pre-publication path validation, choice statistics, Journey-branch management, reader navigation, and history compatibility are all planned. This product page therefore marks Gamebooks as “planned” rather than presenting a complete design document as a usable product.
Relationships and boundaries
Gamebooks are not a new Unit type; they are still books. Ordinary reading progress can record reading status and statistics, but it does not handle interactive navigation. The actual path must be preserved by the Journey model.