Back to Details

prototype-fast

Compare original and translation side by side

🇺🇸

Original

English
🇨🇳

Translation

Chinese

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).
  • 适用于验证单一机制或“假设场景”、制作垂直切片/MVP、关卡或交互的灰盒搭建，以及在投入正式开发前降低创意风险的场景。
  • 当用户提出“先做个可玩的版本看看”、“这东西有趣吗？”或“先搭个粗略框架”时适用。
不适用场景： 有截止日期和提交要求的限时竞赛（请使用
game-jam
技能）；发布或更新正式版本（请使用
steam-publish
/
itch-publish
技能）；构建已验证功能的生产版本（直接使用对应引擎/类型的技能）。

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.
  1. 明确核心问题：写出原型必须解答的唯一问题，例如“坠落时使用抓钩的操控体验是否令人满意？”。如果有两个问题，请制作两个原型。试图测试所有内容的原型等于什么都没测试。
  2. 提前决定代码用途：在编写代码前确定是一次性使用（即spike：硬编码、无架构，用完即删）还是保留复用：保留的代码虽仍粗糙，但文件夹/命名需具备可扩展性。大多数原型应设为一次性使用；否则原型代码会逐渐演变为正式代码库的一部分，留下隐患。
  3. 设置严格时间限制（单个机制30-90分钟；垂直切片需一次完成）并使用可见计时器。约束是关键——它能迫使你测试核心创意，而非无关细节。
  4. 灰盒化所有非必要内容：用基础图形（方块、圆形、胶囊体）替代美术资源，使用内置字体，最多添加一个调试音效或完全不用音效。任何与核心问题无关的内容都不要花费时间。
  5. 针对核心问题添加监测工具：添加屏幕调试文本/ gizmos，显示你需要判断的指标（速度、距离、时间窗口）。你要做的是测量，而非装饰。
  6. 立即且诚实地进行测试：先自己测试，然后交给另一个人，不解释操作方法。观察他们遇到的困难。
  7. 依据舍弃标准做出决策（见下文）。保留→安排正式开发并重写，不要直接复用一次性原型代码。舍弃→记录经验教训后继续推进。重构→缩小问题范围，重新制作原型。

Patterns

实践模式

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

1. 原型 brief（编码前填写）

text
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".
text
QUESTION:     原型必须验证的唯一内容（尽量用二元问题）。
CORE VERB:    玩家重复执行的核心动作。
THROWAWAY?:   yes -> 可自由硬编码，用完即删。 no -> 保留最小可扩展结构。
TIMEBOX:      例如60分钟。时间到即停止，即使未完成。
KEEP IF:      可观察到的信号，表明“有趣/值得开发”（见舍弃标准）。
KILL IF:      可观察到的信号，表明“停止开发”。

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

2. 灰盒化核心循环，其他内容全部模拟（与引擎无关的伪代码）

text
undefined
text
undefined

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
undefined
on update(dt): read_input() apply_core_mechanic(dt) # 这是你唯一要测试的内容——确保体验流畅 draw_primitive(player) # 用方块即可，不要用精灵或动画。 draw_debug_hud(speed, timing) # 显示你需要判断的数值 # 敌人、菜单、存档、音效、美术资源→在核心动作验证通过前，全部用桩代码替代或省略
undefined

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

3. 舍弃标准——让保留/舍弃的决策基于可观察事实，而非主观感受

text
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.
text
保留的条件（使用占位美术资源时）：
  - 新手玩家无需提示，能在约30秒内主动执行核心动作，且
  - 你（或玩家）会主动想要“再玩一次”。
舍弃的条件：
  - 只有在解释后，核心动作才显得有趣，或
  - 要让它变得有趣需要远超原型范围的系统支持，或
  - 你通过添加美术/关卡来逃避核心动作乏味的事实。
重构的条件：某个变量明显不合理（速度太慢、时间窗口太窄）→调整参数后重新测试。

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

4. 隔离：避免一次性原型混入正式代码库

text
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.
text
prototypes/<idea-name>/      # 单独的文件夹或项目，绝不被主游戏引用
  - 硬编码值，单文件即可，允许使用魔法数字
  - 提交到一次性分支（或不提交）
规则：“保留”的决策意味着在正式项目中**重写**，而非复制粘贴一次性原型代码。原型代码带有原型阶段的假设；直接发布原型代码等于发布这些未经验证的假设。

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
    , …).
  • 如需应对严格的外部截止日期并完成提交，请阅读
    game-jam
    技能文档。
  • 如需了解用于灰盒搭建的引擎特定核心循环，请阅读对应引擎的技能文档（
    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.
  • game-jam
    — 将相同的范围管控方法应用于有提交要求的限时竞赛。
  • 引擎核心与类型技能 — “保留”决策后，需在这些技能的指导下进行正式开发。