跳到正文
cccskills
免费在 GitHub 公开

prototype-fast

Create a playable game prototype to test one mechanic within a short time limit. Use simple shapes, observe players, and apply explicit criteria to decide whether to develop the idea, abandon it, or adjust it.

中文简介正在准备中。当前显示英语简介。

原文查看原文说明

Build a playable prototype in about an hour to answer one question — is it fun? — with greybox primitives, a hard timebox, and explicit keep/kill criteria. Use when prototyping a mechanic, making a vertical slice or MVP, greyboxing/blockout, or judging throwaway vs keep.

实测评分 未实测

查看安装方法

适用场景

  • Test whether a new game mechanic is fun
  • Build a playable prototype in 30–90 minutes
  • Test levels and interactions with simple shapes
  • Decide whether to continue, abandon, or adjust an idea

包含的文件(1)

  • SKILL.md5.9 KB

SKILL.md(原文)

安装前可以查看交给 AI 代理的指令内容。

Prototype Fast

Get a mechanic into a player's hands fast to learn whether it's worth building. The output of a prototype is a decision (keep / kill / refactor), not a product. Optimize for learning speed, and decide up front whether the code is throwaway or load-bearing.

When to use

  • Use when validating a single mechanic or "what if", building a vertical slice / MVP, greyboxing a level or interaction, or de-risking an idea before committing real time.
  • Use when the user says "just get something playable", "is this fun?", or "rough it in".

When not to use: a timed competition with a deadline and a submission (use game-jam); shipping or updating a real release (use steam-publish / itch-publish); building the production version of a validated feature (use the engine/genre skill directly).

Core workflow

  1. Write the one question. State the single thing the prototype must answer, e.g. "Is grappling-while-falling satisfying to control?" If you have two questions, build two prototypes. A prototype that tests everything tests nothing.
  2. Decide throwaway vs keep — before you write code. Throwaway (a spike): hard-code, no architecture, delete after. Keep: still rough, but folder/names you can grow. Most prototypes should be throwaway; pretending otherwise is how prototypes rot into the shipping codebase.
  3. Set a hard timebox (30-90 min for a mechanic; one sitting for a slice) and a visible timer. The constraint is the point — it forces you to test the core idea, not the trim.
  4. Greybox everything non-essential. Primitives for art (boxes, circles, capsules), built-in fonts, one debug sound or none. Spend zero minutes on anything the question doesn't depend on.
  5. Instrument for the question. Add on-screen debug text / gizmos that show the thing you are judging (speed, distance, timing window). You're measuring, not decorating.
  6. Playtest immediately and honestly. Play it yourself, then hand it to one other person without explaining the controls. Watch where they struggle.
  7. Make the call against your kill criteria (below). Keep → schedule the real build and rewrite, don't promote the spike. Kill → log the lesson and move on. Refactor → narrow the question and spike again.

Patterns

1. The prototype brief (fill this in before coding)

QUESTION:     The one thing this must prove (binary if possible).
CORE VERB:    The single action the player repeats.
THROWAWAY?:   yes -> hard-code freely, delete after.  no -> minimal structure to grow.
TIMEBOX:      e.g. 60 min. Stop when it rings, even if unfinished.
KEEP IF:      observable signal that means "fun / worth building" (see kill criteria).
KILL IF:      observable signal that means "stop".

2. Greybox the core loop, fake everything else (engine-agnostic pseudocode)

# Only the CORE VERB is real. Visuals are primitives; systems are stubs.
on update(dt):
    read_input()
    apply_core_mechanic(dt)        # the ONLY thing you're testing — make this feel right
    draw_primitive(player)         # a box. not a sprite. not animated.
    draw_debug_hud(speed, timing)  # show the numbers you're judging
    # enemies, menus, save, audio, art -> stubbed or absent until the verb proves out

3. Kill criteria — make the keep/kill call observable, not emotional

KEEP when, with placeholder art:
  - a fresh player does the core verb on purpose within ~30s, unprompted, and
  - you (or they) repeat the loop "one more time" without being asked.
KILL when:
  - the verb only feels good after you explain it, or
  - making it fun needs systems far beyond the prototype's scope, or
  - you're adding art/levels to avoid admitting the verb is flat.
REFACTOR when one variable is clearly off (too slow, window too tight) -> retune, retest.

4. Containment: keep a spike out of the shipping codebase

prototypes/<idea-name>/      # separate folder or project, never imported by main game
  - hard-coded values, single file ok, magic numbers welcome
  - committed on a throwaway branch (or not at all)
Rule: a "keep" decision authorizes a REWRITE in the real project, not a copy-paste of the
spike. Prototype code carries prototype assumptions; shipping it ships the assumptions.

Pitfalls

  • Polishing too early. Art, menus, and audio make a flat mechanic look finished and delay the verdict. Greybox until the verb is proven.
  • No kill criteria. Without a written "kill if", every prototype "has potential" and nothing gets cut. Decide the signal before you're attached to the code.
  • Building systems instead of the mechanic. Inventory, save/load, and settings are not the question. Stub them.
  • The spike becomes the product. Throwaway code promoted to production is technical debt with a fun origin story. Rewrite on a keep.
  • Prototyping in the real codebase. It tangles experiments with shipping systems and makes the spike expensive to delete. Use a separate folder/project.
  • Testing only yourself. You know the controls and the intent. One uncoached outside player reveals more in two minutes than an hour of self-play.

References

  • For working under a hard external deadline and submitting, read the game-jam skill.
  • For the engine-specific core loop you'll greybox in, read that engine's skill (godot-gdscript, phaser-core, love2d-core, unity-csharp-scripting, …).

Related skills

  • game-jam — same scope discipline applied to a timed competition with a submission.
  • Engine cores and genre skills — where a "keep" decision gets rebuilt properly.

评价

还没有评价。欢迎分享你的使用感受。

评论

无需登录即可发表。欢迎分享使用感受、提问,或说明在哪些环境下无法运行。

还没有评论。来写第一条吧。

提交后会立即公开。请勿填写邮箱、电话等个人信息。URL 最多 2 个。

0 / 1000 字

此表单受 reCAPTCHA 保护,适用 Google 的隐私权政策和服务条款。

同一仓库的技能

Implement reusable decision systems for game characters using behavior trees, which organize conditional actions, and Utility AI, which scores available choices. Build either approach or combine them to control patrols, combat, targeting, and needs-based behavior.

中文简介正在准备中。当前显示英语简介。

  • Build a reusable behavior tree runtime
  • Choose attacks or targets using action scores
  • Combine patrol and combat trees with Utility AI
gamedev-skills/awesome-gamedev-agent-skills35002026年10月23日 更新

Design game audio with grouped volume controls, music that responds to gameplay, and varied sound effects. Plan how music lowers during dialogue and how events follow the beat, using principles that can be adapted to different game engines.

中文简介正在准备中。当前显示英语简介。

  • Plan grouped volume controls for music, effects, and dialogue
  • Lower background music while dialogue plays
  • Change music layers or segments with gameplay intensity
gamedev-skills/awesome-gamedev-agent-skills35002026年10月23日 更新

bevy-ecs

免费

Build and debug Rust games in Bevy using ECS, a way to separate game data from behavior. Organize apps and plugins, query entities, control execution order, and fix conflicting data access or frame-dependent movement.

中文简介正在准备中。当前显示英语简介。

  • Organizing a Bevy app with plugins
  • Defining components and shared resources
  • Fixing conflicting queries and execution order
gamedev-skills/awesome-gamedev-agent-skills35002026年10月23日 更新

Build and tune game cameras for smooth 2D following and 3D viewing. Covers motion smoothing, look-ahead, level boundaries, wall avoidance, and framing multiple targets, with techniques that apply across engines.

中文简介正在准备中。当前显示英语简介。

  • Smooth player-follow cameras in 2D games
  • Keep the camera view within level boundaries
  • Prevent third-person cameras from clipping through walls
gamedev-skills/awesome-gamedev-agent-skills35002026年10月23日 更新

card-game

免费

Design the core rules of a card game, including decks, hands, discards, drawing, shuffling, turns, and resource costs. Represent card effects as data and define their resolution order so card movement and gameplay outcomes follow explicit rules.

中文简介正在准备中。当前显示英语简介。

  • Building a deckbuilder or trading card game
  • Implementing draws and discard reshuffling
  • Defining turn phases and card costs
gamedev-skills/awesome-gamedev-agent-skills35002026年10月23日 更新

Plan and prepare consistent game artwork, from sprites and backgrounds to UI icons and 3D briefs. Organize asset requirements, generate or source related visuals, standardize files, and check their appearance and technical fit inside the game.

中文简介正在准备中。当前显示英语简介。

  • Create sprites and backgrounds with a consistent visual style
  • Check asset dimensions, transparency, and tile seams
  • Track asset sources and licenses before release
gamedev-skills/awesome-gamedev-agent-skills35002026年10月23日 更新

查看 gamedev-skills 的全部技能

报告此技能的问题