有限状态机(Finite State Machine或者Finite State Automata)是软件领域中一种重要的工具,很多东西的模型实际上就是有限状态机。
最近看了一些游戏编程AI的材料,感觉游戏中的AI,第一要说的就是有限状态机来实现精灵的AI,然后才是A*寻路,其他学术界讨论比较多的神经网络、模糊控制等问题还不是很热。
FSM的实现方式:
1) switch/case或者if/else
这无意是最直观的方式,使用一堆条件判断,会编程的人都可以做到,对简单小巧的状态机来说最合适,但是毫无疑问,这样的方式比较原始,对庞大的状态机难以维护。
2) 状态表
维护一个二维状态表,横坐标表示当前状态,纵坐标表示输入,表中一个元素存储下一个状态和对应的操作。这一招易于维护,但是运行时间和存储空间的代价较大。
3) 使用State Pattern
使用State Pattern使得代码的维护比switch/case方式稍好,性能上也不会有很多的影响,但是也不是100%完美。不过Robert C. Martin做了两个自动产生FSM代码的工具,for java和for C++各一个,在http://www.objectmentor.com/resources/index上有免费下载,这个工具的输入是纯文本的状态机描述,自动产生符合State Pattern的代码,这样developer的工作只需要维护状态机的文本描述,每必要冒引入bug的风险去维护code。
4) 使用宏定义描述状态机
一般来说,C++编程中应该避免使用#define,但是这主要是因为如果用宏来定义函数的话,很容易产生这样那样的问题,但是巧妙的使用,还是能够产生奇妙的效果。MFC就是使用宏定义来实现大的架构的。
在实现FSM的时候,可以把一些繁琐无比的if/else还有花括号的组合放在宏中,这样,在代码中可以3)中状态机描述文本一样写,通过编译器的预编译处理产生1)一样的效果,我见过产生C代码的宏,如果要产生C++代码,己软MFC可以,那么理论上也是可行的。
前两天刚把自己的程序从if/else更新到state模式,高兴不已,今天无意间看到这些文字。才发现技术,是别人早都玩过的了。
或许是自己做的项目上,很少有这么经典的东西。也或许没有几个可以真正在技术上共同进步的高手。总是看到更多代码里面没有模式,没有清晰的结构,没有良好的管理。
其实个人观点,如果项目不是那么需要用10个以下的if/else也不是什么坏事,至少大家理解都比较方便。
如果你发现代码已经有些混乱,导致修改难以进行,这个时候,就应该进行重构,至于能使用上,上千个状态的,我觉得不是很多吧。毕竟一个程序而言,它的功能和生命期是有限的。
一切都是一个平衡,在代码维护和编写上寻求一个平衡。决定了你使用哪种模式。
进化论准则吧。要不怎么好多企业代码都很烂,但是却好好的占领着市场呢?JAVA不是1.0的时候,也BUG超多?windows1.0不也是被人批为,没前途的公司?
就像一个人技术的发展,如果早就规划好路线,每个人还会不同吗?早就有人研究过这些东西了,而我还是要从设计模式那本书里面,研究代码,用到程序中,等有些时候看看网络某篇文章,才明白其实模式还有更深的东西。记得很早前可能看过,但是由于没有实际的使用经验,所以和这样的技术错过了,或者不太熟悉怎么使用。其实早就在找能自动生成C++代码的东西了。o(∩_∩)o...