48小时Jam了一个井字棋玩法延伸而成的战棋（类自走棋？）游戏，复习了一下蓝图的Dispacher和Minimax递归算法，但不得不说用蓝图写递归真的是个体力活儿，另外，帕拉贡素材真的是UE快速原型之神！
一些原型实现过程中的技术点和设计点：
- Minimax递归方式实现至少不败的AI，选择困难难度则每次决策均为递归决策，否则将有概率随机选择落子位置，难度越低AI随机选择落子的概率越高。本质上是个决策搜索树，但是在8层深度的搜索时由于要搜索的叶子结点太多，会碰到蓝图循环数量超限，需要在项目设置里把循环数量拉高一个数量级，但是即使如此由于长循环持续运行会短时间内吃掉几乎所有的CPU资源（大概这个原因？），会导致帧渲染更新的卡顿，正式项目里最好还是剪枝优化一下决策树减少循环数量，或者单开一个线程做异步loop，主线程异步获取树搜索结果来实现不影响正常画面渲染，有空可以研究一下，蓝图不知道有没有类似的模块，或者思路不对？。
- 规则拓展：在常规井字棋玩法无人胜出和棋后，将转为自动战斗的战棋模式，后手方由于棋子数量较少，因此将获得战力增益，棋子互相毗邻得越多，则获得的增益越高。
- 在必然和棋的未完局面下，决策方向将从达成三连转变为尽量使己方棋子抱团，以获得更多战力提升，增加决策空间。
- 双方棋子自动战斗，所有棋子被消灭的一方落败；增益参数经过测试调整后，基本可以实现在后手方有意放弃三连，专注于棋子抱团情况下，能够获得更高的获胜概率。但是如果是正式项目中，肯定要自动化测试一下调一下增益计算公式和参数。
- 棋盘格在鼠标选择时及三连成功时自动高亮，通过在post-processing volume actor中添加post-processing material并动态修改棋盘格render custom depth实现。这个方法几乎可以用在所有物体描边类用户提示上，而且可复用实现起来特别快，不知道会不会有额外性能损耗，后续可以研究下。
- 原型过程中用到的两个棋子O_Chess和X_Chess的逻辑大体一致，按理来说应该用类派生写比较合理，但是由于早期做原型时玩法和actor类形式都还没确定，没有考虑太多所以在Jam的过程中还是写成了两个独立的Actor类，结果就是类似代码两边复制写，还得微调一下参数，非常浪费时间而且容易出错。但是反过来，这或许反而可以成为正式项目迭代当中的优势，TD一马当先推进玩法验证的原型，求快求功能实现，然后反过来可以给正式实现提供麻烦规避和优化的思路和经验，算是个很好的例子。