回顾与反思（1）

《十诫》是预定大四结束前就写的东西，但是，由于一贯的懒散与迟钝，以及对情感的无法把握，以至于这个期望能用一种客观、辩证的语调写出来的东西，最终只完成了让自己摇头的一半。

一年结束了，契约也马上就要于12月上旬结束了，由于家里的事情，我将拜别游戏产业回家。此去经年，谁知又何时才能归来？即便是回来了，又当如何？当然这都是未来的问题了，而未来的问题是无从去定义和追索的。

现在目光的焦点回到问题与回答问题的交锋中：
而第一个问题就是游戏程序员是什么？任务是什么？工作是什么？

2003年12月初找到这份工作，初时的工作是让自己感到异常的惶恐，因为我在此之前我自己觉得能拿出手的作品只是一个2D小游戏，以及在其他几个小组内部的3D游戏中起到些很有限的作用而已。毕业论文中所写的东西，大部分只是在思考中，或者尚未经过实践的，到我现在真的去实践他们，才发现有这么多细节需要去注意。可以说我是以零的起步来到了一个3D游戏项目组，从那时起，“你喜欢编游戏吗？”这个问题已经退居二位，关键是“我要做什么？怎么做？”

当初因为对OGRE的诚惶诚恐形成的一个基本的认识是不写引擎，因为引擎对我来说相距太远，我根本不可能去驾驭一个类如OGRE、类如Irrlicht或者Neo这样架构完整而且全面的引擎。我负责的也恰好是游戏层的东西，第一个就是做一个弹道计算器，我对它的认知只限于这个东西会在游戏的技能系统中大量采用，可以决定一些在资源那里无法决定的计算方式：例如跟踪弹道等等。

后来也就顺水推舟作了技能系统，第一次设计的技能系统异乎寻常地糟糕，还记得当时设计时的心情：没有参考，没有这个没有那个，好像唯一所做的就是为每一个技能硬编码硬编码，除了在代码里编制所需的数据之外，还要在代码里硬性指定弹道数据。如果说第一次设计有什么还值得自己稍稍满意一些，那就好像只有把“技能”和“状态”分离这个比较值得自己“臭屁”了，因为这个设计在后来分析魔兽技能编辑器的时候，发现与魔兽的思路基本相同。
糟糕设计所产生的代价是必然的，美工给我一个数据，一个模型，一个特效，我要很长时间，编写弹道模型，编写渲染方式，然后才能写进去，而且很多地方充满了反复编码。曾经看过OGRE，被其过度设计所折服的我，最后趁着重构的时候不加思索删掉所有技能系统代码，删掉了那些——用老大一句话说——“这么狗屎的设计”。

在古代的传说中，有一种“游侠”，天马行空，行侠仗义。我在学校时天马行空惯了，当我发现在课堂上偷着在算草纸上写代码画类图的生活很累后，就在校外租了房子不再上课。第一次设计过后我知道自己根本不算是这种“游侠”，多也不过就是一个“走徒”，云游四方，却不知道为了什么目的，只是觉得这样走或许会好些，或许会有力——实际上除了浪费体力一点用还没有。
很早前，看到过金点对他们《圣剑英雄传》的描述，很是佩服。早期的游戏程序员大多是孤胆游侠出身，很多大侠，大牛。参与了一个真实的项目才发觉这种天马行空的思考方式从根本上说没有大的意义，你天马行空别人还想天马行空呢，这么多人交流、讨论、争吵、攻伐，一个小小的程序员在一个3DMMORPG的游戏系统之中能算得了什么？只是中国的国情实在特殊，使得程序员奇货可居罢了。

游戏如此巨大，模块如此之多，人员如此参杂。程序员到底算做什么？是天使？是魔鬼？是正义？还是邪恶？
作为一个程序，就是为了完成需求，这个需求不仅仅来自于自己，也更大的可能会来自别人。
这些需求包括最基本的需求：引擎，包括各式各样的功能，模块的调用风格和定义。这是程序与程序的交流的问题，还有的就是策划和美工的要求：更多集中在编辑器上。
游戏复杂吗？不觉得，其实游戏用到的大家都知道是怎么回事，但是关键在于多个人对游戏都是各不相同的理解，因此游戏开始变得复杂。

我总是希翼C++能为我完成自己需要的功能，但是后来我发现这些东西本来就应该让那些策划和美工去做。程序总是站在自己的角度上考虑问题，美工也总是站在自己的角度上考虑问题，策划就更爱在自己的角度上考虑问题了。如果三角形的三个极点互不相让，丑陋不堪的在人类契约的保护之下妄图维持三角形那优美的形体之时，失败的命运就已经悄悄确定了。游戏是工程，不是一个人的玩具，也不是几个人的玩具，它是所有参与游戏项目的人共同要面对的课题。

期望着游戏为自己带来财产和地位的人，还不如去买彩票或者傍大款，如果没有性病、艾滋和社会问题这一类说法，或许做鸡更能快速带来财富和快感。游戏是一个普通到不能再普通的工程，从原理上说他和一个网站的工程和一个操作系统的工程没有任何不同，其关键都在于协作、争辩、求同、存异的整体工作。策划说我有一个好的想法，你们程序要实现，很多新手策划不懂程序，他们不知道对于他们，仅仅加入一两个“可变性”，需要程序去实现更多、更复杂、更为沉重的“不变性”。没有换装和加上换装，数值上只是多几个小得不能再小的变量来记取装备编号，但是程序的工作量将要扩大多少？与此类同，如果两个系统间不能好好合作，那么结果肯定是两个系统都不想面对的结果。

我总是说美工做得不好，以此来掩盖自己技能系统设计的重大问题，但是我真正考虑了美工的需要吗？完全没有，我忽视了一个重点：游戏不是我心目中的游戏，而是所有人共同协作的结晶。如果现在那位已经离开公司的美工恰巧在看我的文章，那么我只希望向他说一声“对不起，我险些忘了，我们是同事”。

我总是抱怨别人提供的系统似乎总有这样那样的问题，而没有继续去探询问题来自何方。物件系统逻辑中在STL的使用上出了一些问题，导致对物件系统的管理要求很高的技能特效总是挂在及其怪异的地方，但这时我只是希翼别人去解决这个问题。现在的我总是在回想这些事情，充满愧疚。主程，他的事情本来就很忙，划分系统哪个主程都应该是顾大局的，而顾大局的同时还能顾小体本身就是不容易的事情。就像一个将军他不会去亲自用枪杀人，但是他比一个士兵所面对的压力更大，一个士兵在战后只要活下来，他大凡可以逃避“反人类罪”、“杀人罪”，但是一个将军将要面对那些道貌岸然的战争法庭的审判。我在大学时对物件系统的思考延续了一年有余，而且毕竟自己在OGRE基础上自己封装过物件管理，项目中这些小局问题本身就应该是我继续思考、找出问题、商量问题、解决问题。但我逃避了，把这种零碎的小事情一个个交给别的成员。别人顶着天，1米85的我却躺在那里睡觉。
没有人骂我，所以我心存侥幸，所以，到现在，我只能送给自己这个“道貌岸然”和“卑鄙”的头衔，以此希望能给自己一点心灵的安慰。如果，我的第一位项目经理哪一天也看到了我这篇文章，我期望您能接受我的道歉，真的，对不起。


作为一个普通程序员，在提出自己意见的同时我不能自作主张去更改别人也已定下的规矩。我或许会为了省下100行代码而爽得不行，但是别人会为我这种背叛的行为付出10000行代码的代价去修补他们的代码。主程的话你不是必须要听，有不同的方案和见解可以跟主程讨论，但是，一旦定下来，即便有1000万个不愿意，你也要完成。主程面前是整个系统，你的面前最多是自己的模块。所以如果你真的还对这个项目有一点感情，拜托就让自己多写100行代码吧。当然你自己认为的“好”方案，你难道不能自己抽时间去实现他吗？我曾经考虑过一个技能模型（未经过试验），就是通过大量运用配置文件，可以让策划自己实时去调整技能的所有细节。但是最终被否决了，因为网络游戏是撑不了这么大的开销的。网络游戏虽然系统很大，但是模块却又要尽力短小精悍，OGRE的过度设计方针并不是在任何地方都能用的，因为你不可否认OGRE在几个开源引擎中效率并不是最好的。有些游戏是重质量不重效率，而有些游戏则不得不为了游戏效率去舍弃很多东西。
如果我是主程序呢？我没做过，不知道。我私下认为一个主程序不应该对重构抱有太多的希望。重构是当大厦千疮百孔的时候炸掉重来的方式，但如果大厦建到了沙漠里，那炸掉重来千万遍，结果都是一样的。好的初期设计可以减少被拉登投机的机会，XP适用于小规模、变化律高的程序设计，并不适于大规模、小变化律的程序设计。这个是源自于某天跟一位同学的聊天，跟我参加的工程无关，我所参加的工程除了技能系统重构一次、模型重构一次、网络重构一次、地图重构一次外没有别的重构了，但是这四次重构几乎重新开发了整个系统，那初期的设计究竟是否是所有人把方案经过好好讨论、磨合而产生的呢？我自己的技能系统没有，这是我的错。一个人曾经开发过什么成功的东西，并不意味着同样的方式能在另一个系统上成功。我们所说的成功都是相对的，成功是大量矛盾在一种特殊条件下的表现，而且这种表现可被人类所认同，成功和失败只是在人类这里才有的概念。这个概念现在就成为了：一个人曾经开发过包含了一堆矛盾的东西，并不意味着他用同样的方式开发这个系统时这一堆矛盾还会以原来那种形态重现。同是兵书，十个人读却有十一种打仗的风格，看似相同的两场战役，却总会有些细微的差别，因此产生完全不同的结果。这是有参照的情况，何况我还没有参照呢。以后还有机会的话，更应该多注意询问需求，好好分析，寻找参照，解决问题。一个积极的人总比一个消极的人占有更多主动权。

（未完）