我眼中的游戏开发

 不知不觉进入游戏开发行业已11个年头,期间经常会有些非圈内的朋友和一些想进入游戏行业的小朋友与我交流,希望多了解一些游戏行业的东西,想想索性写点什么,那就讲两个故事吧。


01 打造王冠的故事


一个天才设计师想到了一个精妙的创意,并由此设计了一份图纸(策划案),然后召集了一众工匠(游戏开发团队)照着这份图纸开始打造(开发),并在打造过程中不断调整起先一些可能不合理的设计点,不断打磨穿戴(游戏)体验,最终做出一个璀璨的王冠(游戏成品)。设计师将它的作品送往首都参加评比(游戏上线),最终被慧眼识珠的评委们选中作为国王的礼物,设计者们名利双收。

这个故事很美好,大家都爱听,但摸了摸头上的包,我再继续讲另外一个故事。

02 沙漠绿洲的探险家


冒险旅途开始

一个沙漠探险家(看见了/估算出/梦见了)在沙漠的某个地方有着令人神往的绿洲,于是他(说服其他人相信他/雇佣一批人)组成了一支探险队。在准备好充足的装备物资后,开始朝着心中的目标前进。

在这一路上探险家首先得不断沿途规划路线,除了保证能正确的找到通往目的地的道路,还得应对沙漠中恶劣的环境,如无处不在的流沙(让团队内部陷入无止尽纠结的争吵),遮天蔽日的沙尘暴(来自外部不必要的嘈杂干扰),持续干旱导致的缺水(团队士气的低落),可能还有队伍内部二五仔的跑路甚至叛变,以及最重要的———验证绿洲是否真的存在(也许只是沙漠蜃楼),以便及时改变目标,甚至直接原路返回,因为有时及时止损也是正确的策略。

事实证明,所有出发的探险队能最终抵制者恐怕十之无一。非常幸运,这支队伍居然真的找到了地图上未知的绿洲,然而这个绿洲的水源是否足够大到能撑起这个探险队在此驻扎呢?如果不够那就只能赶紧准备准备,开始下次探险了。

假设绿洲的水源足够多,探险家的目的就此达到了么?不,还要检测水源是否优质,标准就在于人们是否接受,于是如何将水送到他们的手中就成了接下来的任务。

如何送达?

这个时候,探险家可以选择插块大牌子,等待路过的人自己来主动品尝,如果运气不错遇到了吟游诗人(编辑推荐),他们将这片地方写入诗歌传唱还会吸引来许多来体验的客人。也可以选择与已在这片大陆上大量铺设管道的组织合作,架设新的管道直达千家万户,但需要付出为此源源不断的按报酬比例支付管道费用的代价,最夸张的甚至能分走90%(分发渠道)。还可以选择数不清的代理商人,由他们负责将水源送往各地,同样也要分走一大笔费用(合作发行)。最近还可以选择先进的无人机送货,精准送达,按照人头收费(广告买量)。最终这片水源是否能够成为一片合格的新绿洲给人们供水,就要看最终人们对这个水的评价了(数据说话,用脚投票)。

倘若运气不错,这里的水为人们所接受了,而且刨除掉运输费用还有一定结余,那是不是接下来就是高枕无忧了呢?Naive!

蠢蠢欲动的跟随者们

在这片沙漠上,不光有具备冒险精神的探险家,还有很多的机会主义者,他们四处打听哪里发现了新水源,然后立马沿着探险者足迹前往新的水源去分一杯羹。更有一些沙漠大佬,直接会组织一支庞大军队,带着抽水泵开着卡车就过去了。

刚到达水源的探险者能做的就是:1. 尽量构筑防御工事(用户壁垒)让机会主义者无法轻易进入;2. 加快汲取水源效率,并将其转化为更多的物资,使自己的力量更加强大,来应对更加难对付的其他沙漠大佬的钢铁式入侵,毕竟能对抗魔法的只有魔法!至于怎么汲取,这是另一个话题了,可以再开一篇。

无孔不入的“污水处理专家”

即使第一时间阻止了大部分跟随者们的侵入,也不是自此就高枕无忧。如果不小心被一些“污水处理专家”偷偷混入此地,往里疯狂倒入污水垃圾,防护不当最终所有水变污水,一般人便再也无法直接汲取水源了,他们再用自己擅长的污水处理技术独自享用,最终逼迫所有正常人离开这里寻找新的水源。

勇士变恶龙

倘若足够厉害以及幸运,这处水源最终被守住了。后来者基本已无法构成威胁,那么最后一个问题来了,水源终究有限,总有开采完的一天,但是队伍却越变越大,如何寻找新的水源?你可以选择轻装上阵,化整为零,重新开始新的旅程。但人性总是懒惰的,能躺着就不会坐着,更多的人会选择摊开地图,选择合适自己开采模式的的新发现的水源,组织现有军队带着抽水泵和卡车直接就过去了,又一个新的沙漠大佬诞生了……


故事讲完了,至于哪个是我眼中的游戏开发?我也不知道。

一个关于luasocket使用的很蠢的问题

今天遇到了一个问题,服务端给客户端发包,偶尔会出现客户端无法解析的情况。我们服务端采用的skynet,客户端使用的是luasocket,协议采用的sproto。

照例首先不怀疑库的问题,肯定是自己的原因,而且应该是比较蠢的问题。首先问题出现在某一个协议上,这个协议每次发出去,客户端都无法解析,然而从proto文件里无法看出任何差别,也尝试修改了其他几个协议来尝试,并没有发现使其必现的规律,折腾了半天。最后只好动用VS,单步调试,内存跟踪,最终发现一个问题,服务端发出的包内容和客户端收到后拿给sproto解析的包内容不一致!
继续阅读

cocos2d-x的锚点与坐标

最近被cocos2d-x的坐标问题绕晕了头,这里整理下。

position: 每个node都有一个position,这个position是相对于它的父节点的坐标,所谓的世界坐标可以认为就是直接挂载在scene下的node的坐标。
AnchorPoint:每个node都会有自己的AnchorPoint,它的作用仅在于在设置position时,是将图片中的哪个点设置到那个位置。

需要注意的是
1 position是逻辑位置,而不是实际像素
2 这个坐标系与windows的坐标系的y轴是反的,cocos2d里(0,0)是在左下角,而不是左上角。
3 每个node的position都是相对父节点的(0,0)的位置,与父节点的锚点无关!我就是因为这个问题没搞清楚在这里绕晕了……

金山这几年--程序员的信仰(二)

“信仰是指对一个人(同样的对他的能力)、事物、神、宗教的教条或教导、没有经验证据的观点(例如拥有强烈的政治信仰)抱有信心和信任。” 维基百科如是说。

做为一名程序员,在金山的经历也使我拥有了一种编程信仰,我相信通过正确的方式方法可以写出优质没有bug的程序(是真的没有bug,而不是自己的声称)。只有你相信了它,你才有了这种可能去做到。

PS:至今还没有人从Tex的bug悬赏金中大幅获利给了我们这种教徒以极大的曙光。

继续阅读

金山这几年--program in project(一)

不知不觉在金山已经呆了近五年,这段时间里犯过很多错误,同时也学到了很多东西,既然已经离开,那也该为这段时间好好的做个回顾。今天就先来谈谈在编程技术这块吧。

首先声明,我谈到的技术相关的东西都是指在项目中的经验,那些纯粹的追求技术的人和在学术上追求的人,这些东西可能对你们来说毫无意义。 ^_^

继续阅读

算是个小结

        从今年6月开始,项目就进入了一个加班时期,直至现在,整个人都很疲惫。没什么个人时间,唯一的周日休息只想通过玩玩游戏来放松下绷紧的情绪,进度的压力确实很大。

最近的改变:

1. 代码要注重可测试性:以前意识到了测试驱动开发的重要,但是并未意识到代码可测试性的重要,导致经常会发现单元测试代码会非常难写,以前一直认为是由于逻辑过于复杂所致,现在看来是因为在设计时就未考虑可测试性导致的。

2. 写代码一定不能偷懒省事,出来混,迟早是要还的。一个地方可以写成通用的,就宁可再多敲几十行代码把它抽象出来通用化,也不要图省事就这么先写着等以后需要再来改,以后你会发现累积起来后改起来会远比想象中痛苦。

继续阅读

三省吾己

       荀子曰:“君子日三省乎己”。欲为善,故效之。

       其一,执念甚重。但凡与人讨论,偶及争议,虽彼此不苟同,仍因执念争至面红耳赤方罢休耳,终不了了之。道不同不相为谋,谨记。

       其二,老子曰:上善若水,水利万物而不争,处众人之所恶,故几于道。捎遇不顺之事,哀声叹气,恨不得捶胸顿足之势,与水做比,相去甚远。

       其三,言过于行。虽知应作为,奈何多敌不过懒惰二字矣。人言,一屋不扫,何以扫天下,起居凌乱,应以此示之。

写在2011.5.1前的回顾

        明天是五一,1年前的这时候来到西山居,回顾下这一年。

        首先,项目变更,因为以前工作室的解散,我们都被安插到西山居的项目组里头,有幸被分到一个我喜欢的项目组,做自己喜欢的工作是最重要的。

       先说技术上观念上的一些转变:

        1 对于脚本的看法:脚本很多情况下是不可或缺的。以前一直都觉得脚本是一个辅助,可有可无的东西。来这边之后,由于这边大量的运用Lua,在此之前只是了解但没怎么使用过,一直都觉得C++是王道。使用后,深感Lua之灵活,好用,觉得脚本真是个不可或缺的好东西。

         继续阅读

编写系统模块的经验总结

        前段时间在写一个系统模块,由于是第一次独立的写一个系统模块,经验欠缺,出了很多问题。事后对这次工作做了下总结,大概是以下几点:

        1) 做设计时过于乐观,轻视了设计的作用,只看到宏观上的功能,没想到琐碎的细节实现(有可能因为某些小点会影响整体上设计)。

解决办法:设计功能时,先把测试案例想好,测试驱动开发,不一定要真的去写测试代码,但测试用例提前写好可以避免很多问题(临界问题,异常处理问题,理顺思路)

 

        2) 编码过程中,急于看到实际效果,希望做出一个快速原型,为此导致了编码质量下降以及临时代码。

解决办法:如果是底层的函数,尽量避免临时代码,尽可能编写单元测试文件测试效果。

 

        继续阅读

工作一年的总结

     不知不觉参加工作一年多了,对自己一点总结吧。

 

开源


     还记得来公司的第一天,分配给我的任务就是,花1周的时间看CEGUI的源代码,知道CEGUI的内部流程。这也是我第一次接触开源。说实话,当时看那些代码有点看天书的感觉,头皮发麻,看了一周也就大概弄清楚了个大概的GUI渲染流程,内部的东西还是一点没懂。慢慢的随着工作需要,会经常跟的CEGUI的内部去调试,加上熟悉了抽象的编程方式,开始逐步对CEGUI有所了解,并且发现它的代码写的很cool,就是易用性方面做的确实不太好(所谓学院派的通病),但是代码中运用了很多成熟的面向对象技术,所以基本上后来看《设计模式》的时候经常能在里头找到真实使用案例。

      再后来,项目变动的原因,开始想自己写一个工程了,参考了CEGUI的SampleHelper,自己也试着将一些设计模式带入自己的代码,当写出来的时候感觉真的很cool,想着以前看这种代码都很难看懂,现在也出自自己之手,哈哈,一点点程序员小小的虚荣心。重要的是,从这之后,再看开源的东西已经是豁然开朗了,阅读代码能力得到了很大提升,更重要的是我领略了开源的魅力,想到如果以后我也能写出一个能让人觉得好的东西,并愿意来解读我的代码,这种感觉真的很cool,而这也对代码的美观提出了很大的要求,毕竟是要拿出去给别人看的。

 

游戏


     从小到大,我都很喜欢玩游戏,从FC到街机,PS再到PC,再从单机到网游,玩的游戏也是数不胜数,但那是的身份都只是玩家。大学毕业设计时选了手机游戏,那是第一次领略到做游戏的快感,虽然很没有经验,做出来的游戏也仅仅是一个Demo,但这种感觉我却记得,所以找工作那会觉得如果能进入游戏行业真的很美妙的事情,有幸得偿所愿,而且是做为一名程序员。

     进入游戏行业以后,我却很少玩游戏了,不是因为对游戏的兴趣减了,而是发现了比玩游戏更大的乐趣——编写游戏。虽然在现实生活中我们只是普通的程序员,但在游戏里我们是上帝,一切的一切都掌握在我们的手指之下,每一个NPC或者物品的诞生与消亡的规则都是我们制定的,这是个多么美妙的世界啊!

继续阅读