本文作者：sodme
本文出处：http://blog.csdn.net/sodme
声明：本文可以不经作者同意任意转载、复制、引用。但任何对本文的引用，均须注明本文的作者、出处以及本行声明信息。
1.勇于承认失败
国内的游戏厂商，让人觉得能有大家风范的少之又少，炒作、随意夸大游戏品质，好象不吹牛就没人知道他游戏作得烂似的。由于网游市场渐显的各种风险增加，资本市场从2004年底开始，对网游的投入渐趋理性化。在这样一个群雄逐鹿的时代，唯有靠品质才能最终取胜，小的游戏厂商会逐渐被市场淘汰或边缘化。未来可以在市场上存活的，将是为数不多的大游戏厂家。值得说明的，这里的“大厂家”并不是一定就是指现在的某些看起来很大的厂家。
在游戏业界广泛充斥着浮躁的大氛围下，智冠和网易给我留下了难得的好印象。王俊伯在RO的代理权易手给盛大后，公开承认智冠的RO运营是失败的。而网易的云风，在05年6期的程序员杂志的网游专题文章中，不仅承认大话I是失败的，更是总结了若干失败的教训和经验，这些东西可以帮助多少人少走弯路呀！网易的作风，给外界的感觉，向来是踏实、务实的。在东西没出来之前，他们从来不会怎么高调作什么所谓的花边宣传，这与国内很多游戏厂商的作法大相痉庭。大话系列的游戏品质相信玩过的自有评说。
承认失败，是需要勇气的，同样也是需要相当自信的。因为他们相信自己将来可以作得更好，所以才会勇敢地承认自己过去作得不好。不管是智冠，还是网易，我想，没有人可以否认他们在国内玩家心中的份量。
2.结对编程
结对编程，一个曾经非常时髦的话题，这个概念刚提出来时，我还在一个名不见经传的“教授型”网络教育软件公司。当时，我们的项目负责人也一再提出结对编程的想法，但是，项目组的成员对执行它却丝毫没有兴趣。是的！结对编程的前提是：参与结对编程的两个人，在技术水平上我认为一定要是水平相差不大的人，但也不能水平相同。你跟一个连“面向对象”都还没有弄清楚是什么的人说什么结对编程，那绝对是在扯蛋！技术水平相差太大，是很容易造成歧义的，水平太低的人往往无法正常理解水平高的人的设计思想，除非在结对编程时指定谁是说话算话的老大，就是说当出现意见相左时到底由谁说了算！有人说，应该民主讨论决定谁说了算。我要说的是，这种民主，在一定的范围内是有效的，但越过了范围，当你该拿决断时就一定要拍板决定，不能给项目成员以犹豫不决的印象，否则别人的工作作起来也是心虚的，因为他们不知道自己现在作的东西，到了明天或者后天是否就会被推翻而不得不重写。对于水平相差不大的人，我觉得结对编程是有益的，我之所以这样说，绝不是因为自己多看了几本书就在这里瞎忽悠，因为我曾经跟我过去的同事这样作过，不管是思维的广度还是深度，都要比一个人写的代码更漂亮，也更安全。坐在旁边看的那个人，往往可以指出你现在正在写的这段代码的问题所在。除此之外，结对编程还是对工作效率的有效约束，两个人一起工作时，精力必定是相对集中的，不会出现三心二意或跑神的情况。
3.阶段性的测试和验收
在多人参与的项目中，阶段性的测试和验收工作是必须要有的。当然，我们的设计总是随着开发的进程而不断调整的，那种一次设计之后再不改动的完美方案在现实中是几乎不存在的。项目组的成员，在阶段性的工作完成之后，应该由项目负责人召开专门的阶段性成果验收会议或演示，由设计者提供相关的设计文档、演示代码等。而参与验收的人，特别是以后可能要用到这一部分功能的人员，要详细询问、了解它的接口使用方式，设想你在使用这个接口时的可能情况以及可能出现的问题。把后期可能出现的因修改延期风险尽可能提到前面来。
4.策划内容与程序实现的配合
游戏的程序人员和策划人员，在很多公司里是“互相鄙视”的。程序鄙视策划整天异想天开，不顾技术实现难度，随意增加、修改变态方案；而策划人员则鄙视程序人员甚至连游戏都不会打，还在那写游戏程序，他们鄙视程序甚至连NPC的确切含义都不知道。而我要说的是，首先，对于程序人员，不管你是作服务器的，作客户端的，还是作数据库的，既然你选择了作游戏，你就得去努力多打一些好游戏。别跟我说实际上你不喜欢游戏，作游戏只是为了混口饭吃，OK！混饭吃可以有很多方式，请不要拿玩家的心情开玩笑。一个游戏公司想成名很难，可是，如果想毁掉则非常容易，他们只要出一两款烂游戏就足矣！而对于策划人员，我要说的是，你们的能想出那些变态方案并不是你们的错，并且我还鼓励你们尽可能地变态，但是，在作案子的同时，我也建议你们尽可能地提高自己的知识量，扩大自己的知识视野，努力多学习一点有关游戏程序方面的知识，我不是让你们学着写程序，但你们可以多与程序沟通，多了解程序的原理。一个方案提出来时，你要考虑到客户端的表现难度以及服务器方面的数据包广播量，当然，限于自己的知识层次，你们可能无法确切知道这些方面的答案，那么，剩下的就是唯一的一条路：多沟通！
5.项目管理者的角色定位
通常的项目管理者，会有两种类型：监工型和实干型。前者是只说话，不作具体的编码、设计；而后者，不光是“说话”，还要作具体的编码、设计。从我目前接触到的项目组来看，两者都有，但我更欣赏后者。而作为投资商，我则建议他们选择前者，前提是：投资商有足够的资金可以烧！欣赏后者的原因，是因为程序员广泛比较崇拜技术牛人，他们总希望自己的老大是一个在技术上非常牛的人，这样他们就会觉得自己有一个靠山，有问题时心里也会比较有底，因为他们知道老大可以给他们一些好的建议。而选择前者，是因为监工型的项目管理者，往往可以在投资商和开发团队之间站在一个相对客观的角度来对项目进行进度跟踪和控制，他们明确知道投资商的项目预期，也可以明确知道自己想要的是一个怎么样的开发团队，团队成员出现问题他可以果断地进行替换。
6.抽象的层次
表现层和逻辑层的分开，是一个再通俗不过的道理。这一点，在游戏客户端上表现是最为明显的。界面层的代码，不要与逻辑层的代码直接混为一谈。说过最简单的道理：两个EDIT控件，一个加法逻辑。在实现加法逻辑时，有两种方法。一种是把EDIT的值直接转换后拿来直接作加法，另一种是首先作一个加法函数，然后将EDIT的值转成数值再调用这个加法函数。这是再简单不过的界面与逻辑层的分离方式了，可惜的是，很多的懒人却没有这样作，又或者，他们尚且还没有意识到自己为什么要象第二种方法那样去作？
7.测试自动化的实现
我从04年4月左右开始作一个休闲游戏，今年又开始作MMORPG。在休闲游戏里，我实现了游戏机器人，就是自己写了个游戏外挂，可以让机器人自己去打游戏。游戏机器人，对于游戏的自动化测试是非常重要的，甚至，我认为是必须的。大量用户的压力测试以及大量游戏逻辑的BUG测试，都需要有一个象游戏机器人的程序自动为我们完成。在云风的文章里，云风为我们提供了一种思路：录制网络数据包行为。这是一个很好的想法，我很赞成。但我想说的是，要作游戏机器人，首先对你的程序设计要有一定的要求，即：你的游戏逻辑设计，不管是服务器端还是客户端都要尽可能地把功能模块化，接口化。这种模块化的粒度越小越好！当然，游戏机器人的实现，更多的，还是依赖于客户端的设计。只要客户端能把每个游戏功能都尽可能地以小粒度加以实现，那种游戏机器人实现起来其实相当容易。一切，只有一个要求：把游戏功能尽可能小的粒度化。
8.最重要的一点，把游戏首先当作一下正常的“软件”来对待
我们经常抱怨国内的游戏是多么多么地烂，其实，你只要对他们的开发团队和开发方式稍微了解一下应该就完全不会大惊小怪的了。有相当多的公司，屹今为止，尚没有把游戏当作一个正常的“软件开发”来对待，在项目的管理上，在人员的组织和任用上，都带有相当程度的随意性。所谓的项目延期，品质低劣，BUG频出，归根结底是人的问题！先不要把目标放那么远，要想作出一个好的游戏，请先把游戏当作一个再正常不过的软件项目来开发，来规范，来控制！
