本书有三让我比较秃的形，第一是我觉得读者老爷们可能会不太喜的容，所以加速推过去，结果遭到群嘲，读者老爷们还迎。

    第二是我觉得还不错的容，结果遭到集抵制。

    第三就是类似这一段的节，我知比较枯燥，阅读验也确实差了，但是不得不写，因为本书的追求中有很大一类是在现有的技术和社会资源的条件面空想一些尚且于空缺的模式。比如《无昏君》的pvp战斗模式。

    读者老爷们可能觉我了一章，但是这容实际上非常费劲，比开车费劲多了，写起来很慢。我看到还有人说写游戏写这么细是冲字数，我靠这个冲字数我得亏死……最适合我冲字数的是商业模式上的探索，以及如何，那个写起来贼快……

    因为，我自己需要反复推演许多次游戏的实现逻辑，然后确认这样的机制是程序猿们可以来的，可以实现为产品。关键在于效果是怎么样的，要思想实验。实际开发过程中很多效果是程序猿足额策划案上的需求的，但是效果来完全不一样，因为有很多地方游戏设计师没想到，但程序是冰冷的，任何设计模型上的缺陷都会现来。

    就以我写的这个理碰撞距离来说，其实发来的并不完整，已经删掉了更枯燥的逻辑论证过程，即对战双方都要先定义3状态，攻击、待机、防御，势必不能现一方正在被胖揍突然转为攻击状态。然后，a方开始攻时b方同时检定是否于待机状态，如是则双方同时移动状态，移动方向呈a到b的方向上一个随机角度，相对距离不变，b防御。

    a攻击结束之后b反攻，这样才会现满屏游走双方激烈对战的视觉表现。这些都写来就成论文了，实际上我已经删减了大分。而且还要从开发者的角度考虑取舍，不能光从作者角度考虑。比如这个机制就舍弃了同归于尽的姿势，不能双方同时攻。从开发者的角度，第一个上线版本的开发肯定是以稳为主，在功能的可玩和上线时间中平衡。

    所以即使可以加同归于尽的机制，比如通过防御者血量判断斩杀线，斩杀线走特殊机制；或者仅为追求一个终战状态的视觉效果，双方同时招攻击比较华丽，有气势。但是从功能合理上，这个实现的逻辑就变得超复杂，因此一般开发者除了玻璃渣那有权利无限票的，都不敢这么。宁可先开发一个稳定可玩的版本，上线之后再慢慢迭代产品。

    否则，以极差的价比把这个非常端的功能来，表现确实很好，但是上线之后扑街了，功夫都白费。关键是扑街可能是其它因素造成的，甚至是运营发行的因素，这个功能无可挑剔，死于非战之罪。有经验的开发者都要平衡开发成本和风险，无论公司有多土豪。

    这些思考都是不能写到书里的，因为真是说明文。

    所以这个第三条才是我最纠结的，完全不写吧，本书的阅读确实是增加了，但是也就和别人的文没啥区别了，只有趣味但没有智慧。写多了吧，肯定挨骂。