PlayMaker属于一个可视化的状态机编辑工具，集成到了Unity的IDE里，在Unity的市场上很受欢迎，本人看见后第一感觉是跟CryEngine的那个状态机特别相似。CE的那个状态机编辑器其实是很难用的，研究过的同学纷纷表示事倍功半。从过去的经验上看，这种可视化的状态机编辑器适合于批量的生产，而且能让逻辑很清楚，说到底是图形嘛，不然还得再画一篇UML图，如果你梳理过复杂的状态机就会知道，画图能提高并使你的设计思路清晰。从工作量来说，例如，新手引导，每一个功能也许都会有一个新手引导，以前的做法是需要程序员们写一堆的代码。写新手引导，要了解状态机，要了解各种事件的触发机制，对一个新手来说，学习曲线还是有的。如果评估工作量的话，一个中等复杂度的新手引导功能，需要一个熟手两天的时间来完成功能并测试。而如果有好用的工具的话，对一个新手，大概需要1天就够了，这就是工具化所带来的效率提升。看起来很美好，但实际上这种美好需要游戏引擎的整体框架要有良好的分层设计。

　　关于其他人说的PlayMaker所产生的问题。首先， 从playmaker的产出来看应该是一组状态机的代码。那么问题来了，一个是编译的时间问题，你要生成那么多的C#代码，势必要增加编译过程的时间，这个也许可以通过代码分割来解决，但肯定避免不了最后的全部编译时间。另外， 不是说所有的对象都要用状态机去控制。playmaker的状态机都是控制gameobject（这里存疑，也许不是），但其实有的状态控制代码是不控制gameobject的，也许只是逻辑上的关系，例如版本更新，是由网络消息流来驱动的。另外效率问题，playmaker应该是会带来很大量的脚本，那么运行起来会不会出现卡顿等等问题呢？从之前的经验看，卡顿主要是IO，实例化这些，单纯逻辑上的运算不可以产生明显卡顿，否则就需要优化了。其实这个编辑工具只能让程序员来使用，至少在功能稳定前，程序员们要明确知道里面都有什么内容。然后就是可视化状态机所带来的复杂度问题，Playmaker会让你把函数功能极小化，这样会导致非常庞大的功能函数库？当然，如果设计的好，也许能在很大程度上减小这个问题。其实这个也是面向对象的要求嘛，把处理单元尽可能减小。

　　显而易见的结论是什么呢？复杂的系统用PlayMaker来进行原型设计将会非常合适，而如果要关注效率呢，那就要手动写代码。当然如果效率不是问题，其实也可以将我们的Actions封装到一个库里，然后提供给策划们去组装。这对策划就要求很高了，不过程序可以协助来做。复杂的系统，像版本更新流程，AI，UI对话框树（对话框体系），切场景进度条，新手引导，角色状态管理（寻路，打怪等等状态）。

　　另外整个游戏的状态机该如何设计？我想的话最好是用PlayMaker把现有的代码进行一次整理，如果用playmaker能完整地完成现有的功能，那么产品化自然就没问题。从之前用状态机的经验来看，务必要把层次梳理清楚，千万不能多层次嵌套，用好命名空间，甚至于每个状态机单元都要有自己的命名空间。