重写一次挂机

挂机系统在4月完成了重写，一直没有把思路整理一下写出来。今天浮躁的心稍微有些平静，就写个急就章吧。

缘起

很久很久以前，有个mmoarpg项目。有了一个需求，要在游戏系统内部提供一个挂机功能。然后有程序员实现了功能，当然这个程序员不是我。再后来发现了挂机不少的bug，团队里其他的程序员很负责的打上各种各样的补丁，基本上if覆盖了常见的代码路径分支。没有人去考虑那些路径分支是常规的，还是违和的。因为看上去没有不对的地方，挂机系统就这样沉淀在系统里了，直到下一个项目。

拿来主义大行其道，启动新项目时，原来项目的代码成为指定基础代码。代码继承了下来了，策划的思路却不是一脉相承的。代码并没有起到基础的作用，大量的工作量花费在阅读，修改和调试上。挂机系统不可避免的增加了更多的if，用来满足一个又一个的“特殊情况”，最后全部都是特殊情况，没有正常情况了。

如果我有足够的时间和精力，挂机的代码早就应该重写了，真正促使我重写的原因是，现在很少有人愿意去老老实实阅读遗留系统的代码，完完整整掌握原作者的意图，这个系统的复杂程度直接减少了能维护代码的程序员数量。中间曾经有人重新实现了技能的使用，结果时间复杂度上升了一个量级，且画面表现力不甚理想。

如果再不重写，挂机终将变成一个无人敢涉的雷区。

思路

挂机功能开启，人物会看上去很智能寻路，打怪，拾取。相应的，整个系统的思路就是实现三个状态的切换：

站立到打怪，打怪到站立；站立到拾取，拾取到站立。

在某个时间点，是打怪还是拾取 策划总是会给出取舍标准的。

用有限状态机来实现，这个逻辑不算太难。

难点

难点在于，站立时找到了合适的怪物，因为距离无法攻击需要移动。移动前是站立状态，移动后攻击状态，这样的衔接是一个难点。因为在原来的系统中，挂机的状态切换和人物常规的站立移动状态切换一直绑定在一起，移动完成后常规状态切换到站立，必然造成挂机空间中又回到了站立状态机。

将常规空间和关机空间的状态切换分离，在移动完成的事件里，续上安排好的状态机，这里是挂机空间的攻击状态机，如果没有安排状态机，人物进入常规站立状态。

从站立转到拾取状态也是一样的道理。

另一种思路

是否可以将挂机的驱动放在客户端来做，解放服务器，这样能空出来的cpu能负载更多的玩家。可惜愿意做这个活的客户端我还没有见过。