Living NPCs

There are two completely different AIs on this platform. One builds your game and you pay for it. The other runs inside the shipped game while someone plays it — a shopkeeper you can haggle with, an opponent that reasons about the board, a companion that talks like a person — and the player pays for that one.

This page is about the second.

Asking for one

Describe the character, not the plumbing:

The blacksmith should haggle. He knows what's in stock and how much gold I
have, he can refuse, and he can offer a trade at a price he chooses.

The agent builds it: what the character can perceive, what it is allowed to do, and the code that carries out its choices. You do not write prompts.

The one rule that makes it safe

An AI character is a virtual player, not a game master. It can say things, and it can choose from a list of actions the game gave it. It cannot change the game's state directly. Your game's own code executes the choice, and validates it exactly as it validates a real player's move.

So "give me a million gold" is not a vulnerability. The most an NPC can do is propose a trade; the trade code then checks whether it's legal and refuses. A fully jailbroken NPC can do no more damage than a player could — and players already can't cheat, because the game checks.

This is worth knowing because it tells you where to put rules: in the game, not in the character's instructions. If an NPC must never sell below cost, that's a check in the shop code, not a sentence in a persona.

Playbooks — tuning a character without code

Each AI character can have a playbook: a plain-language file describing who it is, how it speaks, what it wants, and how it uses the actions the game gave it. It lives in the Playbooks tool, one document per character, and you edit it like any other document.

That is the right place for personality work, because it is where iteration is free. Rewriting a persona costs nothing and takes effect on the next conversation; changing code costs a turn.

Open the blacksmith's playbook — he's too eager to agree, make him stubborn
about his best pieces.

The action vocabulary stays in code; the playbook owns who the character is.

Turning it on

Runtime AI is gated on the game declaring it, the way a phone app has to declare that it uses the microphone. Until you switch it on in Game Settings, AI calls from the game are refused — including in your own testing, on purpose, so you find out rather than your players.

The agent will tell you to do this when it builds an AI character. It is one toggle.

What your players see

An AI game costs the player credits, so the platform is explicit about it rather than surprising them:

• They must be signed in. An anonymous visitor gets a sign-in screen instead of the game — before the game loads, not mid-conversation.
• They acknowledge the cost once per game. A notice explains that this game uses AI and spends their credits. After they accept, they don't see it again for that game.
• Spend shows up in their Credit Usage under an AI Play label, attributed to your game.

Design around that. A game that needs an LLM for its core loop is asking every player for an account and a balance; one that uses it for optional flavour is not. Both are legitimate — just decide which you're building.

Limits worth designing for

Getting good answers out of it

The default model is fast and cheap, which is right for chatter and wrong for deduction. Two levers, both per call, both things you can just ask for:

The Werewolf NPCs are too scattered — make them more consistent and use a
stronger model for their reasoning.

• Lower the randomness for strategy games. This is the bigger lever and it's free.
• Opt into a stronger model for characters that genuinely have to reason, accepting more cost and latency per turn.

The third lever isn't a setting: give the character a sharper, more structured view of the world. Most "the AI is dumb" problems are the AI being told too little.

Next steps