How to Design an AI Bot Game With Clear Rules Memory and Player Choice
To design a playable AI bot game, define a small repeatable loop, store game state outside the conversation, and give each player action a clear consequence. Let the bot interpret requests and describe events; let explicit rules determine costs, progress, and endings. This guide is for game makers building a text-based game with an AI character or narrator. The task is to create one short, testable session in which players understand their options, see their decisions matter, and reach a valid ending. The delivery game below is an illustrative design, not a tested product or reported case study.
Start with a core loop you can play without AI
Write the loop in one sentence: Show the situation → accept an action → check the rules → update state → show the consequence and next options. Every turn should complete that loop or explain why it cannot proceed.
Before writing a personality prompt, define the objective, available actions, action costs, and ending conditions. You should be able to run the game with index cards or a spreadsheet. This makes it possible to inspect the mechanics before generated dialogue adds variation.
Consider a small game called *Festival Parcel*. The player has five time units to deliver a parcel. They can choose a direct route or a garden route and optionally collect a decorative ribbon before leaving. A bot plays the festival courier who explains routes and comments on the delivery.
The proposed rules are deliberately compact:
Show these rules before the first choice. Explain that delivery actions finish the session, so players must collect the ribbon beforehand. A delivery that spends the final time unit still succeeds because the success check comes first.
This prototype has a complete beginning, decision space, and ending. Additional characters or locations should earn their place by adding useful decisions to that loop.
Make explicit state the authority for outcomes
Treat state as the game's record of what is true. Conversation text can explain that record, but it should not silently change it.
Robert Nystrom’s State chapter in *Game Programming Patterns* (https://gameprogrammingpatterns.com/state.html) describes finite state machines through states, inputs, and permitted transitions. It also demonstrates how loosely combined Boolean flags can produce invalid combinations. Apply that principle to your game’s lifecycle: use one session status, such as active, delivered, or missed, with defined transitions.
For the delivery prototype, a small state specification is enough:
Derive the garden postcard from the selected route instead of storing a second value that could contradict it. Likewise, calculate currently available actions from state and rules.
Use a fixed processing order: interpret the request, validate its action and parameters, calculate the result, commit the state change, then narrate it. Give the narrator the committed outcome and permitted next actions. It should not invent a second calculation.
For example, after collecting the ribbon, the authoritative result is: four time units remain, the ribbon is collected, and both routes are affordable. The bot can describe the ribbon’s color, provided that color has no mechanical effect. It cannot add an unannounced time cost or grant a second ribbon.
You can prototype these conditions with an existing narrative tool. Inkle’s official interactive-fiction tutorial (https://www.inklestudios.com/ink/web-tutorial/) explains conditional choices, tracking previously visited content, variables, and explicit endings. Those features offer a useful foundation for testing the authored game before adding AI narration.
Give players choices they can understand and influence
For this design, judge agency by whether the player can anticipate a meaningful difference and then observe it in the result. Several differently worded buttons leading to an identical outcome do little to test that.
In *Festival Parcel*, the route decision supports different player preferences:
These are illustrative calculations from the stated rules. They provide a simple decision aid: choose direct delivery to finish earlier, collect the ribbon for decoration, or take the garden route for the postcard. Remaining time is an ending detail here; it does not secretly award points.
If the game later rewards a particular outcome, disclose that scoring before the decision. Otherwise, players cannot evaluate the tradeoff you intended.
Support free text alongside visible actions. “Let’s take the scenic way” can map to garden delivery. “Make it special” is ambiguous: it might mean collecting the ribbon, taking the garden route, or both. Ask a short clarification without spending time.
For the first prototype, accept one gameplay action per message. If the player requests a sequence, present its steps and ask them to choose the first action. This avoids partially executing a plan whose later steps turn out to be unavailable.
Keep unsupported requests informative. If the player asks to fly, explain that the available routes are direct and garden, with their costs. Free text can expand expression while the action system maintains a predictable set of capabilities.
Define what the bot remembers and what it can know
Separate memory into three layers, each with a different purpose.
Authoritative session state stores resources, progress, selected routes, and endings. It persists across a save and reload and changes only through validated actions.
A session event log records committed actions and their consequences. An entry might say that action 2 collected the ribbon and reduced time from five to four. This supports debugging and accurate recaps. Keep action identifiers so a repeated request cannot apply the same event twice.
Narrative context contains recent dialogue and a compact recap used to maintain tone and continuity. It can be shortened without deleting the actual game state.
Anthropic’s guide to effective context engineering (https://www.anthropic.com/engineering/effective-context-engineering-for-ai-agents) discusses both summarizing conversation history and keeping persistent notes outside the context window. It also warns that aggressive summarization can lose important details. The design implication here is to keep exact mechanical facts in structured storage and use summaries for conversational continuity.
Set knowledge boundaries as well as storage boundaries. A character should receive only the facts it is allowed to know. If a later version includes a hidden route, keep it out of that character’s context until its discovery condition is met. State available to the game engine need not all be available to the narrator.
For this small game, retain progress within the saved session and clear it when starting a new run. Avoid inferring enduring player preferences from one route choice. If you add a saved preference, such as shorter descriptions, make it explicit and editable.
Test memory with a concrete sequence: collect the ribbon, save, reload, ask for status, and select garden delivery. The ribbon must remain collected, four time units must remain before delivery, and the final time must be zero.
Design separate responses for game failure and system failure
A missed objective is part of the game. A failed generation request is an implementation problem. Give them different consequences.
For game failure, name the rule that ended the run. After three waits, only two time units remain, so neither delivery route is affordable. End immediately with a clear explanation and a restart option instead of leaving the player in an unwinnable active session.
For implementation failures, define recovery behavior before adding elaborate narration:
Do not silently replace an unreadable save with a new game. That hides lost progress and makes the next response misleading.
Build a plain result message for every action: what happened, what changed, and what is available next. The bot’s expressive narration can accompany this result. During a timeout or contradictory response, the plain message still lets the player continue.
Finish endings with an accurate recap. Mention the ribbon only if collected and the postcard only for the garden route. Generated prose should preserve the distinctions the player spent the session choosing.
Playtest the rules, then the bot’s interpretation
First test the game with fixed text. Cover each action, ending, and boundary condition. Then add the bot and repeat those tests using varied wording. This separates a broken rule from a misunderstood request.
Invite representative players to complete a delivery without coaching. Ask them to explain what they expect before choosing and what they believe changed afterward. Nielsen Norman Group’s guide to thinking-aloud usability testing (https://www.nngroup.com/articles/thinking-aloud-the-1-usability-tool/) recommends representative participants and tasks while letting participants do the talking; it also cautions that facilitator prompts can influence behavior.
Use observation alongside the action log. Record attempted actions, clarification requests, unexpected outcomes, and any mismatch between narration and committed state. Ask whether players understood the options separately from whether they enjoyed choosing among them.
Compact playtest checklist. Fix failures in the rules and state handling before expanding the world. If players understand the choices but find them uninteresting, change the tradeoffs. If they enjoy the decisions but cannot predict costs, improve the presentation. Expand the prototype when its existing choices remain understandable across different wording, saved sessions, and failure paths.