导致游戏研发不顺利的几个典型“边界问题”

　在我们开发游戏的时候，往往最初我们都有很好很好的想法，但是当动手做的时候，我们对于最初的想法进行了一再的妥协，结果游戏初期我们那些美好的游戏感觉和体验的设计，到最后一个也没有，游戏本身至少自己是觉得惨不忍睹，也许丢出去总有傻瓜会说还不错，但是你自己心里明白。根据经验、教训的总结，不难发现，实际上导致游戏最后过多“妥协”以至于走样的罪魁祸首是一些游戏设计中的边界问题在作怪。

　　什么是边界问题？你可以理解为现实中一些残酷的例子——比如前几天有位不幸的妇女遇到了交通事故，处在上海2个区的边界，于是两个区都表示应该是对方的问题，结果这位妇女在两边推脱责任持续了34分钟后去世了。如果有一方敢于站出来说，我们的民警马上就到处理，请先拨打我区医院的急救电话，我觉得这位妇女生还的可能性还是很大的，毕竟只是失血过多而已。那么同样的问题也往往出现在游戏开发过程中，尤为明显的是策划与程序员之间的边界问题，有几大典型的边界问题，危害着我们游戏的“健康”。

1，策划认为是程序员的事情，但程序员也不清楚这事怎么去办。

　　很多时候策划认为一些事情是程序员做的，而程序员其实并不知道这些事情要怎么做。最典型的是我最近做的一个跑酷游戏，很多朋友认为算法是程序员的事情，我策划只要想法就行了。如果真这么做结果是什么？显而易见、地形是不支持任何角度的，除了平地就是30度、45度（60度上不去不需要了，谢谢）。这是一种很常见的，但却是常见现象中结果最良性的妥协，至少我们的游戏除了平地外有斜坡了。

　　深入思考为什么会发生这样的事情呢？首先程序员并不了解你究竟想做什么，你的表达给出的线索可能仅限于“冒险岛”“彩虹岛”之类的游戏名称，最多可以来个百战天虫什么的，好吧，那么程序员我就看看那些游戏去——哦，原来就是一个标准的2D2维数组地图游戏，只是Y方向加个重量，好吧，地图就是Tile式了。埋头干了半天完事儿了，策划说不对，我们游戏的斜坡怎么没有？斜坡？啊哟妈呀，这斜坡怎么办啊？我角色一走一个格子，你一个44.7度的斜坡，我X走一个格子Y怎么处理？那好吧，妥协了，30度（X走2格、Y走1格），45度（X走1格Y走1格）就行了，60度呢？60度太陡了，一般来说上不去。

　　好吧，最后这个游戏就成了你看到的冒险岛版跑酷，整个游戏只有这些固定的角度组合，为了让视觉效果贴合，你会发现地图棱角分明，感觉很糟。是不是没有办法做的更好了？有，很简单，就像我一样，自己coding，因为我很清楚我要什么，但是我很难一下子让别人知道我想要的，我先完成代码后我们讨论如何优化，讨论谁来动手就行了。现在我们游戏已经支持任何角度的地形了，并且地形还是可以带移动的、带拖拉效果的（人站在上面会自动走，你可以想象那种加工厂的生产设备上的履带），多个地形重叠时没问题。

　　很多时候一个良好的方案并不是不能实现，而妥协的核心原因是策划认为程序应该去做，而程序并不知道策划要做什么，最后做好了开始评论了，来不及了。有时候一些责任看似不是自己的，但是请你记住，大家坐一起搞一个游戏，做出好的游戏才是目的，并不是消磨时间坐在这里完成工作领了工资了事儿，这样简直就是在度死日。游戏开发中，大家都主动一些，游戏才能做的和大家最初的想法更接近些，互推责任只能带来团队人际关系紧张、项目不能如愿完成，一石二鸟，可惜全是自家的鸟，负面效果。

2，策划过于较真，程序员举双手投降。

　　很多时候策划并不了解实现的困难，因此在一些事情上过于较真，而出于环境问题，很多时候决策是偏向策划的，毕竟策划说的都很在理，唯一不在理的是让人忽略的一个因素——我们处于什么样的限制下。

　　最常见的例子是我们做一个游戏中用到的一些算法，就拿百战天虫克隆的游戏来说，策划可能会很用心的去设计，为每一种炮弹想好很多实际参数，设定了很符合现实的函数，这样工作非常棒。可是策划忽略了一个问题——是否有价值去实现这些？这个问题其实对于程序员来说是一个难言之隐，那就是优化问题。因为如果你选择一个百战天虫游戏，他首先不会用到物理引擎，你看起来很多东西很物理，但我可以告诉你他的风向就是负的代表向左的力、正的代表向右的力，你的X方向的速度加上这个力/帧产生了最后X轴移动的规则，毫无物理可言。关键在于，很多时候，你的算法很真实，没错，可它对于游戏来说有2个隐患：

　　第一：过于真实会给游戏带来更高的难度，比如愤怒小鸟的物理引擎给游戏带来了一定难度（正因如此游戏才有了一定的乐趣）但是，小鸟的重量等都是不真实的，以至于玩家很容易接受结果，一个过于真实的环境，反而会让大多玩家不能接受，尤其当你选择了卡通画风。（但我并不是在引导你抛弃一些真实性的设计，只是希望你能够审时度势，看清你的项目是否真有必要这么较真）。

　　第二：给程序带来很多麻烦，尤其是在算法的优化上，而事实上我们面对的很多平台性能并不如你想的那么优秀，尤其是手机游戏。过度复杂的算法会带来很糟糕的结果，而这样的结果谁都解决不了，最后导致项目根本做不出来，这都不是一个妥协问题了。

　　那么遇到这样的问题的时候，策划应该怎么办？和程序协商一种好的解决方式——伪科学方式，很多时候之所以说是伪科学，那是为了优化而违背一定特殊因素，避免了一些不常见的情况，但是避免的手法有很多，可以是在其他方面避免。比如我们有时候做一些游戏，你不得不面对的就是过于特殊的地形没法被使用（这个问题在我的跑酷游戏中现在还没有，但是随着优化的进行，可能会要求不允许出现宽度很小的墙壁等地形），这时候策划必须策划出好的方案来协调问题，不应当过于较真，当然很多时候程序员会采用另外一种偏激的手法推翻整个设计，这也是不合理的，当我们有尽可能完美的方案的时候就应该去做。

　　这里我并不说你可以在设计初期就抛开很多重要的、科学的算法不去用，你应该去设计，但你更应该了解开发中会遭遇的问题，并且及时提出“妥协方案”使得项目有可能正常进行下去，老经验的策划和新手的区别仅在于老策划应该会在初期预测到更多的类似的需要妥协的地方。书本知识是非常重要的，我也认为我们都应该具备很多的书本知识，但是在游戏开发中切忌“马谡用兵”，该灵活转弯的时候必须取些巧。

3，系统设计含糊不清，玩法机制完全不明。

　　通常在我们设计游戏系统的时候会忽略掉这个问题，就是我们一心想的只是这个系统如何有趣，玩起来如何如何，但是压根不会去想这个系统我们如何去实现，流程如何？数据结构如何？研发中瓶颈何在？我们当前条件下（人力）如何克服所有的困难？策划脑袋里面甚至都敢没这些就提出一个系统。

　　最常见的情况，一个典型的例子：我们要做个MT类型的卡牌游戏，我希望每个卡牌角色都能有自己的特色，这些特色不应该仅仅只是数值上的（包括品质等的填表数据）。完了？完了！程序员们听懂了吗？该动手了啊，还愣着干嘛？慢来，请问你怎么做？或者说要我程序员做什么？

　　在这个问题上，你首先必须建立一套机制，来描述你的系统——你想如何实现每一个卡牌有自己的特色？很简单，每一个卡牌有其他卡牌不可取代的特性。很好，那么如何实现这样的特色？我们需要Buff机制，给每个卡牌添加一个Buff，他就能显得不太一样了（具体的buff机制我就不重复了，我之前已经写过，但愿你看到过了，参看：Buff机制及其实际运用）。光有这套机制完了吗？没完，还有很多工作要做，我们如何让这套机制工作？首先你有几个Buff功能函数回调点？他们分别要什么参数？他们是否有返回值？返回值拿来干什么？

　　“这不是程序该考虑的问题吗？”如果你这么想了，这个边界问题就产生了，程序员不是你肚子里的蛔虫，你想得他/她怎么可能知道，你必须明确的指出：

　　1）Buff表和BuffObj（于角色身上的实体）具体表项。

　　2）从BuffObj中可以获得的所有信息。

　　3）更实际点的例子：我需要在每个角色行动前有个函数回调点，这个函数不需要传给我更多的参数了（我已经能获得BuffObj，并由他获得很多重要信息了），不需要返回值，我使用它可以做一些比如角色中毒了在每回合行动前造成伤害的工作。那么程序员立即就会提出如果角色死了该怎么处理，你可以顺便告诉他/她你的想法。

　　4）特殊处理机制：由于这些Buff是被动技能，因此在战斗开始的时候，我就会把他们添加到每个角色身上，根据表项获取每个角色添加那些Buff，回合数都设定为9999就好，层数也许要读表。

　　当你这样和程序员交流的时候，思路和问题很快就出来了，理清思路，解决问题，最后事情就能做，否则很可能你会发现，为什么能做的特性这么少？这表填起来怎么这么别扭？当你提出新的需求的时候，程序员心里也会想“你丫的早干什么去了？让我的代码补丁打补丁”大家都很不爽，东西也做不好，毫无意义。

4，肉眼一看就知道的事情，程序员“看不懂”。

　　开发中我们还会遇到很多东西“我一看就知道了”，可是程序员就是不知道“这个我该怎么做呢？”最典型的例子就是——“只要判断这张图片上有多少艘船，就知道这是不是我要的图片了”，“用计算机程序随机生成图片，然后判断出这张图片上有多少个人脸不就行了么？”。

　　在项目开发中，很多想法沉了是因为最初策划把问题看得太简单，而忽略了残酷的现实。还是那句话，有些东西肉眼看很容易，但是你要教会计算机程序去看，比登天还难。学会站在一个受限的环境下去分析这个问题——“一个瞎子如何看出图片上有多少艘船？”程序员的智商并不会比策划低，只是很多时候他们必须站在一个“弱智”的角度去思考问题，因为计算机程序是“弱智”的，他们不具备人类的智能分析基因，只能通过你告诉他一个规律，他更高速的去演算而已。

　　所以在你设计一个东西的时候，千万不要抱有我一看就知道了的思想，去想想如果你写这个代码，你该怎么写？你如何建立这个结构？如何梳理好逻辑？如何让策划去和计算机程序交互？设身处地的站在别人的角度思考一下这些问题，你也许从一开始就会吞掉一些“伟大的设计”。也不至于弄到后面不仅实现不了还搞得大家很不开心。当然事情也有另外一面，就是程序员的确想不到好的办法解决，而你心里早就有底了，那你就不该坐视不管，应该自己动手来完成你想要的东西，毕竟大家在一起的目的是做出游戏，不是贬低谁。

5，AI设计只需要一个想法。

　　和上面2个问题一样，很多时候我们设计游戏会忽略了AI是一个难点，因为只考虑了游戏系统，想过要一个"NPC"，却压根没去考虑过陪你玩的这位“NPC”该如何陪你玩。

　　设计一个AI就像设计Buff一样，你首先需要一个机制，但是这个却因游戏会产生极大的不同，你策划必须先想好这个机制，然后建立对应系统，以应付游戏中所有的AI设计需要。AI并不简单，并不是“选择一个目标，然后使用技能攻击他”，那么请问：

　　1）如何选择一个目标？

　　2）使用什么技能攻击他？

　　3）延伸出来还有：目标如果掉线了怎么办？技能冷却中怎么办？等等等等很多看似边际问题。

　　策划必须想清楚每一个细节，建立一个函数（不是简单的数学函数），使得这个机制能够正常的运作，即使你不会Coding，你也可以把这个想法思路理清，然后才能告诉程序员，让他/她更容易明白你要做的AI是怎样工作的，该给你提供什么样的接口。

　　残酷的现实往往是，策划并不知道AI如何设计，却像个想吃棒棒糖的孩子哭闹着想妈妈能卖给自己一样，哭闹着要这样的AI，可是AI不是棒棒糖，看不见摸不着，你让程序员怎么帮你呢？

6，“耳听为虚、眼见为实”凡是看到的就是那样了。

　　耳听为虚我们且不说，但是眼见为实却是游戏开发的大忌，这话也是对程序员说的。我们有时候开发一些东西，却不能把逻辑层和渲染层清晰地分开，最后导致产生了很多问题，典型的还是我们主题说的边界问题，这时候还可能牵扯到美术，最后大家开始互相推脱，项目停滞不前。

　　最典型的例子是外行开发动作游戏，程序员认为策划应该设计好角色攻击防御判定，策划认为攻击防御看图片，因此是美术的事情，美术说了我没看到效果我也不知道怎么做这个动作，你让程序员先做一个看看，程序员又说了巧妇难为无米之炊……好了，死循环，谁都做不下去了，A在等B，B在等C，C在等A，结果演变成while (a==1){a=1;}。

　　事实上这个问题的处理很简单，从策划出发，你必须明确一个思路——游戏开发中所见并非即所得，肉眼看到的只是在逻辑层上加一层皮而已。也许这个说法你不好理解，那么我们还是举例到动作游戏中，作为策划：

　　1）我设计好了角色应有的动作，可以是跟据平衡性指定的攻击框防御框，然后我先填完攻击防御框数据。

　　2）告诉程序员，你需要做的事情很简单：逻辑层，根据攻击防御框的碰撞关系得出是否命中、根据命中结果进行ooxx的处理（你的游戏你做主），等美术资源来了，根据某个坐标和某些属性，我们如何贴图就完了。

　　3）告诉美术，我希望的动作大概是这样，请你制作时注意尽可能别偏的太远了。

　　事实就是，没有动作游戏的碰撞和肉眼看到的是完全一致的，如果是一致的，那说明两种可能，1是开发团队（个人）无比牛比；而更多的是2，开发出一个妥协后的结果。

　　在我们游戏开发中的确很多东西都是看到的和逻辑层的完全不同，学会抽象到逻辑层是非常重要的事情，策划要学会在一个线条和多边形组成的世界中思考问题，然后建立一套把这个世界抽象到图形世界的逻辑，这样设计，才能有效地避免这最麻烦的边界问题。

总结

　　项目开发中可能还会有很多的边界问题，其实解决这些问题最根本、最直接、最有效的办法，就是有一个人担起责任来，联通起每一个开发人员思路和工作，最应该成为这角色的就是策划，不是吗？如果你都不知道该怎么做，你如何策划了让别人去做呢？更何况策划喜欢把自己比作将军，那么将军不会打仗还如何指挥打仗呢？

　　也许你现在不懂得任何计算机程序，但我建议你作为策划还是去至少学习一门程序语言，学会用计算机程序的思维思考问题，毕竟你开发游戏还是得通过计算机程序，所谓“理解万岁”，当你有了这样的思维后，才能去更好的理解别人。不擅长的东西，我们应该去学习，而不是避而远之，学习知识永远不可耻，干了12年游戏开发了，我现在才刚学Flash动画基础知识，操作可能还不如一个大学生，这有什么？我学的很开心，掌握了很多新知识，还跟很多没入行的人学了不少相关技术，挺好，知识这个东西学了就是你的，所以学到了就是赚了。

VIA:GameRes