作为一个策划，你是否做过这些事？——2D游戏主策篇（详尽版）

作为一个策划，你是否做过这些事？——2D游戏主策篇（详尽版）

本来不想些这样一篇文章，因为时间太紧精力太紧。但看了之前某些人对我帖子的回复，我觉得他们对我的想法有些，所以我首先要说明一下我写这个东西的原因。

我写这篇文章最主要的目的，是想跟大家分享一下这么多年从事主策划工作的一些经验和知识。让一些刚刚成为主策划，并真心想开发出一款游戏的人能够得到一些指引和帮助。毕竟，目前大多数介绍游戏开发、游戏策划的书籍所介绍的该方面知识和技术要么流于表面形式，过于形式和肤浅；要么则过于深奥，钻研的是关于策划思想和理念方面的东西。而真正关于一个策划（特别是主策划）在项目开发过程中，该做些什么，该学些什么却很少提到。

而之所会写 “未入门、新手策划、手游策划、棋牌策划、WEB游戏策划不在此列”，也完全是基于领域不同技术不同的原理，不想从事这些领域的策划们被我的帖子所误导。

这里需要再次说明一下：我并不是说所有的主策划在开发一款游戏中都需要做到这些事。但是这里面很多知识都是需要主策划去了解、去研究的。所以，也许当你看到一些内容，如果产生“如果我有一个好程序搭档，这样的事就不需要我去做”这样的想法，那么你完全可以无视我的观点，直接跳过。这一篇写给那些没有或不能确定自己有优秀团队、优秀搭档，但又想获得项目成功的人。

另外，还有一些人会说，为什么我提到的更多的是跟程序、美术和策划下属打交道沟通的事，相反会忽略策划的一些本职工作呢？在我看来，策划的一些本职工作：例如写策划案、写剧情案等等，是个策划就会明白，而我写这文章的目的主要目的是交流一些容易被人忽视被人冷落的工作环节，让没有注意到的人能有一个方面。

下面，我就针对我帖子中提到的每一个技术点进行详细分析——用来说明为什么主策划需要了解并运用这样一些知识。

是否建立过项目计划表？
是否每周定期召开策划会议？
是否要求每个策划每天提交工作日志？
这三点，是一个主策划对策划团队管理的基本方法。作为一个专业的游戏开发团队的负责人，为了确保项目的实施进度和效率，这样的管理方法是必不可少的。一个人包揽所有的开发任务或者是所有人全部都自由发挥的团队，开发一两个手游、WEBGAME或许还行，要开发一个大型的MMORPG，这样的主策划专业技术再强，也不可能成功。

是否有规范策划文档（包括策划案、逻辑图、进度表、图量表、元素表、UI设计图、测试工具、BUG提交工具等）的规范写法？
我们写策划案是干什么？给自己看？还是给你的上司看？——都不是。是给其他部门（程序部、美术部、测试部）作为参照和依据。如果不对这一块进行规划，那么你写出来的每一个案子是不是都必须要你亲自去向执行者解释一遍，并陪同他全程开发才能实现？即便是这样，如果没有规划，当你想修改你的策划文案时怎么办？改完了，直接用RTX传到别人那里？然后告诉它某某地方改了，让他马上进行修改？对于一个只有少数人参与的项目，这样做或许比规范文档看起来省事些，但是如果你面对的是一个大型项目、一个大型团队。你这样做将极大的损害整个团队的开发效率，最通常的一个结果就是：开发到一定阶段时，无法再获取到原始策划文档，无法再了解到原始的策划意图。

是否与客户端程序讨论过底层图象引擎的构架，从而确定该游戏用哪种动画表现形式（图片、FLASH）更合适？
作为一个2D游戏，最占内存资源和游戏容量的恐怕就是游戏中动画的播放了。不要指望你的主程序员一开始就会去思考这个问题——因为他不需要对这个东西负责，他的责任是把策划的需求实现，但是在这个需求中你会不会提到你做的游戏准备有一个多大的客户端？准备用多少内存来处理动画渲染和播放？如果你做了，恩——那你当我是在说废话，但我相信绝大多数国内策划还达不到这么高的水准。所以，并不是让你一开始就去做这样一件极具技术性的工作，只是让你跟客户端程序员去讨论，让他给你建议，让他预测一下如果按你的思路这款游戏该用怎样的表现形式更为妥当——如果是一个小游戏，游戏中动画不怎么多，当然用图片比较好，因为内存调用速度比较快，技术也比较简单；如果是一个大型游戏，那么你就得考虑了——用FLASH或强大的图片压缩技术比较能减小客户端的容量，但是相对的，内存读取速度会慢一些，动画加载时间也稍微久一点。不要说，你丝毫不关心客户端的容量，是的，这并不影响你游戏的质量，但是你想想如果你开发出来的一个网游，要别人下一个星期才能下下来，还要占掉人家一大半的硬盘，别人会不会愿意去玩？

是否研究过，针对不同规模的设计需求，使用哪一种界面控件更有效？或者是干脆就直接调用图片？
界面与图片一样，如果不注意，会是一个十分占资源的东西。如果你只是一个小游戏，就那么几个界面，那么OK，直接调图片省事。但如果你是一个MMORPG，界面多如牛毛，此时你调图片？那你的游戏就提前完蛋了！因为，光是加载这些界面图片，以现在的内存处理速度可能就要处理上半个小时到一个小时。这样的游戏谁愿意玩？好吧，你说这个问题不归你考虑，那么你让谁考虑这个问题？你的主程序员？——他怎么知道你要用多少界面？他怎么知道你的界面与界面之间有什么关系？他怎么知道你要提供哪样一些界面功能？然而，这些问题如果不搞清楚，就算他是比尔•盖茨，他也不知道该给你写或者提供怎样一个控件！

是否研究过，客户端程序使用哪种字体控件？或者说，设计的字体控件是否满足游戏风格需求？
你准备让游戏界面显示哪种字体？宋体？——很好，你可以去做MUD了。当你看到你的全宋体字体游戏时，你可以对你的程序和表现策划说说：“我希望用一种很漂亮的、很华丽的字体”，但是这个时候你的主程也许告诉你：“对不起，因为这一块涉及到底层字体控件，要改可能会修改游戏底层，而且可能无法支持矢量字库！”好了，一个休闲Q版游戏，只好顶着宋体（如同关羽拿着烧火棍）冲向了战场。

是否定义过服务器与客户端的消息包结构？是否确定过消息包的大小、类型？是否设计过消息包的数据结构？
这一块对于一些没有接触过程序的主策（别见怪，这样的主策划现在多的是）的要求有些高。假设你是这么一个主策，而且又假设你没有一个真正精通通讯层的主程，我可以很负责任的告诉你，你的游戏就此OVER了。好了，你说你找到了一个马马虎虎可以胜任这一块的程序，那么该游戏即便做出来，客户端的异常当机行为会比一直会困扰到你的运营商跟你说88为止。好的，如果你的运营商比上帝还有耐心，能一直坚持到你解决了所有的封包问题，可以预见的是，当你的游戏出来测试不大半个月之后，游戏外挂会如同蝗虫一样渗透到你游戏的每一个环节。你此时可以责怪你的程序员，相信他们也会承认自己这一块没考虑周全（当然，前提是这个时候你仍然还是主策），但是项目损失能够挽回吗？如果你开始能与他们确定消息包结构、确定消息包大小限制和类型、确定消息把的基本结构——其实这些知识我相信如果你稍微有点悟性就能在一天之内掌握个十之八九，这一切就都不可能发生。
是否设计过数据库的表结构？是否定义过数据字典？是否与服务器程序员（或数据库程序员）商讨过怎样设计数据库表结构才能更有效率的存储、读取？
“我们用的是MYSQL数据库，其他的我就不了解了…”——不用奇怪，这样的主策我真见过。表是什么？结构是什么？什么时候读取？什么时候写入？什么时候备份？什么时候恢复？如何调用一个玩家数据？如何修改？如何重启？有没有后门？…是的，这些似乎都是程序专业知识，但是我可以很负责任的说，如果你自己不懂这一块，而你的策划班子里也没人懂这一块（主要是指数值策划），你的游戏也很容易玩完！数据库架构看似一个简单的过程，其实很复杂，牵涉的内容很多，与网络游戏的运营寿命和安全性密不可分。特别是在网游时代、在虚拟价值现实化时代，你游戏的数据库保存的不仅仅是数据，它反映的是玩家的虚拟财产！！！幸好，现在关于网络的法律还不怎么周全，对虚拟财产的保护还不怎么看重（但是已有相关法律出台），否则——你这游戏的主策划、所谓的游戏灵魂、所谓的游戏大方向掌握者，搞出一个自己都不懂的银行给玩家来储存私有财产，万一出了岔子你该负怎样的责任？豆腐渣工程都要枪毙人，豆腐渣银行该怎么办？退一万步说，你不负这个责，而只对游戏本身负责，下面一个问题就出来了——程序员问你：“你们策划希望在什么时候保存人物属性？”你会怎么回答呢？“时刻保存~恩~每时每刻~~！”这还算你小子有点良心，肯为玩家的财产考虑考虑，不至于说“每次退出时保存！”但是，就算这样，你考虑过你们家服务器的CPU没有？考虑过你们家宽带有多粗没有？酷睿四核CPU+亿兆带宽——差不多了。

是否熟知你们游戏的服务器以及客户端加密格式？
这个东西也比较专业。虽然这个东西与我们游戏的可玩性关系不大，虽然即便你不加密就把你的游戏推向市场，照样可以有模有样的运营一阵子，可是接下来——你的游戏就会像盗版光碟一样变得一钱不值。你的图片也好、你的源代码也好，完全裸露在任何一个下载了这个游戏的玩家手上。“这个俺确定，俺主程说他会做！”是啊，如果你主程是你铁哥们或者是你亲兄弟，你可以暂时不用担心这个问题。可万一人家是挖来了，或高薪聘来的，结果一公司又毫无声息的把他给挖走了，你可就连哭都来不及——加了密，钥匙还在他老人家那里呢！幸好，现在的程序员们都还比较厚道，据我了解还没有谁是加了密不还钥匙的，不过乘机捞一把的程序哥们我倒是见过。

是否能区分对象的私有属性、公有属性和函数？
现在很多游戏都在流行使用LUA脚本语言，而LUA脚本其强大功能就是能平台语言定义的对象带入函数，引用其私有属性、公有属性和函数参与功能与数值计算。写到这里，马上又会有人说了：“我们程序管这事呢！”好吧，好吧，当我最开始说的放屁，我再这里再说明一下——你的最佳程序拍档的确是可以想到这一点，可以将LUA脚本语言嵌入底层，进行继承调用，可关键问题是，他是否能考虑到你的这些调用对象会如何来调用你的属性呢？又如何返回值呢？你才是主策划，案子在你手里握着，哪个步骤会使用脚本，脚本里需要调用什么、需要继承什么、需要执行什么、需要返回什么除了你谁知道？
游戏策划不是神，任何有经验的策划都不可能在一开始就能够预见并解决项目开发时所遇到和经历到的所有问题——即便准备工作再充分、在开始项目之前所写的系统文档和规划文档再详细，在开发过程也可能遇到很多从未考虑到的问题。然而，一个高明的策划之所以高明，主要会体现在两个方面：
1。高明的主策划往往会根据自己的开发经验和当前团队的实力尽量的去思考一些开发过程中不可预见问题的类型，比如：当你知道你的团队服务器程序力量缺乏，新手居多时，你会预见到在你游戏中逻辑部分、通讯部分、数据库部分将会要遇到一些问题，那么，在项目启动时甚至项目启动前，就会投入更多的经历去关注项目计划的相关部分，并为此制定和实行一些特殊应对方案——如：内存泻漏处理和查询方案、数据库备份方案、消息包结构商讨会议等等。虽然，在开发过程中仍不免遇到这些问题，但是因为已经有了具体的应对措施，问题将很快被查明原因，处理时就会显得得心应手。
2。高明的主策划在项目出现了一些没有预见到，甚至从未接触过的问题时，往往不是就问题处理问题，而是在找到问题的原因所在后，及时制定规避及应对此类问题的通用对策。就问题处理问题，是抱着一种侥幸心理处理问题的态度，认为一小块问题是因为工作误差所造成的，之后不会再犯，然而这样的心理往往会成为一个大型项目最大的潜在隐患。以策划写脚本所犯的错误为例——使用空指针类型往往是策划在脚本设计时最容易忽视却十分难查找的一个问题，即便是一个有经验的策划，在写逻辑脚本时仍有可能因为复杂的逻辑结构而调用某些实际上已经被释放的对象。在我的项目刚刚使用LUA脚本语言时，我犯过类似的错误，然而遇到这个错误，我不是马上就对脚本进行修改湖将其加载，而是先与程序商讨，如何在下次出现此类问题时，利用平台语言进行有效检测，将错误的内容直接反馈出来，这样一来，即便下次再出现这样的问题，或者其他策划犯下该错误时，都能很轻松的找到并解决问题。

对于需求，我的看法是：狭义的需求是指对项目本身的需求，就是项目需要设计出怎样的效果、需要表达怎样的逻辑。我刚说过，策划不是神，而是人，所以要求策划在开发时无所不知或者在项目开始前就对项目的所有设计环节都能一锤定音这都是不太实际的想法，何况即便策划主观上有这样的能力，但客观上很多因素都将左右项目设计需求的方向——比如：新的市场环境、新的技术因素、新的运营条件等等。所以，要想这样去要求需求的明确性，只能是教科书上出现的理想状况。但是，这并不是说需求是无法明确的——这里所说的需求是广义的需求，除了项目的设计需求以外，更重要的是团队需求——团队的沟通需求、团队的适应力需求、团队的协调性需求、团队的应变能力需求等等。而这些需求一旦明确，你会发现项目的设计需求所存在的不足，将会被团队需求的明确所补足。比如：当你们在确定一种设计需求之前，你如果和你的策划们坐下来，聊一聊，沟通一下，讨论这个需求需不需要带有一定的扩展性？需不需要做一个错误反馈接口？需不需要更多的注释点？需不需要多层嵌套处理以应对可能出现的需求变化？在满足了这种沟通需求之后，你会发现，设计中需求的不完善性将被彻底的暴露出来，一些可能出现在开发过程中的漏洞将会被很轻松的被弥补掉。

如果你理解了这个广义需求，相信你也能很块理解什么是狭义的策划案，什么是广义的策划案。狭义的策划案——对游戏内容的设计、对游戏系统的设计、对游戏逻辑的设计、对游戏数值的设计、对游戏UI、表现、剧情以及声效等的设计——仅仅局限于设计；然而广义的策划案，除了这些狭义的设计外，还包括文档的规范制度、问题的处理机制、BUG的反馈机制等等等等这些涉及团队需求、部门协作、工作形式规范的需求案——这其实也就是我写前面那篇文章的主要目的。

补一条：
做个游戏内系统和功能的关联图，并维护。在一个系统做了变动时，可以清晰的找到游戏其他部分需要改动的地方以及对这些系统的影响。很多好处，能评价这个改动真实的成本。