盗賊の極意

Feed Rss

 进了一家本土手游大厂,技术受到领导认可,被安排专门处理日常开发之外的一些微科研性质的工作,每月加班时间不到10小时。

在据说是页游史上销量之王的项目组担任一个除我之外公司内无人可以胜任的闲职,除了偶尔帮忙调查一些复杂bug以外,大部分时间工作不饱和。

10年前决心进入游戏行业时,我会想到未来自己竟会对现在这种处境感到满足吗?

在专业领域,我最讨厌的处境是“技不如人”。研究生时代在众神之间自卑到焦虑,工作后来到技术水准严重低下的环境中,竟成了佼佼者,开始自满了。

我现在这样进步全靠自学的状态,想必也是大多数人的工作处境——只能在舒适区活动。
那研究生时代被扔进大神堆里比较有助于成长吗?其实也不是,完全不是。现在回忆起来,那是一个完全的惊恐区,我和他人之间的差距大到我完全想象不到要经历怎样的训练才能和他们站在同一高度。留学时代,我增长的最多的是视野的高度,让一直活跃在井底的自己知道,之前给自己设置的最高目标其实是低的可笑。
让我技术增长最多的,是在学习区“活动”的日子。“活动”可以是写代码,可以是读协议,可以是使用工具。

再来比较我现在的处境。我每天都有在工作,所以工作量是有的,但我感觉不到自己有继续在高速成长,因为用的都是已经相对熟练了的技能。
为一个项目修修补补,锻炼的不是我写代码的能力,而是在庞大的项目代码中寻找关键逻辑的能力。在这一年多的时间里,我漫游项目代码,寻找关键逻辑的能力确实得到了锻炼,但渐渐的,我发现我能更快找到问题的症结不是因为我阅读陌生代码的能力增强了,而是因为我更加熟悉现在这个项目的代码了。
这就很悲哀了。毕竟现在的项目总有一天会结束,那么我习得的这些关于这个项目代码结构的知识也将变得毫无价值。注意,漫游项目代码并不让我获得设计类似架构的能力,至少是帮助十分有限。因为我每次都是在寻找框架中某个非常具体的底层逻辑,并不是在很高的抽象层次中统揽全局。

现在我基本可以确定日常的工作内容对我的专业技能提升速度接近为0了,那我要怎么应对呢?

首先,我在工作范围内,寻找新的工作内容。因为我的岗位的特殊性,基本上日常开发外的东西我都可以参与,所以我可以为美工和测试人员开发和改良他们的工具。这个工作有些我已经在做了,有些我已经预约下来了,这是我接下来一段时间最期待的工作内容了。

其次,我真的非常渴望在工作以外的环境中,尝试从0开始搭建整个游戏客户端服务器端包括之后长期运营更新的整套架构设计。
做得好不好,最好的测试时发布给玩家玩,这就需要整个项目有足够高的完成度,也就是说,这个项目需要是一个团队项目。
参与别人的项目也是可以的,不过要找一个技术水平适合我,至少是要在我之上的业余游戏团队,还是很难的。我在qq群贴吧论坛微博上到处寻找过,结果并不乐观。

自己做项目我最担心的是我没有项目管理能力,也就是项目很可能做到一半就坑了。
业余项目中我认识的最有PM能力的是《四叶妹妹》和《即使如此小镇依然转动》等漫画的翻译组织者“三角”。那种有他在项目一定能完成的安心感和从不会责怪讽刺组员,让组内始终保持和谐的领导力让我对他充满了好感。可惜我自己这里八字没一撇,之前在他那里翻译漫画交稿效率也不高,没有足够的说服力拉他来做游戏开发的PM,可惜。(然而我不会放弃的!)

没有PM能力,没有PM,怎么做?
我能想到的一个办法就是先做些小到不需要PM就能做完的小项目,积累对个人项目成功完成的信心,然后逐渐扩大下一个项目的规模。
这是此刻对我来说最具可行性的方案,但,我还有一个小问题,就是眼高手低,不屑于做小游戏(汗)。不过和上面那些做大项目没有PM力没有足够的热情支撑跨日持久的业余开发等问题相比,不屑于做小游戏这个小问题已经容易对付的多了。

就做小游戏吧,从模仿现有小游戏开始。

回想一下自己当年学做j2me小游戏时的劲头吧,一个个小游戏的项目名我可是从0001一路做到了0012呢,大概。
我会被9年前的自己比下去吗?哼,开玩笑。逆风?看我翻给你看!

开个 swift 的系列贴先。

自己的活,经常做到只差一口气了,却对这个活产生了抵触情绪,就是不想做,十分抵触,严重时甚至能激起生理上恶心想吐的感觉。

最开始观察到这种症状是在研究生时代,我虽然非常想搞好研究报答教授,但真的是无论如何都无法开始阅读论文,也不能进行任何和自己的研究课题有关的活动。即使我痛苦的流泪,在地上打滚,却依然不能让身体和大脑按自己的心愿行动。所以我的研究生时代非常的痛苦。

第二次被这个症状伤到,是我加入了大学的游戏社团,担当了其中一个游戏项目唯一的游戏程序员时,在开发的最后阶段,我突然陷入了这种不愿意工作一心想逃避的状态,也是非常的恶劣。结果我害得这个游戏项目拖了5年没有完成。现在主创成员硕士都已经毕业了,我感觉非常的内疚,但依然无法驱动自己去为此工作。

我可以自豪的说,在我专注时,我的学习效率和工作效率都是业界顶级的。但我不得不面对的是事实,能否进入专注状态并不能由我的主观决定。

至今为止,我都借助兴趣带来的专注力来学习和行动。这种借力方式帮助我取得了相当高的成就。但帆船总不能逆风而行。在我的兴趣消失的时候,那种超人般的能力和天赋也会随之消失。

我曾经尝试过压抑兴趣消失时的抵抗状态,强行执行高强度的学习计划——每天背单词12小时以上,结果只坚持了两周,计划就彻底崩溃了,而且之后再也没能重启那个背单词计划。

为了找到适用于我的解除抵抗状态的方法,我回忆了一下过去的几个成功案例。

首先是备考留学考试。当时是每天泡在自习室里看书做题,生活单调但有规律。一旦生活进入规律,那做事就比较容易坚持了。

之后印象比较深的成功案例是硕士毕业论文。当时是截稿日前一天,我连写了31小时的论文,在截稿时间前40分钟提交了我的毕业论文。当时是拖延症遇到截止日期时的效率大爆发状态,所以情况有点不一样。不过仔细回忆一下,我记得当时写论文时头脑进入了一种麻木的状态。可能是熬夜太疲倦了,我平时每分钟会出现3次的各种分心的念头在当时完全没有出现。但这种麻木又不同于完全的大脑疲倦,因为我调用专业知识时完全不受阻碍,思维运转速度正常,只有在分心这方面的活跃程度大幅度下降了。这个可能是拖延遇到截止日期时的特殊反应,不适用于解决平日兴趣消失后的抵触状态。

学生生涯结束以后,我好像就再也没有成功的让自己进入某种规律的枯燥事务中去。不过等等,我其实并不觉得写程序是一件枯燥的事啊,这个抵抗情绪的原因应该不是枯燥这么简单。它似乎没有什么特别的理由,就是有一天,我突然变得很抵触做某件工作,总是很想逃避。
想解决这个问题,我需要一种压抑自己想逃避的心情的能力,或者说方法,某种思考工具。

对这个问题最常见的讨论就是"自控力"了。我也读过几本自控力方面的书,也看了《少有人走的路》,不过想让我开始行动,只是读几本书还是远远不够的。开始行动需要某种契机,要等到某件事激起了我的3分钟热血,然后赶紧趁着这三分钟热血做一个决定,最好是当场就执行了这个决定的一部分,然后一个行动才有可能随之开始。依赖性太强也好自控力太差也好,这就是现在的我。最好的药是最对症的药,而不是理论上最站得住脚的药,道理说再多也无益,要看疗效。

Unity学习-01

06.07.2015, 8 条评论, 未分类, by , 4,516 views.

目标太大,需要学习的基础知识太多,所以分而治之,开了很多不同的系列。

这次重学Unity是为了给Moba系列写客户端用的。

Unity在我的工作领域中也是非常有价值的技能。估计今后的手游开发就是Unity领军,没cocos2dx什么事了。好可惜最初猜错了方向,不过也没真正投入什么,不过是几个练手用的个人项目而已。

回顾一下开各种系列的因果关系,应该是:

 

想研究网络协议 (L2tp系列)

|- 先练习一下网络编程 (Http服务器系列也算是网络编程练习了,不过要用在工作里,所以不公开了)

    |- 先做个Moba网游服务器端的实现,练练手 (Moba系列)

        |- 需要有个客户端,用来调试和服务器端的通信 (Unity系列)

 

刚入社的时候有个Unity研修,其实也学了点。不过当时赶时间,就决定做个2D游戏,也只看了2D编程的部分。

这次的Moba是3D的,所以要重新学3D部分。

从头学一个大分类的话,比起网上零散的教程,我更倾向于看书,更有效率,进度更可控。

这次在亚马逊的kindle商店下了很多教程的试读,最后选了一本交怎么用外部导入的asset的书,里面还捎带手讲了一下怎么做游戏和怎么用Photon做Unity的服务器端!找到这么对口的书,也真是奇遇。

顺便一提,现在国内的亚马逊上的书还是很少有kindle版。日本是10本书里9本有kindle版的话,国内就是10本里只有1本有kindle的比例,甚至更低。

我真的是受地理位置限制,没法看纸质版,有些时候只好去淘宝找人做pdf电子版。但是新书一般没有pdf版,而Unity啊cocos2dx这种版本更新频繁且剧烈的工具,对教程的时效性要求很高。反正最后我买的那本书是日文版的。嘛,配那么多图的技术类书籍,中日英我都ok啦= =。

这次的兴趣点在服务器端,客户端作为调试服务器端的工具,凑活凑活就可以。不过我毕竟没有3D编程经验,这个凑活的难度还是未知,搞不好是隐藏boss呢。

 

// 下面写着写着,突然发现应该同时实现客户端和服务器端,因为逻辑都要以服务器端为主的。所以回来写个注释。应该双线去开发这个原型。

 

【客户端】 有限地图和可移动的英雄角色

『服务器端』 对应的数据管理

『服务器端』 收到角色移动命令后,向所有人发送移动消息

【客户端】 右键发送移动消息。接收到移动命令后移动(应该预测移动?)

【客户端】 小兵,可接收移动命令,强制移动命令(弥补预测错误),血量控制命令,生死控制命令

『服务器端』 小兵的逻辑,接收命令和广播命令

...

 

通信方面准备多向lol学习一下。这里先记录一个相关内容的博客,以后用到了再检索。

https://nelsonslog.wordpress.com/2014/08/07/league-of-legends-game-protocol/

最近搞了很多简易HTTP服务器端,参考了各种代码。

今天在参考nanohttpd写我自己的java版HTTP服务器时,发现nanohttpd的示例程序发出的response接收起来很慢。

研究了一下代码,貌似是因为nanohttpd最近刚刚merge了一个别人写的gzip格式输出的pull request,但没有好好检查,导致返回Content-Encoding是gzip的response时,既没有添加Content-Length,又没有使用chunked Transfer-Encoding,这再加上keep-alive,根本就是断了浏览器感知response长度的一切手段,难怪chrome收他的response这么慢,人家只能傻傻的等你服务器端超时关闭连接了啊。

添加一行代码,在gzip输出时启用chunked格式,响应时间立刻从5s降到37ms。我看这次改动简洁易懂,有实践证据,也有理论支撑,把握挺大的,就鼓起勇气发出了我个人账户的第一个pull request。

这次虽然是第一次用私人账户发pull request,但其实我们公司管理代码就是用github,我在公司里常常要发pull request,所以也没什么新鲜感了。

听说有拖延症的人怕自己完不成任务,所以尽量少接任务,结果完成效率还是不尽如人意。

结构化拖延理论认为,有拖延倾向就更应该多接任务,这样为了逃避任务A而去做任务B,不知不觉就能搞定大部分工作了。

所以我要挖新坑,哼哼。

最近在看很多通信协议的东西,也需要看Unix网络编程。但网络编程这东西,没有个具体的需求的话,我也不知道这么些函数,这些模型都适合什么场景。

为了给自己一个练手的空间,这次准备尝试一下对实时网络通信质量要求非常高的领域——MOBA类游戏。

以往做的游戏都是websocket就能搞定的小玩意儿,一点儿也感觉不到各种网络通信方式之间的性能差别。MOBA类游戏有一个最重要也最容易分辨的质量标准,就是延迟。UDP到底比TCP快多少?怎么能在保证快速响应和在有丢包风险的连接上保证逻辑正确呢?还是实践出真理吧。

学L2tp,要先看PPP,直接看PPP的rfc担心直接看陌生领域的英文文献会晕,所以先找了本网络协议分析的中文教材看了起来。

可这个教材也不是直接教完整的PPP的,只是讲了几页纸,后面就是简介各种协议,稍微详细地讲了TCP/IP。

我想L2tp也是要为上层的IP协议服务的嘛,先看看IP协议总没有坏处。可这些协议哪个都是充满了细节,一起看下来需要相当的时间。

这种一直读纯理论,不能上机实验的学习方法,在大学时代就被验证了是很容易磨灭学习热情的。上次两天20小时读完HTTP协议已经是我的忍耐极限了,读完之后我一口气写了一星期的代码才缓过劲来。

这次的vpn项目难度不小,要做好持久战的准备,不能期待像HTTP一样一口气吃下来。那怎么打持久战呢?就是注意回复能力。用LOL的话讲就是要有回血赖线的能力。

读教材看文档,吸收纯理论知识是混线涨经验,但是会消耗精神力,相当于对线期的损血。那写代码加深理解,稳固住刚刚吸收进来,根基还不牢靠的知识,让我不用每时每刻消耗大量精神力去把他们暂存在脑内存中,就是磕血瓶回血了。

目前我经验涨了一些,但是血线有点低了,现在不能贪线上兵,要先稳一稳,猥琐塔下回回血吧。

好,那接下来的目标就转向实际动手环节吧。

另外除了这个系列以外,我可能还会开一个自己动手写小HTTP Server的项目。目标是写一个纯java的Http代理,初步是先实现接收Http请求的部分。参考nanoHttpd和mongoose项目。

L2TP(RFC2661)上来就说自己是扩展PPP协议(RFC1661)的,我看我还是先看一遍PPP协议吧。

而PPP协议是一个数据链路层协议,比TCP低两层,比IP协议都低一层。用普通的socket编程不能直接修改包头,所以我需要借助于WinPcap和libpcap库来获得对数据链路层的控制能力。

数据链路层啊,难怪比HTTP难懂,搞这东西要和Sniffer一样用WinPcap,这一点就让我觉得很高端了。

这种超级底层的冷门知识,估计对我的游戏开发工作是没有任何帮助的。不过毕竟工程师,拿这种阳春白雪的东西当业余爱好装个B也是好的。继续看吧。

RFC是什么,维基上有解释。按我的理解,就是一些通信、网络方面的协议和规则,有人把讨论后的结果整理成格式统一的文档,大家都遵守这个文档的话,各自做的软件之间就可以交流了。

举例来说,我上个月读了一份RFC2616,是HTTP 1.1协议,也就是我们现在最广泛使用着的一版HTTP协议。里面定义了客户端(浏览器之类)应该以什么格式内容发送请求(HTTP  Request)给服务器端,服务器端根据自己的情况,应该返回什么格式内容的响应(HTTP Response)。

最开始读这份RFC是因为我需要写一个HTTP代理程序,又毫无头绪,需要了解一些相关知识。

其实在读RFC之前,我尝试性地让代理把接收到的所有请求内容一字不差地转发给服务器端,再把从服务器端收到的内容全文转发给客户端,心想这就是标准的端口转发了吧,结果是代理运行起来一卡一卡的,而且卡得很有规律,每10秒可以读取一批请求,然后要卡10秒,才能读取下一批请求。因为对HTTP协议一无所知,所以当撞大运编程失败以后,我就只能老老实实的去看协议了。

在我花了20小时读完别人翻译的中文版RFC2616以后,我发现我爱上了RFC这个东西。

 

首先,RFC是第一手资料,非常有价值。

你想和别人探讨问题,他举出某HTTP教材里的内容,你举出RFC里面的内容,那结果肯定是你的证据说服力更强。毕竟写教材的人也是看完RFC去写的教材,教材已经是第二手知识了。

其次,RFC的格式严谨,而且只有干货没有废话,上来就可以大流量地吸收新知识,读起来很痛快。

我至今读过的技术书籍里,都没有任何一本有RFC这样清晰易懂的内容组织。不过拿一群人整理出来的RFC和一两个人写的技术教材来做比较,也是有点欺负人就是了。

 

读完RFC之后,再去写我的HTTP代理程序就如鱼得水了。因为目的明确,省去了很多摸索和撞大运的时间。

这种感觉就好象在游戏公司,程序员进项目组的第一天就被告知“游戏策划和美术音乐素材已经全部就绪,就等着您去编程了”时那种痛快的感觉。虽然我从来没体验过。

现在我的HTTP代理已经可以正常运转。虽然实现很简单很不守规矩,但并不影响使用。等下周把keep-alive也给实现了,在主要功能方面我就没有遗憾了。

 

关于RFC,HTTP代理这件事完成的很不错,接下来就要去找下一个战场了。

正好hacklu同学有一个需要搭建l2tp配ipsec的vpn的需求,而我又一直无法突破拖延心境去找资料设置这个东西。干脆,我自己试着写一个l2tp配ipsec的服务器端吧!

在公司用了这么久的git,这次拿到github上去试试身手。如果这次也能顺利搞定,那我就考虑定期攻克一个RFC文档了。

 

还是老规矩,先通读相关RFC,再设计和编程。

相关RFC有:

1. RFC2661 《Layer Two Tunneling Protocol "L2TP"》

2. RFC3193 《Securing L2TP using IPsec》

3. RFC2402 《IP Authentication Header》

4. RFC2406 《IP Encapsulating Security Payload (ESP)》

5. RFC791 《INTERNET PROTOCOL》

6. RFC2409 《The Internet Key Exchange (IKE)》

7. RFC1661 《The Point-to-Point Protocol (PPP)》

8. RFC1962 《The PPP Compression Control Protocol (CCP)》

...

卧槽,这个比HTTP代理程序复杂好多啊……依我挖大坑的经验,这种陨石坑我是填不上的。不过难得有一个可以让我学点东西的目标,不试试就放弃,也太可惜了。

hacklu用练字来磨练自己,那我就用啃RFC来磨练自己吧!

还可以趁机写一些RFC阅读笔记当日志,充充数量。毕竟最近几年的日志产量少得我都不好意思了。