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

xianrena

还是那句话，如果lz连底层图像引擎的效率都要过问的话，那lz一旦要做个3D游戏怎么办，请假先学习半年3D图形图像学？如果你不是某方面的专家，就要保持最大的警惕和耐性，做到不在你不熟悉的方面提些模棱两可的问题或者建议。我很好奇你为什么会认为你们主程序不会尽力提高引擎效率还要你来过问才会注意这件事呢？

sjinny

不太明白为什么lz喜欢把一些技术细节也弄进来，比如说内存泄漏，这个其实跟策划一点关系都没有，脚本是使用垃圾收集的，非脚本的一般也不会是策划去写，策划会去制定编程规范、确定对象生命期？内存泄漏已经有很多工具来进行检测了，也有很多手段来避免，并且不会对策划案产生影响。消息包，如果说策划会说明需要在客户端与服务器之间传递什么样的信息，那还能理解，但是如果说是制定一个消息包里头几个字节是len，然后几个字节是type，我觉得这和策划也是没关系的事情。
27楼的帖子粗略看来感觉观点就是：
1.对策划需求的确定性不能提出要求
2.策划需要关心程序缺陷
但是这样看起来就变得好像策划不受多少约束，而程序却要受到策划的约束了。当策划提出新的需求的时候，如果程序说目前的程序设计不能做，或者改起来很麻烦，这时是否会算做程序的缺陷呢？是否策划提出需求的时候可以说“一切皆有可能”，然后对程序设计的灵活性和扩展性提出很高的要求？

布丁躲起来

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

不太明白为什么lz喜欢把一些技术细节也弄进来，比如说内存泄漏，这个其实跟策划一点关系都没有，脚本是使用...

感觉该楼是个程序，而且是个对策划有成见的程序。HOHO~~

sjinny

我是程序，不过对策划的成见就是，有时需求分析做不好还要插手程序的事，或者是自己没有在文档里做要求然后做出来不满意了又说是程序的bug……

pilipala

不做主策划
太累

清风徐过

顶礼膜拜，LZ威武，继续观摩

布丁躲起来

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

我是程序，不过对策划的成见就是，有时需求分析做不好还要插手程序的事，或者是自己没有在文档里做要求然后做出来不满意了又说是程序的bug……

那要看你碰到什么样的策划.....其实策划需求分析做不好，也可能是因为不懂程序导致的（我说的只是可能），往往写出来的案子是程序无法实现的，或者说，策划没有站在程序技术的立场去去需求分析，所以才导致更改的次数多了。当然，策划修改策划案也是常事（就像程序写出来的功能也有BUG一样）。只是，我觉得懂程序的策划做出来的需求分析改动的次数可能要少。
所以，我觉得一个策划能具备Lz所说的东西，是很好的。
不然可能会遇到这种情况，对要实现某一个功能，策划会说：这个东西这么简单，不可能要做这么久之...。而程序会说：你们策划根本就不懂程序。这样就会出现程序和策划相互推卸责任或相互埋怨的情况。
所以说，我到不觉得做一个策划去思考LZ所说的这个事情，就代表着是要去干涉程序的只能，我觉得如果更多的去思考了这些事情的话，会使得程序和策划的配合更好。

sjinny

我说的需求分析没做好，不是指那种做出来的东西不具有可行性之类的情况，而是指需求一直不稳定，这个不是懂不懂程序的问题，并不是说程序说这样不行得改，而是程序做到半路策划自己说要改这种情况。

布丁躲起来

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

我说的需求分析没做好，不是指那种做出来的东西不具有可行性之类的情况，而是指需求一直不稳定，这个不是懂不懂程序的问题，并不是说程序说这样不行得改，而是程序做到半路策划自己说要改这种情况。

原来你是抱怨策划修改策划案落~~~

程序确实基本都有这个心态

但这种情况存在很正常，毕竟是那么庞大的系统，又不是写演讲稿。只能说修改的次数和间距问题不同。这个就要看策划的

能力和经验了。但你不觉得一开始，策划思考的东西越多，后面的改动就会越少嘛？

呃....算了，不说了....感觉你心里对策划的偏见不浅。以后和策划多沟通吧。

sjinny

恩，看来ls还是认为对策划案的稳定性无法做出要求吧……或者你认为我的偏见是什么呢？
需求的确定性和稳定性会在相当大的程度上决定程序设计和实现的质量。
另一方面，我认为通过原型等方法是可以使策划案最终稳定下来的，当然这个原型阶段应该在正式开发之前。