Claude Code for Game Developers: Advanced Techniques Beyond the Setup Guide

If you have followed our setup guide and have Claude Code running with MCP servers connected, you are past the beginner stage. You can ask Claude to place actors, modify materials, and generate code. That is genuinely useful, but it is the equivalent of learning to drive in a parking lot. The real productivity gains come from advanced patterns that most game developers never discover because the documentation focuses on general software development rather than game-specific workflows.

This post covers the techniques we use daily at StraySpark — patterns we have developed through months of Claude Code usage across Unreal Engine and Godot projects. Some of these are specific to game development; others are general Claude Code techniques applied to game dev problems. All of them assume you are comfortable with the basics and ready to push further.

Custom Slash Commands for Game Dev

Claude Code supports custom slash commands — reusable prompt templates that you invoke with a / prefix. For game developers, these are transformative because game dev involves so many recurring operations with slight variations.

Setting Up Custom Commands

Custom commands live in your project's .claude/commands/ directory as markdown files. The filename becomes the command name.

Create the directory structure:

your-project/
├── .claude/
│   └── commands/
│       ├── scene-audit.md
│       ├── blueprint-scaffold.md
│       ├── material-setup.md
│       └── perf-check.md

Each file contains a prompt template that Claude executes when you invoke the command.

Essential Game Dev Commands

Here are the commands we use most frequently.

/scene-audit — Comprehensive scene health check:

Perform a comprehensive audit of the current Unreal Engine level. Check for:

1. **Missing references** — actors with broken asset references
2. **Performance red flags** — point lights without attenuation limits,
   meshes without Nanite enabled, translucent materials in the scene
3. **Naming violations** — actors not following the naming convention
   (BP_ prefix for Blueprints, SM_ for static meshes, etc.)
4. **Transform anomalies** — actors with non-uniform scale, actors at
   world origin that probably should not be, actors below the kill-Z
5. **Collision issues** — meshes with complex collision that should use
   simple, overlapping actors without proper collision channels

Report findings grouped by category with severity levels (critical,
warning, info). For critical issues, suggest specific fixes.

This command replaces 15-20 minutes of manual scene inspection with a 30-second automated audit. We run it before every milestone check-in.

/blueprint-scaffold — Generate a gameplay component:

Create an Unreal Engine Blueprint component with the following specifications:

Component name: $ARGUMENTS

Follow these conventions:
- Use our project's component architecture (ActorComponent base,
  event-driven communication via delegates)
- Include standard lifecycle functions (BeginPlay, EndPlay, TickComponent)
- Add UPROPERTY declarations with appropriate categories and metadata
- Create delegate declarations for key state changes
- Include basic replication setup if the component manages gameplay state
- Add inline documentation comments explaining the component's purpose

Generate the component in the editor and report what was created.

The $ARGUMENTS placeholder is replaced with whatever you type after the command. So /blueprint-scaffold HealthComponent with damage types and shields generates a fully specified health component.

/perf-check — Quick performance snapshot:

Capture a performance snapshot of the current scene:

1. Count total actors by type (static mesh, skeletal mesh, lights, etc.)
2. Report Nanite-enabled vs non-Nanite mesh count
3. Count draw calls if available through stat commands
4. Identify the 5 most expensive materials in the scene (by instruction count)
5. Check for common performance issues:
   - Excessive point light overlap
   - Skeletal meshes ticking when not visible
   - Particle systems without LOD
   - Unbounded reflection captures

Present results as a concise performance scorecard with actionable
recommendations for the top 3 issues.

/material-setup — Create a material instance with standard parameters:

Create a material instance for the following use case: $ARGUMENTS

Use these conventions:
- Parent material should be the appropriate master material from our
  library (M_Standard_Master for props, M_Landscape_Master for terrain,
  M_Foliage_Master for vegetation)
- Set physically plausible base values for the material type described
- Enable/disable material features based on the use case (SSS for skin
  and vegetation, emissive for lights and screens, etc.)
- Name the instance following our convention: MI_[Category]_[Name]

Create the material instance in the editor and report the parameters set.

Command Composition

Advanced users chain commands together. Claude Code maintains conversation context between command invocations within a session, so you can:

Run /scene-audit to identify issues
Then say "fix all the critical issues you just identified"
Then run /perf-check to verify improvements

This three-step pattern takes under two minutes and replaces what would otherwise be a 30-minute manual audit-and-fix cycle.

Project-Specific Commands

The commands above are generic. The real power comes from project-specific commands that encode your team's conventions, your game's systems, and your production pipeline.

For example, if your game has a specific quest creation workflow:

/new-quest:

Create a new quest with the following details: $ARGUMENTS

Follow our quest creation pipeline:
1. Create a quest Data Asset in /Game/Data/Quests/ following naming
   convention QD_[QuestID]_[ShortName]
2. Set up the quest objectives based on the description
3. Create associated dialogue entries if the quest involves NPC interaction
4. Register the quest in the master quest table DT_QuestRegistry
5. Create a test Blueprint that grants and tracks the quest for
   development testing

Report all created assets with their paths.

This kind of command turns a multi-step, error-prone process into a single invocation. Over the course of a project with 50+ quests, the time savings are substantial.

Multi-File Gameplay System Refactoring

Refactoring gameplay systems is one of the highest-value applications of Claude Code in game development. Game systems touch many files — components, interfaces, data assets, Blueprints, UI widgets — and keeping them all consistent during a refactoring pass is where human error creeps in.

The Pattern: Analyze, Plan, Execute, Verify

Do not ask Claude to "refactor the inventory system." That is too vague and leads to unpredictable results. Instead, use a four-phase approach:

Phase 1: Analyze. Ask Claude to read and summarize the current system.

"Read all files related to the inventory system — the InventoryComponent, ItemDataAsset, InventoryWidget, CraftingSubsystem, and any related interfaces or structs. Summarize the current architecture: what communicates with what, what data flows where, and what the dependency graph looks like."

This gives both you and Claude a shared understanding of the current state. Review this summary carefully — if Claude misunderstands the architecture, the refactoring will go wrong.

Phase 2: Plan. Describe the desired end state and ask for a plan.

"I want to refactor the inventory system to separate item storage from item display. Currently InventoryComponent handles both storage logic and UI update notifications. I want: InventoryStorageComponent for pure data storage and manipulation, InventoryUIBridge for translating storage events into UI updates. Plan the changes file by file, listing what moves where and what interfaces change."

Review the plan. This is your opportunity to catch architectural mistakes before they become code changes.

Phase 3: Execute. Approve the plan and let Claude execute.

"Execute the refactoring plan. Make changes file by file, ensuring compilation at each step. After each file change, list the remaining compilation errors so I can track progress."

The "ensure compilation at each step" instruction is important for C++ refactoring in Unreal. If you change 10 files at once, the resulting compilation errors are overwhelming. Changing one file at a time with incremental compilation keeps the error surface manageable.

Phase 4: Verify. After the refactoring is complete, verify the results.

"Run a search across the entire project for any remaining references to the old InventoryComponent public interface that should now use InventoryStorageComponent or InventoryUIBridge. Also check for any Blueprint compilation errors."

Handling Blueprint Refactoring

Blueprints are trickier than C++ for refactoring because they are visual graphs stored in binary (UASSET) files. Claude Code cannot directly read Blueprint graph structures the way it reads C++ files. Through MCP, it can:

Query Blueprint properties, functions, and variables
Modify variable values and component properties
Create new variables and components
Read and modify Blueprint class defaults

What it cannot do (reliably) through MCP:

Rewire node connections in the event graph
Move execution flow between functions
Refactor visual scripting logic

For Blueprint-heavy refactoring, the practical approach is:

Use Claude Code to refactor all the C++ interfaces and base classes
Use Claude Code via MCP to update Blueprint property values and configurations
Manually rewire Blueprint visual scripting to match the new interfaces
Use Claude Code to verify the changes by checking for compilation errors and broken references

This hybrid approach is less elegant than pure AI-driven refactoring, but it is reliable. Blueprint visual scripting is one of the areas where AI tools have not yet reached the level of capability needed for autonomous refactoring.

MCP Server Integration Patterns

If you are using MCP servers, there are interaction patterns that dramatically improve the quality and reliability of results.

The Context Priming Pattern

Before asking Claude to perform complex editor operations, prime its context with the current state.

Bad approach: "Place 20 trees in a forest arrangement."

Better approach: "First, list all vegetation mesh assets in /Game/Environment/Trees/. Then describe the current level's terrain bounds and any existing foliage. Based on that context, place 20 trees in a natural forest arrangement within the terrain bounds, using the available tree meshes."

The context priming step ensures Claude's operations are grounded in reality rather than assumptions. Without priming, it might try to use mesh paths that do not exist or place actors outside your level bounds.

The Checkpoint Pattern

For multi-step operations, insert explicit checkpoints where Claude reports progress and you confirm before continuing.

"I want to set up a village scene. Let's do this in stages:

Stage 1: Place the core buildings. Use house meshes from /Game/Environment/Buildings/. Place 8 houses in a rough circle with a 30-meter radius. Report the placement when done and wait for my approval.

Stage 2 (only after I approve Stage 1): Add a road connecting the buildings. Use the spline road tool to create a dirt road that loops through the village.

Stage 3 (only after I approve Stage 2): Add detail props — market stalls, barrels, crates, hanging signs. Use assets from /Game/Props/Medieval/.

Do Stage 1 now."

This prevents a common failure mode where Claude executes a long sequence of operations, makes a mistake in step 3, and all subsequent steps are built on that mistake. Checkpoints let you catch and correct errors before they compound.

The Undo-Safe Pattern

When experimenting with scene changes, ask Claude to use the editor's undo system to enable easy rollback.

"Make the following changes and keep them within a single undo transaction: adjust all point lights in the tavern interior to color temperature 2700K, reduce intensity by 30%, and increase attenuation radius by 20%. I want to be able to undo this as a single operation if it does not look right."

The Unreal MCP Server supports undo-grouped operations, which means you can treat complex multi-step changes as atomic — either keep all of them or undo all of them.

Cross-Server Workflows

If you have multiple MCP servers connected — for example, the Unreal MCP Server and the Blender MCP Server — Claude can orchestrate cross-tool workflows in a single conversation.

"In Blender, create a simple wooden crate mesh (1m cube with plank-style beveled edges). UV unwrap it and apply a wood material. Export it as FBX to /tmp/crate_export.fbx. Then in Unreal, import that FBX, enable Nanite, create a material instance using M_Wood_Master, and place 5 instances in the current level at random positions within a 10-meter area."

This workflow spans two applications and involves mesh creation, material setup, export, import, and placement — all from a single natural language instruction. The conversation context carries across MCP server boundaries, so Claude understands that the mesh it created in Blender is the same mesh it needs to import in Unreal.

For Godot developers, the Godot MCP Server enables the same pattern. You can have Claude work across Blender and Godot in a single conversation, or even orchestrate a three-way workflow between Blender, Unreal, and Godot if your project spans multiple engines.

Context Management for Large Codebases

Game projects are large. A mid-size Unreal project might have 200+ source files, thousands of assets, and complex dependency graphs. Claude Code's context window is generous but not infinite. Managing context effectively is essential for getting good results on large projects.

The CLAUDE.md File

Every project should have a CLAUDE.md file at the root that gives Claude essential project context. For game projects, include:

# Project: [Game Name]

## Engine and Version
Unreal Engine 5.7.1

## Architecture Overview
- Gameplay systems use component-based architecture on ACharacter/APawn
- Core systems: Health, Inventory, Quest, Dialogue, Abilities
- Data-driven design: gameplay values in DataAssets and DataTables
- Replication: client-server model, server authoritative

## Key Directories
- /Source/GameName/Core/ — base classes and interfaces
- /Source/GameName/Gameplay/ — gameplay components and systems
- /Source/GameName/UI/ — UMG widget classes
- /Content/Data/ — DataAssets and DataTables
- /Content/Blueprints/ — Blueprint classes

## Naming Conventions
- C++ classes: U prefix for UObject, A prefix for AActor
- Blueprints: BP_ prefix
- Materials: M_ for masters, MI_ for instances
- Textures: T_ prefix with suffix (_D diffuse, _N normal, _R roughness)

## Coding Standards
- UPROPERTY: always specify Category, use meta=(DisplayName) for clarity
- UFUNCTION: BlueprintCallable for public API, BlueprintPure for getters
- Delegates: multicast delegates for public events, single-cast for internal
- Error handling: check pointers with ensure(), log warnings, never crash silently

This file is automatically read by Claude Code at the start of each session. It eliminates the need to re-explain your project structure every time.

Focused Context Loading

When working on a specific system, explicitly tell Claude which files are relevant and which are not.

"I'm working on the quest system today. The relevant files are:

/Source/Game/Gameplay/QuestSubsystem.h and .cpp
/Source/Game/Gameplay/QuestComponent.h and .cpp
/Source/Game/Data/QuestDataAsset.h and .cpp
/Source/Game/UI/QuestJournalWidget.h and .cpp

I don't need you to look at any other files unless I specifically ask."

This prevents Claude from spending context window space on irrelevant files and improves response quality by focusing attention on the relevant code.

The Incremental Approach

For large refactoring tasks, work incrementally rather than trying to change everything at once.

Instead of: "Refactor all gameplay systems to use the new event bus."

Do: "Let's migrate systems to the event bus one at a time. Start with the Health system. Read HealthComponent.h and .cpp, understand the current delegate-based communication, and refactor it to use the EventBus. We'll move to Inventory after Health is working."

This keeps context manageable and allows you to verify each migration before moving to the next. It is slower in theory but faster in practice because you catch issues early.

Context Window Recovery

Long Claude Code sessions can exhaust the context window. Signs that you are running out of context:

Claude starts "forgetting" earlier parts of the conversation
Responses become less specific to your project
Claude re-reads files it already read earlier in the session

When this happens, start a new session. Your CLAUDE.md and custom commands carry over automatically, so you lose conversation context but not project context. For continuity, briefly summarize what you were working on at the start of the new session: "I'm continuing a refactoring of the quest system. I've already migrated HealthComponent and InventoryComponent to the event bus. QuestSubsystem is next."

Reusable Prompt Templates for Common Game Dev Tasks

Beyond custom commands, maintain a library of prompt templates for tasks that recur across projects. Here are templates we have refined through extensive use.

Gameplay System Design Review

Review the [SystemName] implementation across these files: [file list].

Evaluate:
1. Does the architecture follow standard UE5 patterns?
2. Are there potential replication issues?
3. Is the system data-driven or hardcoded?
4. Are there single points of failure?
5. How testable is the system in isolation?
6. What would break if we needed to add [common extension]?

Be specific — reference line numbers and function names.

Performance Investigation

I'm seeing [symptom] in my game. Help me investigate:

1. What are the most common causes of [symptom] in Unreal Engine?
2. What stat commands should I run to narrow down the cause?
3. Based on the project structure, which systems are most likely responsible?

Walk me through a diagnostic process, and I'll share the results at each step.

Pre-Merge Code Review

I'm about to merge changes to the [system] system. Review the diff for:

1. Unintended behavioral changes (logic that was supposed to stay the same)
2. Missing null checks or error handling
3. Replication consistency (are new properties replicated correctly?)
4. Blueprint exposure (are new functions accessible from Blueprint where needed?)
5. Threading concerns (is anything accessing game thread data from async?)

Focus on bugs and correctness, not style.

Asset Pipeline Validation

Validate the asset pipeline from Blender to Unreal for [asset type]:

1. Check export settings in the most recent FBX files
2. Verify import settings in Unreal match the project standard
3. Check for common import issues: scale mismatch, flipped normals,
   missing UV channels, material slot mapping
4. Confirm Nanite is enabled on imported meshes where appropriate
5. Verify LOD settings if Nanite is not used

Report any deviations from our standard pipeline.

Advanced MCP Patterns

For developers deep into MCP workflows, these patterns unlock additional capability.

Parallel Operation Batching

When you need to perform the same operation on many assets, describe the pattern once and let Claude batch it:

"For every Static Mesh in /Game/Props/Furniture/, do the following: enable Nanite, set the Nanite fallback LOD to LOD2, set the collision complexity to Use Complex as Simple for meshes under 500 triangles and Simple for meshes over 500 triangles. Process them in batches of 10 and report progress."

The batching instruction prevents Claude from trying to process hundreds of assets in a single MCP call (which can time out) and gives you progress feedback.

Scene State Snapshots

Before making significant scene changes, capture a snapshot:

"List all actors in the current level with their class, name, transform, and key properties. Save this as the 'before' state. I'll ask you to compare against this after we make changes."

This enables a diff-based review: "Compare the current scene state to the 'before' snapshot and list everything that changed." This is invaluable for catching unintended side effects of complex scene modifications.

Conditional Operations

MCP tools can be combined with conditional logic in the AI's reasoning:

"Check each light in the scene. If it is a Point Light with intensity above 10000 and no attenuation radius set, reduce its intensity to 5000 and set attenuation to 1000. If it is a Spot Light with an inner cone angle less than 10 degrees, increase it to 15 degrees. Leave all other lights unchanged. Report what you changed."

This kind of conditional batch operation is extremely tedious to do manually but natural to express in language.

Working with Godot Projects

While much of this post focuses on Unreal Engine (since that is where most of our users work), the patterns apply equally to Godot development through the Godot MCP Server.

The key differences in Godot workflows:

GDScript instead of C++. Claude's GDScript knowledge is solid, and the simpler syntax means code generation tends to be more reliable than C++ generation. Fewer macros, fewer header files, fewer ways for things to go wrong.

Scene tree instead of actor hierarchy. The Godot MCP Server exposes scene tree manipulation tools. The mental model shifts from "actors in a world" to "nodes in a tree," but the command patterns are identical: "add a CharacterBody3D with these child nodes and configure their properties."

Resource system instead of asset system. Godot's resource-based architecture means the MCP server interacts with .tres and .tscn files differently than Unreal's UASSET files, but from your perspective as a Claude Code user, the commands feel the same.

Custom commands and prompt templates work identically across engine — adjust the terminology (Actor to Node, Component to child Node, Blueprint to GDScript class) and the workflows transfer directly.

Measuring Your Improvement

After implementing these advanced patterns, track your productivity to validate the investment.

Metrics that matter:

Features implemented per week (quality-adjusted — do not count half-finished features)
Time spent on mechanical vs. creative work (the ratio should shift toward creative)
Bugs introduced per feature (AI-generated code can increase or decrease this depending on your review discipline)
Time from "idea" to "playable prototype" (this should decrease significantly)

Metrics that do not matter:

Lines of code generated by AI (volume is not value)
Number of AI interactions per day (more is not better)
Percentage of code written by AI (the goal is shipped games, not AI usage statistics)

The advanced techniques in this post are not about using Claude Code more — they are about using it more effectively. A developer who runs three well-crafted custom commands per day and spends the rest of their time on creative work will outperform a developer who spends all day in the Claude Code terminal generating mediocre code.

Build the habits, refine the templates, and invest the saved time where it matters most: making your game worth playing.