Game mechanics & visual design

CORE LOOP     seconds–minutes   scout → plan → execute → escape → loot
SESSION LOOP  one run or level  pick a job → 3–5 core loops → payout
META LOOP     across sessions   spend payout → upgrade crew → harder jobs

Columns: A name, B damage, C shots per second, D magazine,
         E reload seconds, F target HP
 
Burst DPS        = B2*C2
Sustained DPS    = (B2*D2) / (D2/C2 + E2)
Shots to kill    = CEILING(F2/B2)
Time to kill (s) = (CEILING(F2/B2)-1) / C2
Power score      = weighted sum of the stats you care about
Cost             = fitted from power score (the cost curve)
Outlier          = cost differs from the curve by more than 15%

[sheet type: character turnaround | callout sheet | thumbnails | expression sheet],
[subject, e.g. a heavy guard who blocks doorways, slow, armored, with a lantern].
[paste the style block from the art bible]
View: [view, e.g. orthographic front, side, back, same height].
Shapes: [shapes, e.g. triangle-dominant silhouette, oversized hands].
Palette: [palette, e.g. muted teal and ochre], value: [value, e.g. light figure on mid-gray].
Plain [background: white | light gray] background, even flat lighting, no cast
shadows, no text, no logos, full body in frame with margin.
Aspect ratio [ratio: 3:2 | 1:1 | 16:9].

<context>
I'm designing one core mechanic for my game and I'm not a game
designer. The idea: [one or two sentences, e.g. "guards hear noise,
so the player throws objects to lure them away"].
What exists: [e.g. "a top-down stealth prototype in Godot with boxes
for art; 2 people, 8 months left"].
</context>
 
<task>
Interview me before anything is designed. I'll use my answers to
brief a one-page design of this mechanic and its art direction.
</task>
 
<requirements>
- At most 10 questions, grouped under: Experience, Mechanic, Player
  and platform, Scope, Visuals.
- Cover what MDA needs (the target aesthetic and the dynamics I
  expect), the verbs, where the interesting decision is, the source
  of challenge, how the player learns it, and what must read on
  screen in under a second.
- For each question: why it matters, and 2–3 typical answers I can
  pick from or reject.
</requirements>
 
<output_format>
Numbered questions under the five group headings. Each: the
question, a "Why:" line, a "Typical:" line.
</output_format>
 
<process>
Ask the questions and stop. Don't design anything yet. When I have
answered, write my answers back as a brief of at most 12 bullets
and list what is still missing.
</process>

<materials>
[paste the brief from stage 1]
</materials>
 
<task>
Propose 3 materially different designs for this mechanic, so I can
pick one to write up as a one-page design.
</task>
 
<requirements>
- The designs differ in where the challenge comes from (execution,
  knowledge, strategy or chance) or in the aesthetic they serve, not
  only in numbers or theme.
- For each: a one-line summary; the core loop it creates; the target
  MDA aesthetics; the interesting decision; the dominant strategy a
  min-maxer would try and what counters it; what it asks of the art
  (readability, telegraphs, VFX); prototype cost as S, M or L.
- Never invent numbers, names, quotes or sources: write [NEEDS
  SOURCE] where support is missing.
</requirements>
 
<quality_bar>
Before answering, check your draft against:
- Each design serves at least one pillar from the brief.
- A player who finds the dominant strategy still has a decision.
- The three would play differently in a 10-minute test.
</quality_bar>
 
<output_format>
A comparison table with one column per design, then a
recommendation in 3 sentences: which, why, and what would change
your mind.
</output_format>
 
<process>
Stop after the recommendation and wait for my choice. End with a
list of the assumptions you made.
</process>

<materials>
[paste the brief from stage 1 and the design you chose in stage 2]
[paste any numbers you have: stats, timings, a balance sheet]
</materials>
 
<context>
Game: [genre and platform, e.g. a top-down stealth roguelike for PC].
Camera: [camera: top-down | side-on | isometric | third-person | first-person], characters about [on-screen size, e.g. 80 px tall at 1080p].
Art: [art form: 2D sprites | 2D vector | 3D low-poly | 3D stylized | 3D realistic], made by [who, e.g. one artist, at most a day per enemy].
Readers: [who builds from it, e.g. my programmer partner, and a
freelance artist who has never seen the game].
</context>
 
<examples>
Looks I like: [2–3 games, films or art, each with what to take,
e.g. "Invisible, Inc.: readable vision cones, muted backgrounds"]
One I don't: [one, with why, e.g. "busy realistic textures that
hide the player"]
</examples>
 
<task>
Write a one-page design of the mechanic and a one-page art
direction brief for it. The programmer builds the first prototype
from the design; the artist makes the first assets from the brief.
</task>
 
<requirements>
- One-page design in Stone Librande's format: goal in one sentence;
  the pillars it serves; verbs; rules; starting numbers with units
  (rates, timings, costs); feedback (visual, audio, UI) for every
  action; how the player learns it; counterplay; edge cases; open
  questions; what to cut if time runs out.
- An MDA line: mechanics → expected dynamics → target aesthetic
  [aesthetic: sensation | fantasy | narrative | challenge | fellowship | discovery | expression | submission].
- If the mechanic earns or spends a resource: a sinks-and-faucets
  table with rates per hour of play at hours 1, 10 and 40.
- Where a new player sits in the flow channel, and what keeps them
  there (the difficulty curve, assist options).
- Art brief: the style in one sentence; references with what to
  take; shape language by role; palette with reserved gameplay
  colors; value rules; telegraph and VFX rules; asset specs (sizes,
  frame counts, format).
- Never invent numbers, names, quotes or sources: write [NEEDS
  SOURCE] where support is missing, and [NEEDS PLAYTEST] where only
  a playtest can set a number.
</requirements>
 
<quality_bar>
Before answering, check your draft against:
- Every rule traces to a pillar; nothing serves none.
- The loop closes: each reward feeds the next cycle.
- The decision has no single right answer; the likely dominant
  strategy is named, with its counter.
- The key elements pass the readability tests (silhouette, value in
  grayscale, in-game size, color vision) at the camera above.
- It fits the scope in the context.
</quality_bar>
 
<output_format>
Two parts of at most about 500 words each. "One-page design": the
sections above as short headings with bullets, plus the loop as a
text diagram. "Art direction brief": bullets, with tables for the
palette and the asset specs. Then the 3 questions the first
playtest must answer.
</output_format>
 
<process>
Ask me up to 3 questions first if anything missing would change
your answer; otherwise go on. End with a list of the assumptions you
made.
</process>

<materials>
<brief>
[paste the brief from stage 1]
</brief>
<draft>
[paste the one-page design and the art direction brief]
</draft>
</materials>
 
<task>
Review this draft against the brief before a prototype is built
from it. This is a fresh chat: judge only what is on the page.
</task>
 
<requirements>
- Score each check 1–5 with one line of evidence: serves the
  pillars; loop closes; decisions are interesting; numbers, not
  adjectives; economy holds (sinks keep pace with faucets);
  difficulty breathes and stays in the flow channel; learnable
  without a text tutorial; testable; in scope; silhouette and value
  readability; palette discipline; buildable asset specs.
- Name the dominant strategy a min-maxer would find in the first
  hour, and the player's most likely misunderstanding.
- Don't rewrite the draft. Don't praise it.
- Never invent numbers, names, quotes or sources: write [NEEDS
  SOURCE] where support is missing.
</requirements>
 
<quality_bar>
Before answering, check your draft against:
- Every problem points to a specific line of the draft.
- Every fix is concrete enough to try in a day.
</quality_bar>
 
<output_format>
A score table (check | score | evidence), then at most 7 fixes
ranked by their effect on the first playtest, worst problem first.
</output_format>
 
<process>
End with a list of the assumptions you made.
</process>

Turn my game idea into a 1-page pitch doc: hook, player fantasy, 3
pillars, verbs, core/session/meta loops, references, audience, scope.
Idea: [one or two sentences, e.g. "a heist game where every plan barely holds"].
Team and time: [e.g. 2 people, 12 months, Godot].
Check that each pillar rules a feature out and every loop closes.

<context>
Idea: [one or two sentences, e.g. "a heist game where every plan
barely holds"].
Player fantasy: [what the player should feel, e.g. "a crew leader
improvising when the plan breaks"].
Platform: [platform: PC | console | phone | handheld], input [input: mouse and keyboard | gamepad | touch], sessions of [minutes, e.g. 20].
Business model: [business model: premium | free-to-play | subscription].
Team and time: [e.g. 2 people, 12 months, Godot].
Reader: [who, e.g. a publisher's scout who reads one page].
</context>
 
<examples>
Pitches or store pages I like: [paste 1–2, each with why]
One I don't: [paste or describe one, with why, e.g. "a feature list
with no fantasy"]
</examples>
 
<task>
Write a pitch doc (concept doc) I can use to decide whether to
prototype this, and to show a partner or publisher.
</task>
 
<requirements>
- Sections: hook in one sentence; player fantasy; 3 design pillars,
  one line each; verbs (5–8); core, session and meta loops as
  arrows; the 3 most interesting decisions; references (2–3 games
  and what to take from each); audience by Quantic Foundry
  motivations; scope; the smallest prototype that tests the core
  loop.
- An MDA breakdown: mechanics → dynamics → which of the eight
  aesthetics.
- Never invent numbers, names, quotes or sources: write [NEEDS
  SOURCE] where support is missing (sales figures, audience sizes).
</requirements>
 
<quality_bar>
Before answering, check your draft against:
- Each pillar rules out at least one tempting feature.
- The core loop closes and is still fun at minute 5 and hour 20.
- No decision has an obvious right answer.
- The prototype is buildable by this team in weeks and says which
  result would show the loop isn't fun.
</quality_bar>
 
<output_format>
At most 2 pages of Markdown: one heading per section, the loops in
a text block, the references as a table (game | take this | leave
this).
</output_format>
 
<process>
Ask me up to 3 questions first if anything missing would change
your answer; otherwise go on. End with a list of the assumptions you
made.
</process>

Model the economy of [game, e.g. a 40-hour action RPG] with sinks and
faucets: every source and sink of [resource, e.g. gold] with rates per
hour at hours 1, 10 and 40, net flow and the typical stockpile.
What I have: [paste earn and spend amounts]. Show the arithmetic, say
where inflation starts, and mark every rate you assumed.

<materials>
[paste every way players earn and spend each resource, with
amounts, or write "none yet"]
</materials>
 
<context>
Game: [genre and length, e.g. an action RPG, 1-hour sessions, about
40 hours to finish].
Business model: [business model: premium | free-to-play | subscription].
Resources: [list, e.g. gold, wood, XP].
Progression: [progression: vertical | horizontal | skill | knowledge | cosmetic].
Problem: [what's wrong, e.g. "by hour 15 gold piles up and shops
stop mattering"].
</context>
 
<task>
Build an economy model for these resources, so I can tune the rates
in a spreadsheet before the next playtest.
</task>
 
<requirements>
- The sinks-and-faucets method: a faucets table and a sinks table
  (source, resource, amount, rate per hour at hours 1, 10 and 40),
  with optional sinks marked.
- Net flow per resource and the stockpile a typical player holds at
  each checkpoint; mark inflation (faucets outpace sinks) and
  starvation (sinks win).
- Positive feedback loops, and converters that turn a resource into
  more of itself, each with a damper.
- New sinks that are fun (options, cosmetics, risk), not taxes.
- Never invent numbers, names, quotes or sources: write [NEEDS
  SOURCE] where support is missing, and label every play rate you
  assumed.
</requirements>
 
<quality_bar>
Before answering, check your draft against:
- Every rate has a unit, and its arithmetic is shown.
- Sinks keep pace with faucets at hours 1, 10 and 40.
- No sink can be skipped by the players who hoard.
- Each fix names the number it changes and by how much.
</quality_bar>
 
<output_format>
A faucets table, a sinks table, a net-flow table by checkpoint, a
list of problems with fixes, and the net-flow formulas in Google
Sheets syntax.
</output_format>
 
<process>
Ask me up to 3 questions first if anything missing would change
your answer; otherwise go on. End with a list of the assumptions you
made.
</process>

Here is my [table: weapons | units | cards] as CSV: [paste]. Add burst
DPS, sustained DPS and time to kill against [targets, e.g. 100 and 250
HP], with spreadsheet formulas; fit a cost curve; list outliers and
dominant options. Recompute two rows by hand, and ask me rather than
invent a missing stat.

<materials>
[paste the stat table as CSV, or the list of stats and what each
does if there are no numbers yet]
</materials>
 
<context>
Game: [genre and mode, e.g. a top-down shooter, 10-minute matches].
Targets: [what they fight, e.g. enemy HP 100, 250, 600; armor 0, 20].
What each stat means: [e.g. "fire rate is shots per second"].
Suspicion: [e.g. "the shotgun wins every close fight"].
</context>
 
<task>
Build a balance sheet I can paste into a spreadsheet, to find
dominant options before the next balance pass.
</task>
 
<requirements>
- Derived columns with formulas: burst DPS, sustained DPS with
  reload, shots to kill and time to kill (TTK) against each target.
- A power score with weights you justify, and a cost curve fitted
  from it; flag outliers more than [tolerance, e.g. 15%] off it.
- Dominant options, options that are never the best pick, and the
  situation where each option should be the right pick.
- The smallest stat changes that fix each problem.
- Never invent numbers, names, quotes or sources: write [NEEDS
  SOURCE] for any stat I didn't give, instead of filling it in.
</requirements>
 
<quality_bar>
Before answering, check your draft against:
- Every formula uses the columns given and runs as written.
- Two rows are recomputed by hand, with the working shown.
- Every option is the right pick in some situation.
- No fix creates a new dominant option.
</quality_bar>
 
<output_format>
The table with the new columns as CSV, the formulas in Google Sheets
syntax, an outlier list, and a fix table (option | change | effect
on TTK).
</output_format>
 
<process>
Ask me up to 3 questions first if anything missing would change
your answer; otherwise go on. End with a list of the assumptions you
made.
</process>

Draft an art bible for my [genre, e.g. top-down stealth] game from these
references: [references, e.g. Invisible, Inc. for vision cones]. Sections: one-line style,
shape language by role, palette per area with reserved gameplay colors,
value rules, rendering, lighting, UI, VFX, 5 dos and 5 don'ts, and a
40–60-word style block for image prompts. Check every rule against the
silhouette and grayscale tests.

<materials>
[paste the chosen art direction, e.g. the design picked in stage 2
of the chain]
</materials>
 
<context>
Game: [genre, e.g. top-down stealth], on [platform and resolution,
e.g. PC at 1080p].
Camera: [camera: top-down | side-on | isometric | third-person | first-person]
Art form: [art form: 2D sprites | 2D vector | 3D low-poly | 3D stylized | 3D realistic]
Rendering: [rendering: flat | cel-shaded | painted | physically based]
Team: [who makes art and the time per asset, e.g. one artist, one
day per enemy].
Must read in under a second: [e.g. guards, vision cones, the
player, cover].
</context>
 
<examples>
References I like: [3–10 images or games, each with what to take:
shape, palette or lighting, never "everything"]
One I don't: [one, with why, e.g. "texture noise everywhere"]
</examples>
 
<task>
Write an art bible that turns this direction into rules an artist
or an image generator can follow, before asset production starts.
</task>
 
<requirements>
- Sections: pillars and one-line style; references with what to
  take; shape language by role; proportions; palette per area with
  reserved gameplay colors; value rules; materials and rendering;
  lighting; UI style; VFX style; 5 dos and 5 don'ts; asset specs.
- Readability first: the player and threats win the value contrast,
  the background stays in the mid-values, no information by hue
  alone.
- A style block of 40–60 words to paste, word for word, into every
  image prompt.
- Styles described by visible traits, never by living artists' names.
- Never invent numbers, names, quotes or sources: write [NEEDS
  SOURCE] where support is missing.
</requirements>
 
<quality_bar>
Before answering, check your draft against:
- Each rule says no to something.
- Reserved gameplay colors are never used for decoration.
- The style passes the silhouette, grayscale and in-game-size tests
  at the camera above.
- An asset in this style fits the time per asset.
</quality_bar>
 
<output_format>
Markdown with one heading per section; tables for the palette (area
| colors as hex | reserved for) and the asset specs; the style block
last, in quotes.
</output_format>
 
<process>
Ask me up to 3 questions first if anything missing would change
your answer; otherwise go on. End with a list of the assumptions you
made.
</process>

Write 4 image-generator prompts for a [sheet type: thumbnails | turnaround | callout sheet | expression sheet]
of [subject, e.g. a heavy guard with a lantern], with this style block
word for word: [paste]. Vary one thing per prompt; plain light
background; no text. Then list the 3 signature details to check in
every result.

<materials>
[paste the art bible's style block and palette]
[attach the approved reference image, if there is one]
</materials>
 
<context>
Asset: [subject, role and 3 key features, e.g. "a heavy guard who
blocks doorways: slow, armored, carries a lantern"].
Sheet: [sheet type: thumbnails | turnaround | callout sheet | expression sheet | color key]
Next step: [who uses it, e.g. a 3D modeler builds from the
turnaround].
Image tool: [tool, e.g. Midjourney, Firefly or a chat assistant's
image mode].
</context>
 
<examples>
Approved images: [attach or describe 1–3, with what makes them right]
Rejected: [one, with why, e.g. "views disagree; too much detail"]
</examples>
 
<task>
Write the concept art brief for this asset and 4 prompts for the
image tool, so I can generate, pick one and hand it on.
</task>
 
<requirements>
- Each prompt in this order: sheet type; subject and role; the style
  block word for word; shape and proportion; palette and value;
  view and camera; lighting; background and framing; exclusions;
  aspect ratio.
- Turnarounds: orthographic front, side and back at the same height,
  flat even lighting, no cast shadows, full body with margin.
- Vary one thing per prompt (silhouette, proportion, palette or
  detail), never the style block.
- A character description of at most 60 words: silhouette,
  proportions, 3 signature details, palette as hex, what must never
  change.
- No other studios' characters, no living artists' names, no text
  or logos in the image.
- Never invent numbers, names, quotes or sources: write [NEEDS
  SOURCE] where support is missing.
</requirements>
 
<quality_bar>
Before answering, check your draft against:
- The design reads in solid black (the silhouette test) at its
  in-game size.
- Its values set the figure apart from the background.
- Nothing asks the generator for what it gets wrong: legible text,
  exact counts, hands doing mechanical work.
</quality_bar>
 
<output_format>
The brief (purpose, sheet type, specs, references) in 5 lines; the
60-word description; the 4 prompts in separate text blocks; a
checklist for each result (signature details, views agree,
silhouette, palette).
</output_format>
 
<process>
Ask me up to 3 questions first if anything missing would change
your answer; otherwise go on. End with a list of the assumptions you
made.
</process>

Write a sprite sheet spec for [character, e.g. the heavy guard] in a
pixel-art game: base resolution [e.g. 480×270], height [e.g. 32 px],
palette, animations with frame counts and fps, cell size, padding,
pivot, file naming and export format. Check that the base resolution
integer-scales to 1080p, and end with a checklist for the artist.

<context>
Game: [genre and engine, e.g. a 2D platformer in Godot].
Base resolution: [base: 320×180 | 384×216 | 480×270 | 640×360], integer-scaled to 1920×1080.
Character: [who, e.g. the heavy guard], about [height, e.g. 32 px]
tall.
Palette: [e.g. 16 colors, or a named palette from Lospec].
Animations: [list, e.g. idle, walk, alert, attack, hurt, death].
Artist: [who, e.g. a freelancer paid per frame].
</context>
 
<task>
Write a sprite sheet spec the artist can deliver against and I can
check on arrival.
</task>
 
<requirements>
- Per animation: frame count, fps, loop or one-shot, the key poses,
  and the frame the gameplay event happens on (the hit frame).
- Fixed cell size, 1–2 px padding, pivot at the feet, transparent
  PNG, one sheet per character, names like chr_guard_walk_01.png.
- Nearest-neighbor filtering and integer scaling; no mixed pixel
  sizes; no anti-aliased edges against transparency.
- Readability at real size: the silhouette test on each key pose;
  attacks telegraph with a wind-up before the hit frame.
- Never invent numbers, names, quotes or sources: write [NEEDS
  SOURCE] where support is missing.
</requirements>
 
<quality_bar>
Before answering, check your draft against:
- The cell fits the widest and tallest pose with margin.
- Frame counts and fps give a wind-up long enough to react to.
- Everything the engine needs to import the sheet is stated.
</quality_bar>
 
<output_format>
A spec table (animation | frames | fps | loop | key poses | event
frame), a file-settings list, and a 10-point acceptance checklist.
</output_format>
 
<process>
Ask me up to 3 questions first if anything missing would change
your answer; otherwise go on. End with a list of the assumptions you
made.
</process>

Write a playtest plan for [game, e.g. my stealth prototype] to answer
one question: [e.g. "do players understand distraction?"]. Give a
setup script with no hints, 5 tasks, an observation sheet, 6
non-leading questions, the telemetry to log and how I'll decide.
Check that no question names the mechanic being tested.

<materials>
[optional: notes from the last playtest, quoted exactly]
</materials>
 
<context>
Build: [what is in it, e.g. levels 1–3 of the stealth game, graybox
art].
Stage: [stage: paper prototype | graybox | vertical slice | alpha | beta]
Question: [one, e.g. "do players use distraction after level 2, and
if not, why not?"].
Players: [number and who, e.g. 6 Kleenex testers who play stealth
games and have never seen the build].
Session: [length and setting, e.g. 45 minutes, in person, recorded].
</context>
 
<task>
Write a playtest plan and an empty report template, so I can run the
session and turn what I see into design decisions.
</task>
 
<requirements>
- A setup script I read aloud, with no hints about the mechanics.
- 5 tasks or goals; think-aloud instructions; an observation sheet
  (time, place, what they tried, quotes); 6 post-session questions
  about their experience, not my design.
- Telemetry events, each with the question it answers.
- A decision rule set now: which result means the design works and
  which means it doesn't.
- A report template: issue; testers who hit it; severity (blocks
  progress, hurts fun, cosmetic); likely cause in the design; 2
  candidate fixes; what to measure next time.
- Never invent numbers, names, quotes or sources: write [NEEDS
  SOURCE] where support is missing; quotes in the report are only
  what testers said.
</requirements>
 
<quality_bar>
Before answering, check your draft against:
- No question leads the player or names the mechanic.
- Every task and telemetry event serves the one question.
- The decision rule is fixed before the test, not after.
</quality_bar>
 
<output_format>
One page: script, tasks, observation sheet as a table, questions,
telemetry table, decision rule. Then the report template as an empty
table.
</output_format>
 
<process>
Ask me up to 3 questions first if anything missing would change
your answer; otherwise go on. End with a list of the assumptions you
made.
</process>

Audit this gameplay screenshot [paste a description, or attach it] at
[resolution, e.g. 1080p] for readability. Players must notice, in order:
[list, e.g. guards, vision cones, the exit]. Check value
contrast, silhouettes, reliance on color, visual noise near the player
and VFX covering threats. Give the 5 fixes with the biggest effect,
cheapest first, and don't redesign the style.

<materials>
[attach the screenshot, or describe it: camera, every element, its
colors and position]
[paste the art bible's palette and value rules, if you have them]
</materials>
 
<context>
Game: [genre and camera, e.g. top-down stealth, characters about
80 px tall].
Display: [display: 1080p monitor | 4K TV across a room | phone | handheld]
Must notice, in priority order: [e.g. guards, vision cones, the
player, the exit, pickups].
Seen in playtests: [e.g. "4 of 6 testers walked into vision cones
they didn't see"].
</context>
 
<examples>
Games that read well at this camera: [1–2, each with what it does,
e.g. "Into the Breach: every enemy attack shown on the grid before
it lands"]
</examples>
 
<task>
Audit the screenshot for readability and rank the fixes, so I can
change the art before the next playtest.
</task>
 
<requirements>
- The readability tests: silhouette; value (grayscale); squint or
  blur; in-game size; color vision (no information by hue alone);
  in motion and under VFX.
- For each element on the priority list: whether it wins the
  contrast it should, and what competes with it.
- Fixes cheapest first, each a concrete change ("darken the floor
  tiles by one value step", "add a white rim light to guards").
- Don't rewrite the style or the art bible.
- Never invent numbers, names, quotes or sources: write [NEEDS
  SOURCE] where support is missing.
</requirements>
 
<quality_bar>
Before answering, check your draft against:
- The read order you found is compared with the priority list,
  element by element.
- Each fix names the element, the change and the test it fixes.
- No fix depends on color alone.
</quality_bar>
 
<output_format>
A table (element | priority | passes | fails | what competes), then
the top 5 fixes ranked, cheapest first.
</output_format>
 
<process>
Ask me up to 3 questions first if anything missing would change
your answer; otherwise go on. End with a list of the assumptions you
made.
</process>

Make my roguelike more fun. Add some cool mechanics.

<materials>
Playtest notes, 12 sessions: by room 8, 11 of 12 players took a
damage relic every time; 9 of 12 never parried after room 3; 7 said
runs "feel the same" in the post-session questions.
Relic pool: 30 relics; 12 add damage, 10 add defense, 8 are utility.
</materials>
 
<context>
Game: a top-down roguelike for PC, 20-minute runs; 2 people, 8
months left, Godot.
Pillars: decisive fights; builds that feel different every run; no
grinding between runs.
Verbs: dash, attack, parry, pick a relic.
Core loop: clear room → pick 1 of 3 relics → next room; a boss every
5 rooms.
</context>
 
<task>
Diagnose why every run converges on damage relics and propose fixes,
so I can choose what to build before the next playtest.
</task>
 
<requirements>
- Diagnose with MDA: which mechanics produce this dynamic?
- Say whether "always take damage" is a dominant strategy, and why.
- 4 fixes, each with: the change, the dynamic it should create, the
  pillar it serves, cost to build (S, M or L), and the playtest
  result that would show it worked.
- One fix must make parrying worth it without forcing it.
- No new systems unless a fix needs one.
- Never invent numbers, names, quotes or sources: write [NEEDS
  SOURCE] where support is missing.
</requirements>
 
<quality_bar>
Before answering, check your draft against:
- Each fix traces to a pillar.
- No fix creates a new dominant strategy.
- Every fix can be tested in one playtest.
</quality_bar>
 
<output_format>
The MDA diagnosis in 3–5 bullets, then a table: # | change |
expected dynamic | pillar | cost | playtest signal.
</output_format>
 
<process>
Ask me up to 3 questions first if anything missing would change
your answer; otherwise go on. End with a list of the assumptions you
made.
</process>

MDA diagnosis
- Mechanics: relics stack additively, and 12 of 30 add damage, so a
  1-of-3 offer holds at least one damage relic about 80% of the time.
- Dynamics: more damage shortens every fight, which also shortens
  the time you can be hit, so damage doubles as defense; defense
  and utility relics rarely win a pick.
- Aesthetics lost: expression (builds) and challenge (parrying).
- Dominant strategy: yes. Damage is the best pick in almost every
  room because it also does defense's job.
 
# | Change                                   | Expected dynamic        | Pillar          | Cost | Playtest signal
1 | Damage relics give diminishing returns   | a 4th damage pick loses | builds differ   | S    | under 60% damage picks
  | after the third                          | to utility              |                 |      | after room 8
2 | Every offer holds one relic per category | every pick is a choice  | builds differ   | S    | 3+ categories in final builds
3 | A perfect parry gives +5% damage for 3 s,| parrying pays off       | decisive fights | S    | parries per room rise
  | stacking                                 |                         |                 |      | after room 3
4 | Elite rooms whose enemies resist damage  | some fights reward      | decisive fights | M    | fewer pure-damage runs
  | relics                                   | other builds            |                 |      | reach boss 2
 
All four fixes checked: none creates a new dominant strategy.
Assumptions: players judge relics by the numbers shown; no relic
interacts with parrying today.

Fix 3 pays parries in damage, which feeds the damage stack the
other fixes are trying to break. Replace it with a parry reward in a
different currency (safety, time or options, e.g. a free reroll of
the next relic offer, or a short stagger on nearby enemies). Keep
fixes 1, 2 and 4 as they are. Give the new fix in the same columns,
then check all four fixes together: which build would a min-maxer
pick by room 8, and is it still a dominant strategy?