本章會將說明，使用結構行為合一的架構導向方法來塑模與非架構導向模型 進行比較，將從多個不同的構面來進行解釋，需要這麼做的主要原因還是因為一 個遊戲軟體的開發階段可以用這些不同的構面來當作專案進度的指標，以這幾個 面向來說明使用非架構導向模型與使用架構導向模型的方法上彼此之間的優劣。
5-1 傳統遊戲規格書模型之說明
在實際參與過的行動遊戲開發的專案中，在遊戲規格書中所使用的模型大多 都是使用流程圖(Flow Charts)搭配圖片與文字及表格來完成遊戲規格書，開發人 員透過流程圖來了解遊戲的流程，然後透過表格來得知數量與項目，最後再從文 字得知指定功能的細節規則。
5-1-1 遊戲規格書開發之方法
整個專案的開始皆由遊戲製作人開始投入，構想遊戲核心與目標市場與對象 之後，便開始展開人力配置、能力分工等作業。
5-1-2 需求討論與訪談
遊戲規格書進行開發之前要進行數次的需求討論與訪談，這個階段通常是主 要的團隊的「遊戲製作人」、「技術顧問」、「視覺顧問」進行討論，由製作人提出 行動遊戲的核心玩法與概念，同時也會討論遊戲風格的走向，討論過程通常都是
90
5-1-3 遊戲規格書製作
遊戲軟體的文件開發通常都是在需求訪談完成之後才開始進行細節的文件 開發，這是因為「遊戲製作人」通常只需要遊戲走向與策略，因此在進行需求討 論與訪談的時候，通常都只會把重要的核心定義下來，接下來會找多位成員負責 不同的功能來撰寫遊戲規格書。
5-1-4 遊戲規格書之遊戲架構規劃
在傳統遊戲規格書裡面，表現架構的方法通常都是使用簡單的架構圖來呈現 如下圖，這張圖試圖說明一個軟體遊戲的架構，最底層是遊戲主體這相當於是整 個遊戲軟體，往上一層分別有「遊戲模組」、「遊戲音效」、「遊戲特效」等模組，
在這些模組之上還有「遊戲介面」來進行層與層之間的溝通，最頂層則是最接近 使用者的一層「遊戲指令」，用來接收玩家的操作並轉換成遊戲指令發送給遊戲 介面進行處理。
圖 5-1-1 傳統遊戲規格書之架構圖 資料來源：本研究整理
5-1-5 遊戲規格書之遊戲功能規劃
一個遊戲中附帶的遊戲功能會隨著遊戲規模有多有少，每個功能都會有其不 同的企劃人員負責開發，多個企劃人員分工作業之後最後由單一企劃人員將所有 的企劃內容整合到同一份遊戲規格書之中，通常在撰寫功能的規格書方式是以
「功能需求示意圖」為主，圖中的補充文字為輔，在配上文件中的文字描述來傳 達給規格書的讀者所需要製作的內容與細節，下圖便是一個例子，透過使用「功 能需求示意圖」來說明一個遊戲功能需要有哪些操作，圖中試圖描述Cake Keeper 內當遊戲進行中可能包含的遊戲功能，透過圖片中的黃色字樣與紅色箭頭的引導 來說明與解釋紅色方框中的物件所代表的內容與意義，從圖片中可以得知，這個 畫面需要有「進攻中的敵人」、「守護的蛋糕」、「被擊殺的怪物」、「得分」等功能 或行為，而程式人員會看著這樣的圖一一的把每一個功能實作出來。
圖 5-1-2 功能需求示意圖 資料來源：本研究整理
92
5-1-6 遊戲規格書之遊戲流程規劃
一個好的遊戲會透過控制遊戲難度或是功能數量的流程來讓玩家不會因為 對遊戲的不了解而提早放棄遊戲，這是遊戲流程在一個遊戲軟體中在實務上的一 個操作技巧，在遊戲軟體中，遊戲流程是必須要被依照企劃所設定的流程跟規則 來控制的，因此遊戲規格書中必須要描述遊戲的流程是如何進行的，在目前大家 的遊戲規格書中最常看見的流程表現的方法便是流程圖(Flow Charts)，如下圖這 是一個簡單的遊戲流程描述，途中試圖描述一個使用者操作遊戲軟體從「開啟 APP」開始，接著「開始遊戲」，遊戲中不斷檢查「是否死亡」，如果不是則繼續 檢查，直到「是否死亡」成立為止，最後結束遊戲，這只是一個最基本的流程圖，
這樣子的流程圖在傳統遊戲規格書中是非常常見的
圖 5-1-3 流程圖示意圖 資料來源：本研究整理
5-1-7 遊戲規格書之遊戲素材數量與說明
94
5-2 架構導向遊戲規格書模型與傳統遊戲規格書模型之比較
以下將會從傳統遊戲規格書的做法中採取幾個模型，與架構導向遊戲規格書 進行比較，並且說明其優劣之處。
5-2-1 遊戲結構圖之比較
表格 5-2-1 遊戲架構比較 資料來源：本研究整理
傳統結構圖 SBC –結構行為合一圖
與傳統結構圖相比，SBC 中的結構行為合一圖它不只能夠表現構件的分層 關係，更能夠以行為的觀點來充份了解到一個系統可進行的操作，相較傳統結構 圖，傳統結構圖缺乏明確的構件描述以及分布，且無法從結構圖中得知一個行為 發生時的脈絡，因此SBC 的框架圖可以在行動遊戲規格書中提供一個較完善且 明確的系統框架分析方法。
5-2-2 系統功能（行為）規劃之比較
使用SBC 的構件操作圖表示一個子系統所需要的所有操作，將可以清楚的 表達一個構件所提供的操作細節，有效的切割與其他構件的關聯，幫助程式人員 釐清自己負責的系統邊界；另外再使用互動流程圖來表現這個構件所提供的操作 之流程，確保企劃人員提出的功能與流程可以被程式人員完整且正確的實作，減 少因為需求溝通不明確、認知錯誤導致的重新溝通、重構系統之成本，以「敵人 進攻行為」為例，在傳統的規格書中使用功能需求示意圖透過紅色方框與文字來 說明來表示怪物可能的行為，而架構導向的作法是使用「構件操作圖」來表示一 個敵人可能發生的操作，使用「互動流程圖」來表示一個行為的流程與細節，將 這三種不同的圖型整理如下表。
表格 5-2-2 功能規劃之比較 資料來源：本研究整理
功能需求示意圖 互動流程圖 構件操作圖
比較之下，其實不難看出，非架構導向的傳統做法在進行遊戲規格書的功能 規劃時，雖然可以透過豐富的圖片來表達玩家所可以操作的功能與看到的訊息，
但是卻非常的缺乏訊息露出的順序之開發規格，這種狀況就有可能使程式人員必
96
理解能力，並加快讀者的閱讀速度，最重要的是，為遊戲規格書定義出一套規格，
98
在表格製作的過程，需要由一個非常了解遊戲所有細節的人來填寫「功能」
100
5-3-4-2 更新內容
上述中提到，一個營運中的產品如何「保留玩家」、「增加新用戶」、「找回老 玩家」這是非常重要的三個問題，而這三個問題在過去的經驗通常都有一個共通 解，那就是「開放新內容」，即持續開發，當然也許解決Bug、提高遊戲效能等 等都是可以解決問題的方法，但是依照過去的經驗，最容易同時達到這三個目標 的方法仍然是「開放新內容」。
「開放新內容」即持續開發，那麼必然要做的就是撰寫新的遊戲規格書內 容，單純的開發功能過程與遊戲規格書的比較在前面的章節已經比較過了，這邊 探討的是「延伸」上的差異。
因為遊戲規格書並沒有像架構導向模型的製作手法，因此在經過交接之後，
最容易發生的就是遊戲規格書撰寫的方式變了一個模樣，也因此，同樣的開發人 員可能會被多種版本的規格書搞得暈頭轉向，甚至因為使用舊版本的模式去理解 新版本的模式而導致的認知錯誤最後製作出不正確結果。
導入SBC 架構導向模型之後，因為遊戲規格書符合 SBC 架構導向模型的製 作規範，因此即便文字敘述上可能會因人而異寫出不同的敘述，但是成員們最常 溝通的架構導向模型之各種功能不同分析圖都已經可以讓開發人員了解大半以 上的結構與功能細節；這樣子的模型已經大大的改善了因為移交之後因為遊戲規 格書的格式不同而產生的溝通與製作的成本了。
102
6-1-2 更具體的遊戲測試方法
在使用軟體架構導向之方法論進行分析的同時，也已經完成了測試項目與流 程的規劃與執行細節了，透過「結構行為合一圖」，在分析系統的同時，也明確 的將未來玩家操作軟體的時候所可能發生的行為流程文件化了，透過這樣子的文 件可以讓測試人員依照文件的內容進行測試，進而減少重新分析或規劃測試需求 成本，且可以確保測試與實際製作的結果是相符合的，藉此降低測試成本與時間。
6-1-3 提升延續專案之承接效益
運用軟體架構之方法論採用結構行為合一架構描述語言所產生之分析文 件，未來在進行後續專案人員承接時，維護遊戲軟體之操作與遊戲程式邏輯，運 用「構件連結圖」及「構件操作圖」等圖形化文件來快速了解軟體系統，更為清 晰與簡單且真正的明確的瞭解遊戲軟體的全貌，讓接手的新專案人員可以更快速 且容易的吸收之前開發之精隨，提升延續專案之承接效益。
6-2 未來規劃與建議
在經過研究之後，對於SBC 使用在 3D 行動塔防遊戲之規格書上已可見到 其成果及正面之效益，但在實務上仍然有些問題需要克服。
6-2-1 依照程式碼逆向產生 SBC 相關文件
在實務的案例中，因為競爭對手越來越多，因此開發通常是非常急迫的，在
104
製作開發的成員了解，其他或是後續接手維護的成員並不了解其細節，因此建議 未來或許可以針對各種不同的程式語言進行分析，然後自動導出以SBC-ADL 為 基礎的相關文件，藉此來增加專案的可維護性。
6-2-2 可依照規格書中的分析內容建置遊戲基本框架
透過分析與研究後已可見軟體開發模型之優越性，其實也可以加入一些輔助 的工具，例如自動依照分析文件來產生軟體框架，先自動產生一個軟體框架，然 後再依照需要的功能繼續依照分析圖繼續自動產生出來，最後再依照後續所需要
透過分析與研究後已可見軟體開發模型之優越性，其實也可以加入一些輔助 的工具，例如自動依照分析文件來產生軟體框架，先自動產生一個軟體框架，然 後再依照需要的功能繼續依照分析圖繼續自動產生出來，最後再依照後續所需要