遊戲企畫．GD-X【005】：設計文件撰寫心法
「好文件讓團隊上天堂，爛文件讓團隊住貧房......」
在遊戲界，孤身一人
討厭拉黨結派、討厭白目、討厭沒效率
只有身經百戰的實務經驗是他僅有的武器
遊戲企劃 瑞森，別名 GD-X
有了遊戲界的老狐狸寫的這篇「遊戲企劃書該怎麼寫？」以我的等級就不方便誤導大家了.....（謎之聲：什麼！！！這篇，這樣就結束了嗎？）當然，沒有啦！就像我開頭所講的，我來以個人經驗分享一下，我怎麼寫遊戲設計文件～不管好評、壞評，都是我的青春啊！！！
文件的基本框架
企劃文件很難有固定格式，因為遊戲內容之間的差異、變化太大了，很難找到一本通用的文件格式。（上頭總是想拿軟體工程那套作法來應用於遊戲開發上，企圖提昇遊戲內容的產能。目前看下來，沒有比較好的成果......。遊戲開發可以算是一種軟體開發，但成功的核心在於設計面，過於制式往往把設計面限制住了XD）我很在意別人是否看得懂我在寫什麼？發現有人對於文件描述不太理解，經過解釋後也同時會立即修正。經年累月的琢磨，也磨出自己在用的文件框架～目的是讓團隊成員能由淺入深地瞭解文件內容，也藉此建立閱讀默契。以下是我寫了無數企劃文件後，大致歸納出我習慣使用的設計文件框架。設計目的\目標
背景故事
設計大綱
遊戲流程
特殊需求
備註
聖旨，不可動搖。（設計目的\目標）
遊戲內容製作的需求通常是由上頭發下來的。他們會依據特定的需求或目的，認為遊戲內需要這樣的內容、機制。進而制定設計目的與達成目標，讓企劃開始進行設計文件的撰寫。簡單說就是上頭的旨意，寫給審核文件者看的！這裡有個陷阱，很多人往往就照著字面上的意義開始撰寫文件。如果沒有深入思考這些目的與目標，文件被打槍的機率是90%......
有企劃文件寫，別太興奮！！！先想想，遊戲為什麼需要它？跟上頭確認遊戲內容的需求、想要達成的效果。好好釐清一下，可以減少文件來回來頻率～同時，在設計文件大致撰寫完時，需要回頭來檢視文件內容是否能達成設計目的，符合上頭的需求。
遊戲內容推出時，也順便看看最後有沒有達成自己想要的結果，好好檢討一下。看很多遊戲企劃，業績做多了就開始對自己設計的內容，射後不理......。因此，相同的錯誤一再發生，造成團隊的困擾 XD
有包裝叫遊戲，沒包裝叫軟體（背景故事）
產品，如果能賦予它一些故事，往往能引發人們的想像。對我來說，多人線上遊戲就是在玩我們創造給玩家的遊戲世界。故事劇情能好好包裝遊戲，讓玩家覺得這是遊戲世界該出現的東西，而不會感到突兀。如果世界中出現的事物沒有一些故事性的理由，就讓玩家少了許多想像。沒有了想像，對遊戲也沒有情感投入，也容易沒有留戀的離去...（我知道，有人認為遊戲可以沒有故事，也認為玩家根本不在意故事。我後續會有專篇說說我的想法。）例如，存在於中古魔法世紀，強化裝備基本數值的衝星機制。
衝星用的道具名稱可以很直覺寫成「衝星道具」，也可以給它一個感覺有故事的名詞叫「女武神之淚」。甚至可以給「女武神之淚」一段故事～
當然，要流暢地用故事把遊戲包裝得很有感覺，不容易......我也看過很多遊戲為了故事包裝把道具名稱取得很花俏、有氣勢。但無法直覺聯想到這個道具該怎麼用。只能說，這都是眉角啦！負責撰寫背景故事的人，關鍵啊！好的背景故事能讓企劃輕鬆發想出各種故事包裝～
一群被濃縮再濃縮的文字（設計大綱）
設計大綱就是要寫到讓大家有概念，同時知道大概要怎麼製作文件上描述的遊戲內容。就像種子般植入閱讀者，讓腦海中產生影像。我所寫的大綱就是這整份文件所有關鍵字句的集合。字字血淚，句句掏心掏肺啊～每句盡量不要超過一行，善用子類別的排版。例如：
1. 精靈玉，提供提昇裝備附加屬性的管道。
a. 透過道具「精靈玉」與裝備結合，使裝備產生額外的附加能力數值。
b. 精靈玉取得管道 balabala.......
2. 限制，需等級90以上的綠色裝備。
當然，文字的排版，見仁見智啦！目的都是讓大家看得很順，不會頭昏昏～
大綱寫得簡單扼要，不代表也該簡單想想就好...
兄弟，衷心建議：
想的要比寫的多！！！想清楚再下筆，可以減少被問倒的機會～遊戲做久了，多數人慣性會一直問到遊戲製作的細節。別相信他們只要求你概略寫出想法，然後囑咐不要寫太細節的東西。等到文件送審、開會討論的時候，就開始越問越細，問到忘我......咦？細節後面有寫啊！完整看完一份文件的人，除了作者，就是負責製作的人。開會時，有瞄一下文件就偷笑了......總之，對於文件上的一切，遊戲企劃必須都有一個底。
打字，誰都會。
寫一堆文章也很容易。
知道自己要做什麼嗎？該好好先問問自己嚕～
要怎麼玩？玩家要怎麼玩？（遊戲流程）
遊戲怎麼進行、怎麼玩、有什麼規則。這些，其實沒得教，也沒得抄......企劃文件寫多了就知道該寫什麼。身為遊戲企劃，好好利用自己的想像，在腦海中進行無數次這些玩法。一次又一次的推敲，看看目前想像中的玩法，有沒有問題、怎麼改善。流程說明，建議只比大綱複雜一點點，專注於描述玩法的每一個步驟。邏輯能力強的人，寫這塊會比較吃香。很多人寫這部份，會喜歡用流程圖，然後外拉一堆線出去，連結一塊又一塊的文字框。
老實說，我很討厭看這種圖！看了頭好昏......圖文表現，排版不好，很容易搞得很複雜，擾亂閱讀者。因此，我會盡量用文字是描說流程。不得已，沒招了，才會畫個簡單示意圖，附上幾個標題文字。利用標題文字導向閱讀者看下面每個標題底下的描述。（我以前也常畫流程圖，後來發現並沒有使大家更容易理解，不會讓我省下許多解釋的功夫。反而用文字描述，大家的疑問比較少。）
也許是我對於畫圖沒有天份，無法利用圖讓大家理解遊戲內容。我就是討厭畫流程圖，怎樣！！！
由簡約進入複雜的領域（特殊需求）
需要較多細部說明的步驟，我會額外拉出來。包含，問題處置方式、避免遊戲精神被破壞的限制，以及需要程式、美術另外製作的東西。這部份通常會與程式、美術討論之後才會有比較確定、完整的內容。（文件審核階段，就看審核者的習性。不過可以先找程式、美術詢問一下可能作法。）在進入製作階段後，將會反覆修改、調整、追加。另外，我會把製作需要的各種資料表格、數值設定都列在這塊。值得關注的是製作過程中的任何調整、修改，都需要回頭去檢驗是否違背設計目的、設計大綱。文件寫到後面，往往容易越寫越偏～做人不能忘本（誤）文件要從頭到尾始終如一，才能製作出團隊所期望的遊戲內容啊！
企劃文件完全體
程式、美術在開工前，會跑來討論製作上的問題。這時會把最後實際的作法與技術規格敲定。在他們動工的同時，企劃亦開始把文件內容補齊成為正式文件。YA！！！(對於已經確定會製作的遊戲內容，會在設計文件完成之前，先開美術需求讓美術人員先動工。但，也同時增加白做工的風險...)東西做出來才有業績！
以前，好傻、好天真......總是以為文件寫完，而且通過審核，就可以開心等著遊戲內容被製作出來～沒這回事！依據開發進度，以及各種層面的考量，多數企劃文件完成都不會馬上進入實作，要排隊滴......甚至有可能被遺棄、擱著，打入冷宮。當然，這不是企劃本身的問題，團隊有團隊的考量。我提出來，只是讓想從事遊戲企劃的人少一點失望......（有看過某些企劃頭，為了不傷害小企劃脆弱的心靈。讓他們的文件通過，但那些文件從此就躺在專案資料庫內.....）
很不幸，大家對於企劃能力的評鑑肯定不是你寫了多少文件，而是你參與多少遊戲專案開發、做出多少遊戲內容。更進一步會去評估這些遊戲內容推出後，市場的反應與評價。所以能夠進入製作階段的企劃案，傾全力協助大家把它做出來吧！！！
寫文件好難喔！需要什麼專業背景嗎？
我的觀點：
做企劃之前，可以什麼都不會，什麼都不懂。
做了企劃之後，什麼都要懂，什麼都要知道。（企劃總是會被人一直問問題......）
程式背景來做企劃，好嗎？ 好啊～
美術背景來做企劃，好嗎？ 好啊～
（企劃該去教程式怎麼寫程式？教美術怎麼畫圖？然後，搞到最後大家都不知道該怎麼做，只能說一步做一步........這樣好嗎？）
不管什麼專業背景做了企劃，該具備的技能、擁有的裝備，還是那些啊！反而，這些專業可能會影響對於企劃的發想空間。我喜歡在寫一份新的企劃文件前，把心歸零，不預設任何立場去思考。盡可能忘記過去所有認知，這樣比較容易跟大家討論出意想不到的好結果～
不管過去種種，轉職成企劃後，就是一位遊戲企劃。不是工程師，不是美術人員，是要比任何人都瞭解遊戲的通才！
留言
張貼留言