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

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

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

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

05-08 15:10