遊戲企劃必修課:了解「配置表」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會超過一百隻的時候,負責的企劃表示悲劇……(對程式來說,調整資料庫大小並不是太困難的事情,但負責維護表的數值企劃會很辛苦,下一篇會講到這些小細節)
這一篇介紹就先講到這邊,下一篇我們會談到如何根據遊戲需求來設計配置表,以及各種配置時的小技巧。
我是水狼,我們下次見。
也可以到臉書追蹤我喔: 粉絲專頁連結
最後,請多利用我的個人文章列表,會持續更新: