---

name: crucible description: > Game development forge covering Unity, Godot, Phaser, and web engines -- from game loop to deployment. USE WHEN: User needs game architecture, engine selection, physics setup, input handling, asset pipelines, game state management, multiplayer basics, or platform deployment. DON'T USE WHEN: User needs 3D modeling or art creation. Use creative tools for asset production. Use Architect for non-game system design. OUTPUTS: Game architecture plans, engine configurations, game loop implementations, physics setups, input systems, state machines, multiplayer designs, build and deployment configs. version: 1.0.0 author: SpookyJuice tags: [game-dev, unity, godot, phaser, game-design, mechanics] price: 14 author_url: "https://www.shopclawmart.com" support: "brian@gorzelic.net" license: proprietary osps_version: "0.1"

Crucible

Version: 1.0.0 Price: $14 Type: Skill

Description

Crucible is a game development skill that covers the full arc from engine selection through deployment -- game loop architecture, physics systems, input handling, asset pipelines, state management, and multiplayer fundamentals. It works across Unity (C#), Godot (GDScript/C#), Phaser (TypeScript), and browser-native approaches, giving you engine-appropriate patterns rather than one-size-fits-all abstractions.

Game development is one of the most multidisciplinary software challenges. A single game touches real-time rendering, physics simulation, input processing, audio mixing, state management, asset loading, and often networking -- all running at 60fps with zero tolerance for frame drops. Crucible handles the architecture that makes all these systems cooperate without turning your codebase into spaghetti.

Whether you are prototyping a game jam entry, building a mobile puzzle game, or architecting an indie title with multiplayer, Crucible provides the structural engineering that keeps your project maintainable as scope inevitably grows.

Prerequisites

• Chosen engine installed and configured (Unity 2022+, Godot 4+, or Node.js for Phaser)
• Basic programming knowledge in the engine's language (C#, GDScript, or TypeScript)
• Version control set up -- games generate binary assets that need Git LFS or equivalent
• Target platform identified (web, mobile, desktop, console)

Setup

1. Initialize your project with the engine's recommended project structure
2. Configure version control -- add .gitignore for engine-specific temp files, set up Git LFS for textures, audio, and models
3. Set up your build pipeline early -- configure export templates for your target platform before writing gameplay code
4. Establish your scene/level organization convention -- flat vs nested, prefab strategy, resource loading approach

Commands

• "Design a game architecture for [game concept]"
• "Help me choose between Unity, Godot, and Phaser for [requirements]"
• "Build a game loop with fixed timestep physics"
• "Design an input handling system for [game type]"
• "Set up an asset pipeline for [engine]"
• "Implement a state machine for [game entity]"
• "Design a multiplayer architecture for [game type]"
• "Configure build and deployment for [platform]"

Workflow

Game Architecture Design

1. Define the game's core loop -- identify the single mechanic the player repeats most often (shoot-dodge-collect, place-grow-harvest, move-solve-progress). This loop drives every architectural decision. If you cannot state it in 3-4 verbs, scope is too broad for the prototype phase
2. Select the engine -- match engine to requirements. Unity for 3D, complex physics, console targets, or large asset pipelines. Godot for 2D, rapid prototyping, open-source requirement, or lightweight 3D. Phaser for browser-first, casual/hyper-casual, or web distribution. Do not pick Unity for a 2D web game or Phaser for a 3D shooter
3. Design the scene graph -- plan how game objects compose. In Unity: GameObject hierarchy with component architecture. In Godot: Node tree with scene inheritance. In Phaser: Scene lifecycle with GameObjects. Define your root scenes: Boot, Preload, MainMenu, Gameplay, Pause, GameOver
4. Architect the game loop -- separate update logic into distinct phases: input processing, game logic (fixed timestep), physics simulation, rendering (variable timestep). Use the engine's built-in loop (Unity's FixedUpdate/Update/LateUpdate, Godot's _physics_process/_process, Phaser's update) correctly
5. Design the state management -- plan how game state flows. Global state (score, level, settings) in a singleton or autoload. Entity state via finite state machines or behavior trees. Scene state through the engine's scene manager. Persist state to disk with versioned save formats
6. Plan the component/system architecture -- for entity-heavy games, design how behaviors compose. Unity ECS or MonoBehaviour components, Godot nodes as components, or a custom ECS for Phaser. Keep components single-responsibility: MovementComponent, HealthComponent, InventoryComponent
7. Set performance budgets -- define frame budget (16.6ms for 60fps, 33.3ms for 30fps), draw call limits (mobile: under 100, desktop: under 1000), memory budget per platform, and audio channel count. Establish these before writing gameplay code, not after

Physics and Input Systems

1. Configure the physics engine -- set fixed timestep (0.02s / 50Hz is standard), gravity vector, collision layer matrix, and physics material defaults. In Unity: Physics2D/Physics settings. In Godot: Project Settings > Physics. In Phaser: Arcade, Matter.js, or no physics
2. Design collision layers -- create a collision matrix that prevents unnecessary checks. Typical layers: Player, Enemy, PlayerProjectile, EnemyProjectile, Environment, Trigger, Pickup. Player bullets should collide with enemies and environment but not with the player or other bullets
3. Implement movement systems -- for physics-based movement: apply forces or set velocities on the physics body, never move transforms directly. For kinematic movement: use move_and_slide (Godot) or CharacterController (Unity). Choose based on whether you need realistic physics responses or precise control
4. Build the input abstraction layer -- never read raw input directly in gameplay code. Create an input manager that maps physical inputs (keyboard, gamepad, touch) to game actions (jump, shoot, move_left). This enables: rebinding, multiple input devices, replay systems, and AI-controlled entities using the same interface
5. Handle input buffering -- for action games, buffer inputs for 3-5 frames. If the player presses jump 2 frames before landing, the jump should still trigger on land. Without buffering, controls feel unresponsive and players blame your game, not their timing
6. Implement coyote time and input forgiveness -- for platformers: allow jumps for 3-6 frames after leaving a ledge (coyote time). For combat: queue the next attack during current animation. These invisible assists are the difference between "feels great" and "feels janky"
7. Test with target input devices -- keyboard-mouse and gamepad have fundamentally different input characteristics. Analog sticks need deadzones (0.15-0.25 range). Touch needs larger hit targets. Design for your primary input device first, adapt for secondary

Build and Platform Deployment

1. Configure build settings per platform -- set resolution, aspect ratio handling (letterbox vs stretch vs expand), quality presets, target frame rate, and platform-specific capabilities. Mobile builds need different texture compression (ASTC for iOS, ETC2 for Android) than desktop (DXT/BC)
2. Set up the asset pipeline -- configure texture import settings (max resolution, compression, mipmaps), audio import settings (compression format, streaming vs preload), and model import settings (mesh compression, animation baking). Wrong import settings are the top cause of bloated builds
3. Implement a loading system -- for anything beyond trivial games, assets must load asynchronously. Show a loading screen with progress bar. In Unity: Addressables or AssetBundles. In Godot: ResourceLoader with threading. In Phaser: Scene preload method. Never freeze the game during loads
4. Optimize for target platform -- mobile: reduce draw calls aggressively, use texture atlases, disable real-time shadows, limit particle counts. Web: minimize initial download size, stream assets after load, handle browser tab backgrounding. Desktop: offer quality settings
5. Set up automated builds -- configure CI to build for all target platforms on every merge. Unity: Unity Build Server or GameCI. Godot: export templates in CI. Phaser: standard web build pipeline (Vite/webpack). Catch build failures before they reach QA
6. Test on actual target hardware -- emulators and simulators miss real-world issues. Test on a low-end device for your target platform: a 3-year-old Android phone for mobile, integrated graphics for desktop, throttled network for web. Your development machine is not representative
7. Configure platform-specific distribution -- web: itch.io or self-hosted with proper MIME types for .wasm. Mobile: App Store Connect / Google Play Console with screenshots, descriptions, and content ratings. Desktop: Steam SDK integration, achievements, cloud saves. Each platform has a 2-week review process -- start early

Output Format

+=============================================+
|  CRUCIBLE -- GAME ARCHITECTURE PLAN         |
|  Project: [Game Title / Concept]            |
|  Engine: [Unity / Godot / Phaser]           |
|  Date: [YYYY-MM-DD]                         |
+=============================================+

--- CORE LOOP ---
[verb] --> [verb] --> [verb] --> [reward]
Session Target: [X] minutes

--- ENGINE CONFIG ---
Engine: [name + version]
Language: [C# / GDScript / TypeScript]
Physics: [engine] at [Hz] fixed step
Target FPS: [30 / 60 / 120]

--- SCENE GRAPH ---
  Boot
    +-- Preload
    +-- MainMenu
    +-- Gameplay
    |     +-- HUD
    |     +-- PauseMenu
    +-- GameOver

--- ENTITY ARCHITECTURE ---
  [Entity]: [Component, Component, Component]
  [Entity]: [Component, Component, Component]
  State Machine: [State] --> [State] --> [State]

--- INPUT MAP ---
  Action ......... Keyboard ...... Gamepad ...... Touch
  [action] ....... [key] ......... [button] ..... [gesture]

--- PERFORMANCE BUDGET ---
  Frame Budget: [X] ms
  Draw Calls: max [X]
  Memory: max [X] MB
  Load Time: max [X] s

--- BUILD TARGETS ---
  [Platform] .... [Resolution] .... [Notes]

--- ACTION ITEMS ---
  [ ] [Priority 1 action]
  [ ] [Priority 2 action]
  [ ] [Priority 3 action]

Common Pitfalls

• No fixed timestep for physics -- running physics in the render loop means physics behavior changes with frame rate. A character jumps higher at 120fps than at 30fps. Always use a fixed timestep for physics calculations, even in simple games
• Premature optimization -- profiling a game with 10 entities to optimize for 1000 is wasted effort. Get the gameplay right first, then profile with realistic entity counts. The bottleneck is almost never where you think it is
• God object game manager -- putting all game logic in a single GameManager script creates an unmaintainable monolith. Use composition: separate managers for audio, input, scoring, spawning, and UI. Each does one thing
• Ignoring asset sizes -- a single uncompressed 4K texture is 64MB. Multiply by 50 textures and your game is 3GB. Set import compression and resolution limits from day one. Check build sizes weekly
• Not separating game logic from presentation -- when score calculation lives inside the score UI script, you cannot test it without rendering. Keep logic pure and testable, have UI observe state changes
• Hardcoded values everywhere -- movement speed, jump height, enemy health scattered across scripts makes tuning impossible. Centralize tunable values in data files, ScriptableObjects (Unity), Resources (Godot), or config JSON (Phaser)
• Skipping the prototype phase -- going straight to production art and architecture for an unproven game concept wastes months. Prototype the core loop with placeholder art in 1-2 weeks. If it is not fun with cubes, it will not be fun with polished models

Guardrails

• Never recommends engine-specific patterns without engine context. Unity ECS advice for a Godot project wastes time. Crucible always confirms the engine before recommending architecture patterns.
• Never skips performance budgets. Every game plan includes frame time, memory, and draw call budgets for the target platform. "We will optimize later" is not a plan.
• Never recommends multiplayer without scope warning. Adding multiplayer increases complexity 3-5x. Crucible always flags the engineering cost and recommends starting single-player, then adding multiplayer once the core loop is proven.
• Acknowledges scope honestly. If a game concept is too ambitious for the stated timeline or team size, Crucible says so and suggests scope cuts rather than enabling crunch.
• Never ignores platform constraints. Mobile, web, and desktop have fundamentally different performance envelopes. Recommendations are always platform-aware.
• Recommends version control from day one. No game project proceeds without version control configured, including LFS for binary assets.

Support

Questions or issues with this skill? Contact brian@gorzelic.net Published by SpookyJuice -- https://www.shopclawmart.com