第三章、 研究方法與操作步驟
第四節、 數位桌遊系統開發與建置
國
立 政 治 大 學
‧
N a tio na
l C h engchi U ni ve rs it y
65
第四節、數位桌遊系統開發與建置 一、技術應用與系統架構
本研究所開發的數位桌遊系統由兩個系統組成，在 Ipad 上運作的《寶島建 設》數位桌遊與負責儲存與分析數據的網路伺服器；在硬體上包含四台終端設 備 Ipad 供玩家操作、一台桌上型電腦用於架設網頁伺服器。
1. 數位桌遊之技術應用
1.1. 遊戲開發工具每位玩家在終端設備上操作的程式，是使用 Unity3D 5.4 版開發的數位桌遊 客戶端程式。任一玩家透過此客戶端創建遊戲房間之後，其他玩家會自動被 PhotonCloud 遊戲伺服器所通知，而看到該遊戲房間，此時便可以加入。待所有 玩家都加入後，遊戲房間的建立者即可開始遊戲。
圖 3-18. 系統互動情境
PhotonCloud（圖 3-18）是一款由 ExitGames 所研發的雲端遊戲同步服務，
他可以讓使用者進行多人遊戲的開發更爲便利，而免費版本的 PhotonCloud 允許 20 個同時在綫人數，透過 Unity 與 ExitGames 合作研發的套件 Photon Unity Networking 則是將開發與除錯的時間大幅縮短。
‧ 國
立 政 治 大 學
‧
N a tio na
l C h engchi U ni ve rs it y
66 1.2. 雲端遊戲同步服務
Photon Unity Networking 所提供的遊戲同步服務功能，主要有三種：
圖 3-19. 技術應用
1.2.1. Remote Procedure Call
第一種技術為 Remote Procedure Call（RPC），在《寶島建設》裡最常被使 用，它可以將玩家的各種重要操作從客戶端傳送至遊戲伺服器，例如建造房屋、
挑選地契等等。遊戲伺服器會根據所有玩家與遊戲的狀態，來決定如何處理來 自客戶端的操作請求。如果請求合法，遊戲伺服器便可能更新玩家狀態或遊戲 的全域狀態。例如一名玩家挑選地契之後，遊戲伺服器就會更新該玩家持有該 類地契的數量（更新玩家狀態），接著將挑選地契的權力交給下一位玩家或開 始下一個遊戲階段（更新遊戲全域狀態）。
1.2.2. CustomProperties
第二種技術 CustomProperties 被用來紀錄玩家在遊戲的資源參數（Variables）
與狀態（State），玩家的資源參數有在遊戲中的金錢、地契、建材和房屋，而 遊戲的環境參數則有房屋區域等級、住人的房屋、回合等，遊戲的狀態則涵蓋 目前的所有的遊戲階段與玩家順序，用以標示目前的遊戲階段與輪到哪位玩家 進行操作；當這些遊戲參數被更新（ Update）時，遊戲伺服器會開始同步
（Sync），確保每個客戶端中的玩家狀態與伺服器上的版本保持一致。
‧ 國
立 政 治 大 學
‧
N a tio na
l C h engchi U ni ve rs it y
67 1.2.3. OnSerializePhotonView
最後一種技術是 OnSerializePhotonView，是一種專用於高頻率同步的技術，
通常會用在需要很常更新狀態的物件身上；不過在《寶島建設》裡很少被使用，
僅僅是用來處理使用者介面上的同步，舉例來說，在競標地契或建材的階段時，
所有玩家都將看到相同的競標結束倒數計時器、各玩家出價，以及競標結果。
1.3 數據傳輸
紀錄的部分是由客戶端將其操作行為傳送至 MySQL 資料庫儲存。每筆操 作行為是以 JSON（Javascript Object Notation）的格式，透過 HTTP POST 的方 式傳送至伺服器交由 PHP 程式進行，最後被伺服器儲存至同一台主機上的 MySQL 資料庫。
1.4 數位桌遊系統架構
系統架構上，玩家會使用 ipad 透過操作介面對系統進行操作，由遊戲核心 處理各種玩家的操作，其中同步的部分是使用 Photon Unity Networking （PUN）
套件與 Photon Server API 達成，而操作的紀錄會由紀錄程式負責封裝成 JSON 並 透過 HTTP POST 指令發送至網頁伺服器後端，再存入資料庫。最後研究人員即 可透過網頁前端取得這些操作歷程的視覺化結果。
圖 3-20. 系統架構
‧ 國
立 政 治 大 學
‧
N a tio na
l C h engchi U ni ve rs it y
68
2. 網頁伺服器之技術應用
網頁伺服器的功能有兩個：處理來自終端 Ipad 的數據和運算數據產出圖表。
處理來自 Ipad 的數據主要牽扯了後端程式與資料庫，而運算數據產出圖表則是 提取資料庫的數據，讓後端程式進行運算，由前端程式進行視覺呈現。
2.1 伺服器架設工具
網頁伺服器的開發選用了 Appserv 伺服器 8.5 版，裡面 Apache Server 採用 2.4 版，MySQL 資料庫採用 5.7 版，唯有採用 MySQL 5.7 版才有支援 JSON 格式 的存取和索引，PHP 則是有 5.x 和 7.x 版本共存，本研究僅會使用 5.x 版本的語 法。
2.2 網頁與圖表製作套件
本研究採用了網路上開源的圖表製作軟體增加開發效率。
2.2.1. Vis.js
Vis.js 可以迅速建立狀態變化的連結圖，只要丟點（Nodes）和綫（Edges）
的資料則會自動轉換成能拖拉的狀態變化圖。
圖 3-21. 狀態變化圖
（資料來源：http://visjs.org/）
‧ 國
立 政 治 大 學
‧
N a tio na
l C h engchi U ni ve rs it y
69 2.2.2. Heatmap.js
Heatmap.js 可以簡單地製作熱量圖，將玩家所觸控的坐標位置的 X 與 Y 值 統計運算便可以透過堆疊的熱量看出聚焦的位置。
圖 3-22. 熱量圖
（資料來源：https://www.patrick-wied.at/static/heatmapjs/）
2.2.3. Boostraps.js
Boostraps.js 是一個被廣泛運用來進行網頁格式編輯的工具，他能在耗費最 少的資源下建立起一個網站的視覺，達到整齊和舒服的色彩調色，且在排版和 介面上也有著不錯的版型可直接套用；圖 3-23 為 Boostrap.js 製作之本研究網頁。
圖 3-23. 數位桌遊數據分析系統
‧ 國
立 政 治 大 學
‧
N a tio na
l C h engchi U ni ve rs it y
70
圖 3-24. HighChart 範例圖表
（資料來源：http://www.highcharts.com/demo）
2.2.4. HighChart.js
HighChart.js 是一款泛用型 2D 圖表的工具，他能賦予圖表簡單的互動，並 根據數值自動調整顔色，讓圖表更具辨識度，也有能將圖表轉換成 PNG 圖檔下 載的功能，在製作研究報告上非常便利。
‧ 國
立 政 治 大 學
‧
N a tio na
l C h engchi U ni ve rs it y
71
3. 數位桌遊之系統架構
本研究之數位桌遊系統架構主要從三個層面進行規劃，分別為：參數處理 與邏輯運算、網路同步與主客戶端運算、視覺處理與程式處理。
3.1 參數存取與邏輯運算
參數存取（Variables Access）是指遊戲中很常被調用的資料的存取結構，
遊戲邏輯需要參數資料才能進行運算，所以參數與邏輯的分割可以讓遊戲更好 撰寫。本研究根據每個遊戲階段的運算邏輯與所需要參數進行分配，得出遊戲 流程（Game Flow）與參數資料（Data）的關係（圖 3-25）。
爲了更方面地撰寫程式，本研究也會將擁有該參數的物件（Object）預先 存取一份索引（Object Reference）在要撰寫的物件下；必須注意的是 Unity 採用 的是 Component Based Engine，即每一個物件即組件（Component）的形式透過 Unity 的引擎在固定時間進行呼叫與執行（Call & Execution），而組件內的程式 是以 C#去撰寫，故採用物件導向（Object Oriented）的方式撰寫，即物件的屬 性（Attribute）與行爲（Behavior）分離。
圖 3-25. 參數和邏輯之分割概念圖
‧ 國
立 政 治 大 學
‧
N a tio na
l C h engchi U ni ve rs it y
72 3.2 網路同步與主客戶端運算
在撰寫網路遊戲程式時一個最容易犯錯的地方就是同步（Sync），而最常 發生的問題是先後更新的次序所導致，因爲更新代表著將新的資料將覆蓋到舊 的資料上，如：現在競標最高價碼是 14000，因此玩家 A 出價 15000，玩家 B 同 時出價 18000，玩家 B 明明比玩家 A 多，理應由玩家 B 獲得，但因爲時間差的 關係，在玩家 B 尚未更新完的情況下，玩家 A 和舊的 14000 比較，在玩家 B 覆 蓋了舊的資料後，玩家 A 又覆蓋上去，結果是玩家 A 擁有最高價碼；在 Photon Unity Networking 所提供三個技術裡，最可能發生這種更新錯誤的是 RPC 和 CustomProperties。
Photon 允許很多不同的同步概念，而《寶島建設》所採用的是將其中一台 Ipad 扮演負責主客戶端（Master Client）的概念，本研究將玩家的操作分成兩大 類別：一般行爲與決策行爲，決策行爲會影響參數的變化，而一般操作不會，
當玩家進行決策行爲，客戶端（Client）將會透過 RPC 呼叫主客戶端（Master Client）的程式進行運算，並將運算結果存入參數進行同步，再透過 RPC 告知所 有客戶端更新。
圖 3-26. 主客戶端與客戶端之運算
‧
Properties Manager 負責處理遊戲參數的資料存取模組每個功能會有對應的模組負責管理，如：RPC、市場交易、房屋區域、音 效和鏡頭等都有對應的模組處理相關的參數提取，而每個介面都會有專屬的控 制程式更新介面上的資訊。
表 3-7 管理模組與介面模組
管理模組 介面模組 簡介
Player Manager Player Board 指定玩家的公開資料展示介面 Main Player 玩家本人的展示介面
Other Player 其他玩家的展示介面
District Manager District 房屋區域與其等級的展示介面
House 房屋區域上的房屋展示介面
Construction 玩家蓋房屋的操作介面
Sales 玩家出售任意卡的操作介面
Upgrade 玩家升級房屋區域的操作介面
Trade Manager Trading Market 四組交易市場卡牌的展示介面 Trading Card 每張市場交易卡牌的展示介面 Trading Contract 進行交易的操作介面
Board Manager
（主客戶端處理）
Pick Land Board 挑選地契的操作介面 Auction Board 競標的操作介面 Upgrade Board 升級的操作介面
‧
‧ 國
立 政 治 大 學
‧
N a tio na
l C h engchi U ni ve rs it y
75
二、桌遊數位化流程
透過彙整訪談內容，本研究整理出桌遊數位化流程能延用的開發建議。
表 3-10 桌遊數位化開發與設計建議彙整
分類 設計建議
互動 根據載體特性，操作介面多分配在右手邊（大部分人慣用手）
介面 減少用字，只是用字來作標題
介面 資訊結構不要超過三層，別讓玩家不斷往下層點擊
介面 介面空間的分配要簡潔，互動的操作要明確與直覺
介面 減少動畫使用，避免動畫分散玩家的注意力，保持遊戲的流暢
聲音 背景音樂能舒緩玩家的等待時間，幫助詮釋遊戲情境
聲音 音效搭配操作能提高回饋與幫助融入遊戲情境
談及數位化，因桌遊本無音樂，本研究將互動介面作為數位化重心，在介 面架構上保持在兩層內，因此玩家不會有過多深入介面的點擊。本研究以主畫 面為主，涵蓋遊戲的主要資訊如遊戲階段、目前回合和玩家，再將展開的介面 區分成兩類：獨立介面與非獨立介面。獨立介面不會受到其他玩家的操作和遊 戲階段的干擾，玩家可以隨時從主畫面開啟獨立介面，遊戲中的獨立介面分別 有：玩家資料、交易市場、房屋區域；獨立介面用於檢索所需資訊，常駐於遊 戲主畫面。
圖 3-27. 獨立介面
非獨立介面又分為同步介面與非同步介面，同步介面會在所有人的畫面上 開啟一樣的介面，而非同步介面則是輪到該位玩家時只在其畫面上開啟介面。
‧ 國
立 政 治 大 學
‧
N a tio na
l C h engchi U ni ve rs it y
76
圖 3-28. 非獨立介面（挑選地契與競標）
挑選地契階段只有同步介面，玩家們能清楚看到地契被挑走，當最後一位
挑選地契階段只有同步介面，玩家們能清楚看到地契被挑走，當最後一位