Generated banner for Build Game Monster System
Generated logo for Build Game Monster System

Build Game Monster System

Meng ToCommunityCreated by Meng To

  • Skill
  • Workflow
  • Software development
  • MIT
  • No issues found

From the author

Build, integrate, audit, or refactor rigged monsters for Three.js and web action games. Use for monster asset contracts, procedural or imported creature rigs, semantic joints and sockets, hurtboxes and attack volumes, combat animation states, enemy-runtime adapters, LODs, deterministic review fixtures, and validating that every monster follows one shared system.
— the description by Meng To

AutoGineer summary

Written by AutoGineer from the skill’s own files, not by the author

This skill provides a structured approach to creating game monsters as functional runtime assets rather than static meshes. It defines a strict separation between monster definitions, rigs, runtime state, and view adapters. By following this system, developers ensure that monsters maintain consistent behavior, collision handling, and animation states across different levels of detail and game scenarios. The framework emphasizes deterministic testing and clear contracts for combat mechanics, ensuring that damage and interaction are handled by authoritative logic rather than visual animation frames.

What it does

  • Defines a serializable structure for monster stats, locomotion, and attack definitions.
  • Establishes a semantic rig hierarchy for joints, sockets, and secondary motion.
  • Provides a contract for separating visual meshes from physics, hurtboxes, and attack volumes.
  • Outlines mandatory state machine transitions for combat and movement.
  • Requires deterministic fixtures to verify monster behavior and LOD stability.
  • Standardizes socket placement for VFX, audio, and targeting.

When to use it

  • When building or refactoring monsters for a Three.js-based action game.
  • When you need to ensure consistent combat behavior across different monster types.
  • When you need to implement reliable, testable attack phases and collision logic.
  • When you need to manage monster performance through LODs without breaking gameplay logic.

Advantages

  • Decouples visual animation from authoritative combat logic to prevent hit-detection errors.
  • Ensures consistent behavior across different LOD levels.
  • Facilitates easier debugging through deterministic review fixtures.
  • Provides a clear, shared contract for team-based asset development.

Usage examples

“How should I structure the hierarchy for a new bipedal monster rig?”
The system requires a root, motion, and body hierarchy, with specific semantic chains for the pelvis, spine, neck, head, and limbs, ensuring consistency across all monster types.
“How do I define an attack that is testable and deterministic?”
You must compile attack steps into explicit startup, active, and recovery phases, using a pure sampler to query state and timing without relying on visual animation frames.

Install

  1. Download the skill as a ZIP:

    https://mp-staging.autogineer.com/agent-skills/mengto/build-game-monster-system/download
  2. Unzip it into the cross-client skills folder of your project:

    mkdir -p .agents/skills && unzip build-game-monster-system.zip -d .agents/skills

Documentation by Meng To

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.

Connect behavior and combat

Support at least idle, investigate, pursue, reposition, windup, attack, recover, stagger, and defeated. Each attack definition must declare startup, active, recovery, cooldown, contact shape/socket, damage/posture output, facing rule, and interrupt/cancel policy.

Drive contacts from authoritative action IDs and collision events. Animation may expose a normalized phase, but it must not create damage by itself.

Compose testable movesets

  • Author movesets as serializable sequences of intent states and attack IDs. Keep attack timing in the attack definitions; the moveset references it instead of copying it.

  • Compile attack steps into explicit startup, active, and recovery phases.

  • Provide a pure sampler from (movesetId, elapsed) to state, attack, normalized phase, active flag, interruptibility, and stable action ID.

  • Give every loop cycle a new action ID while preserving one ID across an attack's startup, active, and recovery phases.

  • Expose queryable or seeded fixtures for the midpoint and boundaries of every phase so reviewers can freeze and reproduce them without campaign playthrough.

Verify conformance

  • Add deterministic fixtures for all required states, each attack phase, interrupt/stagger, death, LOD switching, and reset.

  • Test moveset timeline continuity, exact active-window boundaries, full attack coverage, per-action ID stability, and per-loop ID renewal.

  • Test joint propagation, socket stability, collider coverage, single-contact idempotence, and disposal.

  • Render the monster at real encounter distance in the in-app browser.

  • Measure triangles, draw calls, textures, frame time, and mobile pixel-ratio behavior.

  • Fail the asset if it has floating attachments, missing mandatory states, pose-derived damage, LOD socket drift, or unbounded resource cost.

Report whether the monster fully conforms, conforms with documented exceptions, or needs a new archetype capability added to the shared contract.

Files

references/monster-contract.md

Game Monster Runtime Contract

Contents

  • Required authored definition

  • Required rig API

  • Semantic hierarchy

  • Mandatory sockets

  • Collision layers

  • State and pose contract

  • Attack definition

  • Moveset definition and sampler

  • LOD and performance

  • Conformance checklist

Required authored definition

interface MonsterDefinition {
  id: string;
  displayName: string;
  archetype: string;
  tags: string[];
  asset: {
    kind: "procedural" | "glb" | "hybrid";
    source: string;
    license: string;
    metersPerUnit: number;
    forwardAxis: "+Z";
    provenance: string;
  };
  stats: { maxHealth: number; posture: number; moveSpeed: number; turnRate: number };
  locomotion: { radius: number; height: number; stepHeight: number };
  attacks: MonsterAttackDefinition[];
  movesets: MonsterMoveSetDefinition[];
  budgets: { nearTriangles: number; farTriangles: number; maxDrawCalls: number; maxTextures: number };
}

Keep content immutable at runtime. Store health, cooldowns, current target, and state timers elsewhere.

Required rig API

interface MonsterRig {
  root: Object3D;
  joints: Map<MonsterJointId, Object3D>;
  sockets: Map<MonsterSocketId, Object3D>;
  colliders: Map<string, MonsterCollider>;
  hurtVolumes: Map<string, MonsterCollider>;
  attackVolumes: Map<string, MonsterCollider>;
  animationHooks: Map<MonsterState | string, MonsterAnimationHook>;
  lods: Map<"near" | "mid" | "far", Object3D>;
  setLod(tier: "near" | "mid" | "far"): void;
  setState(state: MonsterState, elapsed: number, context?: MonsterPoseContext): void;
  resetPose(): void;
  dispose(): void;
}

root is ground-contact/world motion. motion is authored local locomotion/lean. body owns the main anatomical hierarchy. LOD changes may alter visual children only.

Semantic hierarchy

Every monster:

  • root

  • motion

  • body

  • ground

  • target

  • vfx-hit

  • vfx-death

Humanoid or biped equivalents:

  • pelvis -> spine -> neck -> head

  • spine -> shoulder-l -> elbow-l -> wrist-l -> hand-l

  • spine -> shoulder-r -> elbow-r -> wrist-r -> hand-r

  • pelvis -> hip-l -> knee-l -> ankle-l -> foot-l

  • pelvis -> hip-r -> knee-r -> ankle-r -> foot-r

Add tail-*, wing-*, jaw, tentacle-*, or other semantic chains only when the archetype has them. Secondary cloth, hair, chains, or dangling parts live under explicit secondary-motion pivots.

Mandatory sockets

  • target: lock-on/selection aim point.

  • ground: ground projection and contact VFX.

  • vfx-hit: generic hit reaction origin.

  • vfx-death: defeat effect origin.

  • attack-*: one origin per contact shape.

  • audio-*: only when spatial origin differs materially from root.

  • attach-*: weapons, shields, loot, or detachable modules.

Socket transforms must remain stable through state changes and all LODs.

Collision layers

  • solid: world/character blocking proxy.

  • navigation: radius, height, and step profile.

  • hurt: one or more damage-receiving volumes.

  • attack: disabled outside the authoritative active window.

  • trigger: perception, interaction, or effect-only.

Use capsules, spheres, boxes, or compound primitives. Never infer contact from visual mesh overlap. Store layer, owner ID, semantic part, local offset, and size.

State and pose contract

Required states:

idle | investigate | pursue | reposition | windup | attack | recover | stagger | defeated

The runtime owns state and elapsed time. The rig consumes them. Minimum expected transitions:

  • idle -> investigate|pursue

  • pursue -> reposition|windup|idle

  • windup -> attack|stagger

  • attack -> recover

  • recover -> pursue|reposition|idle

  • * -> stagger when interrupt rules permit

  • * -> defeated when health reaches zero

setState must be deterministic for (state, elapsed, context) and reset all modified transforms before applying a pose.

Attack definition

interface MonsterAttackDefinition {
  id: string;
  startup: number;
  active: number;
  recovery: number;
  cooldown: number;
  range: [number, number];
  arcDegrees: number;
  contact: {
    socket: string;
    shape: "sphere" | "capsule" | "box" | "sweep";
    size: [number, number, number];
  };
  damage: number;
  postureDamage: number;
  facingLock: "startup" | "active" | "none";
  interruptible: { startup: boolean; active: boolean; recovery: boolean };
}

Apply each contact once per stable (actionId, targetId). The renderer may preview the volume but does not resolve the hit.

Moveset definition and sampler

interface MonsterMoveSetDefinition {
  id: string;
  displayName: string;
  description: string;
  range: [number, number];
  loop: boolean;
  loopDelay: number;
  tags: string[];
  steps: Array<
    | { type: "intent"; label: string; state: "idle" | "investigate" | "pursue" | "reposition"; duration: number }
    | { type: "attack"; label: string; attackId: string; recoveryExtra?: number }
  >;
}

The moveset owns ordering and intent durations. Attack definitions remain the only source for startup, active, recovery, contact, damage, and interrupt timing.

Compile each attack step into windup -> attack -> recover. Provide a pure sampler:

sampleMoveSet(movesetId, elapsed) => {
  state,
  attackId,
  normalized,
  active,
  interruptible,
  phaseIndex,
  cycle,
  actionId
}

One attack keeps one stable action ID across startup, active, and recovery. A repeated loop gets a new action ID. Every phase must have a queryable frozen fixture, and tests must cover the samples immediately before, at, and after each active-window boundary.

LOD and performance

  • Near: full silhouette, material channels, secondary motion, and all identity geometry.

  • Mid: remove micro fasteners/straps, reduce radial segments, retain hands/head/weapon silhouette.

  • Far: merge static visual groups and simplify materials; retain root/joint/socket/collider maps.

Default browser target for one standard enemy:

  • near triangles <= 50k

  • far triangles <= 12k

  • draw calls <= 48 before renderer-level batching

  • textures <= 12, generally 1024px

  • steady 60 fps-class frame pacing at intended encounter density

Override only with an explicit boss/hero budget.

Conformance checklist

  • Content definition and runtime state are separate.

  • Rig has real parented joint chains, not a flat list of named pivots.

  • Required sockets exist and stay stable.

  • Solid, navigation, hurt, attack, and trigger layers are explicit.

  • Required states and at least one attack pose are deterministic.

  • Every authored attack is reachable through a moveset or an explicit standalone fixture.

  • Moveset phases are contiguous, queryable, and deterministic.

  • Stable action IDs persist through one attack and renew on the next attack/loop.

  • Attack contacts are authoritative and idempotent.

  • Death disables attack volumes and preserves cleanup/disposal.

  • Near/mid/far LOD switches preserve gameplay transforms.

  • Reset returns every joint/material state to rest.

  • Browser test covers camera distance, animation, collision debug, LOD, and performance.

Requirements and compatibility

Works with: Claude Code, Claude apps, OpenAI Codex, GitHub Copilot, Cursor, Gemini CLI, Kiro, OpenCode, Goose, Amp, Roo Code, JetBrains Junie, Factory Droid, Devin (ex-Windsurf), Mistral Vibe, OpenHands, Letta

“Works with” means the tool reads the open Agent Skills format; a skill written for one tool may use features others lack.

Security

No issues found by our static scan· No issues found

A static scan is not a guarantee. Skills are third-party content: review a skill before you let an agent use it.

Attribution and licence

Created by
Meng To
Publisher
Meng To (Community)
Source
MengTo/Skills · agent-skills/game-development/build-game-monster-system · commit 5ea1661
Licence
MIT License (redistribution allowed)
  • LICENSE (added by AutoGineer from LICENSE)
  • ATTRIBUTION.md (written by AutoGineer)
Synced

AutoGineer is not affiliated with or endorsed by Meng To.

Download ZIP

The ZIP holds the skill’s files, its licence files and an ATTRIBUTION.md. Download build-game-monster-system.zip