/********************有限狀態機自動機***********************/
狀態圖－－乙個圖的資料結構！
1.while + switch;
2.狀態機：就是指定系統的所有可能的狀態及狀態間跳轉的條件，然後設乙個初始狀態輸入給這台機器，機器就會自動運轉，或最後處於終止狀態，或在某乙個狀態不斷迴圈。
遊戲中狀態切換是很頻繁的。 可能以前要切換狀態就是if~else，或者設標誌，但這些都不太結構化， 如果把它嚴格的設為一種標準的狀態機，會清楚的多。
比如控制一扇門的運動， 初始時門是關的， 當有力作用在門上時，門開始慢慢開啟，力的作用完後，門漸漸停止不動， 當有反向的力時，門又漸漸關上， 知道回到初始關的狀態。 這個你會怎麼來程式設計實現呢。似乎很麻煩， 的確，沒有狀態機的思想時會很煩，設很多標誌，一堆if條件。
用狀態機的話，不只是**更清晰， 關鍵是更符合邏輯和自然規律， 不同狀態不同處理， 滿足條件則跳轉到相關狀態。
偽碼如下：
enum
doorstate = closed; // 初始為關
update()
// 而繪製**幾乎不用怎麼變, 門就是會嚴格按照狀態機的指示去運動， 該停就會停
render()
這是乙個簡單但很典型的例子， 狀態機的應用太多了。
就說乙個基本遊戲的運** （用到了乙個狀態然後還有子狀態）
updategame()
begin;
switch(gamestate)
case 等待選擇選單: //它有三個子狀態。
if (選擇選單項 ＝＝ 開始)
if (選擇選單項 ＝＝ 選項)
gamestate = 設定
if (選擇選單項 ＝＝ 退出)
gamestate = 退出
case 開始：
遊戲執行；
if (使用者按退出鍵)
gamestate = 等待選擇選單 ;
...其他的狀態跳轉處理;
case 退出:
釋放資源；
退出；case 設定:
分別處理不同的選項， 跳轉不同的子狀態；
case .... // 其他狀態的處理
end;
某乙個狀態可以包含更多的子狀態， 這樣最好是同一層次的狀態設為乙個列舉, 並分到另乙個switch處理
如 enum states; state2又包含若干狀態
則再定義enum sub_state2;
想很多基本的渲染效果， 如淡入淡出， 閃爍等等， 用狀態的思想會事半功倍， 思路也更清晰。
其實像opengl, direct3d這樣的渲染引擎本身就是狀態機， 當你設定渲染的狀態， 這台機器就保持這個狀態進行渲染工作，如保持光照位置，保持片元顏色， 直到你再次改變它的狀態。
狀態機的應用實在太廣， 相關理論也很多， 最近上課學的隨機過程裡也講到一些， 數位電路裡的時序邏輯器件也是用狀態機來描述。 這些不必多說了。
總之， 用狀態機的角度去看待問題， 往往能把比較複雜的系統分解為能單獨處理的眾多子狀態， 處理也會得心應手。希望大家多用它， 很好的東西。
個人感覺狀態機的幾個不同實現階段：
1、switch/case 最原始的實現方式,是很多的c程式設計師習慣採用的方式。
2、查詢表[狀態、事件、動作],稍微做了一點改進。有點類似mfc的雛形。
3、在以上基礎上做的一些改進或者變體。
[比如用乙個棧結構，啟用的狀態位於棧頂，自動的對映事件和動作的對應，再或者通過一些巧妙的巨集等手段進行包裝。但是線性結構在實際中使用比較受限、過於技巧性的巨集比較難於理解...]
4、物件導向的設計下、靈活運用模式。如上面給出的鏈結。重用性和靈活性方面都有不錯的表現。沿襲類似的設計思路、根據實際開發內容進行改造後利用
形式語言與自動機 有限狀態機
其需求來自於對語言字串識別的需要，給定字串判定它是否屬於語法g產生的 l g 判斷是否屬於這個集合。句子識別 給定乙個字串，判定是否屬於給定語法g 的語言l g 一般來說，這是個難解的問題，並不是有乙個確定的過程，實際上它涉及到上節講的語法分析有關，給出句子的構造過程，與形式系統中公式的證明類似。對...
有限狀態機的實現
有限狀態機 finite state machine或者finite state automata 是軟體領域中一種重要的工具，很多東西的模型實際上就是有限狀態機。最近看了一些遊戲程式設計ai的材料，感覺遊戲中的ai，第一要說的就是有限狀態機來實現精靈的ai，然後才是a 尋路，其他學術界討論比較多的...
Unity有限狀態機實現
有限狀態機主要是用於狀態之間的切換，狀態之間的切換也可以通過switch case或者if else實現。由於使用二者實現主要是對用使用者擴充套件不是很方便，所以就有了有限狀態機的概念。有限狀態機主要是用於不同的狀態頻繁的切換。那在unity中我們如何定義有限狀態機?其實有限狀態機主要包括三部分，切...