从对话框看程序和策划的分工

gantleman

娱乐为主吗，见笑见笑。

walnce: Re:从对话框看程序和策划的分工

笑了，LZ先说BF丢人现眼，BF说LZ中二
LZ马上跳起来大喊“你人参公鸡我！”

最后对撸主说一句：中二是病，得治啊！

gantleman

这样不好，这样不好说不清楚了 [em3] [em14]

正宇不在: Re:从对话框看程序和策划的分工

其实我挺喜欢 gantleman

grspace

一般来说，程序喷策划不懂技术，普通的策划只有乖乖挨批的份，但如果策划真懂技术，且程序用了不恰当的例子来喷，这恐怕要被反杀了。

ab_946

这有什么奇怪。。。
如果策划能够深度掌握技术，并有足够的时间写代码的话，那么这所谓的分工也就不存在了。
作为策划，能够在逻辑上说明白方案，并和程序沟通，弄明白不同方案所需要的工作量，从而作出较优的选择就足够了。

gantleman

重点不是喷策划不懂技术，
而是在说策划什么时候该强势，
项目初期都是零的时候策划考虑越多越细越好，
如果项目初期是做一点看一点，
项目后期还想这样做就要懂得退让。
程序也不可能说因为你想法细了，
就把以前写过的东西都重新搞一遍来补救。

grspace: Re:从对话框看程序和策划的分工

一般来说，程序喷策划不懂技术，普通的策划只有乖乖挨批的份，但如果策划真懂技术，且程序用了不恰当的例子来喷，这恐怕要被反杀了。

gantleman

这里如果前面几十个对话框分别由不同的几个程序小组维护，
那么这个修改就涉及到跨部门的问题，所牵扯的东西就不单单是选择和工作量的事情。

ab_946: Re:从对话框看程序和策划的分工

这有什么奇怪。。。
如果策划能够深度掌握技术，并有足够的时间写代码的话，那么这所谓的分工也就不存在了...

狂澜萧萧

严格来说，就这个例子而言，并非只是一个技术层面上的问题

比如魔兽的处理方式，这也不单单是程序员觉得这么处理起来最省事

这是一个策划和程序共同商量的结果。很多时候在开发过程中遇到类似的事情，并不能设计归设计、技术归技术的严格区分清楚

比如以前做过的一个项目，全套的UI都是我用LUA写的脚本，而程序提供给我的接口，允许我在每个界面关闭的时候，通过脚本决定是否给服务器发送消息，所以我想发就发，不想发就不发，包括发什么样的消息，触发什么处理，都可以通过脚本决定。而就一个界面的逻辑来说，应该是策划比程序更清楚要做什么处理

现在国内做游戏，很多公司还停留在原始的阶段，策划提供各种功能设计，由程序把这些设计利用代码进行实现

说到WOW，粉之黑之皆有，且多走极端。其实WOW真正走在时代前面的，是这些方面的处理，并非是什么世界观、剧情故事、人物塑造之类的东西

那么多游戏成天嚷嚷着超越WOW，话说咱论坛里面还有位仁兄也有这想法的。不过这技术层面上都超越不了，设计层面上能超到哪里去？

说回到撸主所举的例子，如果我是程序，写个接口，然后把脚本丢给策划去写，策划想要哪样就哪样，这才是最好的做法。这个时候请问撸主如果作为一个策划，敢接招不？还是一口咬死了这是个技术问题，不该策划来做？这会被程序鄙视到死的，以后永远也别想在程序跟前抬头做人

BF

正宇不在: Re:从对话框看程序和策划的分工

其实我挺喜欢 gantleman

没骂到你头上你当然喜欢了

其实我本来也觉得有点意思的

BF

狂澜萧萧: Re:从对话框看程序和策划的分工

比如以前做过的一个项目，全套的UI都是我用LUA写的脚本，而程序提供给我的接口，允许我在每个界面关闭的时候，.

你说的界面关闭，指的是在UI上特别放置了一个专门用来关闭界面的按钮，在点这个按钮的时候调用底层开放给lua的接口来给服务器发消息吧？

从我的经历来看，UI底层的hide和delete事件都不会直接通知服务器，否则像wow那样，执行一个/console reloadui的时候服务器该有多蛋疼--!

狂澜萧萧

你这个叫做抬杠了，这种命令即便开放，也不会有那个二货策划在脚本里面写的到处都是

完全自由化的接口调用，是可以允许你做到很多事情的，但是做或者不做，决定权在你，而如果你无视处理效率、内存占用之类的情况，为所欲为，那就是你的思路有问题

这就好像法律一样，只规定了不能做什么事情，但是如果做事只以这个为界限，那就难以将这种货色称之为人了