在腳本語言中撰寫 FSM 的相關程式碼真的容易許多！事實上我在《水晶守護者》中，就是利用 Lua 的威力，才能夠很迅速地完成玩家與敵人角色的狀態邏輯。但相對要付出的代價，就是程式碼比較難以維護，稍不留意就很容易會形成一片混亂的狀態。

不同狀態間的組合是個很難處理的問題，一般來說我會利用類似查表的方式來解決，要不然就得實作出階層式的 FSM 才行了。雖然 FSM 很簡單易用，但也不適合用來處理太複雜的條件轉換邏輯哪。

void Game::SetCurrentState(State *state) {
delete mCurrentState;
mCurrentState = state;
}

//遊戲開始時
game.SetCurrentState(new GameInitState(/**/));

如果所有 State 的洐生類別都是 Stateless 的，更可以使用 Singleton，而不需要每次 new/delete:

game.SetCurrentState(GameInitState::Instance());

除非你希望用一個 enum 把各個 state classes 的實作藏起來 (減少編譯期的 coupling?)，才需要 Factory。

對於 AI 方面來說，用腳本會比較有彈性。我覺得如何利用腳本語言的動態能力，是一個值得探討的問題。和靜態語言 C++ 相比，所需的 “Design Pattern” 會很不同。以 State Pattern 為例，動態腳本裡可以在執行期改變一個 function 的內容，例如 charater.Tick = character.Combat，而不用另外設立類別。

State Pattern 用來實現 AI，應該可以當作是 Finite State Machine (FSM) 的一種實現方式。以前想過做一個 Editor 可視化編輯 FSM，不過在實憏的遊戲中，很多時候會遇到一些狀態組合的問題，例如上半身和下半身的動作狀態是分開的，又或加入其他屬性(痲痺、中毒、祝福…)，單個 FSM 往往很難處理。到最後，好像還是看情況用不同的編程方式處理比較可行。

//遊戲開始時
m_CurrentState = StateFactory::create(StateFactory::GameInitState);

//遊戲主選單
m_CurrentState = StateFactory::create(StateFactory::GameMenuState);

個人猜想這個判斷應該是無法避免的？

謝謝你幫忙補充，我是半路不是猴子大～ XD

@Rich:
之前我也有使用過以 Command 範式實作出來的網路協定機制，真的能夠省下很多不必要的 switch-case 程式碼累贅，也可以讓剛接觸網路系統的程式設計者，更容易理解系統的整體流程與架構。五、六千行的 switch-case + if-else……真是太要命啦～ 囧rz

在 < 和 > 之間的字被吃掉了，我猜你應該是想指《重構——改善既有程式的設計》這本書吧？ XD

@jbyu:
Strategy 和 State 範式，也可以和 Factory Method 範式一起混搭使用，效果會更好！

謝謝你的文章～

@zii:
如果沒有虛擬函式存在，C++ 語言就等同於廢掉了一半武功。所以即使需要付出一些代價，我們還是得瞭解怎麼合理運用虛擬與多型機制才行哪。

@gino:
對於已經用習慣的人來說，會覺得使用 Strategy 和 State 範式是很自然的事情。可是對其他比較不熟悉設計模式的人來說，常常不能理解為什麼我們要這樣做啊。 XD

@Wxy:
在遊戲的程式系統中，Observer 也是個超級實用的好傢伙！（是不是該介紹它出場哩？）

我也同意幾乎可以不用操心存取 vtable 的花費這樣的看法，但我發現對於很多從 ASM 與 C 語言時代走來的人而言，很難說服他們接受「以微小效能影響換取大幅程式碼可讀性」的觀念。

我在上個週末已經買了《The Art of Game Design》。目前找不到合適的詞彙來形容內心的激動與衝擊，正在享受沈浸於這本書中的樂趣，Having new eyes！

@zii:
沒錯！你所提出的函式指標作法，就是從前在 C 語言的環境下經常會使用的一種技巧。然而函式指標有個小缺陷，在於它無法保證提供型別安全的約束力。所以在 C# 以及其他比較新穎的程式語言中，就會提供像是 delegate 這類程式語法，以進一步改善函式指標的問題。

@路人甲:
是的，這篇文章所要傳達的訊息，並不是要叫大家把所有的 switch-case 敘述句都換成 Strategy 範式，只是想提醒我們自己，在工具箱裡除了殺雞小刀可以使用之外，別忘了還有青龍偃月刀可以幫助我們。

我有稍微涉獵過 OGRE 引擎的設計模式，也很喜歡它在許多面向中的架構設計，詳細內容請見這篇文章。

@vamper:
先畫出 Use Case 是個好習慣～ 如果在撰寫程式碼之前，每次都能先從 User 端的角度出發設想，那麼要選擇哪一把工具就會不是太困難的問題了。

非常感謝以上各位的寶貴意見與迴響。 ：）

殺雞用牛刀只是浪費開發成本；當牛刀一出便殺個片甲不流。

typedef int (*loopfunc) (double);

int g_state = 0;

int state_init (double dtime) {}
int state_ingame (double dtime) {}
int state_end (double dtime) {}

loopfunc g_statepool[] = {state_init, state_ingame, state_end};

int gameloop (double dtime)
{
g_statepool[g_state] (dtime);
}