Unity Gameplay Systems

Purpose

Stand up and evolve a verified playable loop for a casual iOS game: a controllable thing on screen, responsive touch input, deterministic update order, mobile-safe hot paths, and behavior proven in Play Mode — not a folder of design docs.

Use When

Starting a new casual game, repairing a weak prototype, adding mechanics/entities, designing C# architecture, wiring touch input, assembling scenes/prefabs, tuning camera/controls/difficulty, or adding juice.

Core Doctrine (shared with the unity-* set)

1. Ship a verified playable slice early. Get a controllable object on screen that runs in Play Mode in the first session, then iterate. Never deliver only design docs.
2. Keep gates lean for a solo dev. Ask at genuine branch points (concept, art direction, scope, billable actions); otherwise proceed with sensible defaults and batch decisions.
3. Edit Unity through MCP, never raw YAML. Scenes/prefabs/components/assets go through unity-mcp-bridge (manage_scene, manage_gameobject, manage_components, manage_prefabs, create_script) or generated Editor scripts. C# is plain text and safe to Edit, but is not done until it compiles clean — confirm with read_console(types=["error"]).
4. Verify APIs on Unity 6. The model's built-in Unity knowledge is ~2022.3. On Unity 6 (6000.x) the Input System and UI Toolkit differ. Call unity_reflect / unity_docs before writing C# you are unsure of. Trust order: reflection > project assets > docs > memory.

Workflow