遊戲企劃必修課:了解「配置表」Part.02

每天面對一堆配置表單,就是企劃的工作。

水狼陽介
THAT GAME DESIGNER - 遊戲設計師
19 min readDec 4, 2019

--

上一篇講解了配置表由來和基礎概念(還沒看過的請點我前往)

今天要帶大家來實際看一些企劃在設計配置表時會遇到的問題,以及一些工作上會用到的小技巧。

可能看起來會比較像是沒整理的筆記(汗),不過應該還是對新手有一點幫助的。

配置表是程式和企劃的溝通媒介

配置表在遊戲中扮演著重要的角色,雖然設計者是企劃,但最終是要交給工程師來讀取和使用的。因此,需要同時滿足企劃方便設計維護,且工程師方便操作資料庫的雙方需求。

在設計系統需求時,往往寫了一堆文字工程師也不見得看得懂。

這時直接搬出配置需求就行,根據欄位的內容,工程師們能夠迅速準確的理解系統構造。

與其讓工程師看文字,不如直接把表格秀出來。同理,和美術溝通的時候,參考圖絕對比敘述重要。

該用什麼程式來編輯配置表?

企劃最愛用的,莫過於微軟自家的Office Excel系列了,支持各種公式,內建各種輔助工具等等,Excel表單能滿足幾乎所有的數值處理需求,但只有一個缺點……它不是工程師愛用的檔案格式。

其實仔細想想就可以明白了,工程師要的只是欄位內的數據而已,Excel內的各種其他資訊,包括表格長寬,字體顏色大小,公式計算等等,對系統來說都沒有任何意義。

但如果讓企劃直接使用純文字編輯器來調配數值,又顯得太不人性了一點。因此這中間通常都要有個轉換的工具。

資料表格式其實可以直接寫成像右側記事本一樣,但企劃用這個來編輯表會累死……

一般在大型專案都會有這樣的一個小程式,執行之後可以把Excel的檔案轉換為程式讀取用的配置檔,例如CSV或是XML等等。有些甚至直接寫在Excel檔案的巨集當中,只要執行巨集,就能自動生成配置檔,相當方便。

google一下,就可以發現非常多轉檔的方法。Excel內建的另存新檔也可以支持轉其他格式,但要注意會不會丟失表單內容。最保險的方法還是自己寫一套轉換工具。

這樣一來,企劃只要負責維護Excel表單,等到修改完畢後,轉成系統能讀取的配置表,再更新到對應的文件地址就行了。

延伸閱讀:

註解是配置表中相當重要的資訊,跟程式碼註解一樣,除了提醒負責的企劃自己以外,也能讓接手的人能快速進入狀況。

轉換工具有時也需要能「篩選掉註解」,就跟程式中的註解內容最終不會編譯進版本裡面一樣。這些註解僅供企劃們使用,不需要給到系統。

這邊有二篇筆者覺得挺有用的範例:
參考資料:策劃指南-配置表的使用(簡中)
參考資料:Unity遊戲配置表格代碼自動生成術(簡中)

千萬不要以為自己記憶力很好,什麼都記得住,所以就都不寫備註。當你面對幾十張表,而這個專案又橫跨兩三年的時候,任誰都無法記得所有細節

常見使用的配置檔案格式

對系統來說,其實能讀取就行,無論用哪一種格式都可以達到目的。通常根據工程師的使用習慣,以及資料庫存儲上的考量,會統一遊戲內的配置表格式。

常見的格式包括:

XML(Extensible Markup Language,可延伸標記式語言)

CSV(Comma-Separated Values,逗號分隔式)

TSV(Tab-Separated Values,Tab分隔式)

JSON(或其他類似的輕量級的資料交換語言)

XLS系列:都是Excel表單,包括Xlsx,Xls(Office舊版本,97~2003),Xlsb(二進位),Xlsm(啟用巨集的表單)等等。

把 Excel 檔案打開再另存新檔,會發現有非常多格式可以選擇。這邊因為是簡體環境,「宏」的意思就是「巨集」。其中,txt副檔名其實就是TSV的一種,只用換行和Tab來做資料儲存。

但無論是使用哪種格式,只要企劃和程式能溝通好,讓系統正常運作即可。

設計配置表的準則

對企劃來說,設計配置表的時候一定要謹記兩件事情。

  1. 配置表要方便閱讀和維護。(這邊是指企劃看的表)
  2. 要保留未來的拓展空間。

所謂的方便閱讀,指的是這份配置表需要讓其他人也能看懂。因此欄位的名稱,配置表中的註解等等,都相當重要。

負責維護表單的企劃(通常是數值)一定要謹記,不要為了自己方便,用一些太過簡單的變數名或是懶得填備註,這會讓其他人在協助工作的時候遇到很大的麻煩。

以下列出幾個筆者認為需要留意的重點。

留意欄位的「性價比」

當企劃在設計配置表的時候,如果發現有一些欄位,大部分的情況下都配置了一樣的值(或是根本不配置,全部留0),就需要思考一下這個欄位是否有存在的必要。

舉個例子,如果今天設計怪物表,「黃金史萊姆」需要一個特殊的效果,就是無論攻擊他的傷害是多少,每單次攻擊都只會讓他受到「1」的傷害。

如上圖,只有Golden Slime才會用到的特殊欄位。

在這種情況下,就要考慮是否要合併或節省這個欄位。因為其他怪物都用不到這個配置值。

例如,請程式直接用Type這個欄位辨別,編號5就留給黃金史萊姆這種特殊怪物,只要是Type5,就自帶損血只能為1。

第二種解法,看看技能系統是否支持最大傷害值的配置,讓黃金史萊姆擁有一個特殊的被動技能,單次傷害的最高上限為1。

第三種解法,看看傷害計算公式是否允許讓防禦極高的時候出現「1」這樣的結果。同時確保以後角色的傷害不會突破這個閥值。這樣一來就可以將黃金史萊姆的防禦配的非常高,來達到這個效果。

例如像是將防禦配的超級無敵高。但這也要傷害計算公式支持這樣的作法才行。

最後一種解法,就是讓程序直接定義ID段,例如黃金史萊姆是2001,那我們就規定只要2001~2050這個ID段落的怪物,都做這樣的特殊處理。

(最後一種方式筆者不推薦使用,雖然用ID段定義可以省欄位,但在這個案例中,用其他配置來區別絕對是比較好的作法。)

留意「互斥」的欄位

例如在怪物表中,需要配置不同的屬性。

新手企劃可能會這樣配

根據不同的屬性,給予不同的Bool值操控。

這邊要注意,如果怪物本身不存在多重屬性的話,那這樣配是相當浪費欄位空間的。而且日後屬性漸漸增加的話,會讓欄位多到難以掌控。

因此屬性這種欄位,通常會配成這樣

在屬性互斥(也就是只會有一種)的情況下,放在同一欄就能大大節省欄位量。

所謂的「枚舉」(或稱為列舉,Enum,點我看解釋)就是在成員互斥的情況下,用來節省總欄位數量的一種方法。

類似這樣的情況其實很常見,在「更動或增加」欄位之前,不妨想一想有沒有其他的解決方法吧。

P.S. 其實Excel也可以直接製作下拉選單,這能避免在輸入的時候出錯:
點我看參考連結。
Google表單也有一樣的功能喔。

沒有註解或名稱,誰都看不懂

例如下面這張表:

Arg是變數Argument的縮寫

如果變數名稱都沒有定義,也沒寫註解的話,任誰都沒辦法馬上理解這張表的內容。對維護工作來說,清楚的註解是相當重要的。

尤其是枚舉的內容,一定要寫在配置表中。

(同時也要注意,有些系統不支持中文變數,用英文比較保險。)

不要相信手動輸入,請搭配公式或剪貼功能

就算照著輸入也是很容易輸錯的,尤其是配置表這種多一個零可能會導致公關災難的事情,一定要非常小心!

在做複製之類的操作一定要記得用各種輔助工具來檢查。

程式需要有相應的「配置防呆」功能

這點也很重要,人是很有可能出錯的,配置表內如果含有特殊符號(例如空格或換行)都要特別留意,如果一張配置表內的符號就會導致遊戲Crash的話,那是非常危險的。

同時特殊符號的使用也需要明定規範,例如字串的配置中,字體格式顏色或是換行符號要用哪一種,如果一開始沒講清楚,很可能導致各種配置讀取錯誤喔!

ID編號盡可能保留「安全空間」

舉個例子,怪物的配置表如下所示:

怪物的ID緊密連結,同時用一個Bool來判斷是否為Boss。

今天突然有了新的需求,需要在一般史萊姆和史萊姆王中間,安插一隻「精英」等級的史萊姆。同時一般史萊姆需要增加到六種。

此時只能將Boss判斷欄位改成枚舉,並且增加ID段落:

這樣整張表會變得非常的難看(強迫症發作)。

有經驗的企劃,一開始就會保留彈性空間:

上面是舊表,下面是拓展後。要習慣一開始就把ID的空間留出來。

這樣表單是不是看起來整齊多了?

按照ID段落,也可以很輕易的辨別是否是Boss,或精英怪物等等。

要留多少空間,怎麼留,這些都是經驗,錯誤嘗試幾次就會懂了(泣)。

除了編號之間的空間,資料型別等等,都仰賴企劃的經驗。一開始就設想到未來的拓展方向,就能大大降低事後調整的工作量。

設計數值需求時的各種小秘訣

1.保護你的眼睛,使用正確的環境顏色

螢幕白色是最亮的,因為光線三原色一個都不缺。相較之下黑色就是不發光。

在需要長時間工作的時候,千萬記得打開螢幕的藍光保護模式,以及把表單轉為黑底淺字,降低職業傷害。

看個幾秒鐘沒問題,但當你要盯著看一整天,還要專注搜尋的時候……

保護好你的眼睛,這是所有秘訣中最重要的一個。

2.用「單欄配置多組值」來縮減欄位

對程式來說,數值表的欄位是可以被「展開」的。也就是同一個欄位實際上可以填超過一個以上的值。

舉例來說,怪物的掉落表就常見這種形式:

同一個欄位用括號和逗號配置多組數值

以上圖為例,這裡的獨立機率指的是,根據群組,哪些掉落需要共享機率(互斥)。

上面寫的結果會是

1030002:80%的機率會掉落。

1030003和1030004:兩者必定掉落其中一個,各佔50%,是互斥的結果。

在欄位的數量不確定,同時又不想讓表單欄位變得太多,不好管理的情況下,就可以在同一欄位放置多個陣列成員,讓表單簡潔一點。

不過缺點就是不太好做反向驗證。例如若兩個同樣群組的掉落,總和機率大於100%,在表單上是很難直接看出來的。(因此這種情況通常用權重,但這邊先不做太多解釋)

3.「你不講話我就當是囉!」-將不標記視為一種標記

在設計表單的時候,不一定要把所有的可能性都列出來。可以和程式商量一個「大部分的情況」,然後僅需要配置特例就行。

舉個例子,假設現在遊戲中有5種屬性,採用循環相剋的設計,例如下圖:

隨便舉個例子
簡單列一下高效和低效攻擊

因為只有五個屬性,所以看起來還好。

如果做10屬相剋,這張表就會變得很大。

這時,眼尖的讀者可能會注意到,除了1和-1,大部分其實都是0嘛。

如果和程式商量清楚,只要沒有提到的通通都代表不影響,那麼就可以把表濃縮一下,如下圖:

上面的表捨棄「一般情況」,就可以濃縮成下面這個簡短的配置了。

這邊也提一下「標籤」(Tags)的概念。

舉例來說,FGO(Fate Grand Order)中,角色會有一些特別的標籤。

這些標籤有些會影響和關卡敵人戰鬥時的加成。但由於這些標籤是特別的,量很大而且每一隻角色都不太一樣,這種時候就適合用String組來配置。

FGO中,角色根據背景故事、登場的活動等等都會有不同的Traits。有些會影響關卡的加成。

裡面的配置表有可能是長成這樣:

上面是直接配置字符組,下面是用枚舉的方式。

4.多重Bool大絕招:「位元域」(Bit Field)

在諸如怪物表或裝備表,設計的時候常常會出現「很多Bool判斷」。(Bool設定值中文也有人稱為「旗標」)

在做異常狀態的時候常會有這種配置出現,內容越多越難管理。

這時表會變得非常寬,同時也不太好複製內容。

別擔心,這邊提供一個有趣的小秘訣,叫做「位元域」。

(位元域,或稱為位元欄 Bit Field,是一種資料結構,點我看解釋)

所謂的位元域,跟程式概念中的Structure之類的概念相近,是一種資料結構,用來存放可以緊密相連的值。例如將多個很短的字段放成一個Bit Field儲存起來,這樣就可以節省空間。

可以簡單的想像成,如果資料型別是一個又一個的紙箱,但是內容物其實沒有全部塞滿,這時候將內容物拆散,以塞滿為原則的方式來儲存資料,就是位元域的基本概念。

在企劃的使用上,可以實現「一個值來儲存很多個Bool的狀態」。

具體的原理請看下圖:

只要是2的次方,就能不重複的組合出各種結果。每種結果只有一種相加的可能,絕對不會出錯。

例如2的10次方是1024,這就代表藉由0~1023不同的數字,可以用來表示十個Bool值的真或假,是相當實用的技巧喔。

在配置時,只要確定哪幾個設定為真,將他們代表的數值加起來,就可以用一個值來配置了。

這項技巧的應用筆者一開始是在Minecraft中學到的,當時覺得用一個值紀錄一堆真假狀態真的超級神奇的。

當然在維護的時候,直接看數字不容易直接拆成數個值,所以表單需要做處理,讓使用者可以很輕易的勾選Bool值,最後在輸出的時候,濃縮成一個欄位即可。

5.嵌套與遞迴

在設計配置表規則的時候,也可以讓這張表的某個欄位「查找自身」,用這種方式來增加配置的彈性。

例如在掉落表欄位中配置另一項掉落ID,就是相當常見的作法。

這樣配置的話,所有的史萊姆都會掉落黏液。

不過要留意這種遞迴的配置法如果出現無窮迴圈會造成系統問題,此外很容易不小心配置了重複的內容,在做檢驗的時候要多留意些。

6.用基礎+調整值的方式來設計欄位

面對超大量的怪物或是英雄,有時在調整數值的時候會覺得工作量很大。

其實可以將數值的「調整值」提取出來,方便配置。

概念就跟小時候學過的「提取公因式」的作法是類似的。

也就是例如

(20+50)=10(2+5)

將公因數提取之後,可以讓表變得更加簡潔。

舉個實例,在遊戲中我們對怪物的定位可能分為「戰士」,「法師」,「盜賊」和「弓箭手」等四種,戰士皮厚肉粗但速度慢,盜賊攻擊高防禦低,弓箭手敏捷高,法師精神高等等。

但因為隨著等級上升,怪物是會跟著變強的。

因此我們可以將「職業」這個公因數提出來,把職業調整值另外配成一張表,如下所示:

將職業表獨立出來,怪物表僅配置等級差異和職業類型。讓系統根據職業定位,自動調整最終的數值。

這樣維護上會更方便,數值平衡也會更好掌握。

7.組合型字串的應用

這其實在檔案分類管理的習慣中是很常見的,例如利用日期來歸檔,名稱命名為「20191204」,大家都可以清楚明白是年+月+日的組合。

配置表也一樣,可以用單一數字來紀錄多個資料。

例如今天要紀錄矩陣方格地形,有XYZ三個軸向的座標。如果長寬高都不會超過999的話,那座標可以被儲存為一個九位數的值 XXXYYYZZZ。等到程式要使用的時候,再拆解出來就行了。

或是在編號上作為辨別使用,例如道具的ID如下:

道具ID是由各種數字組合來表達的

Excel相關技巧

配置表的設計技巧就到這邊,接下來我們來看一些Excel比較特別的技巧吧。

基礎的技能這邊就不列了,包括凍結窗格、篩選排序、行列互換和尋找取代等等,這些都是基本功,有需要的朋友自行Google囉。

順道一題,Google試算表其實這些功能大部分都支持了,如果需要多人線上協作的話,也是一個不錯的選擇。

1.驗證資料(尋找重複值)

在配置表中,最需要擔心的就是 Primary Key 出現重複。

為了避免這件事情,可以很簡單的用驗證格式來做。

操作方法請點我

用這種方式可以很輕易的辨別欄位中重複或唯一的值。可以讓系統自動標紅或其他特殊格式,也可以設定不只一種驗證內容。

2.Vlookup

Vlookup是用來查詢「Key」在對應的「欄位中」的值。

例如說,有一張表列出了ID和對應的電話號碼。此時你可以用這個函式,將指定的ID對應的電話號碼導出。

Vlookup非常有用,尤其是在後面提到的多語言版本會用到。常常和鎖定符號$一起使用。

例如參考資料中的範例,利用縣市別作為搜尋詞,來導出電話。

說明請點我

或比較白話的解說版本

當你的配置表欄位超過一萬的時候,你會需要有些工具幫你快速做比對。

例如以多語言檔案來說,比對同樣一串文字,在不同語言中的翻譯,有沒有字串或是需要導出字串等等。

3.善用”&”和遞迴

有時會遇到,需要把一堆ID塞到一個欄位內的時候。

此時可以依靠公式和遞迴原理來完成。

想把多個ID弄成一組
利用&加上自動完成,往下一拉就整理好囉~
最後使用「貼上值」就可以只貼上數值而不是公式了

配置的地獄:「多語言檔案」

在實作國際專案的時候,常常會遇到需要「多種語言版本」的需求。

通常我們會藉由把遊戲中的文字先配置為「Key」,再根據使用者的版本,替換成對應的「值」(文字字串)。

例如像是下圖這樣

會由一張很大的多語系配置表來控制各種語言。

通常一個專案的外包翻譯流程會是這樣的。

專案內的字串需求確定後,將多語言的Key表和說明備註交給外包,在翻譯期間會有各種需求,例如某個字串的實際意思是如何,或是需要提供遊戲本體和界面截圖等等。

這時Key的文字就非常重要,除了方便查找,一看key的敘述就知道是哪個系統使用的,細節沒做好導致的額外工作量,在做翻譯的時候會特別明顯。

遊戲內的文字一開始都是以Key的形式呈現的。多語言檔案有字串才取代,這樣也方便測試人員尋找還沒配置的字串。

總之,返回的翻譯會是Key值對應翻譯文字。此時運用上面的Vlookup函式就可以將翻譯導回原本的多語言表當中。(當然自己寫個小程式專門導入是最快的啦)

P.S.在做多語言的時候,一定要注意「超框」的問題。因為不同語言的字數不同(例如字超多的俄語),因此讓系統做根據字數調整大小,或是一開始在給外包翻譯的時候就附上字符數的限制是最好的。

額外閱讀:多語言資料包

在實作的時候,其實很多玩家只會遊玩自己地區常用的語言。在上架的時候,App本身可以只包進對應的語言資料,或是連線後僅下載該地區的語言。

等玩家自己想要切換其他語言時,再下載指定的資料,這樣可以縮小一開始的遊戲包體大小。

額外閱讀:i18n與l10n

在做國際市場的時候,常常會聽到兩個詞,分別是「國際化」與「在地化」。

國際化(Internationalization)

也簡稱I18N,因為i和n中間有18個字母,故而得名。(這是習慣用法不是筆者亂掰的喔)

國際化指的是針對要適應各國不同環境,所做的前置作業。

在地化(Localization)

同上,簡稱L10N。

在地化指的是因應地區差異,進行調整的過程。

此外還有g11n和l12y之類的這邊就不贅述。

可以參考這篇:i18n v.s. l10n(英文)

簡單來說,國際化就是先做好架構,讓在地化方便進行。

以多語言為例,做好多語系功能和配置架構就是國際化,實際依照各國差異翻譯文字,以及調整用詞和美術資源就是在地化。

配置的終極進化:「腳本」(Script)

恭喜各位來到配置的最後一站,腳本。

在製作遊戲的過程中,往往會發現需要非常彈性,不能只靠配置表解決一切的狀況。

舉例來說,過場動畫的演出,如果要靠配置表來配,那欄位可能會非常可觀,包括角色動作、特效、台詞和立繪切換等等。

這種情況下,最適合使用的就是「腳本」了。

所謂的腳本(Script),是一種輕量級的程式語言,通常有「不那麼嚴謹」和「學習門檻低」的優點,不適合做系統的主架構語言,但作為可抽換的嵌入式內容相當適合。

常見的腳本語言像是Javascript(備註:和Java是完全不同的語言喔),Lua等等,都有上述的特點。

引用自智庫百科對腳本語言的定義:

在這種需要大量調整的情況下,不太可能讓程式搭配企劃來進行,只有企劃知道他想要呈現的演出效果,此時腳本就會是最好的選擇。

雖然相對而言沒有配置表那麼簡單明瞭,但彈性相當高。作為遊戲企劃,其實有機會摸摸Code也是不錯的訓練喔。

好啦,這篇落落長寫了五六千字,都是筆者自己在做企劃時的經驗談,希望有幫助到大家。

今天就到這邊,我是水狼,我們下次見。

--

--

水狼陽介
THAT GAME DESIGNER - 遊戲設計師

「十個企劃九個宅,還有一個特別宅。」一位忙碌的遊戲從業者。https://www.facebook.com/MizuArk