build-game-monster-system

Build Game Monster System

Build monsters as gameplay-compatible runtime assets, not decorative meshes.

Establish the contract

Read references/monster-contract.md before implementation or audit. Check the real game content model, combat events, enemy state machine, collision API, camera distance, and asset loader before extending the contract.

Use related skills when applicable:

• Use img2threejs for image-driven procedural reconstruction and its staged visual gates.
• Use build-hybrid-game-assets to choose procedural versus imported representation and record provenance/budgets.
• Use tune-enemy-ai for perception, intent, movement, and behavior transitions.
• Use design-action-combat for startup/active/recovery timing and authoritative contact.

Separate four layers

1. MonsterDefinition: serializable authored facts, tags, scale, stats, attacks, locomotion, asset provenance, and budgets.
2. MonsterRig: semantic transform hierarchy, joints, sockets, secondary-motion anchors, materials, and LOD visuals.
3. MonsterRuntime: current state, timers, target intent, health/posture, cooldowns, and authoritative combat events.
4. MonsterViewAdapter: drives rig poses, VFX, audio, visibility, and LOD from runtime state; never decides hits from rendered pose.

Do not duplicate authored combat values in the rig or UI.

Build the rig

• Use +Y up, +Z forward, meters, and a ground-contact root.
• Keep root -> motion -> body stable across every monster and LOD.
• Parent limb segments as real joint chains so shoulder/hip motion propagates through elbows/knees to wrists/ankles.
• Name semantic equivalents for nonhumanoids; do not fake absent anatomy.
• Provide sockets for attack origins, VFX, audio, targeting, ground contact, attachments, and death effects.
• Keep visual meshes out of physics by default. Provide simple solid, navigation, hurt, attack, and trigger shapes separately.
• Preserve root, joints, sockets, collision, and animation state across LOD changes.