End the line…and the Endless development

到现在为止，如果没有奇迹发生，那么我过去一段时间内所从事的项目，可以说是走到了它的终点。


虽然感到委屈，但是这也是无奈的事实，中国的这个环境里，你可能能遇到各种各样以人类的思维所无法预知到的、却是客观存在的事实。一千多年帝国的统治，使得儒家变成儒教，仁、义、礼、智、信从这个民族的基因里彻底毁灭、荡然无存，在这样的环境下出现这样的结果，也只能是一笑了之了吧？说中国人没有信仰，那中国人是从近代开始才没有信仰的吗？家都能变成教，教却再也没能变回家，一千多年没有信仰的生活，出现任何情况都不值得奇怪。


End the line……


but not the end of hope, and life……


 


无论如何，回头看看也总会感谢这段经历。在这之前，我的经历多能证明自己是一个北京圈里、传统意义上的引擎程序员，然而强制地将项目与引擎割裂的这种的传统做法，我自己却并不能表示完全认同。


形成这个想法主要是因为再之前所参与的那些项目。因为06年曾经在上海待过一段时间的经历，所以更多也能够比较一下双方对待游戏项目、对待游戏引擎上的思维差距。传统意义上、被人为割裂的引擎，貌似只存在于中国这片大陆，而我们发现真正我们引擎的出发点——我们所参考的那些欧美引擎的设计思想，却并没有这种人为的割裂。无论是Cry、虚幻、Source还是Doom，其引擎和上层结构全都是互相补充，相互关联，构成一个有机整体的。OGRE？伦家本身只是一个图形引擎好伐？用过OGRE做过项目的老师们不妨想想，我们到底修改了多少东西，才使得这个本来不是游戏引擎的所谓游戏引擎能够去真正制作一款游戏？


这足以引起反思，这种割裂，究竟是否有所必要？


究竟什么级别的软件工程，才可以被叫做是引擎？


广义地说，能够加速游戏开发过程的整套流程、工具、插件的集合，都可以称之为引擎，却为何在耳熟能详的范围里，引擎却总是囿于图形、物理、资源、脚本，最多再加上一个在他们外面所包装的编辑工具集合？


那么，项目本身何在？


这样一个工具集合，是否能够承担项目开发的全部需求？以及全部需求的变化？


 


笔者参与过的项目，很多都遇到过一些同样的问题。


每次立项结束后，整个应用程序框架就会完全重写一次，游戏上层的控制系统、物件系统……越偏上层的东西，就越难共用，每次都要重新设计，重新实现。而且在不同的地方，对其的实现方法和风格也完全不同……然而这些概念真的不能共用吗？我总是感觉在不同的地方，我们似乎在重复着同样的工作，一遍又一遍。


在三个不同的项目里，同一个功能模块，我看到了六种完全不同的实现，只是在最后一个项目里我就看到了三次较大规模的结构调整。为什么这些功能不可能一步到位？呃，因为策划的需求变了。这就好比一个传统软件的程序设计师说“因为用户需求变了，我们设计师的结构也变了”，这像是一个学过软工的程序设计师该说的话吗？


而且，为了通用性而设计的传统引擎本身，每到一个新的项目，难道真的就能够“通用”吗？很难，每个项目的需求都会有少许的不同，这都会牵扯到引擎本身的一些改动。有些游戏适用于大规模的地形Occlusion优化，有些游戏则更需要狭窄空间内复杂的光照计算，有些游戏却对纹理本身的调度提出了更高的需求，通用的场景图、通用的管线、就意味着无法做到有效的配合，很难针对具体的环境进行变化……。VT、LPV、DS……说到底，这些都只是工具，是否适合于项目，只有项目才能决定。你一个双人格斗的项目做什么VT和Occlusion呢？重点明显应该放在物理、动画、表情和IK上好伐？同理，一个手机游戏你做什么DS呢？一个卡通风的游戏你做什么LPV呢？就是这个道理。从引擎出发，也就限制了项目本身的活力。喜欢做卡通风的日本人，即便选择了虚幻三做的也是《失落的神迹》，而不是《勇者斗恶龙》。为什么别人都是先选项目后选引擎，我们却偏偏要先定引擎后做项目呢？虚幻三做卡通风，如果用材质变换的方案，则费性能。如果用Post Pixel方案，材质系统的大部分好用的功能都用不上，何苦不专门搞一个性能高又面向需求的呢？


不仅如此，传统的工具制作方法，几乎是跟引擎本身严格相关的，这也导致了因为不同的项目需求，工具几乎必须全面推翻重来。


当然，我曾经也认为这本来就该是这样，是必然的道路，直到我膝盖中了一箭。


因为跟虚幻打了6年的交道、跟WPF打了3、4年交道，所以发现，这样的问题，明显是可以避免的。


 


于是就有了这个项目的各种尝试：


1、传统的引擎是功能的提供者，它的地位不能，也绝不应该高于项目本身、也就是整体解决方案的需求。


按照系统论的观点，系统的构成第一个主要原则就是系统的每个部分必须在整个系统的大方向下服从整体的需要。如果整个项目必须依照传统引擎来构建，这就相当于引擎系统变成了游戏系统的核心，底层功能本身替代了内容成为了游戏系统的核心，最后做出来的系统，必定处处体现这个原则，并不是说这样就做不出好的项目，因为中国人民总是能够创造奇迹的，但是我们去创造这样的奇迹的必要性何在？以一个完全错误的出发点，作出一系列错误的事情，即便结果正确了，除了说明这些人都是牛人之外又能说明什么？


传统引擎的目的是为了辅助完成项目的所有功能需求，解决方案才是最终整体性的东西，接下来的问题只是在于：如果这个解决方案只能适用于一个游戏或者一类游戏，那么它就可以自我强化为重点完成此类游戏。如果这个解决方案足以应付大多数游戏需求，那么它就可以面对各种不同类型的游戏需求。


2、上层游戏逻辑完全是物件系统本身的逻辑，其在程序结构完全可以，也应该被简化为完全使用同一类结构。就是，最好没有Actor和Trigger的区别，没有Player和Monster的区别，没有Building和Unit的区别。软工一个最主要的原则就应该是归纳法——从看似不同的对象中间，抽取出同样的功能构成，来完成一套基本的层次结构。只有有了归纳出来的原则，才能更灵活地在此层次下去做出演绎。我们所处这个次元、所有的自由都是由那些不能自由的“原理”来提供基础的。离开了这些基础，自由本身毫无意义。海平面上100度的水你能煮饭，喜马拉雅山上88度的沸水你还能煮饭吗？煮出来的就是夹生饭。就是这个道理。


3、有了归纳出来的层次，则尽可能让之后的活动由策划来主导，而非程序来主导。理由很简单：程序有程序BUG，而策划只有逻辑BUG。传统工作流下，策划提供需求，程序实现需求，再小的模块，稳定下来也得一个多月。如果把逻辑工作交给策划去做，程序只是实现模块化好的、接口化好的功能，那么，程序的BUG可以用疯狂组织的单元测试对其进行验证。而从策划的角度来说，可以在不等待程序参与的情况下开始验证自己的思路和思想，也可以铺更多的人手来进行具体的验证工作。这就好比说我们程序定下了海平面附近，100度时水能沸腾的大原则，而具体是用100度去煮大米饭还是大麦茶，那是策划的事情了。让程序从逻辑工作中解脱，并且去追寻程序真正该追寻的东西，因为那才是程序本身应该去做的工作。


我看过很多程序写过伤害数值计算公式，就是被动地把策划的公式拿过来钞誊一遍，何苦呢？先不考虑人力成本，程序写的东西一定不会出BUG吗？平白无故多出来的这个单元，需要组织单元测试吗？难怪老外的程序可以每天朝九晚五，而中国的程序都得天天加班，这明显不该咱程序做的东西，咱干嘛揽过来做？提供个通用数值工具让丫策划自己搞去！


 


如果好好考虑一下，其实还有很多可以做的东西，比如工具化——在这个原则下，工具应该怎么组织之类的问题。很多问题我们都考虑过了，却没有机会实现了。


可以说这三点都做到了，都迈出去了，可惜，没能走到最后。


虽然无法验证说这条道路究竟是否是正确的，但是，只是基于自己的理解，却还是觉得这条路应该继续走下去。


寄希望于他人，不如寄希望于自己，相信自己所选择的道路，并坚持下去。


 


具体的项目中总会有无尽的问题，技术所能解决的问题在其中最多只占两成，那八成是因为各种人的问题所造成的。然而，人的问题，却因为人群的构成而变得不可捉摸，也让技术本身总是在风险和迷雾中前行，找不到属于自己的理想乡。


嘛，无所谓了。


这就是现实，Avalon毕竟只是Avalon，只能存在于传说和幻想中的东西。


Hope 也不过 is just hope。


那又如何呢？


有了希望的存在，也不需要因为挫折而选择放弃。


“End the line” is not “end of the world”.


前面，仍然是一条Endless的道路……