Exercises: AI Design

The exercises below move from observation to design to implementation to critique. Do them in order if you can. The implementation exercise assumes you have completed the progressive project up through Chapter 26 (combat system) and have an enemy entity in your Godot prototype. The analysis exercises require nothing but a controller and attention.

A note on rigor: it is tempting, with AI observation exercises, to stop at "the enemy chased me." Push harder. Go frame by frame. Record footage if you can. The difference between a beginner's AI analysis and an experienced designer's is granularity — the beginner says "it chased me," the designer says "it has three perception states, and the transition from state two to state three takes roughly 0.8 seconds, and the animation for the transition is a shoulder raise with a head snap."

🟢 Analysis: Enemy AI Dissection

Pick three games, one from each category below, and do an in-depth analysis of the enemy AI.

Category A — Stealth AI: Metal Gear Solid V, Dishonored 2, Hitman 3, or Splinter Cell Chaos Theory. Category B — Shooter AI: F.E.A.R., Halo: Combat Evolved, Half-Life 2, or DOOM (2016). Category C — Action AI: Sekiro, Resident Evil 4, Arkham Asylum, or Hollow Knight.

For each game, play for at least one hour specifically observing the AI (not progressing normally). Take notes on:

  1. State inventory. How many distinct behaviors can you identify? List them by name: patrol, idle, alert, search, chase, attack, flee, call-for-help, etc. Time how long each lasts on average.
  2. Transition triggers. What causes each transition? Is it line of sight, sound, damage, time, proximity, or a mix? Test by deliberately provoking transitions (make a sound, peek and hide, fire and retreat).
  3. Perception visibility. How does the game communicate the AI's perception to you? Exclamation marks, light meters, head turns, barks? What happens if you strip these cues (if possible) — does the AI still feel fair?
  4. Legibility score. On a 1-5 scale, how easy is it to predict what the enemy will do next? A high score means you can read the AI's intent from body language and sound; a low score means the AI's state is invisible.
  5. One "oh you bastard" moment. Describe a specific moment the AI made you say this out loud (or the equivalent). What happened? Which behaviors combined to produce the feeling? Would the moment have worked without the bark, animation, or telegraph that accompanied it?

Write a 600-800 word comparative analysis across the three games, organized around a claim: which game has the best enemy AI, and why? Your answer should not be "the most complex one." Support your claim with specific observations.

Deliverable: A PDF or markdown document, 600-800 words, with at least one clip or screenshot per game illustrating a specific behavior.

🟢 Analysis: The Companion Problem

Pick one game with a companion AI that you consider successful (suggestions: BioShock Infinite, The Last of Us Part II, Bastion, Resident Evil 4 Remake, Portal 2 co-op bots in single-player equivalents). Pick one that you consider a failure (suggestions: Resident Evil 4 2005 original Ashley sections, any Sonic friend level, Dead Rising's survivors, the Fable dog sometimes).

For each:

  • Describe the companion's design goals (what is the companion for?).
  • List the design decisions that make the companion work or fail. Be specific: "Elizabeth has no collision with the player" is specific; "Elizabeth is well designed" is not.
  • Identify the single biggest design choice that tipped the companion from good to bad or vice versa.

Write a 400-600 word paired analysis.

Deliverable: A 400-600 word document. Bonus: sketch a 10-item design rubric for companion AI derived from your observations.

🟡 Design: Flying Enemy FSM

Design (on paper or in a diagramming tool — Draw.io, Excalidraw, Miro, Lucidchart, or a hand-drawn whiteboard photo) the finite state machine for a flying enemy in your action-adventure game.

Constraints:

  • The enemy flies in a 2D sidescroller space.
  • It cannot enter confined areas (you define what "confined" means — perhaps ceiling height below a threshold).
  • It has three attack modes: swoop attack (dive at the player), stationary ranged attack (hover and shoot), and retreat (move to ceiling).
  • It has a low-health panic state: erratic flight, attempts to flee the screen.

For your FSM:

  1. List every state with a one-sentence description.
  2. List every transition with the trigger condition.
  3. Identify any state that might experience the "state explosion" problem — where the number of transitions from/to it is unmanageable. Propose a hierarchical decomposition.
  4. Identify any transitions that are event-driven (not time-or-condition-polled in the update loop). Mark them clearly.
  5. Identify the telegraph for each state — what visible/audible cue communicates the state to the player?

Deliverable: A state diagram (PNG/PDF/SVG) plus a 1-page annotation document.

🟡 Design: Stealth Enemy Behavior Tree

Design the behavior tree (not FSM) for a stealth game guard. This is a game where the player sneaks; the guard is not supposed to catch them, but is supposed to feel threatening.

Requirements:

  • Three alert levels: Unaware, Suspicious, Alerted.
  • Each alert level has distinct behavior: Unaware = patrol, Suspicious = investigate a sound or sight, Alerted = engage/call for backup.
  • Guards must coordinate loosely: an Alerted guard should cause nearby Unaware guards to become Suspicious.
  • When a guard loses sight of the player, they go to "search" for a set duration before downgrading alert level.

Draw the behavior tree as a node diagram (selectors, sequences, decorators, leaves). Label every leaf with the concrete action it represents. Identify at least one subtree that could be reused across guard types.

Deliverable: A behavior tree diagram plus a 1-page annotation. Bonus: write pseudocode for one of your leaf actions.

🟡 Design: Panicking Civilian

Design the behavior — FSM, BT, or utility; you pick and justify — for a civilian NPC caught in an emergency. Imagine a city-building game where a disaster strikes; civilians must react.

Requirements:

  • Civilians have a daily routine (home → work → shop → home).
  • When a disaster occurs (fire, earthquake, monster attack), they must transition to panic behavior.
  • Panic behavior includes: running away from the disaster, seeking safe zones, avoiding other panicking civilians (crowd dynamics), and freezing if cornered.
  • After the disaster passes, they must resume routine behavior, but with emotional residue — reduced walking speed, more easily startled for a period.

Your design should:

  1. Justify your architecture choice (FSM/BT/utility). What properties of the design make your choice the right one?
  2. Specify how the "resume daily routine after panic" transition works. How does the civilian know the disaster is over? How do they handle the case where their home was destroyed?
  3. Specify the interaction between civilians (cohesion, separation — from Chapter 27's steering section).

Deliverable: A 1-2 page design document with diagrams.

🔴 Implementation: Extend EnemyFSM With Hearing

Take the EnemyFSM.gd script from Chapter 27 and extend it with a working hearing system. The goal: the enemy should respond to sounds the player makes — footsteps, attacks, breaking objects — even when they cannot see the player.

Tasks:

  1. Create a SoundEvent signal bus — a Godot autoload singleton — that any object can use to broadcast a sound event: position, loudness, type ("footstep" / "attack" / "object_break").
  2. Modify PerceptionSystem.gd to subscribe to the bus and call hear_sound when a sound is broadcast. Use the hearing-radius logic from the chapter.
  3. In EnemyFSM.gd, implement heard_sound(position: Vector2, type: String). The response depends on type: - Footstep → transition to Alert, set last-known-position, but do not commit (the enemy should investigate, not chase). - Attack → transition directly to Chase, since the player has clearly revealed themselves. - Object break → transition to Alert, but with a longer investigation duration.
  4. Make the player's movement emit footstep sound events on a timer while walking. The timer interval should be shorter when the player is running and longer when sneaking (add a sneak action — Shift to walk slowly).
  5. Add a visual debug layer: when the enemy hears something, draw a brief circle at the heard position to show the designer what was detected.

Playtest and refine:

  • Does the enemy investigate the right places?
  • Can the player use sound as a distraction? (Throw a rock to lure the enemy away from a route.)
  • Does the sneak mechanic feel meaningful — can the player pass a guard by moving slowly?

Deliverable: Committed code plus a playtest log describing what you observed and what you changed in response. Include a 30-60 second video of the sneak-and-distract behavior working.

🔴 Implementation: The Last-Known-Position Cycle

Extend the FSM with a proper LKP (last-known-position) search behavior modeled on Metal Gear Solid's alert cycle:

  • Alert (first 2 seconds): enemy freezes, looks toward LKP, bark ("Who's there?").
  • Search (next 5-10 seconds): enemy pathfinds to LKP, wanders in expanding circle.
  • Caution (next 15 seconds): enemy returns to patrol but with elevated awareness — wider cone, faster reaction.
  • Normal: after caution expires, return to standard patrol.

Implement these as an HFSM: Alert, Search, Caution, and Normal are sub-states inside a "NonCombat" super-state. Chase, Attack, Retreat are sub-states of "Combat."

Deliverable: Updated code, plus a state-diagram illustration of your HFSM, plus a playtest describing whether the cycle feels like MGS or merely approximates it. If it doesn't feel right, what's missing?

🔴 Critical: The Moment AI Broke Immersion

Find a specific moment in any game — yours or someone else's, recent or old — where an AI decision broke your immersion. An enemy that saw you through a wall. An ally who stood in the doorway. A boss that reacted inhumanly to an input. A civilian who walked into fire.

Describe the moment in 300-500 words. Then answer:

  1. Was this a bug or a design choice?
  2. If a design choice, what was the designer trying to accomplish? What tradeoff did they make?
  3. What specific change to the AI would have avoided the immersion break without losing the design intent?
  4. Have you seen a game handle a similar situation better? What did it do differently?

Write this as if you were submitting it to a postmortem panel.

Deliverable: A 500-800 word critical essay.

🔴 Critical: Designing the Dishonesty

Revisit the chapter's section on cheating AI. Design a specific cheat — a deliberate, player-benefiting dishonest behavior — for your action-adventure game, and justify it.

Your proposal should:

  1. Describe the cheat concretely. "The enemy has wider aim spread on their first shot after spotting the player" is concrete. "The AI is easier" is not.
  2. Explain what experience the cheat produces. What does the player feel that they wouldn't have felt without the cheat?
  3. Predict the failure mode. If the cheat is set too strong or too weak, what goes wrong? How would you detect it in playtest?
  4. Identify the honesty line: would you tell the player about this cheat if they asked? Why or why not?

Deliverable: A 400-600 word design proposal. Bonus: implement one of your proposed cheats in your game and playtest with and without it to compare feel.

🟡 Design: Barks for an Existing Enemy

Take the enemy FSM from Chapter 27 (or the one you have implemented in your progressive project) and design the full bark set.

For each of the following state transitions or events, write three different barks the enemy might say (for variety, to avoid hearing the same line twice in close proximity):

  • Entering Alert (heard a sound, hasn't seen target yet). Example: "Huh?" / "What was that?" / "Is someone there?"
  • Confirmed sight of target (transitioning Alert → Chase). Example: "There! Intruder!"
  • Losing sight during chase (target ducked behind cover). Example: "Where'd they go?"
  • Taking damage from an unseen source. Example: "I'm hit!"
  • Reloading.
  • Throwing a grenade.
  • Calling for backup.
  • Reaching low health (entering Retreat). Example: "Fall back!"
  • Spotting a fallen ally. Example: "They got Davis!"
  • Returning to Idle after a search found nothing. Example: "Must've been the wind."

Then answer:

  1. How do the barks change by enemy type? Draft three barks for the same event ("taking damage") as spoken by a heavy armored enemy, a fragile mage-type enemy, and a feral beast enemy. The same information — "I'm hurt" — should feel distinct for each.
  2. How do barks handle co-presence? If two enemies hear the same player footstep, they shouldn't both say "Huh?" at the same time. Design a system for bark priority or cooldowns so only one enemy vocalizes any given event.
  3. How do barks handle silence? There are moments when the designer wants the enemy to be quiet (during sneak segments, when the player is hidden). What rules govern when barks are suppressed?

Deliverable: A 1-2 page bark design document for one enemy type in your progressive project. Include cooldowns, priority rules, and suppression conditions. Bonus: record rough placeholder VO yourself and drop the lines into your build.

🟡 Design: Perception-Cue Redesign

Pick a stealth game you have played. Screenshot (or mock up) its existing perception cues — the alert markers, bars, icons, or audio stings that tell the player about enemy awareness state.

Now redesign them. Propose a replacement cue system that communicates the same information differently. Constraints:

  1. Your cue system must not use floating HUD icons directly above enemies (the common genre default). You have to find another way.
  2. Your system must scale to at least four perception levels: Unaware, Suspicious, Alerted, Lost-Player-Needs-Search.
  3. Your system must work in both well-lit and dark environments.
  4. Your system must work for players with color-blindness (at least one non-color channel conveys each state).

Sketch the redesign with visual examples. Then discuss: what does your redesign gain over the original? What does it lose? Which is the better fit for the game, and why?

Deliverable: A 1-page visual proposal plus 400-600 words of justification.

🔴 Implementation: The Doorway Problem

Place four enemies in a room with a single narrow doorway. Make the player escape through the doorway. Four enemies will try to chase; they will all arrive at the doorway simultaneously; chaos will ensue.

Now fix it. Implement one or more of the strategies from the chapter:

  1. Reservation — a single claim flag on the doorway segment; only one agent may occupy at a time.
  2. Priority queue — the nearest or highest-priority agent goes first; others wait their turn with a brief "wait" state.
  3. Soft separation — agents see each other as soft obstacles and route around each other.
  4. Collision phasing — temporarily disable inter-agent collision when multiple agents are crowded at the same waypoint.

Implement at least two of the four approaches and playtest them side by side. Record a short clip of each. Note:

  • Which approach looks most natural?
  • Which is cheapest in CPU/code complexity?
  • Which produces the most visible failure modes?
  • Which approach would you ship, and why?

Deliverable: Two working implementations in your project, a comparison video, and a 400-500 word postmortem.

🔴 Implementation: Designated Leader for Squad AI

Your progressive project has one enemy type. Place four of them in a combat area.

Implement a designated-leader system:

  1. When a group of enemies is spawned together, one is marked as the leader.
  2. The leader runs a group-level decision-maker every ~0.5 seconds: "should we advance, hold, retreat, or flank?"
  3. Other enemies receive the leader's decision and follow it (with some individual variation — a follower might still duck when hit, but their strategic target is set by the leader).
  4. If the leader dies, the group picks a new leader from the survivors (by proximity, by seniority, or by a heuristic — you decide).
  5. Optionally: if the group has no leader, the followers panic — switch to an "uncoordinated" state with erratic behavior.

Playtest with and without the leader system. Is the combat noticeably more tactical with it? Does the "leader died, group panics" moment produce a readable beat for the player?

Deliverable: Working implementation plus a 300-500 word reflection on what changed qualitatively.

Reflection Prompts (for discussion or journaling)

  • Which AI architecture (FSM, BT, utility, GOAP) best matches your progressive project's enemy design, and why?
  • If you had to strip one of the following from your enemy AI — perception cues, barks, animation telegraphs, or the state machine itself — which would you cut to do the least damage? Why?
  • You are hired as AI lead on a game that currently has "cheating AI" (impossibly accurate enemies). The lead designer says this is intentional and good for the game's identity. You disagree. What is your professional path?
  • Pick a game whose AI you admire. In 50 words or fewer, identify the one thing that makes its AI feel alive. Not the architecture — the thing.
  • Compare F.E.A.R.'s flanking (emergent from a planner) and Halo's flanking (scripted in behavior trees). From a player perspective, could you tell the difference? What does your answer suggest about whether GOAP was "worth it"?
  • You are designing a pet companion — a dog that follows the player around in an open-world RPG. Would you model it closer to Elizabeth (never blocks, never dies, provides resources) or closer to Ashley (real collision, real risk)? Sketch your answer and your reasoning.

These prompts are for discussion, journaling, or prep for Chapter 33's ethics content.