「好文件讓團隊上天堂,爛文件讓團隊住貧房......」



在遊戲界,孤身一人
討厭拉黨結派、討厭白目、討厭沒效率
只有身經百戰的實務經驗是他僅有的武器
遊戲企劃 瑞森,別名 GD-X



有了遊戲界的老狐狸寫的這篇「遊戲企劃書該怎麼寫?」以我的等級就不方便誤導大家了.....(謎之聲:什麼!!!這篇,這樣就結束了嗎?)當然,沒有啦!就像我開頭所講的,我來以個人經驗分享一下,我怎麼寫遊戲設計文件~不管好評、壞評,都是我的青春啊!!!


文件的基本框架

企劃文件很難有固定格式,因為遊戲內容之間的差異、變化太大了,很難找到一本通用的文件格式。(上頭總是想拿軟體工程那套作法來應用於遊戲開發上,企圖提昇遊戲內容的產能。目前看下來,沒有比較好的成果......。遊戲開發可以算是一種軟體開發,但成功的核心在於設計面,過於制式往往把設計面限制住了XD)我很在意別人是否看得懂我在寫什麼?發現有人對於文件描述不太理解,經過解釋後也同時會立即修正。經年累月的琢磨,也磨出自己在用的文件框架~目的是讓團隊成員能由淺入深地瞭解文件內容,也藉此建立閱讀默契。以下是我寫了無數企劃文件後,大致歸納出我習慣使用的設計文件框架。

設計目的\目標
背景故事
設計大綱
遊戲流程
特殊需求
備註


聖旨,不可動搖。(設計目的\目標)

遊戲內容製作的需求通常是由上頭發下來的。他們會依據特定的需求或目的,認為遊戲內需要這樣的內容、機制。進而制定設計目的與達成目標,讓企劃開始進行設計文件的撰寫。

簡單說就是上頭的旨意,寫給審核文件者看的!這裡有個陷阱,很多人往往就照著字面上的意義開始撰寫文件。如果沒有深入思考這些目的與目標,文件被打槍的機率是90%......

有企劃文件寫,別太興奮!!!先想想,遊戲為什麼需要它?跟上頭確認遊戲內容的需求、想要達成的效果。好好釐清一下,可以減少文件來回來頻率~同時,在設計文件大致撰寫完時,需要回頭來檢視文件內容是否能達成設計目的,符合上頭的需求。

遊戲內容推出時,也順便看看最後有沒有達成自己想要的結果,好好檢討一下。看很多遊戲企劃,業績做多了就開始對自己設計的內容,射後不理......。因此,相同的錯誤一再發生,造成團隊的困擾 XD


有包裝叫遊戲,沒包裝叫軟體(背景故事)

產品,如果能賦予它一些故事,往往能引發人們的想像。對我來說,多人線上遊戲就是在玩我們創造給玩家的遊戲世界。故事劇情能好好包裝遊戲,讓玩家覺得這是遊戲世界該出現的東西,而不會感到突兀。如果世界中出現的事物沒有一些故事性的理由,就讓玩家少了許多想像。沒有了想像,對遊戲也沒有情感投入,也容易沒有留戀的離去...(我知道,有人認為遊戲可以沒有故事,也認為玩家根本不在意故事。我後續會有專篇說說我的想法。)

例如,存在於中古魔法世紀,強化裝備基本數值的衝星機制。
衝星用的道具名稱可以很直覺寫成「衝星道具」,也可以給它一個感覺有故事的名詞叫「女武神之淚」。甚至可以給「女武神之淚」一段故事~

當然,要流暢地用故事把遊戲包裝得很有感覺,不容易......我也看過很多遊戲為了故事包裝把道具名稱取得很花俏、有氣勢。但無法直覺聯想到這個道具該怎麼用。只能說,這都是眉角啦!負責撰寫背景故事的人,關鍵啊!好的背景故事能讓企劃輕鬆發想出各種故事包裝~


一群被濃縮再濃縮的文字(設計大綱)

設計大綱就是要寫到讓大家有概念,同時知道大概要怎麼製作文件上描述的遊戲內容。就像種子般植入閱讀者,讓腦海中產生影像。我所寫的大綱就是這整份文件所有關鍵字句的集合。字字血淚,句句掏心掏肺啊~每句盡量不要超過一行,善用子類別的排版。
例如:
1. 精靈玉,提供提昇裝備附加屬性的管道。
a. 透過道具「精靈玉」與裝備結合,使裝備產生額外的附加能力數值。
b. 精靈玉取得管道 balabala.......
2. 限制,需等級90以上的綠色裝備。

當然,文字的排版,見仁見智啦!目的都是讓大家看得很順,不會頭昏昏~
大綱寫得簡單扼要,不代表也該簡單想想就好...

兄弟,衷心建議:
想的要比寫的多!!!想清楚再下筆,可以減少被問倒的機會~遊戲做久了,多數人慣性會一直問到遊戲製作的細節。別相信他們只要求你概略寫出想法,然後囑咐不要寫太細節的東西。等到文件送審、開會討論的時候,就開始越問越細,問到忘我......咦?細節後面有寫啊!完整看完一份文件的人,除了作者,就是負責製作的人。開會時,有瞄一下文件就偷笑了......總之,對於文件上的一切,遊戲企劃必須都有一個底。

打字,誰都會。
寫一堆文章也很容易。
知道自己要做什麼嗎?該好好先問問自己嚕~


要怎麼玩?玩家要怎麼玩?(遊戲流程)

遊戲怎麼進行、怎麼玩、有什麼規則。這些,其實沒得教,也沒得抄......企劃文件寫多了就知道該寫什麼。身為遊戲企劃,好好利用自己的想像,在腦海中進行無數次這些玩法。一次又一次的推敲,看看目前想像中的玩法,有沒有問題、怎麼改善。

流程說明,建議只比大綱複雜一點點,專注於描述玩法的每一個步驟。邏輯能力強的人,寫這塊會比較吃香。很多人寫這部份,會喜歡用流程圖,然後外拉一堆線出去,連結一塊又一塊的文字框。

老實說,我很討厭看這種圖!看了頭好昏......圖文表現,排版不好,很容易搞得很複雜,擾亂閱讀者。因此,我會盡量用文字是描說流程。不得已,沒招了,才會畫個簡單示意圖,附上幾個標題文字。利用標題文字導向閱讀者看下面每個標題底下的描述。(我以前也常畫流程圖,後來發現並沒有使大家更容易理解,不會讓我省下許多解釋的功夫。反而用文字描述,大家的疑問比較少。)

也許是我對於畫圖沒有天份,無法利用圖讓大家理解遊戲內容。我就是討厭畫流程圖,怎樣!!!


由簡約進入複雜的領域(特殊需求)

需要較多細部說明的步驟,我會額外拉出來。包含,問題處置方式、避免遊戲精神被破壞的限制,以及需要程式、美術另外製作的東西。這部份通常會與程式、美術討論之後才會有比較確定、完整的內容。(文件審核階段,就看審核者的習性。不過可以先找程式、美術詢問一下可能作法。)

在進入製作階段後,將會反覆修改、調整、追加。另外,我會把製作需要的各種資料表格、數值設定都列在這塊。值得關注的是製作過程中的任何調整、修改,都需要回頭去檢驗是否違背設計目的、設計大綱。文件寫到後面,往往容易越寫越偏~做人不能忘本(誤)文件要從頭到尾始終如一,才能製作出團隊所期望的遊戲內容啊!


企劃文件完全體

程式、美術在開工前,會跑來討論製作上的問題。這時會把最後實際的作法與技術規格敲定。在他們動工的同時,企劃亦開始把文件內容補齊成為正式文件。YA!!!(對於已經確定會製作的遊戲內容,會在設計文件完成之前,先開美術需求讓美術人員先動工。但,也同時增加白做工的風險...)

東西做出來才有業績!

以前,好傻、好天真......總是以為文件寫完,而且通過審核,就可以開心等著遊戲內容被製作出來~

沒這回事!依據開發進度,以及各種層面的考量,多數企劃文件完成都不會馬上進入實作,要排隊滴......甚至有可能被遺棄、擱著,打入冷宮。當然,這不是企劃本身的問題,團隊有團隊的考量。我提出來,只是讓想從事遊戲企劃的人少一點失望......(有看過某些企劃頭,為了不傷害小企劃脆弱的心靈。讓他們的文件通過,但那些文件從此就躺在專案資料庫內.....)

很不幸,大家對於企劃能力的評鑑肯定不是你寫了多少文件,而是你參與多少遊戲專案開發、做出多少遊戲內容。更進一步會去評估這些遊戲內容推出後,市場的反應與評價。所以能夠進入製作階段的企劃案,傾全力協助大家把它做出來吧!!!


寫文件好難喔!需要什麼專業背景嗎?


我的觀點:
做企劃之前,可以什麼都不會,什麼都不懂。
做了企劃之後,什麼都要懂,什麼都要知道。(企劃總是會被人一直問問題......)

程式背景來做企劃,好嗎? 好啊~
美術背景來做企劃,好嗎? 好啊~
(企劃該去教程式怎麼寫程式?教美術怎麼畫圖?然後,搞到最後大家都不知道該怎麼做,只能說一步做一步........這樣好嗎?)

不管什麼專業背景做了企劃,該具備的技能、擁有的裝備,還是那些啊!反而,這些專業可能會影響對於企劃的發想空間。我喜歡在寫一份新的企劃文件前,把心歸零,不預設任何立場去思考。盡可能忘記過去所有認知,這樣比較容易跟大家討論出意想不到的好結果~

不管過去種種,轉職成企劃後,就是一位遊戲企劃。不是工程師,不是美術人員,是要比任何人都瞭解遊戲的通才!






Relate Post