我去年在一场周末Game Jam里当观察员时，见过一个团队：程序、美术、策划全都是有多年经验的老兵。48小时结束后，他们提交的作品连核心循环都没跑通。他们的代码仓库里留着三次重构过的对话系统，但玩家操作的角色根本不能走出去。反而是隔壁三个大学生用网上下的素材做了一个“按钮会逃跑”的冷笑话游戏，拿了最佳创意奖。这让我开始思考：是不是我们对“失控”的看法从一开始就是错的。
大多数项目解散时，大家归因于技术债或人手不足。但真正害人的是一种我称为“随机决策债”的东西。比如周五演示前，有人随手把角色跳跃加速度调成5.5，下午又有人为了让跳跃更跟手，把滞空时间改成0.45秒。没有人记录为什么是这些数字，于是测试时手感差了，所有人都不知道改哪里。技术债至少有个明确的文件和接口，随机决策债却分布在每个人的肌肉记忆里。对比两个产品更明显：《Vampire Survivors》把玩法精简到移动和一个自动触发的攻击，几乎没有第二个系统，却依靠有限参数堆出了数值上的爽快；而《The Day Before》从预告开始就不断加料，生存、驾驶、建造、射击，看起来什么都给你，实际发售四天就迅速变成退款现场，开发商Fntastic随后宣布关闭。SteamDB显示它发售当天峰值是38104人，算得上被骂上热搜的规模。可见，问题不是做得太少，而是做得太“开放”。
我自己在做过几个原型后端出的一套土办法是给项目加“范围栅栏”。不要把它理解成简单的需求列表，而是一组显式写出的不变量。举个例子，在做2D动作原型时，我会先在代码注释里固定：角色只允许在X轴上移动，重力加速度按-9.8m/s^2先顶着，跳跃分成上升和下落两段，起跳初速度设为10.5，受伤后包含4帧无敌帧；场景中同时交互物不超过3个。任何新系统进出都要做“过磅”：如果新系统要求给敌人加灼烧，那必须把原有的中毒或击退删掉。如果你用的是Godot，这套栅栏很容易写进工具层：用@export_range(0, 3)把最大敌人种类直接暴露在编辑器里，美术和策划只能在受限的Range滑杆里选数，而不是打开脚本随手填个99。其他引擎也可以借助自定义Inspector或配表实现同样的约束。这个做法不会让项目一下子变好，但能帮你尽早看到自己是不是在同一个机制上叠加了太多个变量。另外硬件方向也值得抄这套思路：Playdate那枚1-bit黑白屏幕和只有一个旋钮，逼着开发者想游戏核心而不是拼命塞美术。我记得有开发者说，给Playdate做游戏就像在明信片上写短篇小说，这比无限制的4K画布更能催生有趣的决定。
更进一步，约束能把开发过程变成一个可证伪的实验。我现在的习惯是每次动手前写一条一百字以内的“设计假设”，比如：当玩家看到门上的红灯亮起时，他会在三秒内选择直接撞进去而不是绕路找钥匙。然后所有系统只服务验证这句话，其他需求往后放。等两轮试玩后如果依然拿不到明确的行为结论，我就砍掉这个功能。很多团队学敏捷看板反而越学越累，因为他们把工具用来加速生产念头，而不是清空无效工作量。用这种方式做完一个原型，我最深的感受是：完成不是妥协的产物，而是你对假设做了多少次有效取舍的结果。如果你连一个可推翻的设计假设都写不出来，那项目失控几乎注定会发生。
