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