基表設計

遊戲中有關人物素質、關卡資訊以及一大堆雜七雜八來控制用的文件，這些文件稱為「基表」。

基表的用途

舉例來說，《爐石戰記》每週會有旅店大亂鬥，每次的規則都不太一樣。

或是有些手機遊戲，每週都會有更新，開放新的人物，還有提高營收的活動。

「本週只要參與OO活動？就能得到XX！」「限時加價購！購買XX只要再加OO即可獲得限量XX」「稀有角色出現機率超大提升！」

那應該會有一份文件來控制這件事的發生與結束。

簡單的說，基表控制著遊戲的的可變化內容。

這些基表在輸出前可能是這個樣子。

ActivityName	TimeBegin	TimeEnd	Case	Value
商店打8折	2016/7/26 8:00:	2016/7/26 上午 14:00:00	store	80
轉蛋機率提升2倍	2016/7/26 9:00:	2016/7/26 上午 15:00:00	gacha	200
經驗1.5倍	2016/7/26 10:00:	2016/7/26 上午 14:00:01	exp	150
金幣2倍	2016/7/26 11:00:	2016/7/26 上午 15:00:01	coin	200

(表一)

為了方便討論起見，我定表格橫行直列，第一行的欄位稱為key，以下的欄位稱內容。

基表的key與內容，是在遊戲開發時，由企劃根據所需功能設計，並且與程式討論實作的意見後進行修改。

例如今天需要一份基表來控制遊戲中人物素質以及等級的成長。

一種簡便的方式如下

LEVEL	HP	ATK	DEF
1	100	60	18
2	120	72	32
3	140	84	50
4	160	96	72
5	180	108	98

(表二)

直接顯示每個等級的狀態，程式在實作上可以直接讀取相應數值。

最後輸出Json，Html，或是其它支援的格式。

可能的疑問像是……人物的屬性成長是有差別的呢？多開一張表嗎？

要怎麼表示一個防禦力更低的狀態？可以填成負數嗎？

總之，請先弄清楚你的需求，再來談論這些問題。基表的設計就是依照需求來調整。

在單機遊戲中，基表是在遊戲釋出以前就修改完畢，不再變動。

而在需要長期營運的遊戲時，則依據營運團隊的建議製作、修改相關設定，並在每週的定期維修更新時，上傳至遊戲伺服器。

基表的製作

製作基表前有幾個要點。

1.確認需求

通常基表的限制來自需求的彈性，需求的變化彈性越高，基表在設計上的精確度也越低。

「人物只有一個技能」

那麼可於表二再開一列key為Skill,型態int的資料。

「雖然這個人物目前只有一個技能，不過在之後，我希望他擁有多個技能……」

基本上，程式聽到這樣的需求後，就應該將Skill,改用陣列來儲存相關資訊。

「技能本身還有熟練等級可以提升」

那麼欄位內容又會更加複雜。可能本身就是巢狀結構。

2.控制基表的欄位與內容深度

通常欄位越多代表修改與檢查的難度也相應提升。
這時可以考慮以資料縮減，例如相關資料以陣列儲存，或是以巢狀結構儲存。
不過需要注意的是，如果巢狀結構就相當複雜，使得可閱讀性降低，就應該考慮其他方式。

可閱讀性，是指內容在無說明下可直接理解其代表意義，像表一的case代表的是活動項目，但是實際效果是什麼呢？不過這個可閱讀性比起

3.關聯性
這是很容易理解，你可能會在怪物與怪物掉落物品放在同一張基表。
但是不會把武器的售價跟人物等級放在同一張表吧？
...
..
.
難道人物等級提升會使得賣物品價格更高？

好吧，如果是你想做的話，首先你需要在人物的基表中設計到達一定等級會惜得技能的欄位。然後在技能基表中設定可以使販售特定物品的金額提高的性質，然後再去物品基表設定物品會因為技能提升多少售價。

(來自好色龍)

4.輔助工具與防呆機制

在單機遊戲時代，基表的範圍相對單純，無非是單位數值、物品技能一類。而且在上市前都有足夠的時間做平衡調整與檢查。

到了MMO時代，偶爾會聽到某遊戲出包，錢亂噴，寶亂掉，玩家趕快上線去拿啊。
這通常是基表填錯造成的問題。也代表有企劃要飛高高了！

「填表而已，有這麼困難嗎？」
「填表工具人連表都填不好，要你何用？」

等等，墨菲定律這麼說：「可能會發生的錯誤總會發生」我們能做的，是將機率以及後果降到最低，避免不可挽回的災難。

(來自Please Don't Touch Anything)

哪些稱得上是不可挽回的災難？
玩家資料遺失，然後沒有任何備份。
釋出了稀有物品，然後沒有任何備份。
不小心刪除了基表，然後沒有任何備份。
更動到玩家client端出錯無法進入遊戲，然後除了砍掉重裝，沒有方式可以修正。

定期備份雖然可以解決大部份問題，但是屬於補救方法，預防的方法是「細心的檢查」以及「防呆機制」。

什麼防呆機制呢？
可以從基表本身以及遊戲內的程式來改善。

在企劃方面，google spreadsheet或是excel本身都有函式功能，可以預防欄位上出現不合法的數值，例如負數、空格等等，或是可以跨表交叉參照比對，避免不存在的值出現。

在程式方面，則是善用預設值，讀表之前先做判斷，不要傻傻的，表填什麼就讀什麼，把null讀進來炸掉。

與其相信企劃的手不會抖，不如相信自己寫的程式吧。

最後確認遊戲client端的基表更新流程，總是維持著更新優先，這是為了保證任何寫入的錯誤值都有可修復性。

題外話

基表的更新維護，常常都是企劃與程式間發生衝突的地方。
有程式認為企劃會使用基表填寫出非原先預定功能，只是為了湊出新功能。這是在無法變更程式下的權宜之計，可能是上頭壓力。但是最後這些拼湊的功能必須導正，不然會成為某種技術債。

需要營運的遊戲，會有後台操作界面，用來將基表上傳至server。曾經聽過有人在後台按上傳卻按到旁邊的刪除，將資料庫的該表drop掉。
這件問題發生，首先是人員，再來是怎麼會有如此危險的按鈕在後台人人可按到的地方？
如果有個按鈕出現，請預設在最糟的狀況按下會發生什麼事吧！

大概就是這樣，下次再談。