After Project Crash

[] 草稿2

写在失意之后

我想骂人

出来做项目嘛,哪有不失败的,区别是公司处于上升期时大家开开心心去开新项目,而现在是大家都锤头垂头丧气的,很难说会过个好年。

一般这个时候的主题就是发泄怨气:程序策划聚一起就是美术屁事不干,程序美术聚一起就是策划傻逼没能力,美术策划聚一起就是程序低能啥都实现不了。而我们又可以多一个由头:版权方太坑不当人,掣肘太多。

即便是骂爽了,再一哆嗦,酒醒之后还是空虚。

我视角下的问题是什么

直觉第一句免不了又回到上面那段,“那谁谁太拉了,不太行,都是他的原因”,别的时候也许有这个因素,但我想我们现在很难说是谁不行,大家履历能力都不错,问题的根本不是这个。

好多项目经验都是成王败寇,有的项目成功了,那么它的经验就是天经地义的,正确的科学的,经过市场验证的。假如说这个成功项目中某个人在某个阶段放了个屁,那么学习这个项目经验时,这个屁也得安排一个流程。

在我看来,我们有着结构性的问题,它就是MMO的历史经验很难适应强调内容玩法和品质方向的开发。

我原本有个怪物,按照MMO的经验,我配置表加一行就应该有个新怪物了。更甚者,我有个模型A的怪,已经有逻辑了,我换个新模型上来啥都没改,它为啥会可能有问题呢。

现在的分工的问题

现在大家分为美术策划程序,各自职责明确。想象中的完美搭配,程序拿到需求,划分模块,抽象功能解耦实现一套操作,要的就是简洁高效;美术多快好省的设计、制作、包装,策划出方案,最后把美术产出,跟程序实现,整合一配表,成了。

而骨感的现实是,程序提供了一大堆功能齐全但并不好用的接口,美术点灯熬油输出一大堆资产,策划拿来整合半天整不明白程序接口咋用,搞不清楚各个资产利用率,最后不得不推出一个成本高昂但并不起眼的小功能。最后看到结果只能来一句这届策划不行。问题是具体的策划同学可能也很委屈:“我要这个要那个,最后给的不好用,将将就就缝缝补补好不容易把需求弄完了,结果还要说我没用好。”

就说说我自己的例子,我负责角色和NPC的动画和行为,跟我配合的策划已经是我见识过相当优秀的同事了,但是他产出的结果依然天天会遇到某具体NPC转向不对的问题。遇到问题就要我来查,我查到结果来一句接口没用对。一次两次可能是他用不对,但是天天出问题这就不是用的对不对的事情了。我设身处地的想,确实,要求一个没有源码,不知道具体行为如何实现的策划,让他整合一堆含有很多他不能直接看见和理解的规则的API。这本身能做对才是那个不寻常的结果。问题再回到我自己,我本身的工作职责又不天然包含“要对接策划很清楚每个实现,和保证他理解怎么使用”,是原则上我要这么做,但实际上一方面并没有人考评这个结果不这么做也没有多大损失,另一方面还有其他工作,每个需求都是草创阶段,先解决有没有再说好用不好用。

因而在这个环节中,每个人都点灯熬油产出的成果并不能有机的整合成一个高效的结果。现在的分工因为松散,所以不能实现新的需求

分工明确不好么?

一个成熟体系下的分工明确是好的,是工业化的体现,但是它却不适应处于转型的团队。有个不知道恰当不恰当的例子:我有个朋友他妈包饺子味道独特很好吃,他每次想吃就喊妈我想吃饺子。我跟着蹭着喊一句阿姨我能不能也吃一顿,他妈看心可能也给我一顿包一顿少了一些温情和亲情,但是还是那个味道的饺子。但是我回去直接跟我妈说我想吃一顿别的阿姨包的那个口味的饺子,那可就费事儿了。

所以我认为即便是一个成功很多次的团队,切换风格也会遇到不可避免的困难,就像我妈做饭经验再丰富,她也很难多快好省的做出别人他妈能做出的味道。因而分工本来就是对自己熟悉体系流程的整合,对不同体系流程在用相同的分工就是刻舟求剑了。

我的畅想是什么

当前的程序也不是曾经的程序岗位了。上个世代,游戏引擎是各家游戏的独门秘笈,当时的程序大部分算是现在特化的引擎开发岗位。而当下商业引擎的成熟,大量程序算gameplay。既然是gameplay了,那为什么不能为gameplay负责,为直接的策划案负责呢?当下的程序也不是上个世代的程序(做游戏但是不了解游戏),好多程序员都有着不逊于当前策划的游戏经历。因而我畅想就是很多gameplay程序员的分工或组织架构不应该是程序组,而是技术策划组。每一个简单的gameplay都至少有一个人的闭环,方案和实现自我就要完成。

软件工程的孤岛危机

程序关注最大的问题通常是软件工程方面的,当前很多策划都自己无限制的使用蓝图都产生不小的问题了,那未来让大家各自做自己的需求岂不是每个需求都成了孤岛,这不是乱了套了么。起步时内容少还算能控制,长时间做下去一定会失控和混乱。如何控制规模和发展成了问题。

还是工业化

自成一派是探索,是研究,但对于确定需求和功能,肯定是有现成逻辑,有工业化的生产流程才能把规模做大。所以整体的分工不应该跟积极的探索有冲突。