一天做20个版本，是什么概念？
1666: Amsterdam 的主创 Patrice Désilets 最近在接受 PC Gamer 杂志第 428 期采访时，给出了这个数字。他说团队"每天会做 15 到 20 个版本"，并把这套做法归结为 Panache 工作室的迭代逻辑——"进度比完美更重要"。
这句话放在别的项目里，可能只是一句开发日常。但放在 1666: Amsterdam 身上，就有点意思了。因为这款游戏从立项到现在，走过的路实在不算顺。
一条走了十几年的路
把时间线拉出来看，1666: Amsterdam 最早在 2011 年被提出构想，2013 年在 THQ 正式开工。之后育碧收购了这家工作室，解雇了主创 Patrice Désilets，同时拿到了 1666: Amsterdam 的版权。经过一系列法律程序，Désilets 最终拿回了这款游戏的版权。这也是他 2010 年离开育碧之后的第二个项目。
对熟悉他的人而言，Patrice Désilets 这个名字前面通常还会挂一个头衔——刺客信条系列的创造者。而 1666: Amsterdam 是一款"女巫题材"的动作游戏，玩家在其中的核心动作是"换身体"。有媒体把它和 Hitman 放在一起比较，认为两者的相似度比它和刺客信条之间还要高。
今年 8 月，这款游戏以抢先体验的形式登陆 Steam。从 2011 年的一个想法，到 2026 年才和玩家见面，中间隔了十几年。
正方：高频迭代是"进度优先"的必然选择
支持这套打法的人，逻辑其实很直接。
抢先体验本身就是一种"边做边改"的模式。游戏已经上架，玩家已经在玩，反馈每天都在进来。在这种情况下，一天 15 到 20 个版本，意味着团队把"改"的颗粒度压到了极小——不是攒一个大补丁，而是小步快跑。
Désilets 自己的表述是"进度比完美更重要"。这句话可以理解为一种取舍：与其在一个版本里追求零瑕疵，不如先把东西推出去，让下一版去修。
数据也能对上。游戏上线一个多月，团队已经放出了两个大型更新，其中第二个更新包含了"超过 200 项修复"。这个修复量，和"一天 20 个版本"的节奏是能互相印证的。
再看官方在 Steam 页面上给出的说法：他们预计整个开发过程大约需要 1 年时间完成，期间会通过多个大型更新，定期为游戏加入新内容。也就是说，高频迭代不是临时起意，而是写进计划里的节奏。
反方：高频迭代也可能是在补窟窿
但换个角度看，一天 20 个版本这件事，也可以读出另一层意思。
一款游戏如果状态稳定，通常不需要这么密集的构建频率。高频迭代往往出现在两种情况下：一种是团队效率极高、流程极顺；另一种是问题太多，必须靠快速试错来兜底。这两种情况，从外部很难分辨。
更值得放在一起看的，是今年早些时候围绕这款游戏的一场风波。有玩家在游戏的试玩版中发现了 AI 生成的素材，随后开发团队迅速道歉，并承诺在正式发售前移除游戏中所有 AI 生成的内容。
Désilets 今年早些时候向 GamesRadar+ 解释过这件事：这项技术被用在"概念设计和前期制作"阶段，但团队"不会再使用任何 AI 了"。
把这两件事并排放：一边是承诺清理 AI 素材，一边是每天 15 到 20 个版本的构建量。前者意味着要重做一部分内容，后者意味着有足够多的构建次数去承接这些重做。它们之间未必有因果关系，但至少说明，这个项目当前的工作量不小。
判断：数字本身说明不了好坏，但能说明状态
一天 15 到 20 个版本，这个数字既不是勋章，也不是罪证。
它唯一能确定说明的是：Panache 现在处于一个高度活跃的开发状态。游戏还在抢先体验阶段，距离官方预计的约 1 年完成周期，还有相当长的一段路。
至于这条路最后通向哪，现在下结论都太早。已经发生的事实是：
- 游戏 8 月进入 Steam 抢先体验
- 上线一个多月，放出两个大型更新
- 第二个更新包含超过 200 项修复
- 官方预计完整开发周期约 1 年
- 团队承诺移除所有 AI 生成内容
这些是能查证的。至于"一天 20 个版本"到底是效率的证明还是问题的信号，可能得等它真正做完的那一天，才有答案。
在那之前，玩家能做的，大概就是打开游戏，看看今天又更新了什么。
热门跟贴