Game Development

Design and ship browser-playable games from no-build Three.js prototypes to advanced architectures with workflows, budgets, and playtest loops.

MIT-0 · Free to use, modify, and redistribute. No attribution required.
0 · 282 · 1 current installs · 1 all-time installs
byIván@ivangdavila
MIT-0
Security Scan
VirusTotalVirusTotal
Benign
View report →
OpenClawOpenClaw
Benign
high confidence
Purpose & Capability
The name/description (browser-first Three.js prototypes to larger architectures) matches the requested binaries (node for local preview and optional bundling; python3 for offline asset processing). No unrelated credentials, binaries, or config paths are requested.
Instruction Scope
The SKILL.md and supporting docs instruct the agent to create and maintain files under ~/game-development, read local templates (setup.md, memory-template.md), and follow playtest/architecture checklists. There are no instructions to read unrelated system files, access external secrets, or transmit local data to unknown endpoints.
Install Mechanism
No install spec or remote downloads are present (instruction-only). Nothing is written to disk by an installer; the only filesystem actions come from setup instructions that initialize a project folder.
Credentials
No environment variables or credentials are required. The skill's stated needs (node/python3) are proportional to local preview and asset processing work.
Persistence & Privilege
The skill persists project memory under ~/game-development and suggests creating files with specific permissions (mkdir/touch/chmod). It does not request always:true or system-wide config changes. Note: the agent may run local preview scripts (node) as part of its workflow—this is expected but means you should review any generated code before executing it.
Assessment
This skill appears internally consistent and is low-risk relative to its purpose, but take these practical precautions: (1) installing the skill will cause the agent to create ~/game-development and several files (the setup.md commands include mkdir/touch/chmod); review those files if you want to audit what the agent writes. (2) The skill expects to run local preview scripts with node and may recommend running tooling—do not execute generated code you haven't reviewed, or restrict network access while testing. (3) There are no requested credentials or external downloads, but the skill's source is listed as unknown; if you require stronger assurance, verify the homepage/owner or run the skill in a sandboxed account/container. (4) Autonomous agent invocation is allowed by default (normal for skills); if you are uncomfortable with an agent running tasks without a prompt, disable autonomous invocation for your agent or review actions before they run.

Like a lobster shell, security has layers — review code before you run it.

Current versionv1.0.0
Download zip
latestvk979w7ee5m6r33hrhxw25fd50h82bxkf

License

MIT-0
Free to use, modify, and redistribute. No attribution required.

Runtime requirements

🕹️ Clawdis
OSmacOS · Linux · Windows
Binsnode, python3

SKILL.md

Setup

On first use, read setup.md silently and align game scope, delivery target, and technical constraints before proposing implementation.

When to Use

Use this skill when users want to create playable games with agents, especially instant browser games with Three.js that run without a compile step. It also supports advanced projects with multiple systems, larger content pipelines, multiplayer plans, and live operations.

Architecture

Memory lives in ~/game-development/. See memory-template.md for setup and status fields.

~/game-development/
|-- memory.md                     # Current project state, scope, and delivery profile
|-- concept-briefs.md             # Game concepts, target audience, and pillar ideas
|-- user-preferences.md           # User taste, constraints, and style preferences
|-- system-decisions.md           # Technical decisions and tradeoffs
|-- playtest-log.md               # Session findings, issues, and balancing actions
|-- roadmap.md                    # Milestones and release checkpoints
`-- release-notes.md              # What changed between iterations

Quick Reference

Use the smallest relevant file for the current task.

TopicFile
Setup flowsetup.md
Memory templatememory-template.md
Genre and loop selectiongame-types-and-loops.md
No-build browser path with Three.jsbrowser-threejs-fast-path.md
Project folder blueprintsproject-structure-blueprints.md
Systems architecture and state designsystems-and-state.md
Asset/content pipeline and toolingcontent-pipeline.md
Multiplayer and live operationsmultiplayer-and-live-ops.md
QA, balancing, and launch checklistqa-balance-launch.md

Requirements

  • Runtime for local preview scripts: node
  • Optional tools for offline asset processing: python3
  • Browser target for quick iterations: Chrome, Edge, Safari, or Firefox

Prefer local and static workflows first. Move to backend dependencies only when the user explicitly needs multiplayer authority, persistence, or commerce.

Data Storage

Local notes stay under ~/game-development/ and should capture:

  • the current game concept and loop assumptions
  • the user preferences and non-negotiable constraints
  • technical architecture choices with reasons
  • playtest findings, balancing deltas, and release decisions

Keep notes concise and operational. Store decisions and outcomes, not long transcripts.

Core Rules

1. Lock the Delivery Profile First

Choose one profile before coding:

  • Browser Instant: no-build HTML/CSS/JS delivery, fastest iteration, easiest sharing
  • Browser Structured: TypeScript or bundler workflow with modular architecture
  • Engine Path: Unity, Unreal, or Godot when editor tooling and content scale justify it

Do not mix profiles in one milestone unless the user asks for migration.

2. Start From a Vertical Slice, Not a Full Game Plan

Always build a playable loop in this order:

  • input
  • movement
  • objective
  • fail state
  • restart

A complete five-minute loop is more valuable than ten untested systems.

3. Treat Browser Performance as a Product Requirement

For browser-first games, define budgets before adding content:

  • frame target and frame-time budget
  • draw calls and shader complexity budget
  • texture and audio memory budget
  • mobile fallback quality tier

If a feature breaks the budget, simplify first and optimize second.

4. Separate Deterministic Core Logic From Presentation

Keep rules deterministic and testable:

  • game state transitions
  • hit and scoring logic
  • progression and economy math

Render, VFX, and animation should observe state, not own truth.

5. Use Progressive Complexity

System order for agent-driven delivery:

  • loop and controls
  • feedback and readability
  • enemy or puzzle variation
  • progression layer
  • social or online features

Only unlock the next layer after the previous one is playable and measured.

6. Make Playtesting Continuous

Each milestone must include:

  • test objective
  • expected player behavior
  • observed friction
  • one concrete balancing action

No new feature batch should be accepted without a playtest note.

7. Preserve Reusable Project Knowledge

Update local memory after major decisions:

  • concept changes
  • preference updates
  • architecture pivots
  • launch risks

This allows agents to continue work without repeating discovery.

Common Traps

  • Building menus, inventory, and cosmetics before core loop validation -> large scope with no fun proof
  • Tying physics and gameplay directly to frame rate -> inconsistent behavior across devices
  • Importing heavy 3D assets too early for browser targets -> unusable mobile experience
  • Skipping input latency and camera readability checks -> players quit despite stable FPS
  • Adding multiplayer before single-player loop quality -> expensive complexity without retention value
  • Ignoring save and state recovery strategy -> broken sessions and user frustration

Security & Privacy

Data that stays local:

  • concept notes and user preferences under ~/game-development/
  • project decision logs and playtest outcomes

Data that may leave your machine only if explicitly requested:

  • source code pushed to remote repositories
  • asset uploads to CDN or build hosts
  • backend telemetry or analytics events

This skill does NOT:

  • force external services for simple browser prototypes
  • require paid APIs for baseline game creation
  • recommend production launch without performance and playtest evidence

Related Skills

Install with clawhub install <slug> if user confirms:

  • threejs - 3D rendering patterns and WebGL resource hygiene
  • javascript - core scripting patterns for browser game logic
  • typescript - safer large-scale game codebases and tooling
  • unity - engine path for editor-heavy and cross-platform pipelines
  • unreal-engine - high-fidelity pipeline when advanced rendering is required

Feedback

  • If useful: clawhub star game-development
  • Stay updated: clawhub sync

Files

10 total
Select a file
Select a file to preview.

Comments

Loading comments…