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

wq616760759

额，LS的名字和我公司一个同事的一样 - -！

我也翻次页

apm43

这一篇就很有说服力了

jindianer

首先  谢谢   

谢谢LZ能能拿出如此发人深省的文章来与大家共享

但是  LZ对只是点明了各个问题

既然LZ说是详尽版，那么是否可以把如何解决各种问题的方法同时发布一下呢（我是不是脸皮够厚啊  哈哈 ）或

者说LZ平时自己的一套做法拿来跟大家分享一下

谢谢   衷心的感谢    哈哈

GameMonkey

GAMERES上还是偶尔有好贴的，程序飘过。

hilive

经历里得出的经验，赞个。。

65199765

11111111111111111111111111111111111111111111111111

jamesge

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


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

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

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

海洋之舞

不错不错

很实际的执行层面，小弟受教啦。

tonycat

瞒好的文章。很精辟

yxch

确实是容易被忽略的事情，同感。不能单纯的只想设计问题

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