Propose game-architecture skill (Game Coding Complete patterns)

[diego3]

Summary

Proposes a new project skill, .claude/skills/game-architecture/, that documents how this
engine's existing patterns map to Game Coding Complete, 4th Edition (McShaffry & Graham) — the
book already cited in process/process.go's own doc comment — and gives concrete guidance for
implementing the remaining games/metalslug_demo/ideas.md TODOs using patterns already
established in this codebase instead of ad hoc versions.

It sits alongside the existing .claude/skills/game-dev (validation) skill and follows the
structural conventions of .agents/skills/python-design-patterns / python-anti-patterns
(frontmatter name/description, "When to Use This Skill", numbered "Core Concepts", a "Quick
Start", a tiered references/ file for deeper material, and a "Related Skills" pointer back to
game-dev).

What's in it

• SKILL.md (~180 lines): layer boundary discipline (ADR-003), Component-composition actor
  pattern, Prototype spawning via GameObject.Clone()/spawnEntity, a decision guide for
  which of three timing mechanisms to use (single-instance script globals vs. the
  object.Timer component vs. the still-unwired process.Manager), informal state-machine
  guidance for actor AI, resource-cache reuse, and event-driven HUD design. Ends with a table
  mapping each ideas.md TODO to the relevant pattern — and flags that a few (enemy sprite,
  enemy shooting at the player, explosion animation) are already implemented, even though
  ideas.md still shows them unchecked.
• references/pattern-catalog.md: a chapter-by-chapter mapping of Game Coding Complete
  concepts to where (or whether) they're implemented here, a note on the current
  Prototype-clone-vs-true-object-pool tradeoff, and a full worked CameraShake process.Process
  example — the concrete template for the first thing that should attach to a process.Manager.

Why

process/ was added standalone with no consumer yet, and several of the timing/spawning
conventions in the newer Python scripts (enemy_bomber.py, sphere_timer.py,
game_manager.py) were worked out ad hoc, script by script. This skill exists so the next
gameplay feature — pickups, camera shake, a HUD, shader-based projectiles — reuses those
conventions deliberately (and picks the right one of the three timing mechanisms) instead of
re-deriving them, and so a reviewer has a concrete checklist for whether new gameplay code is
bypassing an existing pattern.

No engine or game code changes — this PR only adds two markdown files.

---

Generated by Claude Code

[cursor]

Bugbot is not enabled for your account, so this pull request was not reviewed.

Enable Bugbot in the Cursor dashboard to get automatic reviews on future PRs.