game-development

name	game-development
description	Game development orchestrator. Routes to platform-specific skills based on project needs.
allowed-tools	Read, Write, Edit, Glob, Grep, Bash
version	1.0.0
last-updated	"2026-03-12T00:00:00.000Z"
applies-to-model	gemini-2.5-pro, claude-3-7-sonnet

Game Development

Orchestrator skill that provides core principles and routes to specialized sub-skills.

---

When to Use This Skill

You are working on a game development project. This skill teaches the PRINCIPLES of game development and directs you to the right sub-skill based on context.

---

Sub-Skill Routing

Platform Selection

If the game targets...	Use Sub-Skill
Web browsers (HTML5, WebGL)	game-development/web-games
Mobile (iOS, Android)	game-development/mobile-games
PC (Steam, Desktop)	game-development/pc-games
VR/AR headsets	game-development/vr-ar

Dimension Selection

If the game is...	Use Sub-Skill
2D (sprites, tilemaps)	game-development/2d-games
3D (meshes, shaders)	game-development/3d-games

Specialty Areas

If you need...	Use Sub-Skill
GDD, balancing, player psychology	game-development/game-design
Multiplayer, networking	game-development/multiplayer
Visual style, asset pipeline, animation	game-development/game-art
Sound design, music, adaptive audio	game-development/game-audio

---

Core Principles (All Platforms)

1. The Game Loop

Every game, regardless of platform, follows this pattern:

INPUT  → Read player actions
UPDATE → Process game logic (fixed timestep)
RENDER → Draw the frame (interpolated)

Fixed Timestep Rule:

• Physics/logic: Fixed rate (e.g., 50Hz)
• Rendering: As fast as possible
• Interpolate between states for smooth visuals

---

2. Pattern Selection Matrix

Pattern	Use When	Example
State Machine	3-5 discrete states	Player: Idle→Walk→Jump
Object Pooling	Frequent spawn/destroy	Bullets, particles
Observer/Events	Cross-system communication	Health→UI updates
ECS	Thousands of similar entities	RTS units, particles
Command	Undo, replay, networking	Input recording
Behavior Tree	Complex AI decisions	Enemy AI

Decision Rule: Start with State Machine. Add ECS only when performance demands.

---

3. Input Abstraction

Abstract input into ACTIONS, not raw keys:

"jump"  → Space, Gamepad A, Touch tap
"move"  → WASD, Left stick, Virtual joystick

Why: Enables multi-platform, rebindable controls.

---

4. Performance Budget (60 FPS = 16.67ms)

System	Budget
Input	1ms
Physics	3ms
AI	2ms
Game Logic	4ms
Rendering	5ms
Buffer	1.67ms

Optimization Priority:

1. Algorithm (O(n²) → O(n log n))
2. Batching (reduce draw calls)
3. Pooling (avoid GC spikes)
4. LOD (detail by distance)
5. Culling (skip invisible)

---

5. AI Selection by Complexity

AI Type	Complexity	Use When
FSM	Simple	3-5 states, predictable behavior
Behavior Tree	Medium	Modular, designer-friendly
GOAP	High	Emergent, planning-based
Utility AI	High	Scoring-based decisions

---

6. Collision Strategy

Type	Best For
AABB	Rectangles, fast checks
Circle	Round objects, cheap
Spatial Hash	Many similar-sized objects
Quadtree	Large worlds, varying sizes

---

Anti-Patterns (Universal)

Don't	Do
Update everything every frame	Use events, dirty flags
Create objects in hot loops	Object pooling
Cache nothing	Cache references
Optimize without profiling	Profile first
Mix input with logic	Abstract input layer

---

Routing Examples

Example 1: "I want to make a browser-based 2D platformer"

→ Start with game-development/web-games for framework selection → Then game-development/2d-games for sprite/tilemap patterns → Reference game-development/game-design for level design

Example 2: "Mobile puzzle game for iOS and Android"

→ Start with game-development/mobile-games for touch input and stores → Use game-development/game-design for puzzle balancing

Example 3: "Multiplayer VR shooter"

→ game-development/vr-ar for comfort and immersion → game-development/3d-games for rendering → game-development/multiplayer for networking

---

Remember: Great games come from iteration, not perfection. Prototype fast, then polish.

---

Output Format

When this skill produces or reviews code, structure your output as follows:

━━━ Game Development Report ━━━━━━━━━━━━━━━━━━━━━━━━
Skill:       Game Development
Language:    [detected language / framework]
Scope:       [N files · N functions]
─────────────────────────────────────────────────
✅ Passed:   [checks that passed, or "All clean"]
⚠️  Warnings: [non-blocking issues, or "None"]
❌ Blocked:  [blocking issues requiring fix, or "None"]
─────────────────────────────────────────────────
VBC status:  PENDING → VERIFIED
Evidence:    [test output / lint pass / compile success]

VBC (Verification-Before-Completion) is mandatory. Do not mark status as VERIFIED until concrete terminal evidence is provided.

---

🤖 LLM-Specific Traps

AI coding assistants often fall into specific bad habits when dealing with this domain. These are strictly forbidden:

1. Over-engineering: Proposing complex abstractions or distributed systems when a simpler approach suffices.
2. Hallucinated Libraries/Methods: Using non-existent methods or packages. Always // VERIFY or check package.json / requirements.txt.
3. Skipping Edge Cases: Writing the "happy path" and ignoring error handling, timeouts, or data validation.
4. Context Amnesia: Forgetting the user's constraints and offering generic advice instead of tailored solutions.
5. Silent Degradation: Catching and suppressing errors without logging or re-raising.

---

🏛️ Tribunal Integration (Anti-Hallucination)

Slash command: /review or /tribunal-full Active reviewers: logic-reviewer · security-auditor

❌ Forbidden AI Tropes

1. Blind Assumptions: Never make an assumption without documenting it clearly with // VERIFY: [reason].
2. Silent Degradation: Catching and suppressing errors without logging or handling.
3. Context Amnesia: Forgetting the user's constraints and offering generic advice instead of tailored solutions.

✅ Pre-Flight Self-Audit

Review these questions before confirming output:

✅ Did I rely ONLY on real, verified tools and methods?
✅ Is this solution appropriately scoped to the user's constraints?
✅ Did I handle potential failure modes and edge cases?
✅ Have I avoided generic boilerplate that doesn't add value?

🛑 Verification-Before-Completion (VBC) Protocol

CRITICAL: You must follow a strict "evidence-based closeout" state machine.

• ❌ Forbidden: Declaring a task complete because the output "looks correct."
• ✅ Required: You are explicitly forbidden from finalizing any task without providing concrete evidence (terminal output, passing tests, compile success, or equivalent proof) that your output works as intended.