Ludo Atlas · 实践手册 · 48 小时 Game Jam¶
实践手册。定位：一次完整的发布演习，用最小的可交付范围换来一个做完、能玩、能展示、能提交的小作品。 配套：《游戏设计手册》（一句话概念与核心循环）·《制作管理手册》（范围与排期）·《避坑大全》（项目管理章节）·《独立开发生存手册》（路径阶梯）。
1. 适用场景与目标¶
48 小时 Game Jam 是一类限时开发活动：主办方公布主题后，参与者在 48 小时内完成一款可运行的小作品并在截止前提交。线上办赛与线下会场形式不同，核心规则一致，差异集中在截止时区、素材限制、AI 使用条款与评审方式。
适用：
- 想用最低成本完整走一遍「构思、开发、打包、发布」的全流程。
- 已经做过原型，想检验自己的速度边界：48 小时究竟能做出什么。
- 想为作品集攒一个能玩、能展示的小作品，或想结识未来的搭档。
- 想练范围控制：jam 是少数能把「砍」逼成肌肉记忆的场合。
不适用：
- 想顺便学会一个新引擎或新语言：学习曲线会吃掉一半以上时间（§5 第 2 条）。
- 想按商业作品的标准做长线打磨：jam 产出适合当原型或作品集，不适合直接进入长期迭代。
- 凑不齐连续的 48 小时：拆成碎片的「慢 jam」可行，但节奏要另行设计。
目标（按优先级）：
- 按时提交：截止前完成上传，拿到提交回执。
- 做完：一个从开始界面到结束画面的完整小体验，哪怕只有 10 分钟内容。
- 校准速度：记录每个阶段的实际耗时，为下一次 jam 修正自己的预算。
- 让人看懂：陌生人拿到链接后无需解释即可上手。
时间账：48 小时扣掉睡眠、吃饭与打包，实际可产出时间约 30-36 小时。所有计划从这 30 小时倒推，不从 48 小时倒推。
2. 全景流程¶
48 小时按四个阶段推进，赛前准备独立在时间轴之外。阶段之间设四道门：门没过，不允许进入下一阶段，这是防范围爆炸的第一道闸。
| 阶段 | 产出 | 时长 |
|---|---|---|
| 赛前准备（开赛前一周） | 模板工程、素材库、发布与提交账号、规则检查单 | 3-6 小时，分散完成 |
| 构思与砍范围（0-4 时） | 一句话概念、范围合同、纸面草图、任务板 | 4 小时 |
| 核心可玩（4-24 时） | 灰盒构建：核心循环闭合，能玩到失败与重开 | 20 小时（含吃饭与 6 小时睡眠） |
| 内容与打磨（24-40 时） | 内容填充、音频、界面与反馈、试玩构建 | 16 小时 |
| 提交与页面（40-48 时） | 构建包、平台页面、提交回执 | 8 小时（前 4 小时收尾，后 4 小时缓冲） |
四道门的通过标准：
- 第 4 时：一句话能说清「玩家做什么、为什么好玩」，且范围合同已经写死。
- 第 24 时：无解释、无提示时，测试者能玩到一次完整成败并愿意重开，核心循环闭合。
- 第 40 时：内容冻结（feature freeze），新增愿望一律进「下届清单」，不再动玩法。
- 第 44 时：构建与页面已至少上传过一次；剩余时间只用于修复与替换。
内部截止设在第 44 时，不是第 48 时：上传、转码、平台处理与网络抖动都会吃时间，剩下的 4 小时是保险，不是开发时间。
3. 分步执行¶
3.1 赛前：工具链与模板工程¶
- 用熟不用新：引擎、语言、构建工具全部选最近三个月持续在用的那套，jam 不承担学习任务。
- 模板工程至少包含：输入映射、角色控制与相机、场景切换、暂停与音量、一键打包脚本；从新建工程到出包的最短路径先演练一遍。
- 开赛前在目标平台跑通一次「空项目到安装包」的完整流程，把导出参数与踩过的坑写进检查单。
- 版本控制：单人或小队都从本地 git 仓库起步，每小时提交一次；jam 里不折腾分支模型。
- 任务板只留四列：待做、在做、做完、下届；任何时刻「在做」只有一项。
3.2 赛前：素材库与发布账号¶
- 素材库预置两套授权明确的免费素材（2D 角色与环境、UI 图标）、一套字体、20-30 个通用音效与两首可循环音乐。
- 素材先占位后替换，替换只发生在确认留下的资产上，避免给将砍的内容做美术。
- 发布与提交账号提前注册、验证邮箱、填好作者资料；能先建页面草稿的先建好。
- 把规则逐条读一遍并写成检查单：截止时区、提交材料、参赛人数上限、素材与 AI 条款、是否允许赛前已有资产。
- 素材来源与许可当天记录，提交时要能给出出处。
3.3 主题解读：从词到动词¶
主题公布后的第一小时只做发散，不写代码。
- 拆词：把主题拆成名词、动词、形容词三栏，每栏联想 10 个词，不评判。
- 动词化：问「玩家要做的那个动作是什么」。主题是名词就找它带来的动词，是形容词就找与之匹配的动作。
- 反转与换视角：把主题反过来、缩小、放大、换主角，各出一个点子；反转往往比字面理解更容易出彩。
- 五问过滤：玩法能否一句话说清；48 小时能否做出可玩版本；有没有一个能被截成 GIF 的瞬间；机制是否依赖大量内容；与常见理解是否重复。
发散 60 分钟、收敛 30 分钟。收敛后只留一个概念，其余全部进「下届清单」；选「最容易做出差异化」的，不选「最宏大」的。
3.4 范围纪律：只做一件事¶
一句话概念模板：你是（角色），在（场景）里，用（一个机制），做到（一个目标）。 四个空各填一个词；填不进去，或者想填两个，说明范围已经超标。
范围合同在开赛 4 小时内写死，贴在任务板顶部：
| 做 | 不做 |
|---|---|
| 一个核心机制，反复出现 | 第二套系统、技能树、多角色 |
| 一个场景，一套主题 | 多关卡、多区域、剧情分支 |
| 一个开始与一个结束 | 存档系统、设置菜单、成就 |
| 基础音效加循环音乐 | 定制美术、原创音乐、配音 |
| 简洁界面与反馈 | 联网、排行榜、多人模式 |
裁剪顺序：先砍内容量，再砍表现，不砍核心循环。新想法一律写进「下届清单」，不辩论、不试做。
3.5 团队分工：单人 vs 小队¶
| 维度 | 单人 | 2-4 人小队 |
|---|---|---|
| 常见配置 | 全栈一人 | 程序、美术兼设计、音频兼测试 |
| 优势 | 零沟通成本，决策快 | 并行产出，技能互补 |
| 风险 | 精力瓶颈、通宵失控 | 接口不清、互相等待 |
| 关键纪律 | 睡眠固定，范围再砍三分之一 | 接口先行，定时同步 |
单人：设定固定睡眠窗口，例如在第 20-26 小时之间睡满 6 小时；状态好时写玩法代码，状态差时做素材替换这类低脑力活；超过 30 分钟解不掉的难题先绕开。
小队 2-4 人：开场 2 小时内定死三件事，资产规格（尺寸、命名、导入路径）、模块边界（谁写哪部分、怎么对接）、同步节奏（每 4-6 小时一次 10 分钟站会，只问完成什么、卡在哪、砍什么）。指定一名范围裁判，他说砍就砍，异议留到赛后复盘。
5 人以上：拆成玩法、内容、提交三组，每组一个接口人；人数越多沟通越贵，范围反而要更小。
3.6 时间轴执行细则¶
0-4 时：构思与砍范围。 完成主题解读，定一句话概念与范围合同；画循环图与界面草图，用纸面把核心循环走一遍；搭好环境（模板工程、版本控制、任务板）。这一时段不写正式代码。
4-24 时：核心可玩。 前 8 小时做出最小可玩（玩家能动、核心动作能发生）；8-16 小时闭合核心循环（有成败、能重开）；16-24 小时做内部试玩、修复并睡觉。先做「能玩」不做「好看」，灰盒阶段不碰美化。
24-40 时：内容与打磨。 内容只做已有机制的变体（换参数、换布局、换节奏），不加新机制；音频先铺音效再上音乐；补齐标题页、胜利与失败画面、操作说明；找一名没参与开发的人试玩，修掉他卡住的第一个点。
40-48 时：提交与页面。 第 40 时内容冻结并立即打包，在干净环境验证；页面素材（标题、一句话简介、截图、GIF、操作说明、素材出处）同步做完并上传；第 44 时前完成首次提交，留出修复与替换的余量。
3.7 提交物清单¶
| 类别 | 内容 | 检查点 |
|---|---|---|
| 构建包 | 目标平台安装包或网页版 | 干净环境跑通；文件名带版本号 |
| 运行说明 | 操作方式、分辨率、窗口模式 | 不需要口头补充任何信息 |
| 页面素材 | 标题、一句话简介、3-5 张截图、1 个 GIF | 首屏截图能看出玩法 |
| 封面 | 按平台要求尺寸制作 | 不糊、不裁坏、一眼可分辨 |
| 声明 | 素材出处与授权、AI 使用情况、成员名单 | 与 jam 规则逐条对照 |
| 回执 | 提交完成截图与链接 | 本地与云端各存一份 |
4. 验收清单¶
提交前逐条过，全部通过才算收工。
玩法与体验：
- 从启动到能玩不超过三次点击，没有黑屏与死锁。
- 陌生人无解释可上手，30 秒内做出第一个正确操作。
- 10 分钟内能玩到一次完整成败，且愿意重开。
- 开始、结束、重开路径明确，胜利与失败画面均存在。
- 静音状态下画面仍能看懂，反馈不单靠声音。
技术与分发：
- 在没装引擎的机器或浏览器隐身窗口里跑通全流程。
- 连续玩 10 分钟无崩溃，反复重开不损坏状态。
- 目标分辨率与窗口模式正常，网页版加载在可接受范围。
- 构建文件名、版本号与运行说明一致。
- 音量可调，或至少没有爆音。
提交与合规：
- 页面文案与截图反映实际玩法，无占位文字。
- 素材出处、授权与 AI 声明完整。
- 提交回执已存档，链接在无登录状态可访问。
- 官方规则逐条对照过：截止时间、材料、人数、素材限制。
5. 常见坑¶
- 范围爆炸：第 4 时定完范围，第 8 时就想加第二个机制。对策：范围合同加范围裁判，新想法一律写进「下届清单」。
- 用 jam 学新工具：把比赛当教程，学习曲线吃掉一半时间，产出只剩一个样例工程。对策：主工具选熟的，新工具留给赛前的练手项目或下届。
- 临近截止才第一次打包：导出、页面与上传全部压到截止前，任何一步出错都来不及。对策：赛前演练全流程，第 40 时出包、第 44 时前提交。
- 打磨吃掉内容：时间全花在美术上，玩法还是灰盒。对策：先让循环好玩，再统一替换素材，打磨设时间上限。
- 通宵换进度：后 24 小时质量断崖，Bug 密度翻倍。对策：固定睡眠窗口，宁可砍功能不砍睡眠。
- 没有声音：默认静音交付，体验缺一半。对策：素材库预置音效包，铺音效是低成本高回报。
- 只让队友试玩：群体盲区，没人发现新手看不懂。对策：至少找一名没参与开发的人试玩。
- 主题贴皮：玩法与主题无关，评审一眼看穿。对策：用动词化检验（§3.3），让主题长进机制里。
- 不读规则：时区、素材限制、AI 条款、人数上限，任何一条踩线都可能被取消资格。对策：赛前逐条读并写进检查单。
- 提交后不验证：以为点完按钮就结束。对策：用无登录状态打开链接，下载自己提交的包再跑一遍，确认回执。
延伸阅读¶
- 《游戏设计手册》：核心循环与一句话概念的完整方法，本文 §3.3 与 §3.4 的底稿。
- 《制作管理手册》：阶段模型、范围控制与复盘流程，把 48 小时放大到完整项目时按它执行。
- 《避坑大全》：项目管理与发布章节，本文 §5 的扩充版。
- 《独立开发生存手册》：路径阶梯第 ① 级的说明，以及从 jam 走向下一个体量的决策规则。