獨立遊戲開發，很多時是一個想法和熱情冒出來後，就叫人衝到電腦前想快點把成品弄完……就算做不了完整版，至少也想有個Demo。
既然想「快點」，那還要不要「花額外時間」去寫企劃書呢？
在處理這個問題之前，要先理解的是，這句話裡面至少有兩種情況。
其一：團隊裡只有一個企劃，所有事情都由一人主導
這情況不用多說，不寫企劃書根本就沒人會懂。就算口頭討論過，開發期間肯定會出現誤差。
又或是其他成員一時之間忘記了某些事項，屆時企劃書是最好的依據。
再來，企劃不只要寫，還要寫得越詳細越好，有附圖說明更佳。以下是真實例子：
曾經收到企劃書說要弄一個「從上至下，左至右，順序滾動的三組滾輪」。
聽到這要求，你會做成左邊還是右邊？
最後去問企劃，我理解的是左邊，但原來企劃想要右邊
慣例地（？）再比喻一下：某個富豪買了一塊地，帶同工程人員、設計師等想興建一座遊樂園。
他們站在土地中央，富豪想要在左邊建過山車，右邊建旋轉木馬。
設計師根據要求畫好設計圖，卻被富豪說過山車的佔地太大了需要縮小一點；旋轉木馬只有10隻不夠多，想要多幾隻。
整個設計又要重新來過，成本也就噴了。富豪可能不在意，他不計較成本，其他人只要來來回回設計出「他感覺對了」的東西就好。
但我們都知道，現實中的遊戲開發者不可能無限成本，而是越節省成本越好。
想當然，企劃層面上要降低成本，就是寫詳細點減小誤差。不能只說「大一點」「小一點」，而是有實際尺寸其他人才方便做事。
所以有人說，企劃要懂程式懂美術，懂越多，實作下去時才知道有什麼要注意，而事先把注意都寫在企劃書。
假如真的什麼也不懂，是個新手企劃，那就問問程式和美術同事們吧。只要對方也不是沒經驗，在你說出「要做過山車」時，大概就會追問「要多大？」、「最多一次載多少人？」這些的了。
久而久之，就算不懂畫圖不會寫程式，也會知道需要注意什麼。
以上是「一個企劃主導所有事」的情況。
但很多時，企劃不只是一個人——尤其小團隊。
情況其二：整團只有兩三人，而全部人都是企劃
你們的開發過程就像在玩遊戲。每人都有共同目標和願景，還深知有多少成本。快速開發一個Demo後，有新想法就直接從Demo去改，且戰且走。
這時需不需要企劃？
先假設，你們打算做2D平台遊戲。
期間程式靈光一閃，做了一個「五秒內鑽入地底，在相反的平台上解謎」的機制，然後所有人都覺得有趣，決定放在正式遊戲中……
這時需不需要刻意去寫企劃？已經有了明確的Demo畫面，還所有人都同意這項改動了耶？
老生常談就是，這樣的開發過程很高機率會忘記當初設計的細節。而企劃書就是用來提醒這些細節的。
「一定是要五秒？」、「能鑽入的地底是什麼？」、「在地底有沒有引發角色死亡的機制？」。一個看似簡單的改動，背後需要有一堆細節來填補那留在地面上的坑。（別忘了你已經在地底，地面上有坑也算正常吧:D）
開發過程沒了細節和依據，很容易就會漸漸偏離原本的設計目的，甚至會挖出更多bug。
所以，基本上是建議團隊中找個人去補一下企劃書。
——但，假如真的對記憶力有絕對自信，又能承擔開發時的各種風險，那……其實也可以不寫企劃:D
對，說了這麼多，總結是你能承擔風險的話，寫或不寫都是你決定的。
這種模稜兩可的答案，足夠讓我這篇文定義為「充滿偏見的個人心得」（欸嘿(ゝ∀･)）
如果今天，我是以「新手開發入門教學」為主題，大概會以「新手很容易錯估風險」為由，強烈建議要寫企劃書吧。
但現在只是一個閒聊性質的blog，我不喜歡下一個「絕對」的定義。
面對不同人時，我文章的態度會不同。
就像企劃書要寫1頁、100頁，還是完全空白的0頁。面對不同人時也有不同做法。
正因為企劃書要面對的是人，而對人的事沒有正確答案。企不企劃書，在於你要向什麼人來講解你的遊戲設計。
我們買了新家電，會直覺說明書上的文字都是精準、條列、易懂。但如果是用小說形式來寫說明書，理論上也不會有錯（吧？）。只是要承擔別人看不懂的風險就是。
心得到此。
最後就以我開發個人習慣作結——如果不寫這段，整篇大概是可有可無的廢話XD
總之，我自己是一定會寫企劃的。但因為一直都是個人開發，我的企劃書只是點列式——或者說，那更像是靈感筆記。
假如我今天真的要為團隊寫企劃，那依舊是兩種情況：
其一：面對陌生人時
我大概會很常附圖說明——畢竟用文字描述遊戲畫面，很容易出現誤差。
比如上面寫到「五秒內鑽入地底，在相反的平台上解謎」——在真的企劃書上不會這樣寫，而是會用差不多一頁來詳細描述＋圖解。
其二：面對的人已經對我有一定認識，或者場合較輕鬆時
我可能就會用字輕鬆一點，甚至加入一些inside joke。
就像上面我把「要不要寫企劃書」縮減成「企不企劃書」五個字。
調皮一下:P
