I Distilled My Design Methodology into a Skill, and Then… — A Murloc’s Concise Handbook of Quest and Narrative Design, Part VI

All right, I admit the numbering of these articles is both random and a complete mess… But this one is really just me rambling about something that got me thinking. Yep.

How it all started

First, here’s the skill I distilled my own design methodology into: https://github.com/Hammerstein3217/Quest-design-bible-v3-skill.

English text from the repository screenshot

Quest Design Bible. A Codex skill for generating and reviewing quest/mission flows. It first identifies the interactions and presentation methods the target game already supports, then designs quest nodes, spatial routes, emotional pacing, and fallback conditions. Both design proposals and review reports are delivered as a single HTML file that can be opened directly. Version shown: v3.1.0; updates are listed in CHANGELOG.md.

Generate quest proposals: organize the design through six layers—intent, elements, structure, routing, pacing, and engineering checks. Each flowchart node represents one Step (the player’s current objective) or one Event (a trigger that records a state change). Info Events, Challenge Events, and Act Blocks are written inside the nodes.

Review existing proposals: first identify the quest setting (an open area or a self-contained level) and its progression model (step-driven or event-driven), then choose the applicable checks. Reports include evidence, a pass/warning/fail verdict, and actionable revisions.

Validate the target game: distinguish interactions the game actually supports from proposals that would require new features. Key sequences must match the dialogue, animation, camera, and scene states the game can support. Unknown rules and production constraints are marked for confirmation rather than inferred from genre alone.

Of course, I may update it now and then. That depends on whether some new idea suddenly occurs to me, whether I get any user feedback, that sort of thing.

English text from the example flowchart

Quest end state: A-Liu (阿琉) obtains a verifiable receipt ledger and can continue tracing supplies from its entries. The energy-storage core is destroyed during an emergency shutdown, voiding the lucrative commission. Nicole takes responsibility for the delay in retrieving it. The Cunning Hares’ relationship with the Proxies does not change at the main-story level; only a viewable record in the archive and a short follow-up conversation are added. Rewards and numerical settlement are outside this design’s scope.

02 / Flow — Quest flowchart. Each box represents one completable Step (a player objective) or one flow Event (a trigger that records a state change). Click a box to view its details. Dashed lines indicate a retry from the current checkpoint after failure.

Start → E01 / Event, Lucrative recovery order: the terminal displays a commission to retrieve the core → S02 / Step, Cross-check the two orders: find Nicole and A-Liu in the city hub → E03 / Event, Both orders lead to the same station: Nicole decides to retrieve it on the way → S04 / Step, Enter the sorting station: follow the order numbers to the inner area → S05 / Step, Find the ledger: clear a path and compare shelf numbers → E06 / Event, Retrieval conflict: removing the core will destroy the ledger.

The chip is destroyed; the ledger survives → S07 / Step, Save the ledger: the chip enters emergency shutdown → E08 / Event, The Inventory Taker activates: backup power awakens the boss → S09 / Step, Defeat the Inventory Taker: Nicole provides support; hold the exit. A party wipe loops back to a retry before the boss → E10 / Event, The last page: confirm that the receipt records are still there → S11 / Step, Deliver the ledger: return to Sixth Street and report to A-Liu → E12 / Event, The deferred bill: Nicole accepts a hand-drawn receipt → End.

Legend: Event = a triggered event that records a state change; Step = the player’s current objective; solid line = progression; dashed line = retry. 03 / 38-minute route — Node overview and duration. Visible table headings: ID; time segment / added duration; location; player objective or trigger; completion state; next node; main presentation method.

This skill comes from articles I’ve posted on Gcores, Zhihu, and elsewhere. Those include What Are We Talking About When We Talk About Quests?, which I wrote in imitation of that design bible by Wushiwan (五十万). To turn all this into rules, I added some mind maps and hard constraints: the bits you have to spell out or the thing simply won’t work as a skill.

To be honest, none of this started with some grand practical purpose. I really was just zoning out at work with nothing to do, so I turned my methodology into a skill. People in my “social circle” have lately been getting heavily into making games with AI. Some friends have also found work so miserable that they’ve decided to take a break and make games with AI in the meantime. So yes, when people are anxious and have time on their hands, they really will start reinventing wheels with AI…

That led me to ask myself a question. We know models like GPT6 Astra and Opus 5.5 are a lot more capable than those early models that couldn’t even generate coherent text. But can we actually use them to design a quest from scratch now?

Let me give you my conclusion first: in practice, if you provide enough information and material, this skill really can generate a reasonably usable quest flow. It will design scenes and plot points, give you an emotional arc, and come up with some gameplay. But it also exposes plenty of problems. You can’t, for example, leave the story writing to it. The more stuff you feed it, the longer it takes to work. And as the context keeps growing and growing, the results get considerably worse. You know how it goes.

So this article will also be about the relationship between AI and design.

Rules

As we all know, whatever circles you move in or whatever you do for a living, there are always certain “things” in your life that you can’t quite see or put your finger on.

Put simply, they’re rules. Things you have to abide by if you want to work in that particular circle.

Most of the time, though, they haven’t been quantified or formalized into objective rules. They’re not written down in black and white, carved into stone, or something everyone in the profession is required to memorize word for word.

It’s like reading Dieter Rams’s “ten commandments” of good design, or actually trying to put Mies van der Rohe’s “Less is more” into practice in your own work. You might find it unbearably awkward. You might even, like Robert Venturi, get so fed up one day that you publicly write something like “Less is a bore”: a declaration that both defies the rules and asserts your own personality.

Game design and quest design are, after all, forms of design. So they have these rules too, and people who challenge them.

The same guy pontificating at you here, the one who’s written reams about his own design methodology, once attacked Death Stranding like some staunch traditionalist. He thought it was heresy: something that disregarded game design and cared only about self-expression.

Of course, after a few more years on the job, he quietly deleted that article.

Rules establish a design paradigm, a pattern people can copy, imitate, and mass-produce. They bring with them a style, a design language. When a group of people responds to work made in that language, they start distilling it and imitating it. Eventually, it becomes a trend, a style.

But that’s exactly the problem: when a design language is first being created, it is at its least amenable to rules.

If any of you took intensive art classes for China’s university entrance exams, I imagine you’ve heard this saying: you can never surpass the work you’re copying.

Your teacher will have you find exam drawings that received full marks, or at least work that’s better than what you can currently produce, and copy them. Through copying, you begin to understand what the artist was thinking: how they handled the relationships between light and dark, how they used hatching, how they composed the image, how they broke the objects they were drawing down into geometric forms… In short, you learn their methodology along the way.

You extract an unwritten rule, draw according to it, produce a piece of work, and hand it to your teacher to grade. One person copying gives you an unwritten rule. A group copying turns it into that group’s rules. Once enough people are copying, it takes on the status of an objective rule.

People then write books about those rules, turn them into methodologies and textbooks, and hand them to the next person who wants to imitate the work.

But as long as you’re still copying, you can never surpass the rules themselves.

Throughout this process, you keep creating and refining rules so that more people can get as close as possible to the work they’re copying. You practice to become more proficient. You turn a rule into a concrete method for training yourself. You find your own way to distill rules into a language. Practice, distill, practice, distill… until you truly understand that sentence: you can’t surpass the rules themselves. You can only get closer and closer to them.

If even human beings, with our strange and uniquely human emotional engine, can only get this far, what about AI, whose very existence depends on “rational rules”?

Rational rules and a world that won’t be quantified

This, then, is the problem I ran into while writing the skill for AI, or asking AI to distill it for me. As luck would have it, AI itself pointed out the contradiction.

English text from Kimi’s assessment

I have read this ‘Quest Design Bible for AI’ in full. Here is a systematic assessment.

Overall conclusion: it is an excellent domain-knowledge document, but it cannot yet serve directly as rules for an AI-executable skill. At present it is a summary of a senior designer’s experience. It reads very well for a human who understands game design, but AI still needs an input contract, procedural steps, output formats, and acceptance criteria. In a nutshell: design insight, 8/10; AI executability, 4/10. Fill in those gaps and it could become a high-quality skill.

Detailed assessment — What already works (the parts that meet the requirements of a skill):

1. Defined concepts with clear boundaries. The three elements—Info Event, Challenge Event, and Act Block—are clearly defined. In particular, the distinction between an Act Block and an Info Event (‘the next Challenge is unaffected even if the player misses it’) is crucial for AI.

2. Hard rules and constraints. Examples include ‘a Challenge Event must have an Info Event to explain it,’ ‘one Info Event can explain multiple Challenges,’ and ‘the areas of activity in different stages must not overlap.’ Such MUST/MUST NOT statements are central to a skill: AI can execute and check them directly.

3. Decision branches. The routing section treats open and enclosed designs separately: a typical if–else structure that is easy for AI to work with.

4. A few quantitative anchors. For example, ‘less than three seconds of movement is too short.’ This is one of the statements in the document that most closely resembles an executable rule.

5. Evaluation criteria. The three dimensions of a Challenge—difficulty, information load, and interest—along with four types of factors affecting emotional rises and falls, give AI a framework for checking its own work.

Problems preventing direct execution by AI. The screenshot shows the following issue/example pairs; the rest of the table is cut off:

No input contract: it does not specify what AI needs before starting work (game type? a list of gameplay elements? emotional goals?). No workflow: the document presents knowledge rather than an operational sequence of ‘step 1 → step 2 → step 3.’ No output format: it does not specify what the deliverable should look like (a quest-flow table? a node diagram? JSON?).

Subjective criteria are not quantified: ‘not too frequent,’ ‘avoid overlap wherever possible,’ ‘it will become tiring.’ Undefined terminology: 3C, QTE, the ‘exhibition hall principle,’ and a list of gameplay types. No acceptance checklist / self-review rubric: there are design principles, but no checklist for checking the output item by item.

When I tell it, “A quest needs to be classified as either step-driven or event-driven,” my brain immediately starts arguing with itself: you’ve seen examples that combine both. And event-driven quests can often be more immersive; they work very well in sequences where you want players to explore their surroundings. When I tell it, “In event-driven quests, it’s best to leave some distance between points of interest, or POIs, so that running from one POI to the next doesn’t feel too monotonous,” I can immediately think of a counterexample. If the pacing between events is tight enough, stretching out the distance between two POIs tests how long the player can sustain that tension. It can easily give them time to wonder, “Why am I following this emotional arc?” Then they step outside the experience you’ve planned and start questioning the design itself.

English text from the White Orchard screenshot

White Orchard is an area in Temeria, east of the kingdom’s capital, Vizima. It takes its name from the largest village in the area, also called White Orchard. As the name suggests, it is known for its fruit orchards, which turn white with blossom every spring. The Ismena flows slowly north through the region. Nilfgaardian troops are stationed downstream. After the Battle of White Orchard in spring 1272, they took control of the area from the Temerians.

Developer comment, attributed in the screenshot to The Art of The Witcher 3: Wild Hunt: the game begins in this small Temerian village. At first glance, it looks almost idyllic: clear blue skies and trees covered in white blossom. A little closer attention reveals traces of war everywhere—collapsed houses, damaged carts abandoned by the roadside, and refugees camped in the grass with their possessions scattered around them. The contrast between the sunny spring landscape and these marks of destruction adds tragic color and realism to the game’s atmosphere. Here, whatever the weather or time of day, war continues to devastate people’s lives.

Introduction: White Orchard is known not only for its excellent fruit, but also for the high-quality timber in the nearby woods, suitable for making furniture. Despite the war and Nilfgaard’s occupation following the brutal battle, there is still an unexpected peace to the place. Apart from the dark-clad soldiers occasionally clashing sporadically with guerrilla forces, daily life elsewhere can feel comfortable. In the surrounding forest, shafts of sunlight fall through the trees; in the village tavern, one can drink beer and play a round of Gwent. But a patriotic Temerian is unlikely to enjoy this atmosphere, and even alcohol cannot disguise resentment at the defeat. With Nilfgaardian forces patrolling and watching, one has to be wary of possible conflict. The screenshot cuts off here.

Visible information panel: administrator, Ignatius Verrieres (formerly); former country, Temeria; major events, the Battle of White Orchard in spring 1272 and Emhyr var Emreis visiting White Orchard in May 1272; notable residents, Tomira, Willis, Elsa, and Mislav; type, village / region; location, Northern Kingdoms; main river, Ismena; main religion, Melitele worship; common language, Common Speech; official currencies, Oren and Crown.

After enough of this back-and-forth arguing, I found myself forced to accept something: I have to give AI rules that I don’t consider “perfect,” and accept that, working from those rules, it can only give me quests I’d score at 60–70 out of 100.

I used to think the problem was “experience.” Experience can be made explicit, after all: people who have it are always passing it on to the next person by word of mouth. It just might not apply universally. So if you want an all-purpose quest skill, surely all you need to do is take every lesson you’ve learned in every situation, write the whole lot down as rules, and throw them at AI… And then reality slapped me in the face again. AI doesn’t know which lessons to apply and which to set aside. It’s like someone you’re mentoring suddenly arguing back over a design: “But you told me before that you can’t do it this way, blah blah blah.”

With the former, all you can do is reroll. With the latter, you can still take the time to explain why it’s okay to do it this way here.

By the way, “rerolling,” as if you were pulling again in a gacha game, is really just a way of saying, “I don’t want to explain to AI all over again why this approach works in the current situation and that one doesn’t.”

So you end up with fewer and fewer universally applicable rules, and more and more “amendments” for particular circumstances and situations. Eventually, you realize you can’t distill all this into a complete set of rules that covers every case and can be used to train someone else.

This is one reason the games industry remains so insular after all these years, and why so many people in it look down on game-development training courses. There are very few of these supposed “rational rules,” and they’re often outdated methodologies anyway. The nature of the industry means you first have to find people who, on an intuitive level, feel like “one of us.” Then a more experienced person has to mentor them, patiently taking the time to explain, again and again, why something is okay in this particular case. Even then, you only have a chance of training someone who’s good enough.

So whenever someone trying to break into the industry asks, “What training should I sign up for, what course should I watch, or what exercises should I do to get into games?” people tend to jump to “Hmm, maybe this person isn’t very good at learning.” Or, with the best of intentions, they say something like, “Don’t bother with training courses. Go play more games.”

Because games happen to demand both: concrete, quantifiable methods on the industrial side of design, and individual experience and understanding on the craft side.

So why make this skill at all?

Right. I imagine you’re asking that too. If game design is so damn abstract and so dependent on experience, why write a skill like this in the first place?

A large part of it is that I really did get caught up in the AI wave. In other words, I felt the pressure to keep up. And I thought: having dumped this much game-design methodology garbage onto the internet, why not see whether I could use AI to distill it into a tool? Besides, I don’t want to stare at Codex or Kimi Work every day, thinking, “What should I make with AI today? Something I’ve never actually wanted to make, but the pressure and anxiety mean I have to pretend I’ve always had this indie-game idea deep inside me and the industry just never gave me a chance,” and then get AI to make a prototype.

Honestly, that probably accounts for about 65% of my initial motivation for making this skill.

The experiment also demonstrated something. You can’t take a bunch of house rules, formalize them into a better objective theory, and hand them to a creation whose ability to learn is so powerful that it makes people anxious about keeping up, expecting it to produce something that matches your imagination 100%. At least, today’s AI can’t manage that yet. Maybe a better model will, someday.

On the other hand, I think this skill might have something to offer: my experience of quest design.

At best, I’m a quest designer with a modest reputation. And although I can’t directly tell you which projects I’ve worked on, some of the designs I’m proud of have turned public opinion around, given people a meaningful experience, and conveyed exactly what the creators of the “story” wanted to express, in exactly the way they hoped it would come across.

And I’m still working. At least for now, I haven’t left the industry, and AI isn’t really threatening my position yet. So why not take those rambling, subjective, idiosyncratic articles about design methodology and turn them into an interactive experiment?

You can feed this skill your requirements and ideas and let it generate something. (I do recommend giving it as complete a brief as possible. I’ve already tried letting AI write the story and then design the quest, and the result spoiled the whole pot.) Then bring a critical eye to it. Argue with the result, or try implementing it, and see what problems you find.

I hope you’ll look at what it generates, start thinking, start frowning, and then decide to take the thing apart and rework it a little, bring in your own ideas, and arrive at a design of your own.

That’s the real value this skill can offer. As I said earlier: you can never surpass the work you’re copying.

Actively trying to break out of the design language you’ve learned through copying, making mistakes in an environment where they cost as little as possible, testing your ideas, and building your own experience: that’s how you actually start to move beyond copying and create a methodology of your own.