遊戲企劃必修課：了解「配置表」Part.01
一個既熟悉又陌生的名詞
寫在前面：
老實說，雖然知道資料儲存的結構和方式，但筆者第一次進遊戲公司的時候，還是被有整體規範和流水線的數值配置流程給震驚到了，才知道原來有這麼有效率和便捷的管理方式。
至少對當時剛進公司的菜鳥如我，就像是發現新大陸一樣，只要有時間就把專案內的配置表開起來啃，一方面思考為何前輩要這樣設計，另一方面也思考是否有優化的可能性。
那時就決定，如果有機會，一定要寫一篇關於遊戲配置的文章。對新手系統企劃而言，這是最能迅速成長的方式之一。
在這系列的文章中，會介紹軟體工程中資料的儲存方式，以及資料庫的基本知識，例如關聯式和非關聯式資料庫的概念。下一篇開會談到企劃如何實際的設計配置表，和一些配置上的小技巧。未來有機會的話，則會實際以案例來分析如何拆解配置。
因此本篇可能會稍微偏工程向一些，請大家稍微忍耐下囉。
什麼是「遊戲配置」？
舉凡遊戲內所有的「設定」，包括像是「怪物的血量」、「武器的攻擊力」或是「道具的價格」，甚至跟數字無關的例如「遊戲的規則」等等，都可以用配置的方式來實現。
英文原文是 Configuration，也就是設定檔，通常簡稱Config，副檔名有時會看到.cfg，都是一樣的意思。這些配置會被儲存為表單的形式，也稱為Config Table（配置表格）。
在遊戲中，配置表扮演著紀錄遊戲各種設定的重要角色。設計師可以藉由快速的修改配置表內的數值，不需要經過程序重新包版（就是不用改程式碼，也不用重新編譯），就能在遊戲中調整體驗，是相當方便的作法。
例如今天遊戲內需要有三隻不同的怪物，他們需要有不同的血量和攻擊力，那麼配置表就可能會是下面這樣：
如果還要加入例如怪物名稱，掉落道具等等的東西，可以將這個表再拓展一下。配置表是系統和數值企劃常常要打交道的東西，非常重要。
不過在真正進入到如何配置的教學之前，還是一樣要先講解一下由來。
我們如何「分類並儲存」資訊？
人類和其他動物最大的區別，就是我們不僅僅只是靠「記憶」，而是會「分類」東西。
這個技能有多重要呢？靠著經驗法則，人類學會的火的製造方法，學會了煮熟的食物比較安全，發現並組合各種科學原理，發展出了現代文明。
例如動物們可能會因為吃到不安全的食物，了解到這個食物不能吃。但人類會分析「不能吃的食物」之間的共通點，藉此來避開危險。
（當然也有些負面的影響，例如人們沉溺於分類這件事情，有了貼標籤、刻板印象或難以變通等等的行為……但今天先不談這些人類社會學的問題。）
總之，人類分類事物是與生俱來的能力，藉由事物之間的關聯性，我們能架構出一個龐大的關聯網路，用這種方式來儲存記憶。
同理，我們要將資訊「紀錄」下來時，也一樣。
資料庫的由來
舉例來說，今天在某個學校的班級中，有五名學生，他們分別有著不同的名字，於是，我們就將這些學生紀錄在一個集合裡面。
接著，為了紀錄他們的共同點「性別」，我們需要利用矩陣的形式來分別對應。
這樣，我們就有了一列用來對照（名字）的資料，以及對應的值（性別欄位中的內容）。這就是現在常見的資料儲存格式的雛型。
這個矩陣是可以拓展的，只要我們在後面添加欄位，就可以很輕易的追加資料量。
這種「依照特定參照者，依序擺放資料」的儲存方法，就是一種資料庫。在上面的例子中，參照的對象就是「姓名」。
（順道一題，雖然用陣列來解釋資料庫，但其實資料庫的儲存不是我們表面上直接看到的表的樣式，使用陣列來稱呼只是方便理解，實際上系統讀寫的方式不是直接把整張配置檔案讀取進去。）
資料庫管理和使用是工程師的必修項目之一，在大型的專案中，安排專門負責資料庫的工程師的做法也相當常見。除了儲存資料以外，優化「搜尋」、「排序」等等的效率也是很重要的。
關係鍵（Primary Key）與關聯式資料庫
關係鍵（或稱為主鍵）是資料庫工程上一個很重要的概念。聽起來很學術，但其實一點都不難理解。
所謂的 Primary Key，其實就是多張表單中，用來辨識同一個資料關係的，最重要的唯一的值。可以想像成像是國民的身份證號碼一樣，絕對不會重複，一個身份證號碼就代表一個人。
在資料庫的處理中，有時會遇到這種狀況：
現在有兩張分開的資料表，程式在統一資料時，可以用一個叫做「Join」的資料庫操作，利用兩張表都有「姓名」，將他們整合成同一張表：
這裡的「姓名」就是 Primary Key 的概念。有了 Primary Key 之後，資料表就可以很輕易的拆開和合併。
利用主鍵，實現多個資料表單的對照，方便讀寫和整理的資料庫，這就是「關聯式資料庫」的概念。
不過如果今天轉學來了另一個「廖小惠」，那麼這個資料表就不能這樣寫啦，需要加一欄「學號」，用來辨別到底是哪一個廖小惠。因為「主鍵」是資料庫用以辨別內容，絕對不能重複的唯一資訊。
額外閱讀1：
工程上的「表」的概念，和企劃用來儲存的「配置表」概念是不太一樣的。
對資料庫來說，只要每新增一欄，其實就是新增一張表，只是企劃在管理時，把很多張表放在同一頁當中，方便對照和維護。
程式在運作時，只會讀取需要讀取的表（欄位），「配置檔案」的分開與否，對程式來說影響不大。每張表只要有「鍵」和「值」，程式就能做資料庫的相關操作。
額外閱讀2：
承上所述，所謂的關聯式資料庫（Relational database）就是建立在二維陣列下的一種資料儲存方式。使用的是sql語言（發音近似「C闊」）。
但其實也有所謂的nosql這樣的概念，也就是「非關聯式資料庫」（維基百科連結）。
和傳統的關聯式資料庫相比，nosql不使用原本的sql語言，而且儲存資料的方式只有「鍵」和「值」的對應。例如下圖：
這樣的儲存方式，很容易可以拆解成不同長度的表單，也不太使用Join操作，水平的拓展非常容易。
nosql在近幾年越來越受重視的原因，是因為他在「超大量資料處理」上，比傳統sql資料庫來的有效率。
sql資料庫擅長做範圍小，且頻繁讀寫的資料庫，而面對現今的龐大資料流量，能拆分成很多小段，讓多處理器同時處理的情況下，nosql效率會明顯比較高。
但這並不代表nosql就比sql好喔，只是在「資料超大量级」的情況下，sql表現比較差而已。
這個極端狀況，以遊戲開發來說幾乎不會碰到。只要不是國際爆款級別的遊戲，都可以不用煩惱這個問題。（還真是甜蜜的負荷呢）
資料的「型別」（Data type）
除了知道資料的儲存方式之外，也需要了解儲存的「值」的類型有哪些。
在工程領域中，主要有以下的儲存格式：
對企劃來說，其實只需要懂四種類型。
也就是「布林 Boolean」、「整數 Integer」、「浮點數 Float」和「字串String（也就是上面的Word）」。
- 布林：僅儲存0或1，也就是真或假的差別。
- 整數：不包含小數點的整數數字。
- 浮點數：需要包含小數點。
- 字串：文字與符號。
由於企劃需要開出數值需求，例如說設計一隻怪物，他需要有血量和防禦等等，這些數值都需要被「定義」資料型別。
因為當型別不正確時，就無法儲存特定格式的數值。像是一個「整數」的型別就不能存放帶有小數點的值，會發生小數點被捨去等等的情況。
以RPG類型遊戲為例，像是「攻擊力」就比較適合用整數來配置，而「攻擊速度」的單位如果是「次數/秒」的話，就需要用浮點數而不能用整數來處理。
額外閱讀：
其實資料庫的資料型別會分的更細，例如 TINYINT[1 byte]、SMALLINT[2 byte]、MEDIUMINT[3 byte]、INT[4 byte]、BIGINT[8 byte]，DATE（參考連結）等日期相關的儲存等等。
這部分企劃可以作為進階選修，如果不確定用哪一種方式存，只要在提需求的時候明確數據的範圍，資料庫工程師就會施展魔法（？）來縮小數據入庫的資料量了XD。（感謝小坤補充）
所以為什麼我們需要配置表？
將遊戲中的設定，從編碼中中拆出來變成獨立配置表有諸多優點：
- 可以直接修改，不需要等程式重新編譯，節省時間。
- 同上，調整配置也可以協助測試和除錯，快速縮小問題範圍。
- 拆成多張表的話，方便維護和多人共同編輯。
- 在現有的機制下容易鋪量拓展。（例如新關卡不需要新功能支持，直接配怪物和獎勵就可以）
- 未來可以用「熱更新」的方式讓客戶端直接下載並更新配置表，不需要重新下載整個程式。
不過對於很小型的遊戲來說，不拆成配置表可能工作效率還快一些（因為程式企劃是同一個人）。
或是某些功能完成後就不會再調整了，那也可以不用特別將配置提取出來。
因此依照專案大小，來決定哪些東西需要拆成配置，對於是企劃來說是很重要的工作。
企劃開配置需求的場合
對企劃而言，開配置需求主要有兩種原因。
第一點，是為了要讓「遊戲內的體驗」能夠讓設計者自由調整。
第二點，是為了儲存「玩家的資訊」。
前者是所謂的靜態（唯讀）表，也就是遊戲運行中不會改變數值的表。後者則是關係到系統需要紀錄哪些玩家資訊。
動態數據除了靜態的儲存資料以外，玩家在遊戲中會使用的動態數值也是設計的一環，例如角色的血量就不是固定值。這類資料雖然需要設計，不過並不是今天配置表的討論範疇，所以這邊就不解釋太多了。
同時在開需求的時候，也需要留意「未來的拓展性」。
舉個例子，假設某個專案中，NPC和怪物以及中立生物都算是mob的一種，都歸屬於mob表。
如果一開始只規劃100條ID區間給NPC，後面留給怪物和動物，最後發現NPC會超過一百隻的時候，負責的企劃表示悲劇……（對程式來說，調整資料庫大小並不是太困難的事情，但負責維護表的數值企劃會很辛苦，下一篇會講到這些小細節）
這一篇介紹就先講到這邊，下一篇我們會談到如何根據遊戲需求來設計配置表，以及各種配置時的小技巧。
我是水狼，我們下次見。
也可以到臉書追蹤我喔： 粉絲專頁連結
最後，請多利用我的個人文章列表，會持續更新：
