Start with the action
The concept method starts with the player’s role and recurring job. Natural language is not a default feature; a chat box need not replace a complete set of actions.
An original courier story offers two designs. In one, the player holds a letter and chooses “Deliver to South Gate,” “Hold” or “Return.” With object, route and effects fixed, buttons are sufficient. In the other, a depot dispatcher assigns a courier, recipient, time, stop condition and disclosure. Combining those choices may justify free expression.
Either can support a strong story. Choose from the job, not the amount of dialogue or the presence of a language model.
Compare one task
| Plan | Buttons | Text |
|---|---|---|
| Deliver this letter to the set gate | One clear action | Rewording adds no play |
| Assign Alan after the guard change | Actor and time choices | Keep expression only if combining them matters |
| Return if the gate closes; do not pass it to the aide | A condition menu may suffice | Complex plans need a readable adopted meaning |
Menus may be clearer when combinations are few and costs explicit. Keep wording differences when arranging or negotiating is part of the role’s appeal.
“Handle it soon” cannot authorize arbitrary spending or disclosure. Ask about missing terms. If expression adds no value beyond existing actions, record signature_command as N/A.
Valid input still meets resistance
In the paper design, the dispatcher says: “After the guard change, have Alan deliver this letter to the gatekeeper. Return if the gate is closed; show the contents only to the recipient.” Display the adopted plan before the world responds.
Alan may be absent, the recipient may refuse or an earlier job may occupy the time. Grounded resistance cannot become a model’s invented success. Partial execution must say what happened, who holds the letter and who learned its contents.
World design determines supported plans, costs, rights and disclosure effects. A concept proposes candidates and risks; it is not a working parser. See the separate free-input guide for validation and state commits.
Test the important difference
Prepare button and free-text versions of the same small task under the same world conditions. Ask participants to make a consequential plan. Observe whether they understand actions, anticipate costs and identify which decision caused the result.
This is an unrun comparison plan. If every input produces the same result, repair the gameplay. If valuable expression is often misread, bound intents, confirm the adopted plan or use a menu that combines choices. More NPC chat will not fix the decision.
Keep repeatable actions with distinct consequences. Input should help the player decide rather than merely type.
FAQ
Do buttons make a text game less intelligent?
No. Clear choices, meaningful costs and remembered consequences matter more. Typing toward the same outcome adds little interaction.
Do it with the skill
Use $game-concept with the existing SOURCE_BIBLE and PRODUCT_BRIEF to compare buttons and free text: role, recurring job, expressive value and world resistance. Use N/A for signature_command when unnecessary. Do not implement a parser or claim test results.
Read the method: Role, input and bounded intents