Ludo Atlas · 团队与规模 · 单人开发（Solo Dev）¶
团队与规模。定位：把「一个人做完一款游戏」拆成可执行的范围纪律、周节奏与心理预期，覆盖从一句话立项到发布后更新的全流程。 配套：《制作管理手册》·《独立开发生存手册》·《AI 工作流手册》·《游戏设计手册》。
1. 定位与适用¶
单人开发指核心角色（策划、程序、美术、音频、QA、发布）都由一个人兼任的开发模式。它和团队开发是两种取舍方式：团队用分工扩大产能，单人用缩范围保证完成。星露谷物语、吸血鬼幸存者这类作品都走的是单人路径，它们的共同点是每一件留下的东西都被砍到必需。
先按投入形态对号入座（量级为参考值）：
| 形态 | 每周投入 | 完成一个商业小项目的量级 | 前提与风险 |
|---|---|---|---|
| 业余、学生 | 5-10 小时 | 以年计，或只做 jam 级作品 | 用小作品练完整流程；周期拖长是主要风险 |
| 兼职 | 10-20 小时 | 6-12 个月（《制作管理手册》§7 口径） | 有稳定收入；必须固定时段，否则无限期拖延 |
| 全职 | 40 小时以上 | 3-6 个月（同量级线性外推） | 先算 runway（建议 12 个月以上，《独立开发生存手册》），完不成即断粮 |
单人模式适合的项目形状：机制驱动、体量小、风格统一、单人体验或回合制。不擅长的：长叙事角色扮演、大量手工资产、需要长期在线运营的服务型游戏。遇到体量矛盾，改范围，不改决心。
「单人」指决策与核心制作是一个人，不是所有活都自己干。外包、素材库、AI 是三根杠杆（见 §4），先用它们把时间解放出来，再谈范围。
2. 核心挑战与对策¶
2.1 时间与精力预算¶
每周可用工时 = 168 - 睡眠 - 正职 - 生活，按这个结果排计划，而不是按愿望排。三条纪律：
- 排期只占用可用时段的 50%-70%，其余留给缓冲、杂务与生病（估算与缓冲口径见《制作管理手册》§2）。
- 把每周状态最好的 2-3 个时段锁给核心制作（设计、代码、关卡）；回复、采购、素材整理集中到碎片时段。
- 开工前先做两周时间审计：记录实际投入再定范围。多数人低估杂务，高估专注时长。
2.2 范围纪律：砍到只剩一件事¶
砍范围靠流程，不靠毅力。按下面的顺序执行：
- 一句话验证：玩家在_里，反复做_（一个动词），为了____。写不满这句，不开工。
- 把想做的全部系统列出来，分成三堆：核心（砍掉后游戏不成立）、增强（更好玩但非必需）、装饰（其实来自别的游戏）。第一版只做核心堆。
- 把第一版砍到只剩一件事：一个动词、一种资源、一个目标。多出来的系统全部记进「增强堆」，等内容验证之后再说。
- 逐条破坏性追问：砍掉它，游戏还能玩吗？能，就砍，或者写进「不做清单」贴在看板首页。
- 砍的优先序：平台与语言数、外观与附加模式、系统深度、内容量，核心循环排在末位（完整清单见《制作管理手册》§3）。
- 新功能一换一：加一项先砍一项等量旧项，写进变更记录。
- 核心机制的验证原型控制在 1-4 周：做不出「想再玩一次」，换方向比硬做便宜。
一个具体的降级示例：把「开放世界 + 战斗 + 建造 + 剧情」降成「一张地图 + 一个机制 + 30 分钟流程」；做完之后如果仍然成立，再按需加回第二个系统。砍到位的自检：把项目讲给没听过的人，他能复述出核心玩法。
2.3 心态与倦怠¶
弃坑集中在四个位置，提前认出来就能绕过：
| 时期 | 典型状态 | 对策 |
|---|---|---|
| 开局 1-2 个月 | 新鲜感消退，进度看不见 | 目标拆到周；每周必须有能打开看到变化的构建 |
| 第一次外部试玩 | 被问题清单泼冷水 | 试玩前声明「找问题不是找夸奖」；只记录可修复项 |
| 发布前打磨期 | 「永远做不完」的错觉 | 冻结范围；定义「足够好」的验收线；设硬截止日 |
| 发布后冷启动 | 「没人玩，白做了」 | 第一款目标是走完流程；数据用于修正下一作 |
- 卡住 3 天规则：任何问题卡满 3 天，换任务、把问题缩小、去社区提问，不硬耗。
- 休息写进计划：每周留一天完全离开项目；睡眠是真实的产能。
- 一个人开发容易孤立：常驻一个开发者社群，找 1-2 个能互相试玩的同行。
发布的心理预期单独说：第一款作品的目标是完成发布、把流程走通，这比第一款就成功更现实。愿望单、收入、口碑的冷启动是常态，用首发数据决定下一作改什么，而不是用它否定这一作。
3. 工作流与节奏¶
3.1 每周循环¶
一周的默认配比按阶段调整（开发 / 发布与沟通 / 学习）：
| 阶段 | 开发 | 发布与沟通 | 学习 |
|---|---|---|---|
| 原型期 | 85% | 5% | 10% |
| 量产期 | 70% | 15% | 15% |
| 发布前 8 周 | 55% | 35% | 10% |
| 发布后 3 个月 | 55% | 35% | 10% |
- 学习时间花在「这个月用得上」的东西上，不为学而学；教程地狱是单人头号时间黑洞（见 §6）。
- 发布与沟通时段从垂直切片起就不为零：公开记录（截图、短日志）是发布那天唯一免费的存量；每周保底三件：一个可玩的构建、一条公开记录、一次 15 分钟周回顾。周目标上限 3 个，周一列目标时执行（《制作管理手册》§10）。
3.2 里程碑与任务板¶
- 里程碑 = 可玩的构建，不是「代码写完」。最小序列：玩具原型（1 个月）→ 垂直切片 → 内容量产 → Alpha（功能冻结）→ Beta（内容冻结）→ 发布，验收口径见《制作管理手册》§2。
- 任务板四列：待办 / 进行中 / 自测 / 完成；进行中不超过 2 张卡，单卡工作量切到 2 天以内。
- 单人没有第二双眼睛，自测替代 QA：每个版本过一遍回归清单与破坏性测试（读档、断网、连点、满背包），修不了的进已知问题列表。
3.3 单一信息源¶
- 决策、设定、任务各只放一个地方：设计文档进仓库（从
design.md起步），任务进看板，重大决定当日写 3-5 行变更记录。 - 聊天记录里的「临时决定」每周回收进文档；脑内状态是单人开发最大的隐藏成本。
- 提交信息与代码写给三个月后的自己：说清「为什么」，构建产物按版本号归档。
3.4 发布节奏¶
发布是一条时间线，不是一次动作：
| 节点 | 动作 | 心理准备 |
|---|---|---|
| 垂直切片完成后 | 在 itch.io 或同类渠道做小范围试玩，开始收集反馈 | 收到的问题多于夸奖是正常的 |
| 发布前 3-6 个月 | 商店页上线，愿望单越早越好；保持公开记录 | 愿望单增长缓慢是常态，看趋势不看单日 |
| 发布前 4-8 周 | 准备 Demo 参加展示活动；宣传素材定稿 | 素材质量决定点击率，值得返工 |
| 首发周 | 按发布检查清单逐项过（《全平台上架手册》§10）；留出整天做热修 | 首发 24 小时别安排其他事 |
| 发布后 2-4 周 | 热修、回应反馈、写复盘 | 「上线即消失」会伤掉早期口碑 |
4. 协作与分工¶
4.1 什么时候外包¶
判断标准：稳定交付、容易验收的事外包；要反复迭代的事自己做。
| 任务 | 建议 | 理由 |
|---|---|---|
| 核心玩法、手感、核心循环 | 自己做 | 变更最频繁，外包的沟通成本高于收益 |
| 关键美术（主视觉、封面、角色） | 外包或委托 | 决定卖相；自己不擅长时性价比最高 |
| 音乐、主题曲 | 委托或授权曲库 | 单曲委托常见；确认授权范围 |
| 音效 | 素材库加自行加工 | 单件价格低、数量大，素材库够用 |
| 本地化 | 外包（发布前） | 各语种母语审校；机翻初稿加人工 |
| 主机移植、认证 | 有预算时外包 | 经验壁垒高；第一款作品可以先不做 |
时机判断见《独立开发生存手册》：等「自己做的质量或速度」成为真实瓶颈、资产量上来之后再考虑，风格未定时别下单。流程按《制作管理手册》§4.3 走：需求包（参考图、规格、验收标准、交付格式）→ 试单 → 里程碑合同分批付款 → 分批验收 → 源文件与授权归档。预算量级：外包通常占作品预算的 20-40%。
4.2 怎么找合作者¶
- 渠道：Game Jam、开发者社群、外包平台的试单、前同事。长期合作从一次小任务开始试，再谈继续。
- 优先付费买断服务，权属清晰；分成合作的工作量、时间、退出条件必须落纸，合同参考《法务、专利与竞争手册》。
- 给合作者的输入永远是文档而不是口头转述：「我脑子里那样」是外包返工的第一大来源。
4.3 一个人怎么补美术与音频¶
| 途径 | 适合 | 注意 |
|---|---|---|
| 素材包 | 原型、非关键资产、音效 | 逐个核对授权（商用、署名、再分发）；风格统一性自己把关 |
| 外包、委托 | 主视觉、角色立绘、主题音乐 | 需求包与验收标准先行；分批付款 |
| 自己做 | 选低门槛风格（像素、几何、黑白） | 先做一张「风格测试」图定规范再量产（规范见《美术与音频手册》） |
| AI 生成 | 概念草图、占位资产、纹理变体 | 只当中间产物；终版人工加工并披露 |
音频不建议整个跳过：音效包加一首授权主题曲的最低配置成本不高，但对「完成度」的感知影响很大（规格见《美术与音频手册》）。
4.4 把 AI 当「团队成员」的边界¶
- 定位：AI 是加速器，判断与验收仍在你（《AI 工作流手册》的整体前提）。
- 放心用：样板代码、工具脚本、配置、批量转换、占位资产、文案初稿。
- 用过人工过一遍：翻译初稿、营销文案、需要加工的美术资产；数字与结论逐条核实。
- 不直接用：核心玩法的手感决策、未经加工的最终美术、任何复刻他人作品的产出。
- 留痕：建一份 AI 使用记录（工具、环节、产出用途），平台披露与复盘都要用；披露要求见《AI 工作流手册》§4.5、§8。
5. 工具与技术栈建议¶
工具链的原则是够用、敢换、少折腾：一次性搭好，每月维护不超过半天；纠结时选免费且最熟的。
| 环节 | 够用组合 | 备注 |
|---|---|---|
| 版本控制 | Git 加一个远端仓库 | 每天至少提交一次；大改前打标签；大文件走 LFS 或忽略 |
| 备份 | 本地、云端、异地三处（3-2-1） | 定期做一次恢复演练，验证备份真能打开 |
| 任务管理 | 任选一个看板工具（Trello/Notion/飞书/Codecks 这一级即可） | 单人不上重型项目管理；卡片不超过 2 天 |
| 设计文档 | 仓库内 design.md 加变更记录 |
单一信息源；被孤立的「临时决定」每周回收 |
| 外包协作 | 邮件或文档加源文件归档目录 | 需求与验收标准写进文档，不靠口头 |
| 构建与发布 | 引擎导出加渠道后台，构建按版本归档 | 每个上传过的版本留档，商店回滚时需要 |
发布渠道的够用组合：PC 优先走「itch.io 分发 demo、Steam 首发」，有余力再考虑第二个平台；移动与小游戏按平台要求另算。一个平台做深再加下一个，每加一个平台，QA 与支持成本都上一个台阶。
6. 常见坑¶
- 范围失控：第一作就想做大作。一句话写不满就砍，装不进 12 个月的项目降级重估。
- 原型期堆美术：核心玩法验证前的一切精细工作都可能作废。灰盒先过外部试玩。
- 闭门造车：发布日才第一次听到真实反馈。每个里程碑找 3-5 人试玩。
- 发布时段为零：上线时零愿望单、零社群。公开记录从第一段能看的内容起保持。
- 教程地狱：用学新工具逃避做游戏。学习按项目当前缺口触发，不囤积。
- 没有备份与文档：一次硬盘故障毁掉全部。3-2-1 备份加关键设计外部化。
- 用健康换进度：熬出来的进度，后面要用数倍时间还。休息与睡眠写进计划。
- 外包核心玩法：最该迭代的东西交给别人，往返沟通吃掉全部收益。
- 预期错位：默认「做完就会有人玩」。第一款的目标是走完流程，数据留给下一作。
延伸阅读¶
- 《制作管理手册》：立项包、估算排期、范围控制与单人开发专章，本文第 2、3 节的完整展开。
- 《独立开发生存手册》：模式选择、runway 计算、资金来源与决策关口。
- 《AI 工作流手册》：AI 适用判断表、披露要求与红线清单。
- 《游戏设计手册》：核心循环与系统取舍的底稿。