Somewhere in a LucasArts filing cabinet in the spring of 1996, five people — a director, two designers, a programmer, and a concept artist — stapled together seventy-two pages of flowcharts, character bios, and puzzle write-ups, and put a joke on the cover: a Winston Churchill line about how a report's length defends it against ever being read. They were two and a half years from shipping. The game was called Grim Fandango, and the document was called, with LucasArts' usual lack of pretension, the Puzzle Document.

That document is the spine of this article. It's one of the few surviving internal design documents from the golden age of the point-and-click adventure, and it happens to be an unusually clean specimen of something the games industry has always done informally, and the software industry is only now trying to do formally: turn a creative vision into a dependency graph precise enough for other people — and, increasingly, other systems — to build from.

We're going to use it four ways: as a tour guide through the point-and-click genre, as a primary source for how Grim Fandango came together, as a case study run through Marc LeBlanc's MDA framework, and as an argument for what "spec-driven" AI development can learn from a 1996 puzzle chart. If you build games, write specs, or train models to understand virtual worlds, there's something here for you.

A Brief History of the Point-and-Click Genre

From parser to pointer

The point-and-click adventure descends from the text adventure — games like Colossal Cave Adventure (1976) and Zork, where you typed commands at a parser and the game described a world back in prose. Sierra's Mystery House (1980) bolted static illustrations onto that formula, and King's Quest (1984), commissioned by IBM to show off the graphical capabilities of the PCjr, went further: colour visuals, a scrolling world, an on-screen avatar you steered with the keyboard — even though the game was still parsed as text underneath. It laid down much of the genre's visual grammar without yet having the thing most people associate with it: a mouse.

That arrived the same year. Enchanted Scepters (1984) is usually credited as the first true point-and-click, and Deja Vu (1985), from ICOM Simulations, added the pieces that would define the genre for a decade: a verb list, a proper inventory, drag-and-drop interaction. But it was Lucasfilm Games' Maniac Mansion (1987) that popularized the format and gave it its name — and gave the studio a reusable engine to build the next fifteen years of adventures on: SCUMM, the Script Creation Utility for Maniac Mansion. SCUMM sat somewhere between a scripting language and an authoring tool, letting designers define rooms, actors, objects, dialogue, and verb logic without touching the underlying engine code — an early, unglamorous example of separating content from engine, a distinction that still organizes how games get built.

The golden-age toolbox

Between roughly 1987 and 1997, LucasArts and Sierra On-Line defined the genre's mechanics. Strip away the setting — pirates, wizards, bikers, secret agents — and nearly every game from this era is built from the same interlocking parts:

• A verb-based interaction model that got steadily more economical. Maniac Mansion gave you a wall of fifteen verbs at the bottom of the screen; by Full Throttle (1995) that had become a contextual pop-up, and by The Curse of Monkey Island (1997) it was a three-part "verb coin" — hand, eye, mouth — that inferred the action from context. A decade of iteration, one consistent instinct: get the interface out of the fiction's way.
• Inventory-based combinatorial puzzles. Collect objects; progress means finding which one (or combination) resolves a given obstacle — the rubber chicken with a pulley in the middle, to use the genre's most parodied example.
• Dialogue trees. Conversations chosen from a menu of lines, front-loading characterization and jokes without demanding typing skill.
• Environmental storytelling. A huge share of a point-and-click's writing lives in what happens when you simply look at things — background gags, world-building asides, red herrings.
• The "no death, no dead end" doctrine. In 1989, while designing the first Monkey Island, Ron Gilbert wrote an essay, "Why Adventure Games Suck and What We Can Do About It," arguing that games should never kill the player without warning, never let a player wander into an unwinnable state, and never gate progress behind arbitrary or "backwards" puzzles — solutions found before their problems. It became LucasArts doctrine for a decade.

Sierra took a rockier road on that last point — its games were notorious for sudden deaths and unwinnable states — and the split is a decent proxy for the genre's two schools of thought: LucasArts treated fairness as an obligation; Sierra, for a long time, treated peril as part of the fun.

Decline, and a stubborn afterlife

By the late 1990s the genre was being squeezed from two directions: 3D action games were eating the market, and CD-ROM-era adventures had gotten expensive to make relative to what they sold. Sierra's own attempt to modernize, King's Quest: Mask of Eternity (1998), underperformed badly, and by decade's end its founding studio had been shuttered. LucasArts shipped one further adventure, Escape from Monkey Island (2000), and then quietly left the genre it had defined.

It didn't die so much as go underground — kept alive by fan communities and freeware tools, then pulled back into the mainstream by two things: the 2007 App Store, which turned touchscreens into ready-made point-and-click controllers, and Telltale Games' The Walking Dead (2012), which paired the genre's dialogue-and-choice DNA with cinematic, time-pressured pacing and became a genuine hit. Since then the genre has splintered productively rather than consolidated:

That's the room Grim Fandango walks into: a genre with a settled toolbox, a hard-won ethic about fairness, and — as we're about to see — one studio in the mid-1990s trying to push all of it into three dimensions at once.

Grim Fandango: A Brief History

The pitch: noir meets Día de los Muertos

Grim Fandango was directed and written by Tim Schafer, who'd cut his teeth writing on The Secret of Monkey Island under Ron Gilbert before co-directing Day of the Tentacle with Dave Grossman and soloing Full Throttle. The idea came from two unrelated places colliding: Schafer owned an art book of Day of the Dead imagery and had studied Mexican folklore in college, and around the same time attended a local film noir festival. The result fused both traditions at once — the Aztec/Mexican concept of the afterlife as a four-year overland journey, populated entirely by calaca skeleton figures, rendered in the verbal register of a 1940s detective story. The explicit cinematic touchstones were The Maltese Falcon, Casablanca, and On the Waterfront — you can feel all three in the plot's shape: a disillusioned insider gets pulled into a conspiracy involving corrupt bosses and a woman who isn't quite what she first appears to be.

Building the world in 3D

Grim Fandango was LucasArts' first adventure to use real-time 3D character models over pre-rendered static backgrounds — the same broad technique Resident Evil was using for survival horror at almost exactly the same moment, arrived at from the opposite genre direction. The custom GrimE engine combined the 3D rendering code from the studio's Jedi Knight: Dark Forces II with hand-painted background art, letting a small team produce Art-Deco-Aztec environments far cheaper than modeling them fully in 3D.

That shift came with the most debated control scheme in adventure-game history. Because the camera cuts between fixed cinematic angles — borrowed wholesale from film grammar — Schafer chose tank controls: forward/back/turn inputs stay relative to the character, not the camera, so a hard cut to a new angle doesn't reverse what "forward" means. It's a mechanic chosen in direct service of an aesthetic goal (cinematic staging) at real cost to another one (comfort) — the original release shipped with no mouse support at all, a strange fact to sit with in an article about point-and-click design. That tension wasn't resolved until the 2015 remaster added a conventional cursor alongside the original scheme.

A three-year build, and the parts that didn't make it

Development tracked closely with the game's own four-year, four-act fiction. It was originally slated for the first half of 1998 but slipped to October 30th — deliberately timed to land the Friday before the real-world Day of the Dead. The delay came at a cost: the team had to cut several puzzles and characters to hit the date, including a planned climactic five-step confrontation with the final antagonist. Schafer later estimated the original scope needed another year or two to build in full. Hold that thought — the Puzzle Document still shows exactly where that cut happened.

Reception, and the commercial paradox

Grim Fandango landed to some of the most unreserved praise LucasArts ever received: GameSpot's PC Game of the Year, PC Gamer's Adventure Game of the Year, IGN's Best Adventure Game of the Year, and Adventure Game of the Year at the Interactive Achievement Awards, with a 94/100 on Metacritic. And it still underperformed — North American sales are estimated around 95,000 units by 2003, softened by brutal timing (the same holiday season as Half-Life, Metal Gear Solid, and Ocarina of Time). It eventually turned a small profit, but the executive read at the time was blunt: even a great adventure game wasn't scaling the way action games were. LucasArts shipped one more, Escape from Monkey Island, in 2000, then stopped. Schafer left that year to found Double Fine Productions, taking much of the team with him.

The story got a second act. After Disney shuttered LucasArts as a developer in 2013, Double Fine — with Sony's help — reacquired the license and released Grim Fandango Remastered in January 2015: improved models, a newly recorded orchestral score, and, at last, an actual point-and-click cursor.

Mechanics, Dynamics, Aesthetics: Reading Grim Fandango Through LeBlanc's Framework

To go one level deeper than "this game is well-crafted," it's worth running Grim Fandango through a real analytical tool rather than admiring its craft impressionistically. The standard instrument for this in game design theory is the MDA framework — Mechanics, Dynamics, Aesthetics — introduced by Robin Hunicke, Marc LeBlanc, and Robert Zubek in their 2004 white paper, "MDA: A Formal Approach to Game Design and Game Research," developed out of their Game Design and Tuning Workshop at the Game Developers Conference.

The paper's core move is to insist a game isn't one thing — it's three linked layers, and treating them separately lets you actually diagnose why something works:

Crucially, the paper argues these run in opposite directions for designer and player. A designer works mechanics → dynamics → aesthetics: write rules, hoping they produce satisfying run-time behavior, hoping that produces the intended feeling. A player — and a critic — experiences it backward, aesthetics first, mechanics last on inspection. Reading the Puzzle Document is, in effect, doing that reverse-engineering exercise with the designers' own notes in hand.

Mechanics

Grim Fandango's mechanical vocabulary is smaller and more disciplined than earlier LucasArts games. Gone is the verb list entirely — Manny has one context-sensitive interaction, and the interesting mechanical work happens through a small set of recurring tools rather than a large set of verbs. The clearest example is the scythe, reused across every act as a bone-hook, a lock-pick, a pry bar, a metal-detector-style sweep, and eventually a weapon — one object, repeatedly re-contextualized, rather than a growing pile of single-use items. The second core mechanic is the cross-referenced problem/solution puzzle unit discussed in Part IV: an obstacle stated in the world, resolved by combining an item, an environmental trigger, or a character's help in a specific sequence.

Dynamics

This is where the design document's puzzle-structure charts stop being production paperwork and start being a genuine dynamics specification. The recurring "linear vs. non-linear" annotation is the team explicitly designing for a pacing dynamic: strictly sequential chains create forward momentum, while parallel any-order clusters let a stuck player set one thread aside and make progress on another instead of freezing in front of a locked gate — a direct, load-bearing consequence of the "no dead end" philosophy from Part I. A second recurring dynamic is chain-reaction problem-solving: nearly every solution in the document sets up two or three environmental conditions that then resolve themselves once triggered — chemical-filled balloons meeting inside a pneumatic tube, a hydraulic rig destabilized while a demon still stands on it. The player isn't executing the punchline; they're setting up dominoes and watching them fall, which produces the genre's signature "aha" on a delay rather than on contact.

Aesthetics

Cross-referenced against the paper's eight-item vocabulary, Grim Fandango is legibly chasing a narrow cluster rather than trying to hit all eight at once:

That's a genuinely useful thing MDA gives you that "it's a good adventure game" doesn't: a specific, falsifiable claim about what the game is trying to make you feel, and therefore which mechanics were worth building.

The tank-controls decision is worth revisiting one last time through this lens, because it's the cleanest single illustration of that causal chain in the entire production: the aesthetic goal (Narrative, delivered with real cinematic staging) demanded a dynamic (camera cuts that don't disorient the player mid-scene), which required a specific mechanic (character-relative rather than camera-relative movement) — and that mechanic then produced a second, unintended dynamic (players fighting the controls) with its own aesthetic cost, frustration, at the expense of the very Narrative goal it was meant to protect. MDA doesn't just explain why decisions get made; run in reverse, it explains why some good decisions still don't land with everyone, because a single mechanic almost never maps to a single dynamic or a single aesthetic outcome.

The Game Design Document, and What This One Tells Us

What a GDD is for

A Game Design Document is, at bottom, a specification: a written artifact whose job is to get everyone on a team — designers, artists, programmers, writers, eventually voice actors and QA — building the same game. Formats vary wildly by studio, era, and scale, from one-page pitch decks to hundred-page bibles, but the recurring skeleton usually includes some mix of: a high concept and design pillars, core mechanics, narrative and character material, world layout, and art/technical direction. What a GDD is emphatically not, in practice, is a single frozen document — most experienced teams treat it as living and constantly revised, closer to a wiki than a manuscript. As productions scaled through the 1990s, studios increasingly split that monolith into specialized companion documents: an Art Bible, a Story Bible, a Technical Design Document — and, on Grim Fandango, a dedicated Puzzle Document.

Inside the Grim Fandango Puzzle Document

The document credits five authors — Tim Schafer, Peter Tsacle, Eric Ingerson, Bret Mogilefsky, and Peter Chan — and is dated April 30, 1996, roughly two and a half years before the game shipped. It's organized around the game's four in-fiction acts — El Marrow, Rubacava, The Coral Mines, and Nuevo Marrow — and each act follows an identical internal template:

• A character list — one line per character, name plus a witty functional descriptor. World-building and casting reference collapsed into a single skimmable page.
• A Puzzle Structure diagram — a flowchart of boxed puzzle names connected by arrows, hand-annotated to mark which sequences are strictly linear and which are parallel, any-order clusters.
• A Location Layout diagram — a second node graph, this time of rooms connected by the paths between them, each annotated with which characters populate it.
• Cut-scene and puzzle write-ups — numbered cleanly from Puzzle #1 to Puzzle #80 across the whole document, twenty per act — each with a short "problem" framing and an explicit, separately labeled Solution: paragraph.

That last structural choice — separating the problem from the solution as distinct, labeled fields — is the single most useful thing about this document as a design artifact. It means a reader can independently verify, puzzle by puzzle, whether the stated solution actually satisfies the stated problem, using only information already established earlier in the document. It's a self-checking spec.

A design document you can watch a real production cut into

We know from external accounts of the game's development that the team ran out of time and had to cut a planned climactic confrontation with the villain, Hector LeMans, and that Schafer said the original design needed another year or two to build in full. Look at the Year Four Puzzle Structure diagram in this very document, and you can watch that decision get made in real time: the flowchart runs cleanly through numbered, fully specified puzzles up through "Sprout Hector!" — and then, instead of a diagrammed continuation, there's a hand-drawn arrow to a torn scrap of paper reading, simply, "KILL HECTOR !!!!!"

That's not a fully specced puzzle. It's a placeholder — a stakeholder's note to self, standing in for content that never got built to the original ambition. A design document you can cross-reference against the finished game and the documented production history, right down to locating the exact spot where scope met deadline, is a genuinely rare thing to have in hand.

From studio spec to machine spec

None of this happened because LucasArts in 1996 was thinking about artificial intelligence. But the shape of what they built — a numbered, dependency-graphed, problem/solution-paired specification — maps with almost eerie precision onto what the software industry now calls spec-driven development.

Spec-driven development (SDD) emerged through 2025 as a direct response to the failure mode nicknamed "vibe coding": handing an AI agent a loose natural-language prompt and hoping the output matches intent, only to watch that intent drift as the codebase grows past what the model can hold in context. The fix, formalized by tools like GitHub's Spec Kit and adopted across most major AI coding assistants, is to make a structured, versioned specification — not the code, and not a vague prompt — the source of truth, with the AI deriving an implementation plan and a breakdown of atomic, individually verifiable tasks from it. One widely cited framing names six required elements of a good spec: outcomes, scope boundaries, constraints, prior decisions, task breakdown, and verification criteria.

Now look at the Puzzle Document again with that checklist in hand. Each entry states an outcome (the "problem"). The dependency diagrams encode scope boundaries and prior decisions. The numbering is a literal atomic task breakdown. And the labeled Solution: field is, functionally, verification criteria — precise enough that a tester weeks later, with no other context, could check the finished implementation against it.

This isn't really a new idea being rediscovered — it's the same underlying problem showing up in two industries thirty years apart. Any time creative intent has to survive a hand-off — to a level designer down the hall, to a contractor overseas, to an AI agent with no memory of yesterday's conversation — the fix is the same: write the dependency graph, and write what "correct" looks like, specifically enough that someone else can check it without asking you. Ron Gilbert's 1989 rules against unfair, backwards, unverifiable puzzles and 2025's rules against unverifiable AI-generated code are, functionally, the same essay.

A Few Other Things Worth Noticing

The document's voice is the game's voice

LucasArts adventures are famous for a dry, irreverent comic tone, and what's striking about the Puzzle Document is that the internal paperwork is written in exactly that voice, not a sterile production register. Puzzle write-ups editorialize on their own jokes, footnote themselves with running gags, and sign off with a request to restrict "fallen tears of joy" to a small box at the end. That's a tell about studio culture: a team that writes its internal specs in the same comic key as its shipped dialogue is a team where tone is load-bearing at every level of production, not bolted on at the script pass.

It's a living document, visibly

Faint handwritten marginalia are scattered through the pages — corrections, initials, notes that read as editor's shorthand rather than anything meant for publication. Combined with the torn "KILL HECTOR!!!!!" scrap discussed above, the artifact reads less like a finished deliverable and more like a working tool still being annotated as production moved through it — exactly what a good design document should be, and exactly what "living spec" language in modern software engineering is reaching for.

Puzzle fairness, made visible as geometry

Ron Gilbert's 1989 rules against backwards puzzles and unwinnable states are usually discussed as prose guidelines. The Puzzle Document shows what those rules look like when you actually draw them: a directed graph with no cycles, no orphaned nodes, and an explicit call-out for every place the design intentionally opens into parallel, any-order branches. You can look at the diagram and see fairness, the same way you can look at a well-formed dependency graph in a build system and know it will terminate. Good process discipline turns an ethical design commitment into a mechanically checkable property.

What AI Game Development Can Learn From All This

Bring the threads together and a fairly direct set of lessons falls out — for building games with AI assistance, and for training AI systems on games.

1. Treat the design document as an executable contract, not a mood board.

   The single most transferable habit in the Puzzle Document is the paired problem/solution structure sitting inside an explicit dependency graph. That structure is directly reusable in an AI-assisted pipeline: a spec that states its preconditions, its intended outcome, and a verifiable "solution" is something an agent can implement and test itself against. Loose, mood-board-style GDDs are exactly the kind of underspecified input that produces "intent drift" in AI coding agents, whether the output is code or game content.

2. Puzzle dependency graphs and AI planning representations already speak the same language.

   This is the sharpest edge of the whole comparison: the node-and-arrow charts LucasArts hand-drew for human collaborators in 1996 — puzzle as node, prerequisite as edge, "Solution" as a verified action sequence — are structurally the same object as the precondition/action/effect representations (PDDL, and the STRIPS-style formalisms it descends from) that AI agent research uses to define tasks in text-adventure and embodied-agent benchmarks. ALFWorld, one of the most widely used testbeds for evaluating whether language-model agents can plan and act in a simulated world, is explicitly built on a PDDL-structured internal state. A studio's puzzle chart and a researcher's planning-domain definition are, formally, doing the same job.

3. Point-and-click games are close to an ideal training ground for object interaction and world modeling.

   A recent survey of large language model-based game agents singles out adventure games for exactly this reason: they're defined by partial observability and long-horizon quests, where success depends on remembering what's been explored and tracking which preconditions remain unmet — and notes this is precisely where current models struggle, with even strong LLMs documented as unreliable implicit world simulators. A few properties make the format unusually well-suited to this work: a bounded, discrete action space that makes credit assignment tractable; explicit precondition/postcondition logic already expressed in natural language, exactly the representation LLMs reason over best; the "no death, no dead end" tradition, which lets an exploring agent fail and retry without a catastrophic reset; and long-horizon, multi-location state persistence — an item picked up in Act One paying off hours later — which is exactly the durable world-modeling skill current agents are weakest at.

4. Formalized puzzle documents are a genuinely useful substrate for AI-assisted content generation — bounded, not unbounded.

   The same way spec-driven development constrains an AI coding agent to a reviewed specification instead of a loose prompt, a human-authored dependency graph could constrain an AI content-generation system: a designer sketches the nodes, the edges, the intended emotional beats, and a model fills in flavor text, dialogue, or candidate solution mechanics within those constraints, with the graph itself serving as the acceptance test. The hard part of design — deciding what depends on what, and what "solved" means — stays a human, auditable decision.

5. The fairness discipline is the point, not the flowchart.

   It would be easy to read all of this as "draw better diagrams." The deeper lesson, connecting a 1989 design essay to a 2026 spec-driven-development guide to a 1996 puzzle document to a benchmark paper about language models getting lost in text adventures, is that clear specification is fundamentally an act of respect for whoever has to act on your intent next — a player, a teammate, or a model. The Puzzle Document earns its status not because its flowcharts are pretty, but because a designer sat down thirty years ago and insisted that every obstacle in the Land of the Dead be paired, in writing, with an honest, checkable answer for how to get through it.