這邊不知道有沒有人想要應徵遊戲企劃的工作呢？
最近我拿到不少滿懷熱情與抱負的求職者，在履歷裡附上的遊戲企劃書。
看了幾份各有奇妙之處的所謂遊戲規劃書之後，我回想起當初自身求職時碰到過問題……
企劃書到底該怎麼寫才對？
這個問題，我猜許多有志應徵遊戲企劃的同學應該都碰過，並且不管去搜尋google，或者詢問遊戲相關人士，都獲得一個相同的答案……遊戲企劃書並沒有固定格式，只要讓人能夠理解你的意思就可以了。
這個答案自然很難讓一頭霧水的求職者滿意。剛發現這答案時，我甚至猜測這應該是唬爛外行用的標準答案。
不久，我進了遊戲公司，然後……我知道企劃書該怎麼寫的答案了嗎？
很遺憾，完全沒有。
遊戲企劃書還真沒有固定的寫法……去問公司裡的前輩，得到的答案居然完全一樣。他們頂多是把自己寫的規劃給你看，讓你參考怎麼寫而已。
而且我很快又更進一步發現，不要說不同遊戲案的規劃書格式有很大機率不同，連同案子不同企劃寫出的初版規劃書都可能有很大不同（當然，最後要看誰為主企劃，再將規劃書整理成統一格式）。
開始大量寫企劃書半年之後，我確定，「遊戲企劃書並沒有固定格式，只要讓人能夠理解你的意思就可以了。」是說真的。
但，他忘記強調第二句話的重要性。
讓人理解你的意思，到底是要給誰理解？
打這篇日誌的重點就在這裡了～～
在進公司前，我的想法應該跟大家差不多，規劃書就是要寫給……有能力把我的創意，變成遊戲的人看啊。
這個想法嚴格來說不算錯，但實際上，規劃書一般會需要給四種人看：
1.給美術看：讓他們知道你需要哪些功能、圖片、按鈕、風格，界面切換方式等。
2.給程式看：讓他們知道你需要哪些功能、控制方式、後續是否能由企劃修改數值等規則。
3.給企劃看：讓他們知道你這個系統的數值成長、傷害公式、劇情播放等的輸入填寫規則。
4.給主管看：讓他們知道這東西，有了美術圖形和程式功能後，會是什麼樣子。
而這四種人看的規劃書，絕不會是同個格式。
複雜程度，從高到低，依序是：
程式用系統規劃→美術需求規格→公式填表規格→系統概要或簡報
呈現方式差別，舉個簡單的例子好了：
某天，我想提出一個，我用滑鼠點一下畫面，角色會走到點擊區域的功能。
然後我開始開啟一個有4分頁的規劃書檔案……
第一分頁。準備給主管看，寫概要：
功能目標：1.讓玩家能直覺性操控角色移動。2.玩家能得到符合期望的角色移動過程。
功能概念：當開啟地圖界面時，玩家可以移動滑鼠於地圖上選擇位置，並點擊滑鼠左鍵紀錄複數移動點，關閉地圖界面後，遊戲角色依序沿紀錄的移動點等速度移動，並停在最後一個移動點上。
（大概寫一些目標與過程結果什麼的就可以了。比較重要的是目標與結果要相同，並且要附上簡單易懂的圖示。）
第二分頁：給程式看。大致是寫規則與流程等功能面的東西：
在列出簡單的流程圖與功能需求後，下面大致會這樣寫……
1.移動功能操控規則：
點擊：
A：玩家單次點擊規則：
A-1：xxxxxxxxxxxxxxxxxxxx
A-2：xxxxxxxxxxxxxxxxxxxx
A-3：xxxxxxxxxxxxxxxxxxxx
詳閱附件表格：單次點擊反應表
B：玩家多次點擊規則：
B-1：xxxxxxxxxxxxxxxxxxxx
B-2：xxxxxxxxxxxxxxxxxxxx
C：xxxxxxxxxxxxxxxxxxxxxx
C-1：xxxxxxxxxxxxxxxxxxxx
C-2：xxxxxxxxxxxxxxxxxxxxxxxx
移動：
A：xxxxxxxxxxxxxxxxxxxxxxxxxx等等等等等（非常多項）
（雖然有些人會覺得程式又不是白痴，不用什麼都寫上去，但實際上沒寫的功能程式就有可能不去做。總之，這份有多詳細就寫多詳細，寫到不知道該寫什麼，再努力思考到頭痛就差不多了。）
事實上，我本身嘛……在實際寫出要做成遊戲的企劃書之前，完全沒想過這個問題，所以應徵時寫出的那份企劃書，就我現在看起來就是屎渣。而在我進公司後，寫出的前幾份企劃書，也是屎渣。
就算到今天，我也一直不知道，我任職的公司到底是真得超帶種，還是純粹案子負責人太忙，沒時間看我寫的規劃書，就直接跟上面說ok。
我關於規劃書寫法的學習，一半是去問人，拿文件參考。另外一半，是用實際製作遊戲後產生的大量錯誤來學習的。
說實話，錯誤的程度，拖垮了十幾個程式跟美術的工作時程，連帶影響到一大堆案子，可說是嚴重到沒被革職算滿幸運的地步。
但總算勉強存活下來了。（不過當時做我副手的新人再見了）
適者生存似乎是遊戲界內的常識……前輩的生存率如何我不知道，但我後輩的企劃生存率，大約是1/3～1/4
可以說，一份詳細企劃書中最重要，也最可能出錯的部份，大致就在這邊。
再來是第三分頁：給美術看：
裡面會包含這個系統的界面表現，需求功能按鈕的外型，需要的提示圖示種類，參考的風格（如果已有確立的主風格可省略），切換方式，點擊時、按住時、指上去時按鈕界面框的變化等等等。
開給美術的需求，一般會是在寫完給程式的那一頁之後才開始開，畢竟在確定所有的功能後，才會知道一共要有多少按鈕、提示，和狀態變化。
而這一頁，大部份都是用單純的幾何圖形拼湊而成，上面會再加上相應的文字註解與操作流程解說。聽起來或許比寫程式功能的分頁簡單，實際上也比較直覺化而有趣，但為了要讓美術能理解你的想法，並讓程式拼界面功能時可以參考，有時候這一頁反而會花費最大量的編寫時間。
不過，只要漏列幾次物件，再去請看起來快死掉的美術擠時間幫你補失誤，大部分企劃都會越來越認真去處理這一塊。
最後是第四分頁：給企劃看：
這個分頁是最微妙的的部份，甚至可以說，一般人想像中的企劃書，就只有這一分頁而已。
這一分頁純粹用文字一列列有條理地形容我想要的功能是什麼，以及為什麼需要這個功能，和未來希望能夠延伸的部份，並把相關這系統後續該有的變化全部寫出來。
簡單來說就是把最初的空想與妄想，一列列整理出來的文件。
至於這跟給程式的功能分頁有什麼明顯差別？舉個例子好了。
在企劃分頁我會寫些：我想要讓每個職業的角色有不同的移動速度，且同一職業也會依角色特性有些微的移動速度差距，在特殊時間某些角色的移動速度會變快。然後在下面做一張詳細職業移動速度數值表，標出每職業的速度上下限，再做另外一個時間對於移動速度的影響，與可能對應角色特性。
而同樣的需求，我在給程式的分頁則會是這樣寫的：
A：移動數值需求
A-1.角色數值控制表格中，需要有能填寫角色移動速度的欄位。
A-2.移動速度欄位中，每1點數值代表。角色於畫面上的移動速度為：1像素/每秒
B：被動影響需求
B-1.角色數值控制表中，需要有能填寫限時被動、發動時間的欄位。
B-2.限時被動欄位填寫技能ID，並因應時間欄位決定發動時間。
B-3.發動時間欄位需要能填寫(開始/結束)時間。填寫格式為：01：00：00/24:00:00
實際上會寫得再詳細許多，不過大致就是會有這樣的差別。總之，給企劃的文件比較像是讓其他企劃知道你為什麼要這樣設計系統，和後續該怎麼處理數值設定的說明書。如果需要交給別人填寫數據，或當自己只是臨時救援人員時，這部份就要寫得用心，且好懂一些，不然很多時候被後續接手企劃曲解，或因為寫太爛所以直接被改掉的可能性會很高。
需要注意的是，如果把這部份的表列在給程式的分頁，程式真的會把數值寫死給你看，讓你拿到遊戲測試後後想調快一點都沒辦法調。
四個分頁大致就這樣。
而只要寫出完整的四個分頁，企劃書也就差不多完成了。
另外，雖然上面我是說四個分頁要給四種人看，但實際上，交出企劃書時，不管給誰都是給一整份完整的文件，畢竟，有時候美術會想要看看功能與設計概念來激發靈感，程式也會看看界面與概念還設想初步結構，主管也會對於感興趣的系統看看細部設定，接手的企劃也要看看程式功能與界面才知道該怎麼算數值。
不過，假設以這種格式寫，並且只靠一個人，每天八小時，要寫出一個完整遊戲的系統規劃書，大約是要花上30～35個工作天。
雖說有時間能這樣寫當然很好，甚至只要內容寫得夠好，能證明自己擁有立即上工能力的話，被遊戲公司率取的機率會瞬間飆升。
不過，我還是是不建議無經驗的求職者這樣寫企劃書。如果沒有相關開發經驗，寫越詳細的規劃書，出現扣分錯誤的可能性絕對是加份的數倍以上。
所以，我寫了這麼多，是想要說什麼呢？
一般求職者，要寫的，其實是把給主管看的那一份抽出來，並把所有系統都寫出來，再按照核心系統循環做出一份簡報形式的文件。嚴格來說，新人求職者該寫的並不是遊戲規劃書，而是開案說明。
簡單來說，這文件不是要讓你跟面試官說明這個遊戲的詳細設定，而是要告訴面試官，你想要做得的遊戲，好玩的地方在哪裡？特別的地方在哪裡？會受歡迎的地方在哪裡？看起來會是什麼樣子？
這種東西，才是新人求職者該拿出來的東西。並且也能夠讓面試官知道，你進公司之後大概要先放到哪個位置去適應。
我看過拿著東抄西抄的龐大規劃書，硬是騙過面試官進入公司，以為能夠進來再學習，卻直接接手規劃遊戲系統的新人（沒過試用期），也看過自稱有遊戲開發經驗，但寫得企劃書根本沒人看得懂的新人（過試用期後兩個月消失），還看過故事規劃寫得不錯，但一分配去寫角色劇本卻只會寫BL的新人（調動到適合的遊戲後存活）。可以說，隱瞞許多重要訊息，靠著裝作有相關經驗，雖然是進入遊戲業的捷徑，不過，後續保證很麻煩，而且還會留下不好的紀錄，瞬間就會從LINE（或其他通訊軟體）上面傳到各家公司。總的來說，不推薦。
比起賭上自己的學習能力，與未來的名聲，不如盡量展示自己的長處會比較好，也比較順。
大致就是這樣，有機會的話，再來分享什麼是，經常看到求職訊息提到的遊戲核心循環。
創作內容
近期的一些感想
LOL (52)