bookmark_borderUnity学习-01

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

这次重学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啦= =。

bookmark_borderMoba系列-01-目标太大,细分一下

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

 

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

 

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

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

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

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

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

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

 

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

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

bookmark_border发出了我在github上的第一个pull request

最近搞了很多简易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,所以也没什么新鲜感了。

bookmark_border新坑,(移动端?)MOBA游戏探索!挖坑的不嫌坑多,多线并进保护研究热情!

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

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

所以我要挖新坑,哼哼。

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

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

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

bookmark_borderL2tp over ipsec系列-02-前置知识太多了,会损耗学习热情

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

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

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

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

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

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

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

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

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