Study Guide: Alex for Game Developers

Your reference for applying Alex to game design documentation, systems balancing, narrative design, technical architecture, and playtesting analysis. Ready-to-run prompts — built around the hard parts of shipping games, not the game jam tutorials.

What This Guide Is Not

This is not a habit formation guide (see Self-Study Guide for that). This is a domain use-case library — the specific ways Alex supports professional game development work.

Where to Practice These Prompts

Every prompt in this guide works with any AI assistant you already use — GitHub Copilot, ChatGPT, Claude, Gemini, or others. The prompts are the skill; the tool is just where you type them. If you already have a preferred tool, start there.

For the deepest experience, the Alex VS Code extension (free) was built for these workflows. It understands game development context, lets you save what works with /saveinsight, and keeps your study guide and exercises right inside the editor where you already work.

You don’t need a specific tool to benefit. You need the discipline of reaching for AI when the work is genuinely hard — not just when it’s repetitive.

Core Principle for Game Developers

Game development is the intersection of engineering, art, and design under the constraint that the result must be fun — which is subjective, emergent, and impossible to specify in a requirements document. The hardest problems in game development are not technical; they are design problems disguised as technical problems: performance budgets that constrain art direction, networking architectures that limit game feel, and scope decisions that determine whether a game ships or dies in development.

Your primary discipline with Alex: use it to think through systems interactions, document design decisions before they get lost, and analyze playtest feedback for patterns your intuition might miss.

The Seven Use Cases

1. Game Design Documentation (GDDs)

The game developer’s documentation challenge: Game design documents are either 200 pages that no one reads or a wiki that is perpetually out of date. The real design knowledge lives in the heads of the design team, and it walks out the door when people leave. The discipline of design documentation is not writing everything down — it is writing down the decisions that would be expensive to rediscover.

Prompt pattern:

I need to document [game system/feature/mechanic].
Core loop: [how the player interacts with this system].
Design intent: [what experience this is trying to create].
Constraints: [platform, performance budget, team size, timeline].
Current state: [prototyped / in production / shipped but needs redesign].

Help me:
1. Structure this as a design specification that a new team member could implement from
2. Identify the design decisions that are implicit — the things "everyone knows" but no one has written down
3. Find the edge cases in the player experience that the design has not addressed
4. Separate the design intent (what we want the player to feel) from the implementation (how we achieve it)

Try this now: You are documenting the progression system for an open-world RPG. Players can progress through combat, crafting, or exploration, and the design team disagrees about whether these should share a unified XP pool or have independent tracks. Use the GDD prompt to capture both positions, the tradeoffs, and the playtesting criteria that will resolve the disagreement — before anyone writes code.

2. Systems Design and Balancing

The game developer’s balancing challenge: Game systems are interconnected in ways that create emergent behavior — which is the point of systems design and also the nightmare of systems design. Changing one variable (weapon damage, resource cost, cooldown timer) cascades through the entire economy. The developer who balances well is the one who can predict second-order effects before they reach players.

Prompt pattern:

I need to balance [game system: economy, combat, progression, crafting, matchmaking].
Current state: [describe the system — variables, relationships, player feedback].
Problem: [what is broken — too easy, too punishing, exploitable, boring at endgame].
Constraints: [what I cannot change without breaking other systems].
Data available: [telemetry, playtest reports, player feedback, internal testing].

Help me:
1. Map the variable relationships — what affects what, and with what magnitude?
2. Identify the dominant strategy that players have found (or will find)
3. Propose three adjustment approaches with predicted player impact
4. Design an A/B test or telemetry plan to validate the change before full rollout

3. Narrative Design and World Building

The game developer’s narrative challenge: Narrative in games is not a screenplay — it is a system. Player agency means the story must accommodate multiple paths, variable pacing, and the possibility that the player ignores your carefully crafted narrative entirely. The failure mode is writing a great story that the game undermines, or building game mechanics that the story ignores.

Prompt pattern:

I am designing narrative for [game/feature/quest/dialog system].
Genre and tone: [describe the world, mood, and player fantasy].
Player agency level: [linear / branching / open-world / emergent].
Integration points: [how narrative connects to gameplay — quests, dialog, environmental, UI].
Constraints: [voice acting budget, localization, technical limitations].

Help me:
1. Identify where narrative and gameplay are in tension — where does the story ask the player to do something the mechanics discourage?
2. Design branching structures that feel meaningful without exponential content costs
3. Write character dialog that reveals character through specificity, not exposition
4. Find the environmental storytelling opportunities I am not using

4. Technical Architecture and Performance

The game developer’s technical challenge: Game engines are real-time systems with hard performance budgets. The frame must complete in 16.67ms (60fps) or 33.33ms (30fps), and everything — rendering, physics, AI, networking, audio — must fit. The architect who builds game systems well understands not just what the code does but when it runs in the frame, how much memory it touches, and what happens when it takes longer than expected.

Prompt pattern:

I am designing the technical architecture for [system: rendering pipeline, networking, AI, physics, save system, procedural generation].
Engine: [Unity / Unreal / Godot / custom].
Platform targets: [PC, console, mobile — specify constraints].
Performance budget: [frame time allocation, memory limit, draw call budget].
Current bottleneck: [what is too slow or too expensive].

Help me:
1. Identify the architectural patterns appropriate for this system on these platforms
2. Find the memory and CPU hotspots I should profile first
3. Design the system boundary — what runs every frame vs. amortized vs. async?
4. Recommend the data layout that minimizes cache misses for this access pattern

5. Playtesting Analysis and Player Research

The game developer’s research challenge: Raw playtest feedback is a mix of valid observations, personal preferences, and solutions to problems the player cannot articulate. The developer who handles feedback well separates what the player experienced (reliable) from what the player recommends (unreliable — they are not designers) and looks for patterns across multiple playtesters rather than reacting to individual outliers.

Prompt pattern:

Here is playtest feedback from [number] testers for [game/feature]:
[Paste consolidated feedback — quotes, survey results, telemetry, or session notes]

Help me:
1. Identify the top 3 recurring themes — what are multiple people experiencing?
2. Separate "player felt" (valid signal) from "player suggested" (may not address actual issue)
3. Find the contradictions — where do different players want opposite things?
4. Prioritize issues by: impact on core loop × frequency × effort to fix

6. Production Planning and Scope Management

The game developer’s scope challenge: Games are cut, not finished. The discipline of shipping a game is the discipline of cutting the right things — removing content and features that do not serve the core experience without hollowing out what makes the game compelling. The failure mode is cutting late and badly (removing load-bearing features under deadline pressure) rather than cutting early and intentionally.

Prompt pattern:

I need to scope [game/feature/milestone].
Core experience: [the 1-sentence player fantasy that must be protected].
Feature list: [everything currently planned].
Resources: [team size, timeline, budget].
Risk areas: [where things are behind or uncertain].

Help me:
1. Identify the features that are load-bearing (cut them and the game falls apart) vs. nice-to-have
2. Propose three scope tiers: minimum viable, target, and aspirational
3. Find the dependencies I have not mapped — what blocks what?
4. Design the cut plan: what gets cut first, with what impact on player experience?

7. Post-Launch Operations and Live Service

The game developer’s live-ops challenge: A shipped game is the beginning, not the end. Live service means maintaining a relationship with players through content updates, balance patches, community management, and data-driven decision making — all while the original development team may have partially moved on.

Prompt pattern:

I need to plan [post-launch activity: content update, balance patch, seasonal event, community response].
Game state: [current player sentiment, retention data, reported issues].
Resources: [live team size, available development time].
Priority: [player retention / new content / technical debt / community trust].

Help me:
1. Prioritize changes by player impact — what moves retention or satisfaction most?
2. Design the communication plan (patch notes that inform rather than disappoint)
3. Identify the changes that seem small but have large systemic effects
4. Plan the rollback strategy if the update introduces new problems

What Great Looks Like

After consistent use, you should notice:

• Design decisions are documented before they are forgotten — new team members can understand why systems work the way they do
• Systems balancing is more deliberate — changes are predicted before they are deployed
• Playtest feedback produces actionable insights, not reactive feature changes
• Technical architecture decisions account for platform constraints from the start
• Scope management is proactive — you are cutting intentionally rather than panicking at the end

The game developer who will thrive in an AI-augmented environment is not the one who generates assets or code fastest. It is the one who thinks most clearly about player experience, systems interactions, and the tradeoffs that determine whether a game ships and whether it is good.

Your AI toolkit: These prompts work in ChatGPT, Claude, Copilot, Gemini — and in the Alex VS Code extension, which was designed around them. Start with whatever you have. The skill transfers across all of them.

Your First Week Back: Practice Plan

Month 2–3: Advanced Applications

Design Decision Archive

Build a queryable history of design choices:

/saveinsight title="Design: [system/feature]" insight="Decision: [what we chose]. Alternatives: [what we rejected and why]. Player impact: [observed or predicted]. Revisit if: [conditions]." tags="game-design,decision"

Balancing Change Log

Track balance changes and their actual impact:

/saveinsight title="Balance: [change description]" insight="Variable changed: [what]. From: [old value] To: [new value]. Expected impact: [prediction]. Actual impact: [measured result]. Side effects: [unintended consequences]." tags="game-design,balancing"

Continue your practice: Self-Study Guide — the 30/60/90-day habit guide.