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

jamesge

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

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

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

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

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


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

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

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

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

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

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

是否定义过服务器与客户端的消息包结构？是否确定过消息包的大小、类型？是否设计过消息包的数据结构？
这一块对于一些没有接触过程序的主策（别见怪，这样的主策划现在多的是）的要求有些高。假设你是这么一个主策，而且又假设你没有一个真正精通通讯层的主程，我可以很负责任的告诉你，你的游戏就此OVER了。好了，你说你找到了一个马马虎虎可以胜任这一块的程序，那么该游戏即便做出来，客户端的异常当机行为会比一直会困扰到你的运营商跟你说88为止。好的，如果你的运营商比上帝还有耐心，能一直坚持到你解决了所有的封包问题，可以预见的是，当你的游戏出来测试不大半个月之后，游戏外挂会如同蝗虫一样渗透到你游戏的每一个环节。你此时可以责怪你的程序员，相信他们也会承认自己这一块没考虑周全（当然，前提是这个时候你仍然还是主策），但是项目损失能够挽回吗？如果你开始能与他们确定消息包结构、确定消息包大小限制和类型、确定消息把的基本结构——其实这些知识我相信如果你稍微有点悟性就能在一天之内掌握个十之八九，这一切就都不可能发生。（待续）

suquan77

占楼待看……对我是有益的，其实WG这边也有很多相似部分，慢慢学习中

eff8888

搬板凳看。。

khan

其??我??橹鞑????l就?蛄恕Ｆ溆嗟?|西都??腥俗觥

jamesge

（继续）
是否设计过数据库的表结构？是否定义过数据字典？是否与服务器程序员（或数据库程序员）商讨过怎样设计数据库表结构才能更有效率的存储、读取？
“我们用的是MYSQL数据库，其他的我就不了解了…”——不用奇怪，这样的主策我真见过。表是什么？结构是什么？什么时候读取？什么时候写入？什么时候备份？什么时候恢复？如何调用一个玩家数据？如何修改？如何重启？有没有后门？…是的，这些似乎都是程序专业知识，但是我可以很负责任的说，如果你自己不懂这一块，而你的策划班子里也没人懂这一块（主要是指数值策划），你的游戏也很容易玩完！数据库架构看似一个简单的过程，其实很复杂，牵涉的内容很多，与网络游戏的运营寿命和安全性密不可分。特别是在网游时代、在虚拟价值现实化时代，你游戏的数据库保存的不仅仅是数据，它反映的是玩家的虚拟财产！！！幸好，现在关于网络的法律还不怎么周全，对虚拟财产的保护还不怎么看重（但是已有相关法律出台），否则——你这游戏的主策划、所谓的游戏灵魂、所谓的游戏大方向掌握者，搞出一个自己都不懂的银行给玩家来储存私有财产，万一出了岔子你该负怎样的责任？豆腐渣工程都要枪毙人，豆腐渣银行该怎么办？退一万步说，你不负这个责，而只对游戏本身负责，下面一个问题就出来了——程序员问你：“你们策划希望在什么时候保存人物属性？”你会怎么回答呢？“时刻保存~恩~每时每刻~~！”这还算你小子有点良心，肯为玩家的财产考虑考虑，不至于说“每次退出时保存！”但是，就算这样，你考虑过你们家服务器的CPU没有？考虑过你们家宽带有多粗没有？酷睿四核CPU+亿兆带宽——差不多了。

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

是否能区分对象的私有属性、公有属性和函数？
现在很多游戏都在流行使用LUA脚本语言，而LUA脚本其强大功能就是能平台语言定义的对象带入函数，引用其私有属性、公有属性和函数参与功能与数值计算。写到这里，马上又会有人说了：“我们程序管这事呢！”好吧，好吧，当我最开始说的放屁，我再这里再说明一下——你的最佳程序拍档的确是可以想到这一点，可以将LUA脚本语言嵌入底层，进行继承调用，可关键问题是，他是否能考虑到你的这些调用对象会如何来调用你的属性呢？又如何返回值呢？你才是主策划，案子在你手里握着，哪个步骤会使用脚本，脚本里需要调用什么、需要继承什么、需要执行什么、需要返回什么除了你谁知道？（待续）

hexagon

收藏。

字体那个在意的游戏和公司很少，绝大部分游戏系统字都是用的宋体。虽然宋体不要钱，但如果能用个好点的字体会给游戏加分不少，比如武侠类的用隶书，Q版游戏用幼圆。

APPLE也算是搞字体起家的吧。

khan

其??武?b游?蛴秒`??h?]有武?b游?蛴盟误w好。

sjinny

对顶楼本身我就不评论了，其实有一件事我更感兴趣，因为lz说是主策，所以想问一下在lz看了，策划需求的确定性有可能得到确保吗？因为以前我所听到的所有说法都是，策划提需求不可能那么确定，以后总是会变的，而且怎么变也都不知道，由此引出的往往是当策划补充需求时，如果当前的程序设计不能满足新的需求，那么就会算是程序的责任，所谓的设计不足，但是却很少看到这个过程中有策划被说成需求分析不完整的。甚至遇到过这样的情况，测试部门从玩家的角度（姑且这么说）提出目前版本有某某缺陷，然后一看策划文档里没有就此作出规定，这时策划说这是程序bug，这当前是特例，但是也能反映一些问题。
lz对需求确定性有什么看法？有没有可能在程序开始动手之前把策划需求明确下来，尽量避免在程序开始做之后又修改或补充需求？

hexagon

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

其??武?b游?蛴秒`??h?]有武?b游?蛴盟误w好。

恩，聊天文字还是宋体好，不过像人物任务名字，标题之类的可以用隶书，

sjinny

“你的图片也好、你的源代码也好，完全裸露在任何一个下载了这个游戏的玩家手上。”
这个……一般来说把图片资源解包是有可能的，要直接根据客户端逆向工程得到源代码可就不那么容易了。要防止逆向工程，一般也不是靠“加密格式”，不过这方面的具体技术我也不懂。