Summary
Character design for games treats characters as systems in motion, not as static biographies. A character is defined by what they want, what obstacles they face, and what choices they make under pressure. This framing — drawn from screenwriting (Sheldon) and game AI research — applies equally to player characters (designed for felt agency) and NPCs (designed for predictable meaning). Modern NPC design spans a spectrum from deterministic state machines to LLM-driven agents, each with different trade-offs for expressiveness, performance, and safety.
(Prof Charles, CRE341 Wk 4.2, see source-cre341-lectures)
Character as system — the Sheldon framework
Lee Sheldon’s game character design approach (drawn from screenwriting and drama) centres on four principles:
1. Character = system in motion
A character is defined by goals and constraints, not backstory trivia. Meaning emerges from decisions under pressure; gameplay is a continuous “character reveal”.
Design prompt: If you remove the dialogue and cutscenes, what remains that still signals who this character is?
Character “outputs” designers can control:
| Category | Examples |
|---|---|
| Mechanics | Movement verbs, risk profile, resource limits |
| Perception | Silhouette and animation, audio cues, UI affordances |
| Narrative | Choices and consequences, relationships, arc beats |
2. Goal-driven characters
Characters are defined by what they want, not by backstory trivia. Desire creates momentum.
A practical design format:
“In this situation, I want _____ because _____.
So I will _____ even if _____.”
- Use goals expressible as verbs the player or NPC can perform
- Separate immediate goals (moment-to-moment) from long-term goals (arc)
- Make trade-offs legible: the player should be able to anticipate why
3. Conflict is the engine
Internal flaws and external obstacles are not decoration — they are the engine of play.
| Conflict type | Description |
|---|---|
| External | Obstacles, opposition, scarcity |
| Internal | Flaw, fear, value tension, competing goals |
| Systemic | Rules that force prioritisation between goals |
Common failure mode: interesting backstory + no pressure in play = flat character experience.
4. Mechanics are character expression
Abilities and constraints are “personality” in motion. Feedback (animation, timing, consequences) shapes perceived temperament. Consistency is key: the system teaches players what the character would do.
| Mechanic | Implied personality |
|---|---|
| Slow acceleration | Weight, caution |
| Tight parry window | Discipline |
| Limited ammo | Pragmatism |
| No-kill constraint | Ethics, restraint |
Character verbs technique: list the 8–12 verbs the player performs in a game. Ask: which are rewarded? Which are penalised? What values does the system imply?
Player character vs NPC design contracts
| Player character | NPC | |
|---|---|---|
| Core promise | Meaningful agency | Readable intentions |
| Embodiment | ”I am doing this" | "I am watching this” |
| Controls | Communicate temperament | Must be consistent and explainable |
| Player role | Interprets gaps as identity | Expects predictability |
| Performance pressure | Single agent | Potentially thousands of instances |
Design heuristic: Player character — prioritise felt agency. NPCs — prioritise predictable meaning.
Player character design
Agency
Agency is felt when actions are meaningful and their consequences are visible. Relevant factors:
- Proteus effect — avatar appearance and self-representation can shape player behaviour
- SDT — autonomy, competence, and relatedness all correlate with enjoyment and continued play (see self-determination-theory)
Design checks:
- Can players form intentions before acting (or are they guessing)?
- Does the game acknowledge choices promptly and clearly?
- Do failure states teach rather than merely punish?
- Do NPCs react in ways that reinforce the player’s identity?
Character arc
Avoid forcing a single transformation; instead build micro-arcs at session scale:
- Arc pressure comes from repeated choices with accumulating consequences
- Use constraints and incentives to nudge, not compel
- State → Pressure → Choice → Updated reputation/capabilities (repeat)
Research framing: interactive narrative repeatedly grapples with coherence vs agency — preserving story coherence while allowing player actions that can derail planned events. The design response: build arcs from system state and constraints, not scripted inevitability.
NPC design
NPC roles
NPC roles are structural “tests” of the player character:
| Role | What they test |
|---|---|
| Antagonist | The player’s core values and limits |
| Mentor | The player’s willingness to learn |
| Ally | The player’s willingness to trust |
| Foil | The player’s identity by contrast |
Readability beats realism: players should infer NPC goals quickly from pose, gaze, and behaviour.
Readability checklist
- Is intent telegraphed (pose, gaze, audio, UI)?
- Is action selection consistent with the NPC’s established “rules”?
- Can the player predict the next 1–2 seconds of NPC behaviour?
- Do reactions acknowledge player actions?
NPC AI architectures
Choosing an AI architecture is a design decision, not a technical one. Architectures are not mutually exclusive — they can be combined.
| Architecture | Characteristics | Best for |
|---|---|---|
| FSM / HFSM | Fast, explicit; brittle with many states | Simple NPCs, 3–5 behaviours |
| Behaviour Trees | Modular, reactive; tick-based; authoring tool support | Many NPCs sharing behaviour; interrupt-heavy |
| GOAP | Plans from action preconditions/effects; emergent tactics | Complex multi-step goals; tactical surprise |
| Utility AI | Continuous action scoring; smooth blending | Adaptation, stylistic variety, no hard transitions |
| Social simulation | Models norms, roles, relationships; rule-based authoring | Social gameplay as core mechanic |
| LLM-driven | Natural language + memory; high expressiveness | Dialogue, emergent conversation; requires safety guardrails |
See game-ai-agent-design for detailed implementation of FSM/BT/GOAP.
For CRE341 specifically, the clearest canonical route is: FSM prerequisite first, then behaviour-trees as the main architecture, then utility-ai, then goal-oriented-action-planning, with HTN via squad-ai-patterns as the advanced production case. player-modelling still matters, but it belongs more on the adaptation and experience-management side than in the core NPC-control spine. See overview-cre341-agent-ai-route.
Utility AI
Utility AI scores all available actions each tick and selects the highest-scoring one. Each action’s utility is computed from current world features (health, distance, resource levels, etc.):
utility(Heal) = curve(1 - health / maxHealth)
utility(Chase) = curve(distance / maxDistance)
// select argmax over all utilities
Advantages over BTs/GOAP:
- Smooth adaptation with no hard state transitions
- Scales naturally to many simultaneous competing behaviours
- Good for NPCs that should “feel” rather than “decide”
Development tip: log the top-N utility values per tick. Utility systems look random without instrumentation — storing feature values and scores enables replayable debugging and tuning.
Utility AI is commonly combined with BTs or GOAP: utility selects goals; BT or GOAP handles execution.
Emotion and appraisal models
Emotional models serve as decision-weighting signals, not just animation triggers. The OCC (Ortony-Clore-Collins) model maps events to emotion types and intensities.
Appraisal loop:
Event → Appraise → Emotion state → Action bias → Expression
Example: if fear > threshold:
- Increase
utility(FindCover) - Decrease
utility(Chase) - Switch dialogue tone to fearful
- Widen personal space radius
Keep it small: emotions are most useful when they modulate existing decision logic rather than replace it.
Social simulation
Social simulation models represent social norms, roles, and relationship state as rules — authoring reusable rule sets rather than enumerating individual scenes.
Research examples:
- Comme il Faut (CiF) — authoring social knowledge for interactive stories
- Prom Week — “social physics” as core gameplay; social actions have preconditions and effects like GOAP
- Versu — simulationist interactive drama using social practice rules
Player modelling
Player models build inferences about the player from telemetry (what they do, not what they say), then feed those inferences back into the game to adapt difficulty, pacing, hints, and NPC responsiveness.
Pipeline: Telemetry → Features → Model → Adaptation → Evaluation
Common modelling approaches:
- Micro-behaviours — specific action patterns (does the player use cover?)
- Tactics — short-term patterns (is the player aggressive or cautious?)
- Strategies — long-term plans (is the player rushing or exploring?)
- Player profiling — type, preferences, skill level
Caution: beware “creepy” adaptation and unstable inferences. Adaptation that feels manipulative or unfair damages trust. Test with diverse play styles.
Experience management (adaptive narrative)
Experience management systems monitor player state and world state, then select narrative interventions to guide the player toward an intended experience while preserving their agency.
Interventions available:
- Spawn or withhold NPCs and events
- Re-target NPC goals
- Reveal information
- Adjust difficulty
- Reframe consequences
Why this matters for characters: NPCs can be “directed” to create pressure or relief at the right moment. Character arcs can be expressed as state changes and goal re-prioritisation rather than scripted scenes. Interventions should always be explainable in-world — if the player notices the system steering them, trust breaks.
LLM-driven characters
Large language models for NPCs lower the authoring cost of dialogue and enable novel conversational responses, but require careful architecture to remain coherent over time and safe for players.
Key risks: hallucination, role drift, safety violations, latency/cost, difficulty of evaluation.
Reference architecture:
Perception
→ Memory store
→ Retrieval (relevant memories + world state)
→ Plan (intended action/utterance)
→ Act (tools: dialogue, movement, game state changes)
Guardrails:
system prompts + content filters + world-state validation
Pragmatic implementation pattern:
Use the LLM for intent and language, not for authority.
Validate outputs against game state; route to deterministic actions; provide fallbacks.
See also game-ai-agent-design for the Unity + LLM interactive storytelling architecture.
Safety and ethics checklist for LLM NPCs:
- Constrain — world-state grounding + limited tool calls (no arbitrary actions)
- Filter — input/output moderation and policy constraints
- Monitor — logs, incident handling, and rollback capability
- Test — adversarial prompts and regression suites
- Representation — test across demographics and play styles for bias
- Privacy — respect player privacy in logging and behaviour modelling
Production pipeline
Making character systems shippable:
| Stage | Activity |
|---|---|
| 1 | Character spec — goals, values, character verbs |
| 2 | Behaviour spec — rules, architecture choice (BT/GOAP/utility) |
| 3 | Implementation + instrumentation (logging, debug views) |
| 4 | Content authoring — dialogue, barks, reactions |
| 5 | Playtest + telemetry |
| 6 | Tune + lock-down — regression tests, performance budgets |
Production constraints that dominate character AI work:
- CPU and memory budgets (thousands of agents simultaneously)
- Authoring and QA time
- Debuggability and determinism
- Localisation and accessibility
- Safety and content compliance (especially for generative NPCs)
Further reading
- Sheldon — Character Development and Storytelling for Games
- Orkin — Three States and a Plan (F.E.A.R., GOAP)
- Colledanchise & Ögren — Behaviour Trees in Robotics and AI
- Yannakakis & Togelius — Artificial Intelligence and Games
- Park et al. — Generative Agents (LLM memory architecture)
- Gallotta et al. — LLMs and games survey/roadmap
Related
- game-ai-agent-design — autonomous agents; BTs; GOAP; IIS architecture; Falstein’s design rules
- overview-cre341-agent-ai-route — recommended CRE341 route through agent architectures and adjacent AI topics
- ai-state-machine-pattern — OOP State Pattern; simpler alternative for 3–5 NPC behaviours
- narrative-design — character arcs; player story; ludonarrative harmony; branching narrative
- self-determination-theory — autonomy, competence, relatedness in player character design
- machine-learning-games — RL, player modelling, ML taxonomy
- generative-ai-game-dev — LLM tools; safety considerations for generative NPCs
- steering-behaviours — provides the locomotion layer beneath NPC action selection
- source-cre341-lectures