这个系列写到这里，主要关注的2点在于。
1. 到底是call好还是cast好
2. 到底怎么测试更简单
现在发现前面的想法坚持不下来，让我觉得不舒服。
1. call 还是比较适用于阻塞期间无需及时处理其他消息的用法，这不适合多人游戏。
之前为什么纠结于这个问题，实际上是希望利用call的有返回方便测试。
但后面在进程端的测试其实很少，也就是说没有增益。
具体是否合适，只有在项目里检验才知道。
2. 之前说游戏逻辑可以在数据结构上测，这种说法没什么问题。
但又产生新的问题：
2.1 进程才是erlang建模的世界观，是系统的API，而不是数据结构。
数据结构测试完整逻辑，不能保证进程关于数据结构的使用是正确的。
从API的观点看，进程是必须要测试的。
2.2 把业务逻辑放到数据结构， 实际上使得数据结构模块臃肿了。
上个流产的项目我是按照这个思路去做的，不确定写这个系列时，为什么会去探索别的方案。
最大的可能是当时进程测试太啰嗦，却没有去简化进程测试，而想着改变测试位置。
现在想到进程测试同样可以简化， 直接把数据置为指定状态，然后再起进程，不就得了。
接下来，会按照这个思路，先把代码和测试调整过来吧。。。。郁闷