LostDougeon：一小步、一大步

六周时间，不算长，刨去立项的第一周以及回归测试的最后一周，迷失地牢这款游戏的实际开发时间其实只有短短四周。

虽说这个自定的项目本就是公司给我们实习生自己练手的一个东西，但是麻雀虽小也算是五脏俱全。从最初的第一周至第二周，其实这段时间实际开发的进度很慢，晚上经常都还在和龙之谷那边的策划扯皮，我们一个小组前后端加起来整整六个人，经常在半夜被策划喷的哑口无言…中间开发的过程，说实在的，其实还是蛮顺利的，因为有对标的产品在，很多时候一些特效或者打击手感我们都是照着“元气骑士”去做的，毕竟元气骑士确实是手游中一款非常优秀的类rouglike游戏。

在项目立项的早期，龙之谷那边的项目管理问我们最多的问题就是我们这款游戏和市面上同类型游戏最大的区别是什么，目标用户是什么，那段时间我们组里几个人也思考了很多，有几次甚至因为对游戏机制的理解不同吵了起来，最后我们定下的核心卖点是“联机”（当前市面上联机的rougelike类手游比较少见）

开发了一段时间后（其实就是一周后），在项目中期的时候，龙之谷那边给的意见是我们这款游戏的可玩性不高，游戏体验时间据他们估计只有2-3小时。当时LostDougeon只有PVE一个模式，其中只有每层的BOSS房中的BOSS AI相对是比较好玩的，面对玩家会有很多不同的react，剩余其他的小怪其实都比较憨，近战怪只会憨憨的追人，远程怪也只会憨憨得朝玩家直线放火球，虽然我们的地图以及怪物分布都是通过（罗哥）设计的算法随机生成的，但是这种随机并没有给我们带来更高的可玩性（当时随机生成道具以及道具相关的技能 or BUFF还没有实装）

之后因为各种原因，我们的画的大饼上多了一块PVP（其实当时因为想做的模块比如道具合成，主动道具被动道具分开开发什么什么的，还有一堆奇思妙想，这个PVP的优先级其实非常低），照我们当时想的，PVE开发完成后有时间就做PVP，做不完就直接砍了。

五一后两周的工作强度其实还蛮高的，特别是五一后的第二周，一边当时我们的道具模块中的道具还不够丰富，另一边之前写的代码中的一些bug在系统复杂度提升后开始暴露出来，当时基本就是白天构思新模块，晚上定位bug、改bug不知到几点，虽然比较累，但是过程始终是快乐的，毕竟是自己想做的东西嘛（自己写的bug，哭着通宵也要改完，此处@神の10）

后期改bug加班最多的其实就是我和10了，10加班是因为我们组只有10一个人做服务端，有什么问题都只能他一个人去判，非常辛苦，而我加班就是纯属自己前期设计太天真，要是回到六周前，我一定甩自己一个大嘴巴子，为什么不用定点数？？？？？？？？？？

说来惭愧，自己在组里主要负责寻路模块与碰撞检测模块以及子弹类的设计，这几个东西在开发的前中期其实就已经实装了，但是随着客户端运算压力的提升，一些因为我不合理的设计而产生的问题逐渐暴露出来。

其中问题最大的是寻路模块。

早期在设计寻路模块的时候，因为考虑到我们要做的rouglike的地图（房间啊障碍物啊小怪啊还有道具啊什么的）都是随机生成的，罗哥和辉哥也需要一定时间去设计合理的生成算法，而hh这边又急着对接寻路模块去做Monster AI，我自己就偷了个懒，在测试过不同平台上一次浮点数运算的差别仅有1e-12后，自己便“大胆”的将PVE中非常核心的寻路整个都用浮点数来写了…

当时想的是，一帧的时间里就只有这么点误差，我跑个十分钟都不会出肉眼可见的不同步，根本没问题。现在想想实在是太天真了….

天道好轮回，爽得了一时爽不了一世，在开发后期，因为子弹类型以及道具类型还有怪物类型都多了，在出包测demo的时候，很明显的就出现了小怪寻路不同步的问题。

最开始测出来的时候其实还蛮淡定的，因为之前“背锅”背的太多了，因为所有东西的不同步都有可能是寻路模块以及碰撞检测模块引起的，之前其他组员也怀疑过是寻路的问题，但后来很大一部分被证明是他们的其他部分写出了bug（其中包含最初第二周我碰撞检测中叉积和点积写反了这种沙雕bug….）

因为寻路一直没出什么锅，实际跑起来绕障碍物或是追人的视觉效果都比较好，没有憨憨版Astar生成路线那种很生硬的感觉，我自己对这个魔改版的寻路一直是比较自满的，一直到和hh一起打粗日志FC不同环境下寻路的日志数据…

当时看到数据人都傻了，这和我当初想的完全不一样，每次寻路整个逻辑跑完都会差1e-5，我们的游戏40帧，这样连续跑个几分钟就能有肉眼可见的不同步问题了…

当时我还是觉得我一开始的测的数据只差1e-12是没问题的，于是加班得在寻路中找其他可能引起这个问题的原因，后来倒还真找到了一个。

为了避免寻路时所有怪物都堆到一起，我在寻路模块中引入了repath的概念，简单讲就是调用系统时间每隔100ms再进行一次寻路，这样子实际上差不多就是每隔4帧进行一次寻路，在视觉效果上其实跑起来是比较好的。

但是也就是因为引入了System.Time，因为后期加入了一堆其他的运算模块，在一些性能比较差的手机上跑的时候（就比如BOSS瞬间发射25+的弹幕时），这个System.Time是受到视图层的影响的，这个时候逻辑与试图其实是分离不完全的，一部分逻辑反过来变成视图驱动那种感觉了（可能叫驱动也不好吧，就是视图层对逻辑有影响）

后来将这一块的时间改成我们自己定的帧时间由Net模块收包解包后再通过事件系统Tick，同步问题（看似）一下子就解决了。说实话当时真的是常常的舒了一口气…

后来到了最后一周，突然又出现了不同步的问题，这个怀疑自然又落到了我身上。当时和hh一起联调，测了一整天后来才发现是hh写的事件系统有时候会出现不合理的dispatch问题导致收包顺序不正确，于是乎hh就改了一下午的事件系统，然而事情还没完，改完这里之后人物的位置倒是真的完全同步的，然而怪物寻路还是有问题，排除了因为人物位置引起的寻路target不同步的原因，最后问题还是落到了寻路模块本身上。

究其根本，还是因为浮点数的问题。
全部都是因为自己一开始没有设计合理的验证demo，只是写了个小demo去测浮点数的影响，因为最后运算复杂度和当时验证demo的复杂度根本不是一个数量级，自己之前得出的1e-12的误差实在是太过理想化。

最后为了将模块中的浮点数全部改成定点数，那两天没有两点之前回去的。

总的来说，这款项目立项和开发都挺顺利的，其中尤其要感谢hh，没有hh带我们熟悉ECS架构，整个客户端的开发难度真的很可能就一下子上去了。尽管如此，最后还是因为一些游戏资源版权的原因无法在taptap上线，心里还是蛮遗憾的

不管怎么说，游戏从立项到上线的整个过程自己也是简单的体验了一遍，最后自己也算是做出了一个自己觉得好玩（狗头憨憨）的游戏，其实还是蛮开心的。这一个多月里自己暴露了很多问题，别人身上也很有多需要自己去学习的地方，还是需要继续加油继续成长啊！

Steven（笑）：还没懂，还没懂~

最后贴个github的repo，源码反正都里面了，版权相关的资源我已经全部移除了，不过最下面扔了android和pc打出来的包，想体验的可自取（服务端需自己部署）

LostDungeon