遊戲企劃必修課:了解「配置表」Part.02
每天面對一堆配置表單,就是企劃的工作。
上一篇講解了配置表由來和基礎概念(還沒看過的請點我前往)。
今天要帶大家來實際看一些企劃在設計配置表時會遇到的問題,以及一些工作上會用到的小技巧。
可能看起來會比較像是沒整理的筆記(汗),不過應該還是對新手有一點幫助的。
配置表是程式和企劃的溝通媒介
配置表在遊戲中扮演著重要的角色,雖然設計者是企劃,但最終是要交給工程師來讀取和使用的。因此,需要同時滿足企劃方便設計維護,且工程師方便操作資料庫的雙方需求。
在設計系統需求時,往往寫了一堆文字工程師也不見得看得懂。
這時直接搬出配置需求就行,根據欄位的內容,工程師們能夠迅速準確的理解系統構造。
該用什麼程式來編輯配置表?
企劃最愛用的,莫過於微軟自家的Office Excel系列了,支持各種公式,內建各種輔助工具等等,Excel表單能滿足幾乎所有的數值處理需求,但只有一個缺點……它不是工程師愛用的檔案格式。
其實仔細想想就可以明白了,工程師要的只是欄位內的數據而已,Excel內的各種其他資訊,包括表格長寬,字體顏色大小,公式計算等等,對系統來說都沒有任何意義。
但如果讓企劃直接使用純文字編輯器來調配數值,又顯得太不人性了一點。因此這中間通常都要有個轉換的工具。
一般在大型專案都會有這樣的一個小程式,執行之後可以把Excel的檔案轉換為程式讀取用的配置檔,例如CSV或是XML等等。有些甚至直接寫在Excel檔案的巨集當中,只要執行巨集,就能自動生成配置檔,相當方便。
這樣一來,企劃只要負責維護Excel表單,等到修改完畢後,轉成系統能讀取的配置表,再更新到對應的文件地址就行了。
延伸閱讀:
註解是配置表中相當重要的資訊,跟程式碼註解一樣,除了提醒負責的企劃自己以外,也能讓接手的人能快速進入狀況。
轉換工具有時也需要能「篩選掉註解」,就跟程式中的註解內容最終不會編譯進版本裡面一樣。這些註解僅供企劃們使用,不需要給到系統。
這邊有二篇筆者覺得挺有用的範例:
參考資料:策劃指南-配置表的使用(簡中)
參考資料:Unity遊戲配置表格代碼自動生成術(簡中)
千萬不要以為自己記憶力很好,什麼都記得住,所以就都不寫備註。當你面對幾十張表,而這個專案又橫跨兩三年的時候,任誰都無法記得所有細節。
常見使用的配置檔案格式
對系統來說,其實能讀取就行,無論用哪一種格式都可以達到目的。通常根據工程師的使用習慣,以及資料庫存儲上的考量,會統一遊戲內的配置表格式。
常見的格式包括:
XML(Extensible Markup Language,可延伸標記式語言)
CSV(Comma-Separated Values,逗號分隔式)
TSV(Tab-Separated Values,Tab分隔式)
XLS系列:都是Excel表單,包括Xlsx,Xls(Office舊版本,97~2003),Xlsb(二進位),Xlsm(啟用巨集的表單)等等。
但無論是使用哪種格式,只要企劃和程式能溝通好,讓系統正常運作即可。
設計配置表的準則
對企劃來說,設計配置表的時候一定要謹記兩件事情。
- 配置表要方便閱讀和維護。(這邊是指企劃看的表)
- 要保留未來的拓展空間。
所謂的方便閱讀,指的是這份配置表需要讓其他人也能看懂。因此欄位的名稱,配置表中的註解等等,都相當重要。
負責維護表單的企劃(通常是數值)一定要謹記,不要為了自己方便,用一些太過簡單的變數名或是懶得填備註,這會讓其他人在協助工作的時候遇到很大的麻煩。
以下列出幾個筆者認為需要留意的重點。
留意欄位的「性價比」
當企劃在設計配置表的時候,如果發現有一些欄位,大部分的情況下都配置了一樣的值(或是根本不配置,全部留0),就需要思考一下這個欄位是否有存在的必要。
舉個例子,如果今天設計怪物表,「黃金史萊姆」需要一個特殊的效果,就是無論攻擊他的傷害是多少,每單次攻擊都只會讓他受到「1」的傷害。
在這種情況下,就要考慮是否要合併或節省這個欄位。因為其他怪物都用不到這個配置值。
例如,請程式直接用Type這個欄位辨別,編號5就留給黃金史萊姆這種特殊怪物,只要是Type5,就自帶損血只能為1。
第二種解法,看看技能系統是否支持最大傷害值的配置,讓黃金史萊姆擁有一個特殊的被動技能,單次傷害的最高上限為1。
第三種解法,看看傷害計算公式是否允許讓防禦極高的時候出現「1」這樣的結果。同時確保以後角色的傷害不會突破這個閥值。這樣一來就可以將黃金史萊姆的防禦配的非常高,來達到這個效果。
最後一種解法,就是讓程序直接定義ID段,例如黃金史萊姆是2001,那我們就規定只要2001~2050這個ID段落的怪物,都做這樣的特殊處理。
(最後一種方式筆者不推薦使用,雖然用ID段定義可以省欄位,但在這個案例中,用其他配置來區別絕對是比較好的作法。)
留意「互斥」的欄位
例如在怪物表中,需要配置不同的屬性。
新手企劃可能會這樣配
這邊要注意,如果怪物本身不存在多重屬性的話,那這樣配是相當浪費欄位空間的。而且日後屬性漸漸增加的話,會讓欄位多到難以掌控。
因此屬性這種欄位,通常會配成這樣
所謂的「枚舉」(或稱為列舉,Enum,點我看解釋)就是在成員互斥的情況下,用來節省總欄位數量的一種方法。
類似這樣的情況其實很常見,在「更動或增加」欄位之前,不妨想一想有沒有其他的解決方法吧。
P.S. 其實Excel也可以直接製作下拉選單,這能避免在輸入的時候出錯:
點我看參考連結。
Google表單也有一樣的功能喔。
沒有註解或名稱,誰都看不懂
例如下面這張表:
如果變數名稱都沒有定義,也沒寫註解的話,任誰都沒辦法馬上理解這張表的內容。對維護工作來說,清楚的註解是相當重要的。
尤其是枚舉的內容,一定要寫在配置表中。
(同時也要注意,有些系統不支持中文變數,用英文比較保險。)
不要相信手動輸入,請搭配公式或剪貼功能
就算照著輸入也是很容易輸錯的,尤其是配置表這種多一個零可能會導致公關災難的事情,一定要非常小心!
在做複製之類的操作一定要記得用各種輔助工具來檢查。
程式需要有相應的「配置防呆」功能
這點也很重要,人是很有可能出錯的,配置表內如果含有特殊符號(例如空格或換行)都要特別留意,如果一張配置表內的符號就會導致遊戲Crash的話,那是非常危險的。
同時特殊符號的使用也需要明定規範,例如字串的配置中,字體格式顏色或是換行符號要用哪一種,如果一開始沒講清楚,很可能導致各種配置讀取錯誤喔!
ID編號盡可能保留「安全空間」
舉個例子,怪物的配置表如下所示:
今天突然有了新的需求,需要在一般史萊姆和史萊姆王中間,安插一隻「精英」等級的史萊姆。同時一般史萊姆需要增加到六種。
此時只能將Boss判斷欄位改成枚舉,並且增加ID段落:
這樣整張表會變得非常的難看(強迫症發作)。
有經驗的企劃,一開始就會保留彈性空間:
這樣表單是不是看起來整齊多了?
按照ID段落,也可以很輕易的辨別是否是Boss,或精英怪物等等。
要留多少空間,怎麼留,這些都是經驗,錯誤嘗試幾次就會懂了(泣)。
除了編號之間的空間,資料型別等等,都仰賴企劃的經驗。一開始就設想到未來的拓展方向,就能大大降低事後調整的工作量。
設計數值需求時的各種小秘訣
1.保護你的眼睛,使用正確的環境顏色
螢幕白色是最亮的,因為光線三原色一個都不缺。相較之下黑色就是不發光。
在需要長時間工作的時候,千萬記得打開螢幕的藍光保護模式,以及把表單轉為黑底淺字,降低職業傷害。
保護好你的眼睛,這是所有秘訣中最重要的一個。
2.用「單欄配置多組值」來縮減欄位
對程式來說,數值表的欄位是可以被「展開」的。也就是同一個欄位實際上可以填超過一個以上的值。
舉例來說,怪物的掉落表就常見這種形式:
以上圖為例,這裡的獨立機率指的是,根據群組,哪些掉落需要共享機率(互斥)。
上面寫的結果會是
1030002:80%的機率會掉落。
1030003和1030004:兩者必定掉落其中一個,各佔50%,是互斥的結果。
在欄位的數量不確定,同時又不想讓表單欄位變得太多,不好管理的情況下,就可以在同一欄位放置多個陣列成員,讓表單簡潔一點。
不過缺點就是不太好做反向驗證。例如若兩個同樣群組的掉落,總和機率大於100%,在表單上是很難直接看出來的。(因此這種情況通常用權重,但這邊先不做太多解釋)
3.「你不講話我就當是囉!」-將不標記視為一種標記
在設計表單的時候,不一定要把所有的可能性都列出來。可以和程式商量一個「大部分的情況」,然後僅需要配置特例就行。
舉個例子,假設現在遊戲中有5種屬性,採用循環相剋的設計,例如下圖:
因為只有五個屬性,所以看起來還好。
如果做10屬相剋,這張表就會變得很大。
這時,眼尖的讀者可能會注意到,除了1和-1,大部分其實都是0嘛。
如果和程式商量清楚,只要沒有提到的通通都代表不影響,那麼就可以把表濃縮一下,如下圖:
這邊也提一下「標籤」(Tags)的概念。
舉例來說,FGO(Fate Grand Order)中,角色會有一些特別的標籤。
這些標籤有些會影響和關卡敵人戰鬥時的加成。但由於這些標籤是特別的,量很大而且每一隻角色都不太一樣,這種時候就適合用String組來配置。
裡面的配置表有可能是長成這樣:
4.多重Bool大絕招:「位元域」(Bit Field)
在諸如怪物表或裝備表,設計的時候常常會出現「很多Bool判斷」。(Bool設定值中文也有人稱為「旗標」)
這時表會變得非常寬,同時也不太好複製內容。
別擔心,這邊提供一個有趣的小秘訣,叫做「位元域」。
(位元域,或稱為位元欄 Bit Field,是一種資料結構,點我看解釋)
所謂的位元域,跟程式概念中的Structure之類的概念相近,是一種資料結構,用來存放可以緊密相連的值。例如將多個很短的字段放成一個Bit Field儲存起來,這樣就可以節省空間。
可以簡單的想像成,如果資料型別是一個又一個的紙箱,但是內容物其實沒有全部塞滿,這時候將內容物拆散,以塞滿為原則的方式來儲存資料,就是位元域的基本概念。
在企劃的使用上,可以實現「一個值來儲存很多個Bool的狀態」。
具體的原理請看下圖:
例如2的10次方是1024,這就代表藉由0~1023不同的數字,可以用來表示十個Bool值的真或假,是相當實用的技巧喔。
在配置時,只要確定哪幾個設定為真,將他們代表的數值加起來,就可以用一個值來配置了。
當然在維護的時候,直接看數字不容易直接拆成數個值,所以表單需要做處理,讓使用者可以很輕易的勾選Bool值,最後在輸出的時候,濃縮成一個欄位即可。
5.嵌套與遞迴
在設計配置表規則的時候,也可以讓這張表的某個欄位「查找自身」,用這種方式來增加配置的彈性。
例如在掉落表欄位中配置另一項掉落ID,就是相當常見的作法。
不過要留意這種遞迴的配置法如果出現無窮迴圈會造成系統問題,此外很容易不小心配置了重複的內容,在做檢驗的時候要多留意些。
6.用基礎+調整值的方式來設計欄位
面對超大量的怪物或是英雄,有時在調整數值的時候會覺得工作量很大。
其實可以將數值的「調整值」提取出來,方便配置。
概念就跟小時候學過的「提取公因式」的作法是類似的。
也就是例如
(20+50)=10(2+5)
將公因數提取之後,可以讓表變得更加簡潔。
舉個實例,在遊戲中我們對怪物的定位可能分為「戰士」,「法師」,「盜賊」和「弓箭手」等四種,戰士皮厚肉粗但速度慢,盜賊攻擊高防禦低,弓箭手敏捷高,法師精神高等等。
但因為隨著等級上升,怪物是會跟著變強的。
因此我們可以將「職業」這個公因數提出來,把職業調整值另外配成一張表,如下所示:
這樣維護上會更方便,數值平衡也會更好掌握。
7.組合型字串的應用
這其實在檔案分類管理的習慣中是很常見的,例如利用日期來歸檔,名稱命名為「20191204」,大家都可以清楚明白是年+月+日的組合。
配置表也一樣,可以用單一數字來紀錄多個資料。
例如今天要紀錄矩陣方格地形,有XYZ三個軸向的座標。如果長寬高都不會超過999的話,那座標可以被儲存為一個九位數的值 XXXYYYZZZ。等到程式要使用的時候,再拆解出來就行了。
或是在編號上作為辨別使用,例如道具的ID如下:
Excel相關技巧
配置表的設計技巧就到這邊,接下來我們來看一些Excel比較特別的技巧吧。
基礎的技能這邊就不列了,包括凍結窗格、篩選排序、行列互換和尋找取代等等,這些都是基本功,有需要的朋友自行Google囉。
順道一題,Google試算表其實這些功能大部分都支持了,如果需要多人線上協作的話,也是一個不錯的選擇。
1.驗證資料(尋找重複值)
在配置表中,最需要擔心的就是 Primary Key 出現重複。
為了避免這件事情,可以很簡單的用驗證格式來做。
2.Vlookup
Vlookup是用來查詢「Key」在對應的「欄位中」的值。
例如說,有一張表列出了ID和對應的電話號碼。此時你可以用這個函式,將指定的ID對應的電話號碼導出。
Vlookup非常有用,尤其是在後面提到的多語言版本會用到。常常和鎖定符號$一起使用。
當你的配置表欄位超過一萬的時候,你會需要有些工具幫你快速做比對。
例如以多語言檔案來說,比對同樣一串文字,在不同語言中的翻譯,有沒有字串或是需要導出字串等等。
3.善用”&”和遞迴
有時會遇到,需要把一堆ID塞到一個欄位內的時候。
此時可以依靠公式和遞迴原理來完成。
配置的地獄:「多語言檔案」
在實作國際專案的時候,常常會遇到需要「多種語言版本」的需求。
通常我們會藉由把遊戲中的文字先配置為「Key」,再根據使用者的版本,替換成對應的「值」(文字字串)。
例如像是下圖這樣
通常一個專案的外包翻譯流程會是這樣的。
專案內的字串需求確定後,將多語言的Key表和說明備註交給外包,在翻譯期間會有各種需求,例如某個字串的實際意思是如何,或是需要提供遊戲本體和界面截圖等等。
這時Key的文字就非常重要,除了方便查找,一看key的敘述就知道是哪個系統使用的,細節沒做好導致的額外工作量,在做翻譯的時候會特別明顯。
總之,返回的翻譯會是Key值對應翻譯文字。此時運用上面的Vlookup函式就可以將翻譯導回原本的多語言表當中。(當然自己寫個小程式專門導入是最快的啦)
P.S.在做多語言的時候,一定要注意「超框」的問題。因為不同語言的字數不同(例如字超多的俄語),因此讓系統做根據字數調整大小,或是一開始在給外包翻譯的時候就附上字符數的限制是最好的。
額外閱讀:多語言資料包
在實作的時候,其實很多玩家只會遊玩自己地區常用的語言。在上架的時候,App本身可以只包進對應的語言資料,或是連線後僅下載該地區的語言。
等玩家自己想要切換其他語言時,再下載指定的資料,這樣可以縮小一開始的遊戲包體大小。
額外閱讀:i18n與l10n
在做國際市場的時候,常常會聽到兩個詞,分別是「國際化」與「在地化」。
國際化(Internationalization)
也簡稱I18N,因為i和n中間有18個字母,故而得名。(這是習慣用法不是筆者亂掰的喔)
國際化指的是針對要適應各國不同環境,所做的前置作業。
在地化(Localization)
同上,簡稱L10N。
在地化指的是因應地區差異,進行調整的過程。
此外還有g11n和l12y之類的這邊就不贅述。
簡單來說,國際化就是先做好架構,讓在地化方便進行。
以多語言為例,做好多語系功能和配置架構就是國際化,實際依照各國差異翻譯文字,以及調整用詞和美術資源就是在地化。
配置的終極進化:「腳本」(Script)
恭喜各位來到配置的最後一站,腳本。
在製作遊戲的過程中,往往會發現需要非常彈性,不能只靠配置表解決一切的狀況。
舉例來說,過場動畫的演出,如果要靠配置表來配,那欄位可能會非常可觀,包括角色動作、特效、台詞和立繪切換等等。
這種情況下,最適合使用的就是「腳本」了。
所謂的腳本(Script),是一種輕量級的程式語言,通常有「不那麼嚴謹」和「學習門檻低」的優點,不適合做系統的主架構語言,但作為可抽換的嵌入式內容相當適合。
常見的腳本語言像是Javascript(備註:和Java是完全不同的語言喔),Lua等等,都有上述的特點。
在這種需要大量調整的情況下,不太可能讓程式搭配企劃來進行,只有企劃知道他想要呈現的演出效果,此時腳本就會是最好的選擇。
雖然相對而言沒有配置表那麼簡單明瞭,但彈性相當高。作為遊戲企劃,其實有機會摸摸Code也是不錯的訓練喔。
好啦,這篇落落長寫了五六千字,都是筆者自己在做企劃時的經驗談,希望有幫助到大家。
今天就到這邊,我是水狼,我們下次見。
也可以到臉書追蹤我喔: 粉絲專頁連結
最後,請多利用我的個人文章列表,會持續更新: