game-jam

Game Jam

将主题和固定期限转化为一款完成并提交的游戏。这是一份规划与控制范围的实战指南，不涉及引擎代码：胜利条件是提交一款可玩的游戏，而不是做出你想象中的游戏。

适用场景

• 参加限时 Game Jam（Ludum Dare、GMTK Jam、Global Game Jam、周末 Game Jam）、规划 48 小时的开发范围，或决定删减哪些内容以赶上截止时间时使用。
• 用户询问“我周末实际能做出什么”或“如何向这个 Game Jam 提交作品”时使用。

不适用场景： 使用引擎代码构建核心循环（使用引擎技能——godot-2d-movement、phaser-core 等——或 platformer 之类的游戏类型技能）；没有截止时间的一次性实验（使用 prototype-fast）；发布商业作品（使用 steam-publish / itch-publish）。

核心工作流

1. 主题公布前先阅读规则。 确认 Game Jam 的时长、主题公布时间、提交截止时间（含时区）、是否允许组队／使用预制资源／使用游戏引擎，以及评分是否要求你给其他作品评分。漏掉其中任一项，都可能让一款原本完成的游戏失去参赛资格。
2. 提前准备好繁琐事项（大多数 Game Jam 都允许）：能构建和导出的空项目、输入功能和标题／结束画面占位内容、已实际运行过一次的导出流程，以及已获授权可使用的字体／音效来源。第一天的时间宝贵，不该花在这些事情上。
3. 主题 → 一句话。 用 15 分钟构思 10 个点子，然后选定一个，并能用以下句式表达：“你通过[动词]来实现[目标]，同时受到[限制]。” 如果没法用一句话说明，说明范围太大。
4. 根据时间安排范围，而不是根据想法。 使用下方的预算表。选定一个核心机制和一个“亮点”。其他所有内容都是扩展目标。
5. 优先制作垂直切片。 尽早做出一个可玩的 30 秒循环（开始 → 游玩 → 输／赢 → 重开）。一个完整的小循环胜过一个只做了一半的大游戏。
6. 预留最后约 20% 的时间用于发布，而不是开发新功能。导出、在干净环境中测试构建版本、截取屏幕截图、编写页面内容。到了第 47 小时，构建版本总会出问题。
7. 尽早提交，有时间再更新。 远早于截止时间上传一个可运行的构建版本；大多数 Game Jam 页面允许你在截止前替换文件。提交的平庸作品能获得评分，未提交的优秀作品则不能。

模式

1. 按 Game Jam 时长制定范围预算（从截止时间倒推）

              | 48-hour jam            | 72-hour jam           | 1-week jam
--------------|------------------------|-----------------------|------------------------
Core mechanic | 1, proven by hour 6    | 1-2                   | 2-3 interacting
Levels/content| 1 hand-made or gen'd   | 3-5                   | 8-12 + progression
Art           | placeholder/1 palette  | cohesive 1-artist set | themed set + UI
Audio         | 3-5 SFX + 1 loop       | SFX + 1-2 tracks      | adaptive music
SHIP BUFFER   | last 8-10 h            | last 12-16 h          | last full day

2. 48 小时时间安排（具体时段）

H0-2    Ideate -> lock ONE-sentence concept -> name the core mechanic + win/lose.
H2-8    Core loop in code with primitives (boxes/circles). Make it playable, no art.
H8-12   Sleep. (Tired code is tomorrow's bug list.)
H12-24  Content: 1 level/encounter, tune difficulty, add the "hook" feature.
H24-30  Sleep + playtest with one other person; cut anything not landing.
H30-38  Art + audio pass. Juice: screenshake, hit-stop, tween, particles, SFX.
H38-44  Bug-fix freeze: no new features. Fix only crashes + soft-locks.
H44-48  EXPORT, test the build clean, screenshots, write page, SUBMIT (by ~H46).

3. 功能优先级排序——快速决定，并明确说出来

For every feature ask, in order:
  1. Does the core loop work WITHOUT it?   -> if yes, it's a stretch goal, not MVP.
  2. Can a player tell it's missing?       -> if no, cut it.
  3. Is it < 30 min of work?               -> if no, defer past the ship buffer.
Default answer under deadline pressure is CUT. You can always add in a post-jam version.

4. 提交前构建检查（在干净副本上运行，而不是在开发文件夹中）

[ ] Build runs from an extracted zip on a path with NO engine/IDE installed.
[ ] Controls are shown on-screen or on the page (jurors won't read your mind).
[ ] No dev console errors; no soft-lock; restart works.
[ ] Web build (if any) is set to the platform's playable-in-browser mode.
[ ] Page has: 1-line pitch, controls, screenshots, credits + asset licenses.
[ ] File uploaded and the submission is actually attached to the JAM, not just the page.

常见问题

• 范围蔓延是 Game Jam 的头号杀手。 如果时间过去三分之一时核心循环还不能玩，现在就删减功能，别拖到以后。
• 没有发布缓冲时间。 导出、压缩文件和编写页面通常需要 1–3 小时，而且总会暴露构建问题。把截止时间视为提前约 2 小时。
• 只在页面上提交了游戏，却没有提交到 Game Jam。 在 itch.io 上，Game Jam 参赛作品需要单独提交，并关联到 Game Jam 页面——仅上传游戏并不算参赛。
• 导出后未经测试。 “在编辑器中能运行”不等于“构建版本能运行”。在干净环境中测试导出的文件；资源缺失和工作目录错误都是常见问题。
• 使用未获授权的资源。 从网上下载的音乐／字体／精灵图可能违反 Game Jam 规则，也可能影响后续发布。使用已获授权的资源，并在制作人员名单中列出。
• 核心循环还不好玩就开始打磨细节。 润色能放大乐趣，却不能凭空创造乐趣。先用占位资源把循环做好。

参考资料

• 关于一次性原型与可保留原型的思路，以及灰盒制作技巧，请阅读 prototype-fast 技能。
• 关于实际上传流程（项目页面、渠道、butler push），请阅读 itch-publish。

相关技能

• prototype-fast — 在投入游戏 Jam 的开发时间之前，快速验证一项机制。
• itch-publish — 创建页面并上传构建版本（大多数游戏 Jam 都托管在 itch.io 上）。
• 引擎核心技能（phaser-core、love2d-core、godot-gdscript 等）和类型技能 （platformer、roguelike 等）——构建游戏 Jam 规划围绕的实际玩法循环。