上周因为和菠萝分工问题，试着介入解决了下角色运动的调试。结果一发不可收拾。导致连续一周都没有推进项目和设计的进展。也缺了博客的更新。
总之悬崖勒马，今天好好反省了下。以8.1为单位结束这个Sprint。明天尽快回到更快的迭代和重设计的开发周期上。
这个Sprint的制作重点：
- 主要针对旅程和末世地面的Traversal体验来制作原型。目前还在持续迭代原型关卡中。
- 配合制作了2d原型来抛出设计问题。
- 在3d原型环境中反而引出了一些比较雪地深度，空间规划等挑战设计思路。
这周和菠萝散乱地主要处理了各种技术和管线方面的事情。主要有：
- 菠萝开始使用houdini配合制作资源， 现在测试关卡里的桥就是houdini做的，方便快速重构关卡。
- 本来打算用可破坏打断桥的两端，不过试了下还是难于满足当前的迭代和控制需求。明天转会blender用布尔运算先处理更快一些。
- 碰上根据美学和游戏设计需求需要重组关卡地形的问题， 逐渐转用Terrain Composer2的Stamp管线辅助迭代修改，而不使用更编程向的Map Magic。
Ootii +Mecanim VS Motion Matching技术的选择评估
- 一开始使用ootii的运动系统做原型， Ootii是unity上比较主流的运动解决方案，但是过于复杂和冗余的代码和系统框架给调试带来了巨大的麻烦，特别是在要调整某个动画细节效果的时候，需要彻底理解和排查代码才能定位到导致出问题的点。
- 整体来说ootii基本是上个时代的高层运动系统方案的较为完善构架，比较统一地处理了旧时代常见的动画状态机+混合树系统的常见结构组织问题。不过这种蜘蛛网式的动画技术已经逐渐难于满足当代的大量动捕动画和独立开发者人少难于。
- 过去10年在商业项目制作中我们已经被动画图坑了不知道多少次了，所以现在开始逐渐转用Ubi和The Last Of 2 中使用的Motion Matching技术解决运动数据组织和各种动画对位问题。
- Unity的Kinematica遥遥无期，菠萝早先的Motion Filed实现在落地上没有Motion Matching技术扎实。在最近经过了数周的评估后，最后决定花75刀购入了Motion Matching For Unity的Solution。这个基础方案有着相当高的产品级管线，进一步可以发现开发者明显是常年混迹于游戏动画技术领域的老兵，在管线上针对上个时代的旧动画技术做了彻底的处理。
- 在初步的使用和熟悉后，可以进一步确定是适合当前我们项目需求的Solution，按照早先unity的新技术发布来看，Kinematica在发布时决定难于满足产品级应用需求，所以果断决定采用Motion Matching For Unity中间件。
- 如果说有什么缺点的话，就是相对的需要花不少功夫封装出自己的上层运动系统，对缺少TA和程序的团队在调教这种新技术的习性上可能得花不少功夫。目前还在Beta版，在价格和未来是否能够有长期的支持还是未知数。
- 所以我们的解决是逐步替代当前用来原型的ootii的系统。既然买了代码，如果有必要之后自己做后续维护和魔改。
一些结论和反省：
- Houdini熟悉程度还不够，在使用的时候比较像编程工作，在快速迭代的时候还是不如blender快和方便。为了尽快恢复早先的快速开发模式，接下来还是以blender为主要手段。houdini更多有进一步的生成组织思路的逐步配合制作。
- 接下来需要进一步保证每天我们在设计工作上的投入。当前项目设计问题严重程度远远高于其他问题，不能因为管线和技术工作阻碍设计问题的解决。