今天要分享的部份是規則層的實作，這些是我自己一路摸索過來的經驗、想法，作為知識分享交流，不代表標準答案。

泛用規則系統？

在第三天我曾談到 if-else 的寫法造成開發、維護困難的地方，於是我後面就在構思，能不能做一個方便設計師開發的架構？能不能做出「載入規則」就像載入模組的系統？這樣的想法在我開發遊戲時萌芽，變成我後面想要開發泛用規則系統的原因。

如果成功的話，那對開發者來說會是一件幸福的事。因為遊戲規則寫好的時候，就差不多等於遊戲完成了。通常「遊戲規則」在其他領域可能會被叫做「業務邏輯」、「Business Logic」。我曾經問過我的大學教授，他說最接近這種概念的語言叫做 Prolog ，你只要描述這個抽象世界運作的規則，然後就可以在裡面跑東西了。

克服 if-else 的弱點

if-else 之所以越來越複雜，是因為後面加入的遊戲機制越來越多，原本的判定規則越來越多。如果有A、B、C三條判斷規則，那麼程式就必須三條規則一起檢查。也就是說，有些判定規則是不用檢查的，但因為 if-else 寫死了，它沒辦法隨著遊戲狀態調整。

改善它的方法，是透過「事件監聽」來處理判定。例如：

1. 說場上有「嘲諷」生物時，生物攻擊才需要檢查是否會被其他生物阻擋？
2. 若同時具備「嘲諷」、「潛行」的生物，那麼這種特殊情況就必須要額外處理。
   用優先度的方式緩解不同規則造成的衝突現象。

這樣做的優點是，判定規則變靈活，會根據目前遊戲場面狀態，處理不同的事件判定。
缺點是測試規則的時候，比較不容易發現一些規則組合的漏洞。多種事件造成不一致的結果是，必須要處理規則衝突的問題。

觸發、變化

最早《爐石戰記》出來的時候，我覺得裡面的程式應該可以全部轉成「觸發」的方式運作。像是「戰吼」「死亡之聲」「祕密」…很多很多。

能夠產生「觸發」的事件如下：

1. 生物召喚 > 戰吼
2. 生物遭受攻擊(前) > 祕密
3. 生物已受傷 > 啟動某些生物能力
4. 生物死亡 > 死亡之聲
5. 玩家受到攻擊 > 祕密
6. 玩家發動法術 > 祕密
7. 生物發動攻擊
8. 回合開始
9. 回合結束

「變化」是觸發造成的結果，「變化」會造成遊戲狀態改變。隨著場上的判定規則、事件監聽不同，結果就會不一樣。

實作遇到的一些細節

在規則處理上，大約會著重在幾個部份：

1. 可行性，玩家的操作是否合法？
2. 有效性，玩家的操作是否成功？
3. 其他修正，數值調整 or 對象改變

接下來會分享專案開發的歷程，一樣也是經驗分享。
如果鐵人賽結束之前來得及的話，我會嘗試實作一個簡單的規則系統，給大家參考。明天見！