## 18 — Programmable PGs and NPC mode

**Decision: keep as a user-requested major feature.** Programming one's PG is an important part of MUD play and should remain possible and actively encouraged. A player should be able to write behavior in Lua or another language, then turn on an optional **NPC mode** in which that PG acts under the player's program. The PG remains the same owned character with the same world state, identity, and ordinary game rules.

### Ways to program

- Preserve the ability to use programmable Telnet clients and external scripts. Give other languages a documented, authenticated event-and-command interface so players are not locked into one runtime.
- Offer Lua as a first-class scripting route, with an accessible web editor, examples, script versions, logs, and a way to test behavior before activating it. The exact runtime and hosting model remain to choose.
- Expose permitted observations and events such as the PG's visible room, messages, combat state, inventory, and timers. A script submits ordinary PG commands; the engine decides whether they succeed.
- Provide examples, documentation, and a place in the community forum for players to share techniques or scripts if they choose. A shared script never gains access to another owner's PG or credentials.

### NPC mode

The owner explicitly turns NPC mode on for a chosen PG, selects the program, and can pause it or take manual control at once. The mode should show whether the PG is being controlled manually or by a script. It should support a defined way to keep acting when the owner disconnects, if the owner has enabled that behavior; exact offline-presence and progression rules remain to design.

Scripted actions use the same movement, combat, speech, timing, visibility, resource, and permission checks as manually entered commands. Scripts cannot acquire staff powers through the account's other PGs. Script-generated speech follows the same language preferences and channel-aware moderation as manual speech. If a script stops, errors, or reaches a configured limit, the PG remains recoverable and the owner can inspect what happened.

Player-authored PG programs and NPC mode are distinct from the administrator-configured AI NPCs in the migration plan. AI assistance could help a player draft a script later, but it does not replace the player's ability to program their PG directly.

### Decisions and open design

- Keep: **Lua and other language routes for programming a PG, including programmable external clients**.
- Keep: **optional NPC mode, explicit owner activation, and immediate manual takeover**.
- Keep: **the same PG identity, game rules, language behavior, and moderation in manual and scripted modes**.
- Still to choose: **script hosting, event API, offline residency and rewards, execution limits, and how shared scripts are reviewed or installed**.