回到前端

文章目录[隐藏]

花了几天时间对“网络游戏”有了些许概念性的了解后,就还是开始攻克前端这个真正摆在眼前的问题了。

插句题外话,前些日子脂评版石头记看完后,这些日子公车途中在看汪曾祺先生的散文。特别是偶得一本说吃的合集,特长,特爽。心得有二。其一,终于意识到散文是什么了,从小一直说散文散文啊,都没想通到底什么是散文,原来这种便是;其二,我真是妄称热爱文学,博客都写得烂如这般,文字洗练还是要下功夫。一名作家,看小说会让你喜欢上他,于是想了解他。故此,散文便是最好的途径了。如汪老一般写到这般“信手拈来无不是”的境界,也就“字如其人”了(搜狗给我打了个信手拈来无不适……我很震惊自己一直理解错了吗?一查发现用“是”是对的,而且这句还真出自脂批)。

前两天状态很不错,一直有点担心是不是打折能量饮料喝多了,后面就“萎了”。至少现在看来并不是。我也不完全信是褪黑素的功劳,但是解决了“贪睡”这个老大难问题,还是挺好的,印证了一句老话:办法总比困难多。

正题

回到前端的问题上。

升了 Unity 2017.2,一是新项目用最新版的习惯(长痛不如短痛),二是有些新功能(比如原生的Tile Map)想试试看情况。

改了下.gitignore。排除了/.vs、Resharper相关路径,还有AssetBundles的导出路径

重新整理了一下Directory,从之前几个项目中,把混乱的“Framework”(自己写的框架,仗着重构namespace方便就先乱起了个名字)切出来,导入插件。

框架和插件选择这两点,等以后稳定下来,肯定需要专门系统的写几篇说明。

然后就是解决了几个问题。首先是AssetBundle,AssetBundle Manager这个插件本身没问题,不过2015年之后在Asset Store上就没更新了。按照我对Unity的理解,这么重要的东西肯定还是在做的,不说别的,就看这几年光官方就出了那么多AssetBundle插件就可能看出官方还是挺重视的,而AssetBundle Manager在这一堆插件中还算是很不错的了。于是Google一下就发现BitBucket上官方有个项目叫AssetBundleDemo,点进去一看果然最近还在更新。Clone下来导入项目一款,嗯不错,Asset Store版本中注释掉的Inspector面板,这个版本是实现了的,应该就是同一个项目的演化版本无疑了,就用它了!

某次还看到了Asset Bundle Browser Tools,Asset Store就有,也是官方出品,看上去比较靠谱,也是果断Github之(比较新),果然,很好用。

接下里的问题就花了几个通宵了,AssetBundle Manager有一些bug和一些兼容性问题,这个好修,修好以后想给提个Pull Request。随后没提真不是我懒,是我一看,好家伙,已经一堆人提过了,官方目前还没管呢。然后呢,这接口是异步的,按照Node.js的经验,异步接口无外乎写成回调和Task(或者Promise,这个我还没完全了解一堆这种名字到底是不是同一个概念的东西,哪天得好好研究研究),对于Task形式的接口,我希望是可以写成

var task = new Task<TResult>(DoSomeJob());
yield return task;
var result = task.Result;

其中,DoSomeJob函数返回值应该是个IEnumerator。

一开始我可犯了难,yield return 一个对象。 这是什么东西?这时才发现原来其实Unity用迭代器实现的这个协程自己理解的还不是那么透彻的。憋了很久算是憋出来了,结果发现嗨,不是和AssetBundle Manager原生接口返回的东西基本一样嘛。那么这个实际上就只是个适配器而已了,充其量可以打两个Log。在使用var的情况下,两种方式的代码甚至可以做到基本无差别。于是……这代码就被我怒删了。

当然……现在后悔了,因为发现其实后续一些框架接口也是要写成异步形式,所以这个类还是有用的,用到了再补回来,知道怎么写了就快了,代码很短,就是个IEnumerator的实现而已。代码后续补上。

研究了AssetBundle Manager与AssetBundle Browser的搭配工作流程,在Editor下和手机上都跑通了,我也困得不行,就拿衣服边上先睡了。

应该淘宝一床被子放公司里。

第二天一早精神依然挺好,继续整框架,发现一个新需求,我必须要让所有逻辑代码在框架启动完毕之后启动。

插播一下,现在框架启动已经是通过[RuntimeInitializeOnLoadMethod]了,真的爽飞。

于是开始改写之前临时写的GameLogic类,开始很顺利,后面发现自己想错了一大堆东西,其实并不可能写成自己想象中优雅的方式,结果还是大改特改,目前算是能跑了,先用着,在自己使用中越来越完善嘛。

这种方式,让服务启动也是使用协程顺序启动成为可能,也算给服务启动时异步加载提供了可行方案(不然脚本肯定比服务先启动的),这个根据需求后期修改。

具体实现依然等稳定了再慢慢写说明……

然后看了新的TileMap,这个很难说,因为我至今还没搞清楚怎么用,所以还是不说了吧,继续研究研究……

所以就去了。