游戏开发中的复杂度与银弹

一切思考从：两件事情开始，
一个是最近看到我们认为是业界一哥的寒霜引擎在EA内部受到比想象中多得多的抱怨，
一个是在《无限法则》中不停的在做出之前我们常常认为不应该做的大型升级。
到底有没有银弹？

谈论寒霜引擎的文章
这里：
从神坛跌入地狱，BioWare到底怎么了？
其中提到了一个点，就是公司强推frostbite引擎，结果怨声载道。
这个在我周围的程序员，制作人甚至各路大大里也引来不少的谈论争论。

诱人的银弹
看了大家的很多说法，发现大家找银弹的倾向还是很强，归根到底，人之常情就是希望能有一个要么“巧妙解决问题的方法”，要么“自己能承受能搞定的解决方法”，而不是一个巨烦无比，自己难以承受的解决方法。
有个银弹多好啊！！

项目中无简单银弹
在我看来，大型高品质甚至AAA游戏就是没有我们常规认为的那种银弹，没有那种大家都没有发现的，却客观存在的，怎么一弄，哎，两三个月就好了的，然后在市场上还特别牛逼的东西。

两点因素决定这个：
1，本然的项目复杂度
大型项目模块很多，无论怎么优化简化，依旧是一个巨物，面对一个复杂度为n的东西，不可能用低于n的方式描述它。
我们的方案如同能量守恒定律有一个不可逾越的坎的。

2，市场中的竞争
当一个问题解决了之后，市场的竞争立刻会转而提出新的问题。
我们与之争斗的不是问题，而是其他的开发团队，银弹即便存在，只会消灭一两个问题，然后大家在竞争中创造出更复杂更牛的问题，然后这个银弹便随之消逝。

项目中的黄金法则
不妨我们抛开银弹，放下想简单解决问题的懒惰，客观正视问题，不要试图简化不能简化的东西，追寻最优解就好。
依旧是：

• 团队：人才才是解决问题，构建牛逼虚拟世界的关键
• 遵循开发原则，不要试图去简化，对于代码保持一个复杂度控制，并且hold住它
  那么一切大型升级都可以做，也可以搞定，而且可以弄得很好。

反例
之前看到一些大公司，建立一个极其庞大的测试用例库，能跑过的程序才算，本来是一个想保证程序质量的东西，我个人也非常认可这样的做法，但这依旧不能替代程序开发的基本原则。
这种做法带来一种诱惑，程序员写一个程序能跑过这些测试用例就好，而不是静下心来，面对海量程序去将其理清楚；
最后程序就会开始腐烂。

认为有一个游戏引擎，然后大家不需要做什么东西，然后就牛逼了，像EA一些工作室抱怨frostbite没有攀爬系统。。。
那个引擎有啊？frostbite该有么？