This is the repository for concepts and code related to Quest Driven Development, which is discussed here: https://blog.rendall.dev/posts/2021/3/15/quest-driven-development/
A minimal narrative builder and visualizer is here: https://rendall.github.io/quest-driven-development/tools/index.html
The narrative builder is on the left, and the visualizer is on the right. Build a narrative by inputting information about it into the builder.
The builder has an "Import:" Choose File button at the top, and an "Export:" Choose download location button at the bottom. Use these buttons to save and load previous narratives.
The visualizer shows a directed graph, visualizing the contents of the builder. Because the builder is empty except for a single 'started' state, the visualizer shows one node labeled 'started'
- The automatic layout should be better
- The layout should center
- The state names must be typed in completely.
- The Action target fields should be drop-downs or auto-complete
Fill in the empty Title field with a catchy name for your narrative.
Fill in the empty Description field, perhaps a detailed overview of the narrative plot, outlining an overall theme and all major decision points of the narrative and all major endings. Even if your narrative takes place in a visual medium like a platformer or a first person adventure, record in words your intent for this narrative.
Below the Description field is a State card.
A State is the answer to the questions "What are the consequences of the previous decision?" and "What decisions are available now?". These questions are only ever asked in response to a single previous decision by the player. Even deep into the narrative, after many decisions by the player, the current State will always have an answer to the question "What is happening now (as a result of the single decision that brought the player from the last State to this one)?" and "What choices does the player have now?"
The State field inside the State card is a unique identifier, and should be a word or short phrase that describes the State. While being descriptive is important, it's essential that it be unique. This identifier is how you and the builder will distinguish one state from another. As a suggestion, consider naming the state after the action that caused the transition to this state, and use the past tense (e.g. the PC decides to steal the crown, so the subsequent state might be named stole-crown; after deciding to jump ship, the subsequent state is jumped-ship)
The builder by default shows a started state. For now, keep this identifier, but you can change it any time.
The Summary field is intended to be a focused statement of what occurs at this State.
The Description is to be a more in-depth paragraph or two which includes everything relevant to the current state and also to the decisions that will cause the current state to exit (or transition).
Inside the State card, press the button labeled Add action.
There are two fields. The left describes the action and the right field is for the name of the state that this action transitions to. The left field might be steal the crown and the target state might then be stole-crown; or pull the lever and pulled-lever
Add an action description on the left and a state identifier on the right. If the state identifier is to an existing node, then an arrow points from the current state's node to the following state's node.
Note that the action field is for a description of the action, and not necessarily a game command. For instance, if the player needs to collect plate, a cup and a box of matches in order for the narrative to proceed to the next step, the action could be collect plate, cup and box of matches or get everything ready or gather materials. It's not necessary or desirable to capture that with a parallel chain of 3 states collected-cup, collected-matches, collected-plate and so forth.
In general, every state should be about a decision that the player must make. If there is only one action-transition from that state, it's likely that the state could be combined with its subsequent.
Also include actions that could happen without player choice or intervention, as long as it's specific to that state. If there is a trap that has a 50% chance of triggering while that state is current, then include this action as well even though it's not strictly a player decision (e.g. trigger trap)
In the QDD approach, a State will list every action that will move the narrative to another state, but it must not contain every possible action the player can take. It might occasionally be important narratively for an action to loop back to the same State (for example, to demonstrate futility), but the focus is on the narrative and not on modeling a response to every possible action. Definitely do not (yet) model actions that have only generic responses (e.g. "That does nothing.") or actions that cannot be done (e.g. "You do not have the axe!")
Cytoscape contributes massively to the application filesize. For the sake of growth-hacking, this will be ignored for now, as long as actual in-browser responsiveness and performance is not affected.
This repo follows the all contributors specification.
 dssjoblom 🤔 |
 Tomas Čerkasas 🤔 |
 Rendall 🤔 |
 kiwih 🤔 |