Performance Optimization
Find and fix game performance problems methodically, measure with the engine profiler...
Install
npx skills add gamedev-skills/awesome-gamedev-agent-skills --skill performance-optimization -g -a claude-code -y- Repository
- gamedev-skills/awesome-gamedev-agent-skills6.4k
- Category
- Engineering
- Updated
- 8d ago
- License
- Apache-2.0
- Context cost
- Mediumabout 2,405 tokens
- Runs scripts
- No, instructions only
What it does
Find and fix game performance problems methodically, measure with the engine profiler first, reason about the frame-time budget, locate the CPU-vs-GPU bottleneck, then apply the right fix: object pooling, draw-call batching, fewer allocations/GC spikes, and asset budgets. Engine- neutral method that pairs with each engine's profiler. Use when the user mentions performance, optimize, low/dropping FPS, frame drops, stutter, lag, profiler, frame budget, draw calls, batching, garbage collection/GC spikes, object pooling, or "the game runs slow".
Performance optimization
Performance work is a measurement discipline, not a bag of tricks. The method is always the
same: profile → find the one bottleneck → fix that → measure again. This skill teaches that
loop and the highest-leverage fixes (pooling, batching, allocation control, asset budgets), and
points you at each engine's profiler. It pairs with physics-tuning for simulation cost.
When to use
- Use when the frame rate is low or uneven, the game stutters/hitches, or it must hit a target (60 FPS desktop, 30/60 mobile) and currently doesn't.
- Use to decide what to optimize: profile, read the frame budget, and identify whether the CPU or GPU is the bottleneck before changing any code.
- Use to apply specific fixes: object pooling, draw-call/batch reduction, removing per-frame allocations and GC spikes, and setting asset budgets.
When not to use: for physics jitter/tunneling/timestep specifically, use physics-tuning.
For the engine's concrete profiler UI and rendering settings, use that
engine skill (godot-export covers some build settings; engine cores cover the rest). This skill
is the cross-engine method and the shared fixes.
The golden rule: measure first, never guess
Most performance "fixes" applied without profiling target the wrong thing and add complexity for no gain. Do not optimize code you have not measured. Open the profiler, find the single biggest cost in a representative scene on representative hardware, and fix that. Re-measure to confirm the fix helped before moving on. Profile a release/optimized build where it matters, editor and debug builds lie (editor overhead, no compiler optimization).
