Game studio skills

---
name: game-design
description: Use when shaping or changing a core loop, mechanic or rule set, writing a design brief, or deciding what to prototype next. Produces a testable design with clear player goals, rules, feedback and success measures.
---

# Game design

Draft from the Game studio skills library by THE DREAMING JESTER. Adapt it to your game, team and engine.

## Goal

Turn an idea into a design that can be built, played and judged quickly. A good design states what the player does, why they want to, and how you will know it works.

## Before you start

- Read the existing design notes, the current build and any playtest or analytics findings.
- Identify the target player, platform, session length and the experience the game promises.
- Ask what decision this design needs to support: prototype, commit, cut or change.

## Process

1. Write the core loop in one sentence per step: what the player sees, decides, does and receives.
2. List the player's goals at three timescales: the next 30 seconds, the session, and the long term.
3. Define each mechanic by its inputs, rules, outcomes and the feedback the player gets.
4. Name the interesting decisions. If a choice has an obvious best answer, it is not yet a decision.
5. Identify the riskiest assumption and design the smallest prototype that tests it.
6. Set success measures before building: what playtest behaviour or metric would confirm or reject the idea.
7. Record what is deliberately out of scope.

## Quality bar

- Someone new can explain the loop back after reading one page.
- Every mechanic has visible feedback and a reason to exist in the loop.
- Numbers are placeholders with ranges and the reasoning behind them, not false precision.
- The design names how it will be tested and what would change it.

## Output

A one-page design brief: player fantasy, core loop, mechanics, key decisions, risks, prototype plan and success measures. Link to deeper documents rather than growing the brief.

## Avoid

- Feature lists without a loop that connects them.
- Designing for an imagined player instead of observed players.
- Locking numbers before anything is playable.

---
name: level-design
description: Use when planning or reviewing a level, map, mission or encounter space. Covers intent, flow, pacing, teaching, landmarks, encounter placement and greybox validation before art.
---

# Level design

Draft from the Game studio skills library by THE DREAMING JESTER. Adapt it to your game, team and engine.

## Goal

Build spaces that guide players without telling them where to go, teach mechanics in safe conditions, then test them under pressure.

## Before you start

- Confirm the mechanics, movement metrics and camera that the level must respect: speeds, jump heights, sight lines and ranges.
- State the level's job in the wider game: what it teaches, tests or reveals.

## Process

1. Write the intent: one sentence for the experience and one for what the player should leave able to do.
2. Draw a beat chart: introduce, develop, twist, test, release. Mark intensity over time.
3. Sketch the flow: critical path, optional routes, loops, choke points and points of no return.
4. Place landmarks and lighting so the player can orient without a map or marker.
5. Introduce each mechanic safely before combining it with threat or time pressure.
6. Place encounters with clear approach, cover or space, and an exit or recovery moment.
7. Greybox it, play it at real speed, and watch others play before any art pass.
8. Mark metrics the level relies on, so later mechanic changes can be checked against it.

## Quality bar

- First-time players find the critical path without hints at least most of the time.
- Every encounter can be read before it starts.
- Rest beats exist after high-intensity moments.
- The level still works with placeholder art.

## Output

Intent statement, beat chart, annotated top-down map, encounter list and a greybox build with playtest notes.

## Avoid

- Decorating before the layout is proven.
- Relying on UI markers to fix unclear spaces.
- Difficulty spikes caused by unclear information rather than skill.

---
name: narrative-design
description: Use when writing or structuring story, dialogue, barks, item text, tutorials or world-building that players meet during play. Keeps narrative tied to mechanics, pacing and readability.
---

# Narrative design

Draft from the Game studio skills library by THE DREAMING JESTER. Adapt it to your game, team and engine.

## Goal

Make the story something the player experiences through play, not something that interrupts it.

## Before you start

- Know the tone, the player's role and what the player is doing when they meet each piece of text.
- Find the systems that can carry story: progression, items, enemies, places and failure.

## Process

1. State the narrative promise in two sentences: who the player is and what is at stake.
2. Map story beats to gameplay beats. Each beat should change what the player wants or knows.
3. Choose the delivery for each beat: environment, systems, short lines, scripted moment or optional lore.
4. Write the shortest line that does the job. Lines heard during action must be understood at a glance.
5. Give recurring voices distinct speech patterns and consistent knowledge.
6. Keep text in data with stable IDs and context notes, so it can be edited, localised and tracked.
7. Read every line in context, in the build, at real speed.

## Quality bar

- No essential information exists only in long text.
- Barks and prompts are short enough to read during play.
- The tone stays consistent between a tutorial prompt and an item description.
- Every line has an ID, speaker, trigger and context note.

## Output

Narrative brief, beat-to-gameplay map, text in data with IDs, and a list of triggers and conditions.

## Avoid

- Exposition dumps before the player cares.
- Text that contradicts what the systems show.
- Hardcoded strings that cannot be localised or tracked.

---
name: ui-ux-design
description: Use when designing or reviewing HUDs, menus, inventories, shops, onboarding or any player-facing interface. Covers information hierarchy, input methods, feedback, readability, flows and testing.
---

# UI/UX design

Draft from the Game studio skills library by THE DREAMING JESTER. Adapt it to your game, team and engine.

## Goal

Give players the information they need, at the moment they need it, in a form they can read without stopping play.

## Before you start

- List the player's decisions on each screen and what information each decision needs.
- Confirm the target devices, resolutions, viewing distance and input methods: mouse, controller, touch.
- Collect the current UI, its pain points and any playtest or analytics evidence.

## Process

1. Rank information by urgency: what must be read in combat, what can wait for a pause, what can live in a menu.
2. Sketch flows before screens. Count the steps for the most frequent tasks and remove what you can.
3. Establish a visual hierarchy: size, contrast, position and motion reserved for what matters most.
4. Design every state: empty, loading, disabled, error, full, new and changed.
5. Design for every input: focus order and navigation for controllers, hit sizes for touch, shortcuts for mouse and keyboard.
6. Give every action immediate feedback: visual, audio and, where available, haptic.
7. Prototype in the engine early. Mock-ups hide timing, scale and readability problems.
8. Test with players who have not seen it. Watch where they look and hesitate.

## Quality bar

- Critical HUD information can be read in under a second at the target viewing distance.
- Every screen works with every supported input without a mouse fallback.
- Text meets readable sizes and contrast, and scales with a setting.
- No information is carried by colour alone.

## Output

User flows, annotated wireframes, a component and state list, and an in-engine prototype with test findings.

## Avoid

- Designing at a monitor distance when players sit on a sofa.
- Hiding important stats behind hover-only interactions.
- Adding UI to fix problems the game should communicate itself.

---
name: systems-balance
description: Use when tuning damage, health, costs, rewards, drop rates, progression curves or in-game economies. Uses models, data and playtests to keep choices meaningful and avoid dominant strategies.
---

# Systems and economy balance

Draft from the Game studio skills library by THE DREAMING JESTER. Adapt it to your game, team and engine.

## Goal

Keep choices meaningful: no option should be clearly best, and progress should feel earned at a steady, intended pace.

## Before you start

- Gather the current numbers from data, not memory, plus any telemetry on usage, win rates and time to progress.
- State the intended pace: how long to the first upgrade, the midpoint and the end.

## Process

1. Model the system in a spreadsheet or script: inputs, formulas and the resulting time-to-kill, cost-to-power or time-to-reward.
2. Define each item or ability by its role, what it excels against and its trade-off. Every option needs a weakness.
3. Look for dominant strategies: compare value per cost, per slot and per second across options.
4. Map sources and sinks for every currency and resource. Unbalanced flows inflate or starve the economy.
5. Change one variable at a time, in small steps, and record why.
6. Validate with telemetry and playtests: pick rates, completion times, deaths and quits.
7. Keep balance data in versioned files so changes can be compared and reverted.

## Quality bar

- Every option has a situation where it is the right choice.
- The model predicts the observed pace within a reasonable margin.
- Each balance change has a reason, an expected effect and a measured result.

## Output

A balance model, a change log with expected and observed effects, and updated data files.

## Avoid

- Buffing everything until nothing stands out.
- Tuning from anecdotes when data is available.
- Hiding the maths in code where designers cannot see or change it.

---
name: accessibility
description: Use when designing or reviewing controls, UI, audio, difficulty, motion or text. Covers remapping, readability, colour, subtitles, motion sensitivity and difficulty options, planned from the start.
---

# Accessibility

Draft from the Game studio skills library by THE DREAMING JESTER. Adapt it to your game, team and engine.

## Goal

Remove barriers that stop people from playing, without removing the challenge the game is about.

## Before you start

- Identify the core challenge. Accessibility options should keep that intact while removing unrelated barriers.
- Review the platform's accessibility guidelines and any certification requirements.

## Process

1. Controls: full remapping, hold or toggle alternatives, adjustable sensitivity, and no required simultaneous inputs without an alternative.
2. Vision: scalable text, strong contrast, no information carried by colour alone, and readable fonts.
3. Hearing: subtitles with speaker names and sizes, captions for important sounds, and visual cues for audio-only information.
4. Motion: options to reduce camera shake, flashing, motion blur and head bob; respect system reduced-motion settings where available.
5. Cognition: clear objectives, a way to review instructions, and adjustable game speed or timers where they are not the core challenge.
6. Difficulty: separate options for combat, puzzles and timing where it makes sense.
7. Test with players who use these features, and keep the options consistent across menus.

## Quality bar

- Every essential action can be remapped.
- Every essential sound has a visual equivalent.
- Options are available before the first gameplay, including on first launch.

## Output

An accessibility checklist for the game, the options list with defaults, and test notes.

## Avoid

- Adding options late, when the UI and input systems cannot support them.
- Hiding accessibility settings deep in menus.

---
name: art-direction
description: Use when setting or reviewing a game's visual style, creating style guides, giving art feedback or checking that new assets fit. Keeps shape, colour, value and detail consistent with gameplay readability.
---

# Art direction

Draft from the Game studio skills library by THE DREAMING JESTER. Adapt it to your game, team and engine.

## Goal

Give the game one recognisable visual language that also makes gameplay easy to read.

## Before you start

- Collect the pillars: tone, setting, audience, platform and camera.
- Gather reference with a reason for each image. Reference without a reason becomes a mood board, not a direction.

## Process

1. Define shape language: what shapes mean friendly, dangerous, interactive and background.
2. Define a value structure first, then colour. Gameplay-critical elements must read in greyscale.
3. Set a palette with roles: environment, characters, threats, interactables, UI and effects.
4. Set detail density rules: where detail goes, where the eye rests, and what stays simple.
5. Write a style guide with do and don't examples for each asset type.
6. Review assets in the game, at gameplay distance and under real lighting, not only in isolation.
7. Give feedback as a target and a reason: what to change and how it serves readability or style.

## Quality bar

- A screenshot is recognisable with the UI removed.
- Threats and interactables stand out from the background at gameplay distance.
- New assets pass the style guide without needing the art director in the room.

## Output

Style guide, palette and value rules, annotated reference, and review notes per asset.

## Avoid

- Approving assets from turntables only.
- Colour carrying meaning that value and shape do not support.

---
name: technical-art
description: Use when building shaders, VFX, materials, LODs, import pipelines or performance budgets for art. Bridges artists and engineers, balancing visual quality against frame time and memory.
---

# Technical art

Draft from the Game studio skills library by THE DREAMING JESTER. Adapt it to your game, team and engine.

## Goal

Get the look the art direction wants within the frame-time, memory and workflow limits the game can afford.

## Before you start

- Know the target hardware, frame rate and resolution, and the current budgets for draw calls, triangles, texture memory and shader cost.
- Profile the current scene before changing anything.

## Process

1. Agree budgets per asset type and per scene with art and engineering, and write them down.
2. Build shaders and materials as reusable masters with parameters, not one-offs.
3. Validate on target hardware early: overdraw, shader complexity, texture streaming and particle counts.
4. Use dithering, tone mapping and correct colour spaces to avoid banding and washed-out results.
5. Automate checks in the import pipeline: naming, scale, pivots, texture sizes, compression and LODs.
6. Document how artists use each tool or shader, with examples and limits.
7. Keep a performance view in the editor so artists see the cost of their work.

## Quality bar

- Every scene meets its budget on the lowest target hardware.
- Artists can make common changes without engineering help.
- Visual quality holds at every supported quality setting.

## Output

Budgets, master materials and shaders, pipeline checks, tool documentation and profiling captures.

## Avoid

- One-off shaders that nobody else can maintain.
- Discovering budget problems after content lock.

---
name: animation
description: Use when creating or reviewing character, creature, vehicle or UI animation, animation state machines and game feel. Balances readability, responsiveness and appeal.
---

# Animation

Draft from the Game studio skills library by THE DREAMING JESTER. Adapt it to your game, team and engine.

## Goal

Make motion that communicates intent, responds instantly to input and has personality.

## Before you start

- Know the gameplay timings the animation must support: wind-ups, active frames, recovery, cancels and movement speeds.
- Agree the camera distance and the poses that must read in silhouette.

## Process

1. Block key poses first and check silhouettes at gameplay distance.
2. Fit timing to gameplay: anticipation long enough to read, but short enough that input feels immediate.
3. Respond to input within the first frame or two; use blending, layering or additive animation rather than delaying control.
4. Build state machines with clear entry and exit conditions and no dead ends.
5. Add secondary motion, impact frames, camera response and effects only after the timing works.
6. Test in game with real input, not only in the animation editor.

## Quality bar

- Every attack or threat is readable before it lands.
- Players never feel input lag caused by animation.
- Transitions do not pop, slide or foot-skate noticeably at gameplay distance.

## Output

Animation sets, state machine diagrams, timing tables shared with design, and in-game captures.

## Avoid

- Polishing animation before gameplay timing is locked.
- Root motion that fights the movement system.

---
name: asset-generation
description: Use when producing concept art, icons, portraits, textures or other assets through generation tools or scripted pipelines. Keeps outputs consistent with the art direction, traceable and reviewable, with rights checked.
---

# Asset generation workflow

Draft from the Game studio skills library by THE DREAMING JESTER. Adapt it to your game, team and engine.

## Goal

Generate art quickly without losing consistency, quality or traceability.

## Before you start

- Read the style guide and confirm the asset types, sizes, formats and naming the game expects.
- Check the licence and terms of every tool, model and source image. Record what is allowed for commercial use.

## Process

1. Define a recipe per asset type: tool, model or version, settings, prompt structure, reference inputs and post-processing steps.
2. Keep recipes in version control next to the assets, so any asset can be regenerated or explained.
3. Generate in batches with consistent seeds or references, then select against the style guide.
4. Post-process for the game: crop, clean up, colour-correct, resize and compress to the target format.
5. Check at gameplay size and in context, next to existing assets.
6. Record provenance for every shipped asset: recipe, inputs, date and who approved it.
7. Hand-correct anything that breaks readability, anatomy, text or brand rules.

## Quality bar

- Assets from different batches look like they belong to the same game.
- Every shipped asset can be traced to its recipe and approval.
- Nothing ships with unresolved rights questions.

## Output

Recipes, generated and approved assets, a provenance log and a rejected-variants archive where useful.

## Avoid

- One-off prompts that cannot be reproduced.
- Shipping generated text or symbols without checking them.

---
name: audio-design
description: Use when designing or reviewing sound effects, music, mixing, audio feedback and audio implementation. Prioritises gameplay information, clarity in the mix and performance.
---

# Audio design

Draft from the Game studio skills library by THE DREAMING JESTER. Adapt it to your game, team and engine.

## Goal

Use sound to tell the player what is happening, especially what they cannot see, while setting the mood.

## Before you start

- List gameplay events that need audio feedback, ranked by importance.
- Know the target platforms, voice limits, memory budget and middleware.

## Process

1. Give priority sounds a distinct identity: threats, hits, pickups, low health and objectives.
2. Design for repetition: variations, pitch and volume randomisation, and cooldowns for frequent sounds.
3. Mix by priority with ducking and voice limits, so important sounds cut through busy moments.
4. Use spatial audio deliberately: direction and distance should match what the player needs to locate.
5. Let music follow game state through layers or transitions, without abrupt cuts.
6. Test on the speakers and headphones players use, at realistic volumes.
7. Provide separate volume controls and captions for important sounds.

## Quality bar

- Players can identify the main threats with their eyes closed.
- Busy combat never masks critical cues.
- Frequent sounds do not become irritating after an hour.

## Output

An audio event list with priorities, implemented events, a mix snapshot plan and performance figures.

## Avoid

- Mixing only on studio monitors.
- Every sound at full volume, so nothing stands out.

---
name: gameplay-programming
description: Use when implementing or changing gameplay features: player control, abilities, AI behaviour, items, rules and game state. Favours data-driven design, small testable systems and fast iteration.
---

# Gameplay programming

Draft from the Game studio skills library by THE DREAMING JESTER. Adapt it to your game, team and engine.

## Goal

Implement mechanics so designers can tune them, engineers can trust them and the game feels right.

## Before you start

- Read the design brief and agree the parts likely to change. Those belong in data, not code.
- Read the existing systems before adding new ones. Extend patterns already in use.

## Process

1. Get a rough version playable fast, then refine. Feel is found in the build, not in documents.
2. Move tunable values into data files or resources that designers can edit without a code change.
3. Keep systems small with clear inputs and outputs. Avoid hidden coupling through globals or singletons.
4. Make state explicit: what can happen in each state, and what causes transitions.
5. Handle timing deliberately: fixed versus variable update, input buffering and frame-rate independence.
6. Add debug views and cheats for the feature, so it can be tested quickly.
7. Write tests for rules and edge cases that can be tested outside the engine loop.

## Quality bar

- Designers can tune the feature without engineering help.
- The feature behaves the same at different frame rates.
- Edge cases (death mid-action, disconnects, pausing, saving) are handled.

## Output

Feature code, data definitions, debug tools, tests and a short note on how to tune it.

## Avoid

- Magic numbers in code.
- Building a general framework before the second use case exists.

---
name: engine-programming
description: Use when modifying a game engine or its core systems, including maintaining an engine fork: rendering, memory, threading, scripting, editor integration and upstream merges. Prioritises stability, measurement and maintainability.
---

# Engine programming

Draft from the Game studio skills library by THE DREAMING JESTER. Adapt it to your game, team and engine.

## Goal

Improve the engine without destabilising the games built on it, and keep the fork maintainable.

## Before you start

- Understand the subsystem you are changing, its callers and its tests.
- For a fork, know where it diverges from upstream and why. Check whether upstream already solves the problem.

## Process

1. Write down the problem with evidence: a profile, a crash, a workflow cost or a missing capability.
2. Choose the least invasive change. Prefer extension points, modules or plugins over editing core files.
3. Keep fork changes isolated and labelled, so upstream merges stay manageable.
4. Measure before and after on target hardware: frame time, memory, load time and build time.
5. Add tests or reproducible benchmark scenes for the change.
6. Document the change for engine users: what changed, how to use it, and migration steps.
7. Merge upstream regularly. Small, frequent merges cost less than rare, large ones.

## Quality bar

- No regressions in existing projects or test scenes.
- Every divergence from upstream has a recorded reason.
- Performance claims are backed by measurements.

## Output

The engine change, tests or benchmark scenes, measurements, documentation and a divergence log entry.

## Avoid

- Large rewrites without a measured problem.
- Letting the fork drift so far that upstream fixes cannot be merged.

---
name: multiplayer-networking
description: Use when designing or implementing online multiplayer: authority models, replication, prediction, lag compensation, matchmaking, sessions and network testing. Plans for latency, cheating and failure from the start.
---

# Multiplayer networking

Draft from the Game studio skills library by THE DREAMING JESTER. Adapt it to your game, team and engine.

## Goal

Make multiplayer feel responsive and fair under real network conditions, and hard to cheat.

## Before you start

- Decide the authority model: dedicated server, listen server, or peer-to-peer, and why.
- Know the player count, session length, target regions and expected latency.

## Process

1. Classify state: what the server owns, what clients predict, and what is purely cosmetic.
2. Replicate only what clients need, at the rate they need it. Budget bandwidth per player.
3. Use client-side prediction and reconciliation for the local player's movement and actions.
4. Use interpolation for remote entities, and lag compensation where hit detection depends on timing.
5. Validate every client request on the server. Never trust client-reported results.
6. Handle joins, leaves, reconnects, host migration and session end explicitly.
7. Test with simulated latency, jitter and packet loss from the first prototype, not only on a local network.
8. Log network metrics: round-trip time, packet loss, bandwidth and desyncs.

## Quality bar

- The game is playable at the target maximum latency.
- No client can grant itself items, damage or position the server would reject.
- Disconnects and reconnects do not corrupt game state.

## Output

An authority and replication plan, the implementation, network test results and metrics dashboards.

## Avoid

- Adding networking to a single-player architecture late.
- Testing only on a local network.

---
name: tools-pipeline
description: Use when building editor tools, importers, build scripts, content validation or automation. Starts from the team's real bottlenecks and measures time saved.
---

# Tools and pipeline

Draft from the Game studio skills library by THE DREAMING JESTER. Adapt it to your game, team and engine.

## Goal

Remove the repetitive, error-prone steps that slow the team down.

## Before you start

- Watch people work. Find the tasks that are slow, frequent or often wrong.
- Estimate the time a tool would save against the time to build and maintain it.

## Process

1. Pick the bottleneck with the best saving for the effort.
2. Build the smallest tool that removes it, inside the tools people already use.
3. Validate content at import or save time with clear, actionable error messages.
4. Make tools safe: undo, previews, dry runs and no silent destructive changes.
5. Automate builds and checks so every change is built and tested the same way.
6. Write short usage notes with examples, and show the tool to the people who will use it.
7. Measure the result: time saved, errors prevented and adoption.

## Quality bar

- People choose to use the tool without being told.
- Errors point to the exact asset and the fix.
- The tool is maintained and has an owner.

## Output

The tool or pipeline step, documentation, and a before-and-after measure.

## Avoid

- Tools built for imagined workflows.
- Validation that blocks work without explaining how to fix it.

---
name: performance-optimisation
description: Use when the game misses frame-rate, memory, loading or battery targets, or before a milestone. Profiles on target hardware, fixes the largest costs first and guards against regressions.
---

# Performance and optimisation

Draft from the Game studio skills library by THE DREAMING JESTER. Adapt it to your game, team and engine.

## Goal

Hit the performance targets on the lowest supported hardware, and keep hitting them.

## Before you start

- Set targets: frame time, memory, load time and, on mobile, thermal and battery limits.
- Choose repeatable test scenes and camera paths, including the worst cases.

## Process

1. Profile on target hardware, not only on development machines.
2. Find whether each frame is CPU bound, GPU bound or waiting on I/O or synchronisation.
3. Fix the largest cost first. Small optimisations of cold code waste time.
4. Common wins: fewer draw calls and state changes, culling, LODs, pooling, caching, avoiding per-frame allocation and batching work.
5. Measure after every change in the same scene, and keep the captures.
6. Add automated performance tests or budgets to catch regressions.

## Quality bar

- Targets are met in the worst-case scenes on minimum hardware.
- Every optimisation has before-and-after numbers.
- Regressions are caught before they reach players.

## Output

Profiles, a ranked list of costs, the fixes with measured gains, and regression checks.

## Avoid

- Optimising by intuition without profiling.
- Trading readability for micro-gains that do not move the frame time.

---
name: analytics-telemetry
description: Use when adding telemetry, defining metrics, building dashboards or using player data to make design decisions. Starts from questions, respects privacy and turns data into specific changes.
---

# Analytics and telemetry

Draft from the Game studio skills library by THE DREAMING JESTER. Adapt it to your game, team and engine.

## Goal

Answer real design questions with data, quickly enough to change the next build.

## Before you start

- Write the questions first: where do players quit, which options do they pick, how long does progress take?
- Check privacy law, platform rules and your own policy. Collect only what answers a question.

## Process

1. For each question, define the metric and the events needed to compute it.
2. Name events consistently with a version, a timestamp, a session and build identifier, and only the properties needed.
3. Validate events in development: fire each one and check it arrives with the right data.
4. Build a small dashboard per question rather than one dashboard for everything.
5. Compare by build, so every change can be judged against the previous version.
6. Turn findings into a decision: keep, change or cut, and say what will be measured next.
7. Remove events that no longer answer a question.

## Quality bar

- Every event maps to a question.
- Builds are comparable, and changes are judged with data where data exists.
- No personal data is collected without a clear need and consent.

## Output

An event specification, validated instrumentation, focused dashboards and a decision log.

## Avoid

- Tracking everything and analysing nothing.
- Drawing conclusions from tiny samples without saying so.

---
name: playtesting
description: Use when planning, running or analysing playtests, from quick hallway tests to structured sessions. Focuses on observed behaviour, clear questions and actionable findings.
---

# Playtesting

Draft from the Game studio skills library by THE DREAMING JESTER. Adapt it to your game, team and engine.

## Goal

Learn what players actually do and feel, and turn that into specific changes.

## Before you start

- Write two or three questions the test must answer.
- Choose testers who match the target audience and have not seen the build, where possible.

## Process

1. Prepare a stable build, a short script and a way to record screen, input and voice with consent.
2. Give minimal instructions. Do not explain what the game should already communicate.
3. Watch more than you ask: where players look, hesitate, fail and smile.
4. Ask open questions afterwards: what were you trying to do, what was confusing, what would you do next?
5. Separate observations from opinions and suggestions. Weight observed behaviour highest.
6. Group findings by frequency and severity, and link each to a proposed change.
7. Retest the changes with new players.

## Quality bar

- Findings cite what was observed, not only what was said.
- Each finding has a severity, a frequency and an owner.
- The next test checks whether the changes worked.

## Output

A test plan, recordings or notes, and a ranked findings report with proposed changes.

## Avoid

- Leading questions and explaining the game during the test.
- Treating one player's request as a requirement.

---
name: production-planning
description: Use when planning milestones, scoping features, sequencing work, tracking progress or managing risk. Keeps scope honest, dependencies visible and decisions recorded.
---

# Production planning

Draft from the Game studio skills library by THE DREAMING JESTER. Adapt it to your game, team and engine.

## Goal

Ship the game that matters most, within the time and people available.

## Before you start

- Know the fixed constraints: dates, budget, team, platforms and commitments.
- Gather the feature list with rough sizes and the dependencies between them.

## Process

1. Define milestones by what is playable and proven, not by tasks completed.
2. Rank features by value to the player and risk. Do the risky, valuable work first.
3. Split work into pieces small enough to finish in a few days, with a clear definition of done.
4. Make dependencies visible, especially across disciplines.
5. Track progress against the plan weekly. When reality differs, change scope before changing quality or people's hours.
6. Keep a risk list with owners and mitigations, and review it regularly.
7. Record decisions and why they were made.

## Quality bar

- Anyone can see what is in, what is out and why.
- Milestones end with a playable build and a review.
- Scope cuts happen early and deliberately, not at the last minute.

## Output

A milestone plan, a ranked backlog, a risk list and a decision log.

## Avoid

- Plans that assume everything goes right.
- Hiding slipping work until it cannot be recovered.

---
name: pull-requests
description: Use when preparing or updating a pull request: scoping the change, writing the description, adding evidence and responding to review. Makes changes small, explained and easy to verify.
---

# Pull requests

Draft from the Game studio skills library by THE DREAMING JESTER. Adapt it to your game, team and engine.

## Goal

Make every change easy to review, safe to merge and easy to understand later.

## Before you start

- Confirm the change does one thing. Split refactors from behaviour changes.
- Run the project's own checks and tests locally.

## Process

1. Keep the diff small and focused. Large changes should arrive in a reviewable sequence.
2. Write a title that says what changes, not how it was done.
3. Describe why, what changed, how it was tested and any risks or follow-ups.
4. Add evidence: screenshots or captures for visual changes, profiles for performance, steps to reproduce for fixes.
5. Call out anything the reviewer should look at closely.
6. Respond to every review comment: change the code or explain why not.
7. Keep the branch up to date and green until it merges.

## Quality bar

- A reviewer understands the change from the description alone.
- Checks pass before review is requested.
- Unrelated formatting and generated-file churn are left out.

## Output

A focused pull request with a clear description, evidence and passing checks.

## Avoid

- Mixing unrelated changes.
- "Fixed stuff" descriptions.

---
name: code-review
description: Use when reviewing a pull request or diff. Looks for correctness, edge cases, performance, security and maintainability, and gives clear, prioritised feedback.
---

# Code review

Draft from the Game studio skills library by THE DREAMING JESTER. Adapt it to your game, team and engine.

## Goal

Catch problems before they reach players, and help the author improve the change.

## Before you start

- Read the description and the linked design or issue so you know what the change should do.
- Check that the automated checks have passed.

## Process

1. Understand the intent, then read the diff with it in mind.
2. Check correctness first: logic, edge cases, error handling, state, threading and timing.
3. Check game-specific risks: frame-rate dependence, save compatibility, network authority, memory and per-frame allocation.
4. Check security and data handling where players, accounts or networks are involved.
5. Check clarity: names, structure and comments where intent is not obvious.
6. Run or play the change when behaviour or feel matters.
7. Label feedback by priority: must fix, should fix, or optional suggestion. Explain why for each.

## Quality bar

- Blocking issues are clearly marked and explained.
- Feedback is about the code, specific and actionable.
- Approval means you would be comfortable shipping it.

## Output

Prioritised review comments and an explicit decision: approve, request changes or comment.

## Avoid

- Style debates that a formatter should settle.
- Approving changes you did not understand.

---
name: qa-testing
description: Use when testing builds, writing test plans, exploring features, reproducing bugs or writing bug reports. Combines planned coverage with exploratory testing and precise reports.
---

# QA testing

Draft from the Game studio skills library by THE DREAMING JESTER. Adapt it to your game, team and engine.

## Goal

Find the problems players would hit, and report them so they can be fixed quickly.

## Before you start

- Know what changed in the build and the areas at most risk.
- Get the target platforms, settings and accounts needed for testing.

## Process

1. Write a test plan for new features: the happy path, edge cases, failure cases and interactions with other systems.
2. Run smoke tests on every build: launch, core loop, save and load, and quit.
3. Explore with intent: try unusual inputs, orders, timings, settings and disconnects.
4. When you find a bug, reproduce it and find the shortest steps.
5. Report with a clear title, build, platform, steps, expected and actual results, frequency and severity, plus a capture or log.
6. Verify fixes in the build where they land, and check for regressions nearby.
7. Track trends: which areas produce the most bugs, and why.

## Quality bar

- Developers can reproduce reported bugs from the report alone.
- Severity reflects player impact, not tester frustration.
- Every fix is verified before the bug is closed.

## Output

Test plans, smoke-test results, bug reports and verification notes.

## Avoid

- Vague reports such as "it crashes sometimes".
- Testing only the happy path.

---
name: release-management
description: Use when preparing, approving or publishing a build or update: release branches, version numbers, checklists, store submissions, sign-off, release notes, monitoring and rollback.
---

# Release management

Draft from the Game studio skills library by THE DREAMING JESTER. Adapt it to your game, team and engine.

## Goal

Release builds predictably, with no surprises for the team or players.

## Before you start

- Know the release date, platforms, store requirements and certification lead times.
- Know who signs off and what must be true before release.

## Process

1. Cut a release branch or tag at a known state, and control what enters it after that.
2. Version every build consistently, and make the version visible in the game.
3. Run the release checklist: full test pass, performance targets, crash rate, save compatibility, legal and ratings text, and store assets.
4. Get explicit sign-off from the agreed owners.
5. Write release notes for players: what changed, in plain language.
6. Release in stages where the platform allows, and monitor crashes, errors and player feedback.
7. Keep a rollback or hotfix plan ready, and practise it.
8. Hold a short review afterwards and update the checklist.

## Quality bar

- Anyone can tell exactly which code and content is in a build.
- Releases follow the checklist every time.
- Problems after release are detected and handled quickly.

## Output

A tagged build, a completed checklist, sign-off, release notes and a monitoring and rollback plan.

## Avoid

- Last-minute changes that skip testing.
- Releasing without a way back.