AI Mini Game Development

AI Mini Game Development

Use this skill to keep mini game development iterative, verifiable, and safe. Optimize for small playable increments: establish a stable base, expand gameplay, then polish.

For the complete original Chinese guide, read references/full_rules.md when the user asks for the full rules, wants to compare against the source guide, or when a project decision needs the more detailed rationale and examples. For a reusable kickoff prompt, read references/start_prompt.md.

Scope

Use directly for small and lightweight games:

• 2D casual games, 3D mini games, ball games, puzzle games, platformers, shooters/bullet hell, card/board games, idle/management games, and Web mini games.
• Unity, Cocos, Godot, pygame, Three.js, HTML Canvas, and similar lightweight game stacks.

Do not apply this workflow as-is to large multiplayer online games, strong real-time networked competitive games, full commercial game production, or projects requiring complex backend, payment, account security, or regulatory compliance. The phased delivery, authorization, documentation, and rollback principles may still be useful, but the process must be extended.

Core Rules

• Build in phases; every phase must have a runnable, checkable deliverable.
• Ask more in early phases, work more autonomously in later phases.
• Do low-risk tasks directly, choose and document defaults for medium-risk tasks, and stop for authorization on high-risk tasks.
• Do not continue building on an unverified or broken foundation.
• Stop when the next decision requires human judgment about core gameplay, feel, visuals, dependency changes, destructive edits, or project direction.

Autonomy Model

Use project maturity to decide how much to ask.

Early phase: low autonomy, high confirmation.

• Use for requirements, technical choices, project skeleton, and first runnable build.
• Summarize understanding, ask key questions, propose a short plan, then implement only the current phase.
• Do not install dependencies, overwrite assets, cross phases, or stack features when the project cannot be run.

Middle phase: medium autonomy, module delivery.

• Use once core gameplay runs.
• Complete low-risk work inside the current module: rules, UI, enemies, levels, save/settings, simple AI.
• Keep the core architecture and engine choices stable.
• End each module with verification steps and a checkpoint for user confirmation.

Late phase: high autonomy with backups.

• Use for feel tuning, visual polish, audio, particles, UI refinements, performance, and small experience details.
• Back up configs/scenes/key files before changes.
• Prefer configuration and data changes over core code changes.
• Tune one class of issue per round and state how to roll back.

Risk Levels

Low risk: proceed directly.

• Add non-conflicting files, tests, docs, logs, config entries, placeholders, versioned assets, README content.
• Fix clear syntax, compile, import, or local runtime errors.
• Perform narrow refactors within the current module.

Medium risk: choose a reasonable default, continue, and record the choice.

• Use conventional project structure, rendering/physics defaults, placeholder assets, basic UI, simple AI, default keybindings, or config-file-driven parameters.
• Add the decision to docs/decisions.md when the choice could matter later.

High risk: stop and request authorization.

• Delete files or assets.
• Overwrite existing scenes, levels, prefabs, resources, user assets, or final art.
• Install, upgrade, or replace dependencies.
• Modify global project settings.
• Change engine, framework, render pipeline, core architecture, or core gameplay.
• Perform large directory refactors.
• Trade visual quality for performance, or gameplay feel for visuals.
• Introduce large third-party tools.
• Publish, upload, or package for a formal release environment.

Phase Workflow

Use these phases unless the existing project clearly maps to a later stage.

0. Requirements freeze Confirm game type, target platform, engine/framework, input method, single/multiplayer, core loop, AI, save, networking, dependency permission, test/package expectations, and autonomy protocol. Do not start complex implementation before essentials are clear.

1. Project skeleton Deliver directory structure, entry points, base config, empty modules, and initial development docs. Verify the project starts and dependencies are clear.

2. Minimal runnable version Deliver empty scene/canvas, main loop, input reading, and visible base object. Verify it runs without errors and has acceptable frame behavior.

3. Core gameplay Deliver player control, core entities, basic collision/rules, and reset. Verify whether it is playable, natural, and free of obvious blocking bugs.

4. Rules, levels, and AI Deliver score, win/loss, levels, enemies/AI, and difficulty. Verify rules match expectations and difficulty is plausible.

5. Visuals and audio Deliver materials/textures, animation, particles, sound effects, and UI polish. Verify the style is coherent and polish does not damage playability.

6. Feel and performance tuning Deliver parameter tuning, optimization, caching, and object pooling as needed. Verify frame rate, responsiveness, stutter, and device compatibility.

7. Testing and packaging Deliver automated tests where practical, package scripts, README, and controls/instructions. Verify the target platform can run the build without critical errors.

Phase Status On Continuation

When the user gives positive feedback and asks to continue, first state the current phase as major phase + minor focus, then proceed. Choose the major phase from the workflow above, and make the minor focus concrete to the current task.

Examples:

• 当前阶段：Minimal runnable version + ball bounce tuning
• 当前阶段：Core gameplay + player board control
• 当前阶段：Feel and performance tuning + input responsiveness

Use this especially after replies like "继续", "效果可以", "基本满足要求", "下一步", or "可以进行下一阶段". If the project is still a validation prototype, say so explicitly in the phase label, such as Minimal scene validation + repeated ball bounce optimization.

Tool Declaration

At the beginning of each phase, state which tools or integrations will be used when relevant, and which obvious tools will not be used.

Common tools include Git/GitHub for versioning and review, Figma for UI references, Unity or Godot editor integrations, Cocos tooling, image generation for textures/icons/characters, audio tools for sound effects or music, browser automation for Web game screenshots and interaction tests, and CI for tests/package checks.

Do not install or enable new tools, plugins, dependencies, editor integrations, or CI publishing without authorization.

Phase Gates

Do not continue past a failed gate.

• If phase 1 is not verified, do not implement gameplay.
• If phase 2 is not verified, do not add complex rules.
• If phase 3 is not verified, do not do visual polish.
• If phase 4 is not verified, do not finalize UI.
• If phase 5 is not verified, do not package.
• If phase 6 is not verified, do not publish.

When user confirmation is needed, say:

当前阶段已完成，但需要你运行并确认。
确认后我再进入下一阶段。

Stop Conditions

Stop and give the user concrete next steps when:

• The project cannot run or the result cannot be verified.
• Build/test failures are unclear.
• Key requirements are ambiguous.
• Work requires overwriting user files or assets.
• Work requires installing dependencies or changing the technical route.
• The decision depends on human judgment of feel, visuals, or rule intent.

Use this shape:

我已经完成本阶段代码，但当前无法验证运行结果。
请你执行：
<command or editor/browser steps>
然后把错误日志或截图发给我。

Avoid Step-by-Step Questioning

Do not ask about obvious low-value implementation details such as filenames, imports, basic README additions, clear syntax fixes, or necessary tests.

Ask about gameplay forks, overwrites, dependency installs, core structure changes, visual/feel tradeoffs, and whether to enter the next phase.

When defaults are reasonable, say:

我会按默认方案处理低风险事项。
本阶段结束后会停下等你确认。

Documentation

Prefer maintaining these files when the project has or needs docs:

• docs/dev_log.md
• docs/decisions.md
• docs/pitfalls.md
• docs/tuning.md
• docs/asset_pipeline.md
• docs/test_plan.md

At phase end, document what changed, which files changed, what was verified, user feedback, and next step.

For pitfalls, record:

问题：
原因：
修复：
复用教训：

For decisions, record:

决定：
原因：
替代方案：
风险：
回滚方式：

For tuning, record:

参数：
修改前：
修改后：
原因：
效果：

Backup And Rollback

In late-phase or high-autonomy work:

• Back up configs, scenes, levels, and key assets before changing them.
• Create v2 or versioned assets instead of overwriting important resources.
• Prefer Git commits/checkpoints before larger changes.
• Avoid hardcoding tuning values when config/data can hold them.
• Explain what changed, why, and how to roll back.

Natural-Language Tuning

Translate subjective feedback into concrete, limited changes.

• "角色跳起来太轻": inspect gravity, jump velocity, fall speed, landing feedback.
• "画面不够高级": inspect lighting, materials, post-processing, camera, UI hierarchy; do not alter core rules.
• "操作有点粘": inspect input latency, acceleration, damping, and animation transitions.

Tune one concern per round, verify it, and update docs/tuning.md when present.