prototype-fast

快速制作原型

尽快让玩家体验一项机制，了解它是否值得开发。原型的产出是一个决策（保留 / 放弃 / 重构），而不是产品。以快速学习为目标，并预先决定代码是一次性使用还是要作为长期基础。

适用场景

• 验证单项机制或“假如……会怎样”，制作垂直切片 / MVP，为关卡或交互制作灰盒，或在投入实际时间前降低创意风险时使用。
• 用户说“先做个能玩的就行”“这个好玩吗？”或“先粗略搭出来”时使用。

**不适用场景：**有截止日期和提交要求的限时比赛（使用 game-jam）；发布或更新正式版本（使用 steam-publish / itch-publish）；为已验证的功能构建正式版本（直接使用对应的引擎 / 类型技能）。

核心工作流

1. 写下唯一的问题。 明确原型必须回答的单个问题，例如： “下落时使用抓钩，操控起来是否令人满意？” 如果有两个问题，就制作两个原型。一个什么都测的原型，实际上什么都测不了。
2. 写代码前，决定代码是一次性使用还是要保留。 一次性使用（spike）：硬编码、不做架构设计，测试后删除。保留：仍然粗略，但文件夹 / 命名要便于扩展。大多数原型都应该是一次性使用；假装它们不是，原型就会逐渐腐化为正式代码库的一部分。
3. 设定严格的时间限制（机制测试 30-90 分钟；切片测试一口气完成），并放一个显眼的计时器。限制本身就是重点——它会迫使你测试核心创意，而不是修饰细节。
4. 将所有非必要内容都做成灰盒。 美术使用基本图形（方块、圆形、胶囊体），使用内置字体，音效只用一个调试音效或完全不用。对问题答案没有影响的内容，一分钟也不要花。
5. 围绕问题添加测量手段。 添加屏幕调试文本 / 辅助线框，显示你要评估的内容（速度、距离、时机窗口）。你是在测量，不是在装饰。
6. 立即、诚实地进行试玩测试。 先自己试玩，再交给一个人，不要解释操作方式。观察他们在哪里遇到困难。
7. 根据淘汰标准（见下文）做出判断。 保留 → 安排正式开发并重写，不要把 spike 升级为正式代码。放弃 → 记录经验，然后继续。重构 → 缩小问题范围，再做一次 spike。

模式

1. 原型简报（编码前填写）

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. 将核心循环做成灰盒，其他部分全部模拟（与引擎无关的伪代码）

# 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. 淘汰标准——让保留 / 放弃的判断有据可查，而非出于情绪

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. 隔离：让 spike 远离正式代码库

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.

常见问题

• 过早打磨。 美术、菜单和音频会让平淡的机制看起来已经完成，并延后结论。先用灰盒验证核心玩法。
• 没有淘汰标准。 如果没有写下“满足什么条件就放弃”，每个原型都会“有潜力”，最终什么都不会被砍掉。在你对代码产生感情之前，先确定判断依据。
• 构建系统，而不是机制。 背包、存档 / 读档和设置都不是要验证的问题。用桩代码代替。
• spike 变成产品。 将一次性代码升级到正式环境，就是背着技术债务讲一个有趣的起源故事。决定保留后应重写。
• 在正式代码库中制作原型。 这会让实验和正式系统纠缠在一起，也会增加删除 spike 的成本。使用独立的文件夹 / 项目。
• 只测试自己。 你了解操作方式和设计意图。让一个未经指导的外部玩家来试，短短两分钟就能揭示比一小时自测更多的问题。

参考

• 如需了解如何在严格的外部期限内完成并提交作品，请阅读 game-jam 技能。
• 如需了解你要制作灰盒的引擎专属核心循环，请阅读对应引擎的技能 （godot-gdscript、phaser-core、love2d-core、unity-csharp-scripting……）。

相关技能

• game-jam — 将同样的范围控制原则用于有提交要求的限时比赛。
• 引擎核心和类型技能 — 了解如何妥善重建“保留”的内容。