我所看到的，似乎大家都知道自己的游戏会随着发展而变化。但我们很少讨论如何管理这个变化以最小化成本。

我学到的经验是：不要为一个更大的变化付费，而这个问题实际上并不需要。我曾经多次犯过这样的错误，甚至还鼓励过它。

为了帮助解决这个问题，我将游戏中的变化和调整分成3大类别，根据它们对游戏、生产计划和时间表的影响。

基础性变化- 这里影响游戏的基本产品层面。所以，例如：

  • 从付费模式转为免费模式。
  • 从单人游戏转为多人游戏。
  • 从PC转为手机。

方向性变化- 这里是典型的转折点，倾向于围绕游戏的支柱进行变化。所以…

  • 从故事为主的游戏转为战斗为主的游戏。
  • 添加或移除大型系统。或者...
  • 对现有系统进行大规模的调整，如重新设计整个进度系统和循环。

迭代性变化- 这里是更为集中，但仍然非常重要的变化。没有什么奇怪的，例如…

  • 调整和平衡
  • 新的敌人行为
  • 在现有系统中添加新的表达形式（如添加壁爬或替换武器或能力）
  • QoL改进和可读性。

现在，允许我说一下，这些类别并不是完美的，而且边缘处确实存在重叠。目的不是要把变化“准确”地分类，而是用这些类别来帮助我理解变化的影响，并确保我们做出正确的变化。

那么，这意味着什么？

我试图做出最小化的变化来解决问题或处理反馈。虽然这听起来很明显，但在实际操作中，它确实更为困难。

尝试在更大的类别中进行变化是很诱人的，因为这样可以获得更大的杠杆作用。一个在“方向性”级别进行的变化会导致更大的调整。这可以解决你正在试图解决的问题，但它会增加大量额外的工作，创建新问题，引发范围扩散，并破坏时间表。

避免这种情况的方法是保持专注并接受约束。真正地深入了解是否可以在“迭代性”级别解决问题。这需要纪律。

在努力推进进展的愿望下，很容易试着尝试几件事情，看看它们不起作用，认为问题需要更大的变化。

但有时这是真的。但我犯了一个错误：放弃太早，改变一个“更大的”东西，仅仅因为它看起来在当时更容易，但后来它会导致更多（更大的）问题。

一个简单的方法是真正地调查：是否有一个更小的“东西”我可以尝试或改变来解决问题。