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

版权声明:本文为博主原创文章,未经博主允许不得转载。 https://blog.csdn.net/ccanan/article/details/88774873

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

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

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

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

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

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

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

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

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

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

没有更多推荐了,返回首页