距离不变，B进入防御。
A攻击结束之后B反攻，这样才会出现满屏游走双方激烈对战的视觉表现。这些都写出来就成论文了，实际上我已经删减了大部分。而且还要从开发者的角度考虑取舍，不能光从作者角度考虑。比如这个机制就舍弃了同归于尽的姿势，不能双方同时进攻。从开发者的角度，第一个上线版本的开发肯定是以稳为主，在功能的可玩性和上线时间中做出平衡。
所以即使可以加入同归于尽的机制，比如通过防御者血量判断斩杀线，斩杀线下走特殊机制；或者仅为追求一个终战状态的视觉效果，双方同时出招攻击比较华丽，有气势。但是从功能合理性上，这个实现的逻辑就变得超复杂，因此一般开发者除了玻璃渣那种有权利无限跳票的，都不敢这么干。宁可先开发一个稳定可玩的版本，上线之后再慢慢迭代产品。
否则，以极差的性价比把这个非常高端的功能做出来，表现确实很好，但是上线之后扑街了，功夫都白费。关键是扑街可能是其它因素造成的，甚至是运营发行的因素，这个功能无可挑剔，死于非战之罪。有经验的开发者都要平衡开发成本和风险，无论公司有多土豪。
这些思考都是不能写到书里的，因为真是说明文。
所以这个第三条才是我最纠结的，完全不写吧，本书的阅读性确实是增加了，但是也就和别人的文没啥区别了，只有趣味但没有智慧。写多了吧，肯定挨骂。
比如说技能带来的强制位移和碰撞体积带来的主动位移之间的区别和实现中的冲突处理等等，应该是绝大多数读者老爷们不关心的内容，但是体现了我对于站桩式对砍的鄙视。而且
来自作者君的纠结，说明文应该怎么写(2/3)