novel-to-game

Original：🇨🇳 Chinese

Translated

Turn a novel into a fully playable game on the selected target platform. Orchestrates the whole adaptation pipeline — requirements intake, gameable deconstruction, concept selection, world and visual design, target-runtime build, and evidence-based QA — for a novel in any language. Use for novel to game, story to game, book to game, adapt this novel into a game, turn this book into a playable prototype, make an interactive story or text adventure from this novel. NovelToGame Main Entry. Convert original novels, split libraries, or oh-story writing projects in any language into games that are based on the original works and fully playable on the target platform. Orchestrate gameable deconstruction, concept selection, game and visual design, target runtime environment construction, and evidence-based quality verification. Suitable for requirements such as novel-to-game conversion, turning a book into a game, adapting a novel into an interactive novel/interactive narrative/text adventure game, etc.

2installs

Sourceworldwonderer/novel-to-game

Added on2026-08-13

NPX Install

npx skill4agent add worldwonderer/novel-to-game novel-to-game

SKILL.md Content (Chinese)

View Translation Comparison →

NovelToGame Main Entry

You are the overall director of novel gamification: uphold adaptation judgments, stage boundaries, and completion evidence, and do not package ordinary prototypes as conclusions on fun, balance, rights, or release quality. Read pipeline-contract.md before starting.

Default Strategy

First, speed-read the source material and draft the

PRODUCT_BRIEF.md

for the user, then follow intake-method.md to only address ambiguities that will substantially change the direction or bring risks related to rights, scale, or platforms. Low-risk gaps are collectively listed as unconfirmed assumptions without stopping for each item.

targetFinish

only indicates the desired quality:

graybox

,

playable-prototype

,

polished-vertical-slice

or

showcase

. All projects use the same minimum QA: actual startup, rendering, input, core loop, at least one design result, and restart. Continuous 3D, voice, generated media, multilingual support, or accessibility features will only undergo effect regression testing specific to the project when actually adopted, without forming a second set of acceptance criteria.

PRODUCT_BRIEF.md

and

SOURCE_BIBLE.md

are upstream facts and cannot be silently rewritten downstream. The brief must lock in the platform, production engine, actual deliverables, target runtime, and available actual test runtime. When the toolchain is unavailable, only the alternative runtime approved in the brief can be used; the alternative result does not prove that the target platform has passed verification.

Modes

```
quick
```
: Default; proceed with recommended drafts, compare three concepts, then automatically select and complete the full process.
```
director
```
: Present three concepts and recommendations, then pause to wait for the user to choose a direction.
```
resume
```
: Read
```
_progress.md
```
and actual deliverables, then continue from the earliest incomplete handoff.

Process

Set up a workspace, record the source material, mode, current stage, and unconfirmed assumptions.
Generate
```
PRODUCT_BRIEF.md
```
; only pause when high-risk ambiguities are unresolved.
Call
```
novel-game-analyze
```
to generate the evidence-based
```
SOURCE_BIBLE.md
```
.
Call
```
game-concept
```
to generate three truly distinct directions and select
```
CONCEPT.md
```
; the
```
director
```
mode pauses here.
Call
```
game-world-design
```
to generate
```
GAME_DESIGN.md
```
.
Call
```
game-art-direction
```
to generate
```
ART_DIRECTION.md
```
; create visual target packages only when required by the desired quality.
Call
```
game-build
```
to generate a runnable version, then verify the minimum closed loop via
```
game-qa
```
; issues are routed back to product/design/art/build owners, preventing silent rework of planning during the implementation stage.

The orchestrator only records two completion results:

```
scope
```
: Upstream scope and stage owners are complete and conflict-free;
```
playable
```
: All six minimum player effects have actual operation evidence.

Language and Culture

Accept novels in any language. Deliverables use the language specified by the user; if not specified, follow the conversation language. Original text evidence retains the original language, and only translations required for decision-making are added for cross-language scenarios, along with a maintained glossary. The original work's cultural context, target market, and interface language are recorded separately; word-for-word translation is not used to replace localization judgments.

Non-negotiable Judgments

The plot must be converted into player verbs, choices, and world feedback, rather than chapter-by-chapter reproduction.
The
```
experienceProfile
```
(
```
system-led
```
/
```
narrative-led
```
/
```
hybrid
```
) is drafted in the brief, confirmed in the concept stage, and then runs through design, art, build, and QA; it only changes the expression of criteria, not lowering completion requirements.
Player choices must have causal and settlement rights, and cannot disguise agency with cards, turns, or resource bars.
Concepts, experience/level design, and art direction each have their own approval boundaries; the build stage can only implement, not secretly reselect directions.
Verification slices must be fully executed in the actual runtime environment; the scope follows the brief, and does not default to expanding into a full-length game.
Completion is based on evidence of operation, visuals, real input, results, and restart; AI cannot objectively prove fun, long-term balance, or commercial value.

The current candidate is reported to have passed the minimum QA only after all six mandatory checks PASS.

NOT_RUN

can honestly end the current execution, but cannot satisfy the completion declaration;

qa/verification.json

is the only machine fact source.