标签：
PlayMaker属于一个可视化的状态机编辑工具，集成到了Unity的IDE里，在Unity的市场上很受欢迎，本人看见后第一感觉是跟CryEngine的那个状态机特别相似。CE的那个状态机编辑器其实是很难用的，研究过的同学纷纷表示事倍功半。从过去的经验上看，这种可视化的状态机编辑器适合于批量的生产，例如，新手引导，每一个功能也许都会有一个新手引导，以前的做法是需要程序员们写一堆的代码。写新手引导，要了解状态机，要了解各种事件的触发机制，对一个新手来说，学习曲线还是有的。如果评估工作量的话，一个中等复杂度的新手引导功能，需要一个熟手两天的时间来完成功能并测试。而如果有好用的工具的话，对一个新手，大概需要1天就够了，这就是工具化所带来的效率提升。看起来很美好，但实际上这种美好需要游戏引擎的整体框架要有良好的分层设计。
关于其他人说的PlayMaker所产生的问题。从playmaker的产出来看应该是一组状态机的代码。但是问题来了，不是说所有的对象都要用状态机去控制。playmaker的状态机都是控制gameobject（这里存疑，也许不是），但其实有的状态控制代码是不控制gameobject的，也许只是逻辑上的关系，例如版本更新，是由网络消息流来驱动的。另外效率问题，playmaker应该是会带来很大量的脚本，那么运行起来会不会出现卡顿等等问题呢？从之前的经验看，卡顿主要是IO，实例化这些，单纯逻辑上的运算不可以产生明显卡顿，否则就需要优化了。其实这个编辑工具只能让程序员来使用，至少在功能稳定前，程序员们要明确知道里面都有什么内容。然后就是可视化状态机所带来的复杂度问题，Playmaker会让你把函数功能极小化，这样会导致非常庞大的功能函数库？当然，如果设计的好，也许能在很大程度上减小这个问题。其实这个也是面向对象的要求嘛，把处理单元尽可能减小。
另外整个游戏的状态机该如何设计？我想的话最好是用PlayMaker把现有的代码进行一次整理，如果用playmaker能完整地完成现有的功能，那么产品化自然就没问题。从之前用状态机的经验来看，务必要把层次梳理清楚，千万不能多层次嵌套，用好命名空间，甚至于每个状态机单元都要有自己的命名空间。
标签：
原文地址：http://www.cnblogs.com/designyourdream/p/4302963.html
