游戏人生

颂山川,吟古道,偏失半点笔墨;言世事,问苍生,更差一声长嗟。

在大连这个风大不怕闪了舌头的地方,游戏产业的巨头们你方意淫唱罢我来粉墨登场,说着漏洞百出、出尔反尔、尔虞我诈的话,把台上台下的观众雷了个外焦里嫩。

在此撷取一二(排名不分先后),插个注释,权当给各位看官留个乐呵。

陈晓薇:希望年轻玩家不要只是崇尚LV等西方产品,我们的老祖宗有很多绿色的东西。

Fox:如果陈小姐主政的九城还在继续代理特别迟,如果不是为了勾引掉线城的玩家,不知道这话该怎么说。

朱威廉:目前的网游公司中没有一个是绿色的。

Fox:史总提了一年的绿色网游,你这话是在打我们陈美女的脸呢?还是在造史总的反?

刘伟:我们特别邀请能造|反的人,尤其是能造史总反的人。

Fox:OO无罪,XX有理。毛先生那一套打天下被历史证明成功了,坐天下被历史证明失败了,不知道史总和刘总是怎么想的。

吴军:如果说《阿凡达》是传说中的电影大片,请大家相信久游网即将陆续推出的次世代作品就是传说中的网游大片。

Fox:没有前面的如果,更没有后面的相信。没有最雷人,只有更雷人。吴总身体力行,现身说法,真是难为你了。

刘伟:我和史总的区别是,风光的事他做,出力的事我来

Fox:看来刘总很清楚,出席今年的年会并不是一件风光的事

王峰:第一代、第二代、第三代,这个词是我发明的,你们知道什么是第三代吗?就是孙子是吧

Fox:毛先生说过一句名言:世界是我们的,也是我们的儿子们的,但归根结底是那帮孙子们的。

明明是一个朝阳产业,不到十年,被一帮孙子做成了夕阳产业

去年经济危机爆发时,业界有一个普遍的声音:韩国在上个世纪末的亚洲金融危机中,游戏业得到了一个迅速发展的空前机遇,中国的网游业也将在这场经济危机中迎来腾飞的时代。

一年过去了,依然有人认为在这场危机中网游业一枝独秀,在我看来,持这种观点的人要么是无知,要么就是别有用心了。

从各上市公司2009年公布的财报来看,时隔多年,绝大多数公司依然是靠成名的第一款游戏苦力支撑,由于缺少优秀的产品丰富市场,各大公司的营收并没有出现下滑,甚至还在继续保持可喜的增长势头。

一方面,大家急于找寻另一款产品以便让自己焕发第二春,另一方面又要不断变着花样为主力产品续血。

我们不禁要问:十年来,这个行业的方方面面都在发展,从个人到团队、从技术到市场,都取得了可喜的进步,为什么却依旧是危机四伏?

因为从内容到表现的严重同质化,从程序、策划到美术,可以做的似乎就是那么多,最后不得不依靠日益膨胀的宣传推广吸引玩家,这个行业已经不是一个创意行业,变成了一个营销行业;充斥在游戏内外的是形形色色的皮条客,到头来,被充当老鸨的这些周边媒体赚的盆满钵满。

昨天和同事去看《阿凡达》,我们一边讽剌着詹姆斯·卡梅隆在向魔兽磕头:我们在这里见到了暗夜精灵与人类的对决,见到了生命之树,见到了风暴要塞;普通玩家只能骑马,牛逼点的玩家骑上虚空龙了,而全服唯一的骨灰级玩家骑的是火凤凰。一边又反复强调着:太好看了,这次看了2D英文版,下周要再看一次3D中文版。

模仿、借鉴并没有错,抄袭就显得太低劣了。可怜可悲的是:我们明明是在抄袭,嘴却比鸭子还硬。

子曰:出来混,迟早要还的

时常听到有同事在抱怨项目中的代码有多么乱。对于现有的很多复杂的模块,几乎没有人愿意去修改,如果你想确切的知道哪些代码是已经废弃的,哪些代码又是在使用中是一件很难完成的事情。

Andrew Hunt和David Thomas在《程序员修炼之道》中提醒我们:不要容忍破窗户(Don’t Live with Broken Windows)

终于,在一次讨论之后,我们决定开始做code review(是的,以前没有)。两周之后,我发现在提交的重读报告中,几乎千篇一律的空白,意思是没有问题。难道平时抱怨的那些代码都开疾风步跑了?

显然是没有用心,随便翻一翻,最后你好我好,都没有问题了。

我只好站出来抓重读的质量,制定了格式规范的重读报告文档,要求从代码规范、设计审查到最后给出修改意见都要做到。如果确实感到别人代码写的漂亮,没有问题,那就一定是别人比你做的好,重读文档中要体现出来对自己的反思。总之,文档是强制的,不能马虎。

用心读别人的代码一定是大有收获的,每次做交流,单靠一个人坐在那儿讲一个模块的功能,你无法确切的知道他到底是怎么想的。因为拿到一个功能需求,大家的设计思路基本都一样:

o 策划给的案子有哪些东西要写在配置里,有哪些东西要放在现有的类里,有哪些东西要新加类和接口;

o 什么时候读取配置,定义一个配置的静态结构,添加配置读取的接口;

o 要用到哪些消息,怎么处理这些消息;

o 消息处理的接口里面做哪些判断,错误和正确如何处理……


每次听同事讲解功能,心里暗想,和我想的差不多……,需求、数据和逻辑策划都给了,大家的思路肯定差不多。

但真正读代码的时候,原来有这么多的不同:

o 别人写配置的结构体和你不一样吧?

o 别人使用STL的习惯和你不一样吧?

o 别人消息处理的时候验证条件使用的局部变量习惯和你不一样吧?

o 别人写for和switch的习惯和你不一样吧?

o 原来代码还可以这样写,为什么不是那样写呢?

我做重读代码的时候,对比发现了很多别人比我用的好的地方,不是我用的有问题,而是换一个方式之后,别人用的更简单,更好理解了。

估计没有人不讨厌过于形式化的东西,但每个人心中所谓的形式化是有度的,同样的一个东西,不同的人来做,有可能你就是应付成形式化的东西,而他从中体会到了很多。本来可以提升团队能力和效率的一个东西,到头来变的形式化,我很失望。

我以前认为,把自己的代码写好了就够了,别人代码写成什么样子,我也管不了。

后来需要经常用别人的模块,一个接口一个接口的跟进去,跟到最后发现自己快晕了,好不容易走出来,忘了自己该干什么了。

这时候,就想如果有个文档该多好。

后来要求大家写一些文档,可是每个人写文档的风格和自己完全不一样,一点不比直接读代码快,然后就做了一个格式规范的设计文档,这样每个模块功能不同,但文档的描述顺序统一了,想看哪一部分,了如指掌。

可能有人觉得奇怪,在开源项目里,没有人参与管理,大家做的很好,放在一个现实中的团队里,反而做不好。

开源项目没有人管理,是因为他们很容易做到自我管理,所有的规范是约定俗成的。你自愿加入一个项目,就意味着你认同并服从这个项目的开发模式和细节实现,这是游戏规则。

而进入一个公司,并不总是因为这个项目吸引了你,当然我们希望这个项目可以吸引你。

统一规范不是为了约束,而是为了效率,没有人希望每天在几个系统、几个工具之间换来换去。不是因为它们差,而是因为他们太多不同。

我们很在意自己的代码别人怎么去评判,显然不是你好我好大家好,这一点大家心里都明白,看看别人在重读文档里是怎么评价的吧。

如果放在其他环境里,你写的代码什么样,花钱谁给你看呢?

现在有些年轻人的心态比较浮躁,大致总结以下『四点表现』:

1. 眼高过顶;

2. 垂手过膝;

3. 期望值高;

4. 积极性低。

深层次的客观原因大致是『四个没有』:

1. 没有吃过苦;

2. 没有干过活;

3. 没有说过话;

4. 没有当过家。

一般都具有『四个特征』:

1. 独生子女;

2. 毕业新人;

3. 沉默寡言;

4. 半瓶开水。

———————————

1. 你想要什么?

参考:一个有影响力的人。(@李开复

2. 那是否是你想要的?

参考:你的眼光有多远,决定了你能走多远。(@Fox

3. 你需要做什么?

参考:高筑墙,广积粮,缓称王。(朱元璋)

4. 你还需要做什么?

参考:平和的心态,进取的态度,坚定的目标,不懈的努力。(@Fox

5. 你是否做到了?

参考:没有,但我一直在努力。(@Fox

脑子里一直藏着一个问题:我想要一条什么样的路?

我曾经生活在一个信息闭塞的环境中:离家求学之前,我生活了十八年的家乡虽说不上什么穷山恶水,但也相去无多。小时候家里没有电视可以看,没有很多书可以读,父母一个初中肄业,一个连自己的名字都不会写。

但仔细想来,那时周围一些环境似乎是对我产生了极重要的影响:

1. 五岁之前,父亲早过幼儿园教我识字数数,甚至还很是买了几本画书(时不时想起来竟似乎可以记得书上的大多内容)。没有父亲的启蒙,我应该接了他的班,守着自己的丑妻近地热炕头,孩子应该都会喊爷爷,也会替他爹买烟打酒,帮他娘买盐打酱油了吧;

2. 我有一个一字不识的奶奶,她却能分辨写字的好坏,告诉我先能写一手小字以后写大字才好看,于是我就努力去用中毫写铅笔粗细的小楷,一次次让她看是否中意。放在现在我是断不会相信她的,因为我不觉得这当中真是有必然的因果。但我今天的确没有写一手太丑的字;

3. 我有一个善于作画的小学老师,他是省里都知名的民间艺人(如果不能称『家』的话)。我闲暇时也会自己画画,以致在初中的时候被班主任发现我的『才艺』,学画两年,荒废了学业。我其实挺记恨这位初中班主任的,如果不是他,我或许不用多读一个初三才升入高中。他为了能有个好的升学率,以我为赌(这所初中,一年也没有几个可以升入高中或中专的,学音体美说不定还有一线希望),所幸,我并没有学成,我直到现在也不认为我真有作画的禀赋。饶是如此,我还是认为那两年相当于提前踏入了社会,这也算收获吧(虽然得不偿失);

4. 我有一个喜欢评书的姨夫,家人反对我读『闲书』,但我每年寒暑假时都会去他家过,他反是支持我读,《三侠五义》、《小五义》等,都是那时读的,似乎我也只读过那几本小说;

5. 高中时的三位语文老师对我都很是待见,一个理科学生,硬是做了三年的语文课代表。他(她)们都给了我比其他同学读更多书的条件,也给了我很多自信,让我心中的文学梦一直做着。如果不是为了那时刚朦胧的初恋,我是一定会学文科的,而且一定会读中文;

6. 高三的班主任老师是一个颇有几分怪才的『电脑高手』,可以用PPT给我们讲课(当时全校也只有他一个吧,而且他是几年都在全省讲课比赛前几名的),一次考完试之后,他带我们全班在一间教室用投影看《搭错车》,放到最后只听一屋女生哭的稀里哗啦的,我却被那电脑吸引住了。毕竟,对于一个没摸过的乡下孩子,电脑的魅力不是一般的大,因此,我毫不犹豫的把所有报考学校的第一志愿都填了『计算机科学与技术』。

————————————-痛苦的分割线————————————-

一个连历年分数线都看不明白的孩子和他周围一群连清华北大都不知何物的庄稼汉,面对一个不到一本线的差强人意的高考分数时,你不能指望他们能有多么高水平的报考策略,你得接受调剂的现实。当然,对于死要面子的他们,你也不能强求他们再来一年。

一个连电脑开机都不会的毛头小子,面对强大的PPT和电影播放,你得允许他仅仅为了这两点而去追求他的计算机梦想。当然,一旦他知道这一切只要装上几个软件就几乎不用动手也能做到之后,你也不能强求他不会失望甚至绝望。何况,即使他学了C语言,他也不知道那到底会有什么用。

于是,心灰意冷的我决定放弃该专业,深感于信息落后所带来的无知以及无知的可怕,我选择转攻『新闻学』,以期可以振聋发聩,开启民智。

当然,一个连有人点播一下的专业都放弃了的家伙,你不能指望他真能在其它专业的自学上走多么远。

于是,心灰意冷的我决定放弃该专业,深感于信息落后所带来的无知以及无知的可怕,我选择转攻『经济学』,以期可以经世济民,改善民生。

同样,一个连有人点播一下的专业都放弃了的家伙,你还是不能指望他真能在其它专业的自学上走多么远。

就这样,不知不觉,两年过去了。可怜的家伙终于在几次翻墙未果反倒屡撞南墙的情况下带着满身伤疤回到了本该属于他的黯淡的轨迹上……

回头看看,年少时的无知曾经令我义无反顾的我行我素,却也总会无心插柳,开阔了些许眼界。反倒是现在颇有些心得的我畏首畏尾,不知该何去何从,偏偏却自己不争气,任谁也动我不得。

这像极了国内的互联网现状:看上去无所不知,无所不能,实际仅是个固步自封的局域网而已,却偏偏又喜欢卖弄。被别人指责时又浑身都是G点,多说一句话便待翻脸。

————————————-反省的分割线————————————-

其实不妨放低姿态,再学学当年的无知,多些书生气多读书,少点功利心少邀功。

想到这里,忽然觉得文章一开始提的问题里分明的透着焦虑。与其一直停在路边盘算着怎样走最近,不如边走边想。甚至不必在意一时走过的『弯路』。

做程序的大多是年轻人,思维活跃、积极乐观,对进度的评估往往是按照最好情况来做,对困难估计不足,对他人的进度无法预判。

关于项目进度预评估的几个问题:

1. 不能准确评估各模块的时间分配

对模块大小的评估往往只能跟着感觉走,对于相对陌生的需求,直观的感觉多半是错觉,这里面有个8020定律,而我们通常是根据功能按比例分配,最终容易陷入进度失控的泥潭。

单就编码而言,往往前面的80%的工作只应该花掉20%的时间,因为你无法保证在后面80%的时间里面不再回头修改之前的代码。因此,在评估时应尽力缩短前期设计和编码的时间。这绝不是说设计不重要,恰恰相反,设计应投入大量时间,只是要避免纠缠于无谓的设计细节,尤其是那些在后面编码时可能会修改的设计。

尤其是有完美主义和理想主义倾向的coder,记得上次在和Joe谈起来的时候,他提到Soft在这一点上做得很好,拿得起,放得下,不拘泥于一些非关键的细节优化,先保证20%的关键部分的实现。

2. 不能准确评估bug调试的时间花费

我们时常遇到的情况是,本来计划好一天的工作,在完成基本的编码后,发现代码有bug,甚至是前一天、前一周、前一个模块的功能出现bug,而这些显然没有纳入这一天的工作计划中。这种情况越是到项目后期越多,后期的加班也最多,落下的进度也最多。

调试bug是很麻烦的一件事,除了需要良好的设计、扎实的基础、精缜的逻辑、细致的编码外,还需要平和的心态去调整自己。

3. 不能准确评估协作沟通的时间损耗

这种问题出现在多人协作时,大家的工作进度中难免有一个先后依赖在里面,我们连自己的进度都难以掌控,很难要求别人的进度达到我们的预期。

这时除了需要及时有效的沟通之外,还需要能够及时调整自己的开发计划,不要空耗干等。

随便写点要点,没怎么展开说,主要是自我总结。

上午和Soft聊天的时候,他提到团队里面一位成员因为个性突出与其他同事合作出现问题的事情。我也提到自己想从『瞎操心』的民族、民生、民权转向实际点的经济、管理的讨论上来。

本来已经决定从普通员工的角度说一说团队协作的一些问题,不曾想打开GR的时候,Soft已经在Blog上讲了这个话题,我就顺着这个话题说一说。

从游戏研发团队的构成来看,程序似乎是一个比较特殊的组,大家往往感觉程序员都有自己的个性,不易管理,其实,在游戏开发这种比较注重平等、创新的团队中,策划、美术和程序一样有个性。

我们很容易将团队的协作分成两种形式,一种是『联邦共和』、一种是『中央集权』,二者没有一个分明的界限,只是一个度的问题。对于创业的小团队来说,合作的几个成员一般资历相当,私交甚笃,因此在很多问题上更多的是集思广益,即使吵得面红耳赤,也不会偏离了项目的主导方向,说穿了,这样的小团队基本不存在协作的问题,也不存在谁领导谁的问题,因为大家面对的最大的问题不是利益分配,而是危机因应。但这并不能说明这样一个『共和』的团队就不会出现问题,随着项目上市盈利,利益分配成了团队面临的主要问题,这也是导致很多创业团队在中期发展时成员分道扬镳的根本原因。因此,能够共患难的团队未比是优秀的团队。

如果说团队创业时期最大的危机在于财力、人力不足,这些尚且只是客观因素,容易控制。那么在团队发展中期,最大的危机就在于团队动荡,直接表现是团队人员不稳定,主要原因是成员个人心理严重失衡,至于心理失衡的原因看上去会很多,实际上,只有一点:利益,这里的利益无外乎金钱、地位,其他的都可以忽略不计。

关于利益分配,中国有句古话『不患寡而患不均』,这里所谓的『不均』,具体到个人,其实就是『』,没听过有嫌多的。关于多寡,每个人有每个人的衡量标准,这里面最容易出问题的就是应该多得的少得不应该多得的少得

应该多得的少得,是团队领导的问题,一般容易解决。关键是不应该多得的少得,乍一看,觉得似乎没有道理,不应该多得的可不就是应该少得么?问题就在这儿,你认为他应该少得,可是他认为他应该多得,矛盾就出来了。

我的思路是通过沟通协调使其认识到自己的不足,调整自己的心态,接受少得的事实,更重要的是使其建立对团队的认同

绕了半天,说到了团队认同上,对团队的认同包括对团队理念的尊重、对团队成员的支持和对团队决策的执行

对团队理念的尊重是认同的前提,对团队理念没有起码尊重的员工,你很难指望他能够为团队付出心血。

对团队成员的支持是认同的基础,也是团队协作的基础,没有成员间的相互支持,产品的研发无论从进度还是质量上都难以得到保障。

对团队决策的执行是认同的根本,行胜于言,我们做的是产品研发,我们要的是产品收益,我们靠的是产品质量,离开了执行,一切都是纸上谈兵、空中楼阁。执行决策靠的是有效的沟通和扎实的技能。

这里面最容易做却又最难做的是沟通,容易的是言语沟通,难的是坦诚交流。如果一个团队的大多数成员能够做到坦诚交流,问题就会少很多。

从个人而言,坦诚交流本身就因人而异,这里面对团队leader的要求比较高,首先其本人就要做到坦诚,还要求他对成员有一个充分的了解,才能准确的把握到不同成员的不同的利益需求,并根据其能力特点分配恰当的任务,不至于让他有吃不饱的感觉,以免其自以为是、滋生不满不屑的情绪,也不至于让他有吃不消的感觉,以免其自暴自弃、消极蹉跎。

先写这么多吧,信马由缰,写的有些乱了。