为什么关注过程，而不是具体的游戏内容？游戏内容是满足当时当地的玩家需求的，你看梦幻的捉鬼很好玩，但没有梦幻的用户群和整个游戏架构的支持，孤立的照搬1个玩法只是邯郸学步。所以这里总结的是设计过程，学习授人以渔，看怎么去捉住活鱼，而不是游戏产品里已经烹饪好端上桌的成熟内容。

游戏设计的是1种体验，所有的规则、数值和美术等因素都是为了产生特定的玩家感受。1个系统或玩法的设计，包括了构思、表述、执行和评估这4个过程，其中构思和评估是最核心的。

构思

首先，整个构思和设计的出发点，是为什么我们的产品需要这个内容？要考虑的是自己游戏的整个背景，而不是孤立的这个系统本身。要看整个游戏哪里玩起来不爽了？需要增加什么体验来解决问题？还有1种情况是从下到上的，我们看到其他游戏有个不错的玩法，想是否借鉴过来。但从下到上思考时，“上”仍然是思考的出发点和标准，要看这个玩法是否符合游戏的整体架构？是否有这方面需求？我们当时照搬了梦幻的组队合约人，这个在梦幻里是组队练级必备的，但是在我们游戏里门可罗雀、玩家根本不理。为什么呢？因为我们游戏里组队成本比梦幻小太多了，场景小、跑路近，又到处是组队集结人，队伍散了很容易再找到人。而梦幻很不一样，像海底龙宫那样的地方，一旦队伍有人跳水了，基本没可能再找到其他人，这个组队成本催生了组队合约。所以从下到上借鉴其他游戏玩法，要想清楚它在原来的游戏里满足的是什么需求？提供了什么体验？我们自己游戏的大环境有没有这方面的需求。机械移植的话往往牛头不对马嘴，或者是完全是另一种味道。征途的送花系统是花钱买经验的，送花人送花得经验，送花给女性只是顺便借花献佛。我们游戏里的送花系统，送花人没有什么好处，纯粹是女性玩家炫耀能得多少花用的。这两个表面看起来很类似的玩法，因为一点不同，本身的定位和带来的体验是完全不一样的。总之，我们要不要增加这个玩法，出发点是看游戏的整个背景是不是需要这种体验，而不是说看到其他游戏有个玩法不错，我们也加上吧。

其次，如果已经想清楚确实需要增加这个玩法，接下来就是具体怎么设计的问题，要清楚自己玩法的核心体验和定位是什么。这个玩法是做给哪些玩家的？他们是在什么情况下玩的？频率、时间点、等级、技能、装备、组队与否等等。乐趣是相对的，对这个玩法有需求的玩家会觉得很好玩，如果没有需求则什么感觉都不会有。像梦幻的师门任务你可能觉得太简单了，没什么挑战，只是枯燥跑路、找物品、打怪。但对那些找不到队伍的玩家，或者短暂上下线的玩家，能迅速拿些经验就是最大的乐趣。说到底，你要清楚自己表达的核心体验是什么，而不是笼统的说做的好玩。所有设计都围绕这个核心，你才能清楚必须坚持什么、加强什么、可以放弃什么。

最后，在构思过程中，我们肯定要去参考甚至“抄”其他游戏，应该怎么去参考？参考到什么程度？我们要抄的是体验，而不是规则。你自己必须尽量亲自体验过，思考他们的游戏元素又是如何产生这种体验的，在我们游戏里用什么可以再现其他游戏的体验。像刚才说的组队合约人系统，梦幻组队成本大、跑路太远，何况浪费时间就是浪费点卡，这个系统解决了这些问题，所以玩家才感觉很爽。我们把组队合约的规则搬过来，我们的玩家根本没这些烦恼，也就不会有移走烦恼的快乐，这个系统就废在了那里。所以说，要想模仿的恰到好处，达到自己的设计目的，也是个很考验水平的过程。

表述和执行

把自己的构思表达给别人，推动制作人员实现自己的设计，这两个环节是策划日常的基本工作。你需要找策划、程序、QC和美术沟通，让大家了解并支持你的构思。

设计内容的表述要先经过策划这边，已经讨论好了思路和大致规则，再去程序那边问下技术上的可行性。表述过程中，策划、技术和美术的关注点不同。你也要针对不同的人突出不同的重点。策划关心的是这个玩法体验怎么样，你可以用其他游戏截图、草图，挑起大家的想象，这个东西真正玩起来会怎么样。程序那里关键是技术上的可行性，你有时候没有必要讲整个的设计，只把最核心的几个技术实现讲给他们听下，其他的规则都是不成问题的。QC会追着你的文档不放，询问各种可能导致冲突的地方，还有最细枝末节的提示。美术需要的是1种感觉，你把这个东西的功能和作用讲完了，最好还能拉他们一起看下参考的游戏、搜集的图片、甚至听段相关音乐。

表述中不能忽略的是设计文档，它是口头沟通后的备忘和结果，而不能代替当前沟通。以前有很多讨论，说设计文档应该怎么怎么写，有没有标准的格式，好像设计文档写的好就是表述的好。其实设计文档是写给谁看的呢？主要就是程序，还有QC。设计文档不是要求写的多详细、多优美、多准确，而是程序看了说我知道怎么做了，QC看了说我知道怎么测了，这才是好的文档和好的表述。当然文档还有个功能，就是记录你的设计目的和思路，就是构思的过程，这个是方便以后的策划能学习和接手。在表述游戏构思的时候，图片的力量远胜文字，无论是画的草图还是借鉴的其他现成图片。文字是和表达精确的思想和规则，但涉及想象、感觉、体验的时候，图片显然更有力量。所以无论是口头沟通还是写作文档，如果可能的话，你都可以随手画上几笔，或者找些图片参考。这点在对策划和美术的沟通中，尤其重要，因为比起技术来，他们更关注感觉而不是规则。

说到执行阶段，想必大家都经历过也比较熟悉了，主要是面对开发中的各种反馈和疑问。程序在忙开发，QC在分析文档和测试，美术也开始准备你要的资源，大家一起在问你这个怎么样那个怎么样。这个过程中，最常见的是跟进各种细节，有很多当时没想到的东西，比如状态的互斥、物品的绑定等等。还有就是制作人员的一些反馈，从技术上他们可能觉得换种方式更节省，问你能不能接受。细节方面随手处理就行，但是技术的反馈和疑问，如果构思阶段没想清楚、只是照抄别人的话，就会压不住阵脚、往往被他们问住。对玩法的构思比较清楚，明白要营造的核心体验是什么，才知道要坚持什么、谈判什么、放弃什么，也才能努力去说服别人下功夫去实现。在技术做完后，你要自己去跑一遍，看整个流程是不是自己想要的，只有在这时候，你才真正看到了自己设计的玩法，以前还只是存在于构思和讨论中。确认功能上没问题后，再去喊大家一起来玩下，听听他们的意见，也让大家看下自己的工作成果。

评估

评估是检验自己制作出来的玩法怎么样，这也是最核心的1个环节，推动着后续的构思和修改。我们现在看到的评估手段实在是太多了，玩家的言论、用户测试、数据分析、自己试玩、同事的意见等等。如果问用什么手段来评估游戏？我现在的回答就是，没有任何1种手段能单独得出结论，只能把它们综合起来使用。医学上有种“鸡尾酒疗法”是用来对付艾滋病的，这个术语用在这里正好合适，评估时你要把所有能用的渠道都用上。并且要清楚的是，即使十八般武器都上场，你永远也只是得到1个相对正确的结论，现有的评估是无法给出精确结论的。这点与“鸡尾酒疗法”也很像，它综合各种疗法，也是只能使病情有所好转，不能根治。

所有评估手段中，最重要的是亲身去玩。我这里不用试玩这个词，而是说你要真的在外服，和真正的玩家，拿着真正的技能和装备去玩，去体验自己的玩法。玩的时候，不要带着超然去观察的态度，你一定要在乎，那怕是最少的奖励、最微小的损失，这样才有沮丧和喜悦。游戏设计的是一种体验，能检验它的也只有自己的体验，玩家的言论和数据都只是参考，采不采用完全取决于你自己的体验。我们发布前也拉程序和QC一起玩过，那次玩还只是部分体验，更多检查的是可用性，只有到了外服和玩家一起才是真正的玩。你自己到时觉得不好玩了，就赶紧去找问题，一查数据还真是玩的人不多。是不是难度大了？奖励少了？这是再去查数据也好，问玩家也好，去推敲和检查自己的推测，寻找下一步的改进方案。所以说，亲身去玩，亲身体验，是其他评估手段的基础，也是继续构思和改进的起点，这点什么手段也代替不了。

玩家会有非常多的反馈，在聊天群里、在论坛上、在游戏里、在访谈中，对玩家言论一定要慎重。不要以为玩家玩过就有了发言权，他们只是表达出能看的见摸的着的表面东西，对真正不爽的原因他们不了解、也说不出来。我以前做过流失玩家的电话访谈，玩家回答真是五花八门，有的说水做的不好看不想玩了，有的说没人杀了不想玩了。玩家的话是不能作为决策的依据的，只能作为疑问的出发点。你要说玩家这么说了，所以我们要怎么怎么改，那样要跑断腿的，改了玩家也不领情。你要进一步去思考，他为什么这么说，能反映出什么东西没有。有次访谈，我听个玩家说，我们工作后来玩很累了，战斗不要那么紧张。听到这句话，并不是说把所有的战斗都改容易吧？我想的是他们背后的需要是什么呢，我们的玩家需要有段轻松的时间，他们看下网页、回下qq、甚至看下正烤的蛋糕。所以后来就把烧双战斗放开了，允许你挂机，放心去做下其他事情吧。

还有种重要的反馈是游戏数据，数据可以证实或推倒你的结论，但不能告诉你怎么解决问题，还得靠你的经验和构思来提供方案，然后再去验证。对于数据要带着猜测和疑问去看，那怕只是简单的看看玩的人多不多，否则数据提供不了任何信息。

还有现在玩家测试也是种评估，我们的新手任务就通过这个发现了很多问题。这种测试关注的是可用性，那些你想当然的操作，玩家往往不知就里，看到了你才想到去改。对好不好玩参考价值就少了很多，例如帮派跑商的话，玩家会告诉你跑得无聊死了。它确实无聊，只有对那些急需家族贡献点技能的玩家，才是好玩的。

最后，要注意构思、表述、执行和评估这4个过程不是固定的次序，而是彼此重叠、你中有我、我中有你的。在构思阶段，你可能就把初步的想法讲给大家听，评估可能的反馈。在评估的时候，你也可能一直在重新构思，并表述给别人听。但从整个的设计流程看，是可以区分出这4个不同的思维阶段的。