Choose a Scene Where the Player Can Act
Do not begin with “turn the whole book into a game.” Start with one scene that has a concrete goal, an obstacle, and an observable result. Listening to a character explain the setting or rereading the original dialogue usually does not create interaction by itself.
Answer four questions when choosing a scene:
- Where does it begin and end? Mark a chapter, scene, or event boundary.
- What does the protagonist want now? Write a near-term goal whose completion can be judged.
- What creates resistance? Choose a constraint, character agenda, or time pressure that forces a decision.
- Where can the player intervene? Include an action that changes a visible later fact; do not make the player merely click through the original character’s decision.
Shape one scene first. Use a playtest to decide whether it needs to grow into a larger branching sequence.
Separate Source Facts from Adaptation Choices
Split the adaptation brief into two lists: source facts the scene must not silently rewrite, and design choices this adaptation may change. You can compress events, but do not erase a character’s goal, relationship change, or key decision without a reason. Label a branch not defined by the source as a new design choice, then check it against the established setting.
Copyable single-scene brief
- Source boundary: Chapter ___ / Scene ___; use only the material I provide.
- Facts to preserve: character goals, established events, world rules, and key relationships.
- Player identity: Who does the player control, and what can this person know?
- Scene goal: What does the player want to accomplish here?
- Obstacle and evidence: What creates resistance, and what clues can the player observe?
- Available actions: What can the player do? Which details are source facts and which are new design?
- Downstream consequence: Which relationship, stance, testimony, object, or public fact changes after a choice?
- Scene exit: At what observable result does this scene end?
This brief asks the model to distinguish source material from proposals. A character’s speech, actions, and knowledge must fit the scene and the source facts; putting an author-only secret directly into dialogue breaks the information boundary.
This single-scene brief is an editorial work card, not the complete SOURCE_BIBLE.md or GAME_DESIGN.md. The production workflow also records source version, coverage, and fact boundaries. Check character actions, world facts, and player-visible information separately. A model can draft proposals; outcomes absent from the supplied source still need an explicit adaptation choice.
Original Example: An Island Weather Station Before a Storm
This original fictional paper exercise is neither real weather or ferry advice nor a model output, running game, or playtest. Its departure-decision window ends at 22:00 as a story rule. At 21:54, an island weather-station assistant receives an intermittent automatic tide alert. Walking to the outdoor gauge, observing it, and returning takes four minutes; one call and acknowledgment take about a minute. The exercise’s gauge has a black mark; a visual observation records the water’s position against it at that moment. It does not establish the alert’s cause, the later trend, or a storm’s landfall.
| Brief item | Scene design |
|---|---|
| Source boundary | An original station exercise; both routes are proposed adaptation choices, not events already established in a source manuscript. |
| Facts to preserve | The automatic alert’s cause is unknown; the 22:00 window is fixed; outdoor observation takes time; the assistant observes and reports but cannot decide ferry operations. |
| Obstacle and evidence | The intermittent alert supports an unverified notice. The gauge supplies one current observation while leaving less time for communication afterward. |
| Player and goal | The player controls the duty assistant, aiming to deliver useful information to the harbor office before the window closes, without directly commanding the ferry. |
| Available design | Observe first, then report; or report the unverified alert first. This scene designs one communication; later verification is an action in another scene. |
| Visible consequence | Each route below specifies content, an actual reply, and the record carried forward. Dialing alone does not establish delivery. |
| Scene exit | Receive an explicit acknowledgment. An unanswered call or missed window needs its own undelivered or missed state instead of reusing successful dialogue. |
Walk through the routes separately
| Route | Paper action and result |
|---|---|
| A: observe first | Leave at 21:54, see the water above the exercise’s established black gauge mark, and record the observation time; return at 21:58. Call and report the observation and unresolved alert cause. At 21:59 the harbor operator repeats the observation, logs it, and says it will go to the duty dispatcher for judgment. The assistant has a more specific observation receipt, without knowledge of the dispatch decision. |
| B: notify first | Call at 21:54, stating that the automatic alert is intermittent and has not been checked at the gauge. At 21:55 the operator repeats and logs it as an unverified notice, replying that the duty dispatcher will be contacted pending verification. This route has no gauge observation and cannot borrow A’s reading. Earlier acknowledgment does not establish canceled sailings, a changed ferry route, or a storm’s arrival. |
The choice changes information, arrival time, and the reply actually received. A obtains one field observation, so it is inaccurate to say that nothing was confirmed; the automatic alert’s cause and future tide remain unresolved. B obtains an acknowledgment of an unverified notice without A’s reading. Later scenes read the selected record. A dispatch decision requires its own actual response rather than a narrator declaring it complete.
Ask for One Scene, Not an Entire Game
Provide the single-scene brief with a passage you own or are authorized to use, then ask for one draft. This original starter prompt can be adapted by replacing the bracketed fields:
Adapt the novel passage I provide into one text-adventure scene. First list the source facts to preserve and your proposed new design choices. Label unsupported additions as proposals, not established facts.
Player identity: [identity]; scene goal: [goal]; obstacle: [obstacle]; available clues: [clues]; scene boundary: [exit].
Offer two or three actions that fit the player’s identity. For each, state what the player can observe, what remains unknown, and which downstream state it might affect; label speculation as a proposal. Keep character goals, relationships, and knowledge within the supplied source. Do not choose for the player. Stop at the scene boundary and list unresolved design questions.
Read the source-fact list and branch proposal before accepting the draft, then add the passages that actually support them. Label or remove any new character action, world rule, or ending that the source does not justify.
A Scene Draft Is Not a Runnable Game
A branching scene in chat can help explore an adaptation. A paper prototype can check cause and effect along one path. A runnable game still needs input, state changes, feedback, and a way to restart. Do not treat model-written “the player succeeds” as an implemented or playtested result.
Before expanding, walk through one representative path: What did the player do? What changed? Who learned something as a result? Which consequences appear in the next scene? Then inspect an unchosen path to confirm that an event that did not happen is not treated as if it did. A text draft cannot validate real-time controls, spatial judgment, or physical feedback; match the prototype to the risk you need to test.
In DSH’s NovelToGame workflow, /novel-to-game quick starts an adaptation from a novel file you provide; a complete build continues through design and build stages. If you only want to discuss one scene, use the brief in an ordinary chat first and do not describe that draft as a finished product.
FAQ
Do I need to give the model my entire novel?
Not for a first scene. Provide the passage and brief needed to understand its goal, mark the chapter boundary, and distinguish facts to preserve from open design choices. Complete one interactive scene before deciding what further context the next step needs.
Can one DeepSeek prompt create a playable game by itself?
A prompt can help shape an adaptation brief or draft an interactive scene. A runnable game still needs design, implementation, and actual verification. Track a scene draft, a paper path check, and a running build as separate stages rather than treating a concept as a finished result.
Will player choices break the source story?
First distinguish facts that must remain from design choices the adaptation may change. Player choices can alter a route, a cost, or another character’s response. If a key decision or ending changes, label it as a new branch and check it against character goals, rules, and knowledge boundaries.
Do it with the skill
In DSH, /novel-to-game quick can start from a novel file you own or are authorized to use and move from an adaptation brief through concept, world design, build, and QA. To discuss direction only, start with one scene’s source boundary and brief rather than asking a model to write an entire game.
Read the method: Source scope, observation evidence, and adaptation boundaries · Choices, character knowledge, and branch consequences · Player actions and actual world responses