遊戲設計的好書 The Art of Game Design: A Book of Lenses

通常我自身是比較不建議用純看書的方法來瞭解遊戲設計，
因為"讀萬卷書不如行萬里路"，
遊戲設計由實作來得到驗證會比看書來的深刻。

當然也不是說看書一定沒有幫助，
有的時候參考別人的想法也是對自己有一定的助益。

在台灣遊戲業待了6年，會好奇別人是怎麼遊戲的，
所以就去找遊戲設計相關的書來看。

那時候就挑到了這本The Art of Game Design，
在網路上試閱了前面幾章後，感覺寫的不錯，
就立刻去天瓏把它買下來了。

如書名A book of lenses，提供各種透鏡(lenses)，讓我們以多種角度去審視遊戲。

本書在前面幾節也提到了親手做遊戲才是真正成為遊戲開發者的方法，

所以妄想從某本書籍就能做遊戲是不切實際的。

雖然書籍作者Jesse Schell參與的遊戲我都沒玩過，

但是作者的經歷還滿有趣的，

曾經做為馬戲團員、魔術師助手、作者、喜劇演員、軟體工程師、大學教授。

本書是以傳統的電玩遊戲為範本，將遊戲分為四個部份，

Aesthetics(美學)、Mechanics(機制)、Story(故事)、Technology(科技)。

美學是指遊戲的外在呈現，包含了畫面、音效、感受等外在因素。

機制則是代表了遊戲的規則。

故事是一連串不同的事件，讓玩家一步步進入遊戲。

科技則是目前製作電玩遊戲所須的基礎知識。

建議有做基本遊戲製作能力的人來閱讀這本書，

若對遊戲製作還很陌生的話，可以先找做遊戲的教學，

如果英文比較不熟的人，有另一本簡體中文的書籍可以看

通關遊戲設計之道 (Level Up!: The Guide to Great Video Game Design )。

但是上面這本書我就沒有全部看完了，

因為製作遊戲需要的知識太多了，還是從實作去學習知識比較快。

遊戲設計相關的書籍有繁體中文的相當少，

可以多找找國外的資源。

我想成為成為遊戲作家

這次分享一篇關於「I Want to Write Video Games」，並且參雜一些個人經驗談。因為我的英文實在不怎麼樣，信達雅是沾不到邊，想知道細節請看原文，我個人想法會以「我認為」開頭


在開始之前……
問自己這個問題，你覺得遊戲作家是甚麼？

想當哪一種？

文中將這個職缺分為兩種：
 比較複雜的那種，稱之為敘事設計師（narrative designer ），創作整個遊戲故事的人。故事的進展、時間節奏、角色弧線。簡單的說，就是負責設計玩家體驗（player experience）
而那些不參與設計的稱為寫手（writer），寫手的工作相對單純，在既定框架下寫出符合規範的劇情、人物、教學、提示等等。除此之外，遊戲中還是有大量的文字等著你寫。

這兩者都不是埋頭寫完就將稿件交出去，然後等著團隊將其實現。而且也不能隨心所欲的想怎麼寫就怎麼寫。

你的文字不是最終成品，而是要透過遊戲展現。你必須反覆與團隊商量，依照預算、時間的限制，遊戲中實際的呈現方式來修改。

我的故事超讚！

即便你是敘事設計師，負責整個遊戲故事的創作，也不能保證故事情節必定如你所想的發展。

在遊戲開發的過程中有太多不可控制的因素。
像是你寫了城堡，但是城堡這個場景在美術的排程上來不及完成，或是你的城堡金碧輝煌的不符合製作成本。

文中說得很直白，你要花很多時間在重寫，刪減橋段、修改情節、斟酌對白用字，大概80%的時間是在修改這些大便，是的，在遊戲完成前的大部分時間你都在做這些事。

如果你這麼堅持原則、無法妥協，甚至無法忍受這些不可控制的因素，去寫小說會比較好。

該怎麼找到這種工作？

你可以不用找了，並不是所有的遊戲都有「龐大的文字需求」，不是所有的遊戲都像GTA、Last of us，所以很顯然的這種職缺很少，甚至用外包的方式來處理。
這樣的專門職缺越來越少，很重要的原因是寫作這種技能很難展現出來。

美術看作品集，程式看程式碼。這個職缺會被歸類為企劃，而企劃正是最難獨自展現能力的一群，寫作技巧固然可從作品中看出一點端倪，卻不容易鑑別出好與優秀。

去觀察你期望的那間公司，玩遍它所製作的遊戲，了解他們的風格，掌握這種風格，這樣在你投遞作品時更有機率獲選。

加入新創團隊，因為他們什麼都缺，也沒什麼人可以挑。只要你能證明自己夠格，並獲得青睞。

該如何精進？

如果你還是學生，想知道有什麼課程可以幫助你。

好吧，沒有！

沒有課程教你如何成為遊戲作家，所以你就什麼都去學習吧！
除此之外，持續的閱讀，廣泛的閱讀，因為所有你所看過、經歷過的，都能轉化成你創作的靈感與養分。
玩遊戲，分析那些故事性強烈的遊戲，看他們怎麼鋪陳，怎麼將文字轉化為遊戲，如何與玩家互動，哪部分做得好，那部分做得不好。
然後練習，寫作需要持續練習才能進步。將故事轉化成遊戲也需要練習，試著製作遊戲，將心中所想的呈現出來。

不要寫同人當作品，因為既有的角色已經成形，這些角色並不是被你的文字賦予血肉，並不因為你的文字而變得生動，而是原作的努力。

嚴格來說，這還會會掩蓋你的表現，展現技巧這件事已經很困難了，別給自己找麻煩。

我認為

故事超讚，真的需要改嗎？
大概就像看過多場籃球比賽覺得自己能去打NBA，或是老饕吃過很多美食，突然語出驚人：「我想到一種新菜色超好吃，戈登拉姆齊也會讚嘆！」

你知道要像《百年孤寂》在結尾來一場同步大毀滅，這在實際上非常難做。

即使你已在出版業小有名氣，甚至是職業作家，也不代表你的作品能變成好遊戲。

哈姆雷特，西遊記等可列為經典的文學作品，可不是每部翻拍成電影都很賣座。

而像巫師這樣小說改成遊戲並且成功的案例可就更少了。

關於寫作的練習上，一開始我沒預設要用什麼方式書寫，但是現在我會建議用劇本的方式書寫。
這是我個人經驗，故事在轉化為遊戲演出前，要先被製作團隊理解然後才會產出，我覺得劇本是很好的溝通格式。

例如：「他走過一條小溪，溪水清澈的能看到底下的鵝卵石。」
只有設計者知道這段文字要帶給玩家什麼樣的體驗
而不同人閱讀這段文字後，心中呈現出的圖像並不相同。
畫面上的人是面對鏡頭呢還是背對？小溪是要流向哪邊呢？鵝卵石數量很多嗎？這個畫面是要凸顯他過小溪？還是溪水很清澈？還是小溪中的鵝卵石有什麼異狀？基於心象的一致性，最好讓閱讀者心中呈現想像沒有太大的差距，而劇本則能表示幕與幕的連接關係。

我不建議運用實驗性寫作手法或技巧。
例如意識流，除非你能確實驗證，讓最後的演出呈現出意識流效果。你所呈現的故事並不是直接以文本的方式呈現，即便以電子小說方式也有音樂與美術搭配閱讀節奏來展示，特殊技巧只是徒增困擾而已。

後記

遊戲業界總是有單人開發出卓越遊戲的案例，不否認這些開發者真的相當優秀，程式美術企劃兼具！很可惜我們大部份都沒有這樣的才能，所以我認為遊戲開發是一群人合作產生的，團隊成員的協調、溝通能力應該更重要。

近日我的朋友圈中有人出國健行，他們背著重裝在北極圈走了一百公里。他們說了一句話，特別有感觸，於是記了下來。

一個人可以走很快，但是一群人可以走很遠！

共勉之，那麼下次再聊。

基表設計

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

基表的用途

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

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

「本週只要參與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掉。
這件問題發生，首先是人員，再來是怎麼會有如此危險的按鈕在後台人人可按到的地方？
如果有個按鈕出現，請預設在最糟的狀況按下會發生什麼事吧！

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