系統架構

整個通用棋譜編輯系統開發平台是建構在 J2SE[15]之上（如圖 3-1），提供完整棋譜編輯系統相關功能 API 來供各個遊戲使用。凡符 合我們內部所遵循的通用遊戲模式的遊戲，都能夠透過我們的平台來 開發棋譜編輯系統。遊戲設計者必須負責遊戲相關部分的設定和實作

（即 Game-specific 的部分），有關這部分的內容，將在下一章中以實 例說明。

圖 3-1、遊戲的階層架構圖

通用棋譜編輯系統開發平台的系統架構如圖 3-2：

圖 3-2、通用棋譜編輯系統開發平台的系統架構圖

各種格式的棋譜檔案透過 Reader 讀入並轉換成 GAML[3]架構的 DOM[16] Tree，之後再透過 Builder 機制使得這棵 DOM Tree 的資訊 能夠完整對應於內部的遊戲模式，最後進入編輯階段。在編輯階段 中，使用者可以對這些資料作任意的修改與瀏覽。輸出時，先透過 Filter 將不必要寫在棋譜中的資訊濾除，最後透過 Writer 將棋譜資料 依指定的格式輸出。以下針對各個部分做詳細的介紹：

3.1.1 Reader 和 Writer

在系統中，Reader 負責棋譜檔案的讀取與分析，不同格式的棋譜 檔案使用不同的 Reader 來處理。系統目前支援 GAML 與 SGF[12]這 兩種格式的 Reader，日後如需支援其他種棋譜格式，需要自行繼承 Reader 類別（如圖 3-3）。

圖 3-3、Reader

不同的格式的棋譜檔案在透過 Reader 之後，都會轉換成相同 GAML 架構的 DOM Tree，我們稱之為外部紀錄表述（External History Representation）。

與 Reader 功能相對應的 Writer 負責將 DOM Tree 輸出成為指定的 棋譜格式檔案，目前系統亦支援有 GAML 與 SGF 這兩種格式的 Writer，同樣地，日後如需支援其他種棋譜格式，需要自行繼承 Writer 類別（如圖 3-4）。

圖 3-4、Writer

3.1.2 外部紀錄表述

如上一小節所述，外部紀錄表述為 GAML 架構的 DOM Tree，完 全對應於原始的棋譜檔案內容。一般而言，在將檔案讀入使其成為內 部資料結構後，理應可以直接使用這些資料，不需額外的處理。但是，

因為棋譜中記錄的資訊，並不完全遵循我們平台內部的遊戲模式架 構，因此我們必須再透過下一小節中將會詳述的 Builder 機制將資料 再做處理。最明顯的例子是棋類遊戲中吃子的部分，例如圖 3-5 中兵 向前一步將卒吃掉的一手：

圖 3-5、象棋中「兵吃卒」示意圖

在棋譜當中，對於這一手只會記錄「兵前進一步」這個動作，但 在我們的內部 SPOT 模式中，這一手包含兩個動作（見圖 3-6），一是

「卒」從棋盤上移開，另一動作是「兵」在棋盤上前進一步：

圖 3-6、SPOT 模式中「兵吃卒」示意圖

在一般的棋譜當中，並不需要記錄吃子的部分，因為這部分的資 訊可以透過棋規判斷得知；然而如果不將吃子的動作記錄在內部資料 中，那麼內部平台在處理的時候，就會依據我們所遵循的遊戲模式而 認為那個棋子仍然在棋盤上，而導致嚴重的錯誤。

3.1.3 Builder 和 Filter

如上節所述，我們需要 Builder 與 Filter 的機制來處理棋譜記錄與 內部記錄的差異：透過 Builder 將棋譜中遺失的部分，重新建立回來；

透過 Filter 將不需要記錄在棋譜中的部分濾除。很顯然的，平台本身 並沒有辦法為所有遊戲決定有哪些資訊是屬於棋譜中不需要記錄但 是內部資料需要的部分，因此，Builder 和 Filter 的機制必須交由各個 遊戲自行處理。有關於這部分的實作方式，請參見下一章中的實例。

3.1.4 內部資料表述

外部資料表述透過 Builder 重新建立出完整記錄後，這一份完整

對應於平台內部遊戲模式的資料，仍然是一棵 GAML 架構的 DOM Tree，我們稱之為「內部資料表述（Internal history representation）」。 內部資料表述與外部資料表述之間的差異，便在於 Builder 重新建立 使用者介面模組（GUI Module）。核心資料模組負責棋譜資料的處理，

包含所有資料的編輯以及內部資料狀態的記錄等部分；使用者介面模

Board、Reader 和 Writer。其中 Reader 和 Writer 對應於上一節系統架