單人專案管理的心得和教訓

引言

單人獨立開發可以說是最自由的一種形式了，如果再加上不以開發遊戲為主業，往往就會誕生一些…………永遠做不完的作品。

對遊戲開發有熱情的人很多，但是大家的熱情通常都只存在於“自己想做的遊戲”之上。這就使得業餘開發的團隊難以凝聚。相比開工資的專業團隊，或者主創能讓人信服“這樣做下去能賺到錢”的團隊，一群業餘愛好者湊在一起往往很難團結起來做出一個較大的專案。很多情況下，我們只能選擇自己單幹。

因為單人開發不需要遷就任何人，想改需求就改需求，單人專案的管理比起團隊要困難得多。這裡筆者僅以個人開發中的經驗和與他人交流的體會，談談單人遊戲開發的一些心得和教訓。（偷偷說下，很多事情筆者自己並沒有做到）

立項

雖說做任何事情都得搞清楚到底要做什麼。但是對單人開發而言，“到底在做什麼”這個問題是很難回答的，在開發過程中需求可能會因為各種各樣的原因而變化。越大的組織慣性越大，而單人則是一個念頭就足夠推翻整個遊戲的設計。

雖然明確需求很重要，但是也不能因此而害怕改變，畢竟靈活性是單人開發最大的優勢之一，開發的過程本身也是尋找並確認需求的一環，獨立開發者不用像大團隊那樣有著明確而穩定的安排，或是小型團隊那樣害怕傷害隊友的感情不敢改需求，可以享受甲方亂改需求的快感（雖然接鍋的乙方也是自己）。

因為不需要和團隊進行溝通，也不需要和贊助商之類的人交流，單人專案的專案文件並不需要對遊戲的型別和玩法之類的基礎資訊進行詳盡而嚴謹的描述。相比於那些能夠列印出來貼在牆上的專案文件，獨立開發者的專案文件是要時常進行編輯的。但是理清楚自己“現在想要的是什麼”也是非常重要的。

一個在各個地方被各種人提過很多遍的方式就是“用一句話概括你的遊戲”，像是“波瀾壯闊的田園史詩”這樣什麼有用的資訊都沒說的也好，或是“基於卡牌系統的故事用適量的隨機性來處理類牧場遊戲‘每天不知道該幹啥’的問題”這種像畢業設計標題一樣的也好，或是乾脆“這是一個銀河城”也好，把最開始的時候，想到的用於概括這個遊戲的一句話，寫在專案文件的開頭，然後不要去改它，即使專案變成了可以完全將其無視的樣子也不要去改它。這句話對於把握專案的全貌有著無法取代的作用。

獨立開發者往往都會對“創新”有著很大的執著，甚至會羞於提及自己的遊戲像什麼遊戲。雖然這種心情很普通，但是“瞭解和自己的遊戲相像的遊戲”對於開發的幫助是非常大的。很多人可能會覺得“你這個遊戲像XX”不是什麼好話，但是大家也都知道，自己喜愛的遊戲的痕跡一定會留在自己開發的遊戲之中的，那些能夠激發人們“我要做個遊戲”的衝動的遊戲更是如此，像是Mother之於Undertale，牧場物語之於星露谷。不要羞於提及自己的遊戲中那些遊戲的痕跡，而是要正視他們，這樣可能反而更能打造屬於自己的獨特性。畢竟像“類銀河戰士惡魔城”，直接把自己模仿的遊戲打進了標籤，但成功的作品都有各自的特色和長處。

時間

這是專案管理最核心也是最根本的問題之一了。獨立開發因為沒有明確的期限，在時間安排上也會和團隊專案有巨大的差異。

暑假作業和畢業設計之類的東西，存在著死線，很多人都知道暑假開始時定下的作業計劃最後往往會變成漫無止境的八月的結尾。和暑假作業不同，遊戲開發不僅僅是交差完事，而是精益求精，打磨是個無底洞。但同樣的，我們會害怕作業和畢業設計的死線，對於獨立開發這種自發的死線就不那麼重視了。

“獨立遊戲沒有準時”，對單人開發來說更加如此。大型企業有相對嚴格的死線，小型團隊有共識，哪怕只有兩個人也會對拖延有所顧忌，而單人就只有“雖然我今天什麼也沒做但還真是辛苦了”，對於有辛苦的本職工作的更是如此。

或許有些人會有“一年沒做好就去找工作”“畢業之前做完”“做完這個遊戲就回老家結婚”之類的期限。沒有這種期限的自由開發者，只能手動造一個死線出來。在其他人面前“承諾”一個死線，或者階段性成果完成的時間表出來，在indienova/微博等地方吹牛比較安全，在眾籌網站吹牛可能會導致死線壓力變得更具體，筆者沒有試過眾籌所以也不好說那樣有沒有用。

即使再老道的開發團隊，也很難正確估算遊戲開發的必要的時間，但他們能制定出相對寬鬆，能確保完成整個專案需要的時間。對於獨立開發者而言估算時間的精確性要低得多，但同時估算時間的必要性也沒那麼高，時間安排上可以相對寬鬆。這是出於工作積極性和情緒的考量，每天都能按進度完成任務，相比跟不上進度，積極性會相差很多。不過這也和個人有關，需要大家結合自己的經歷來考量。

“完整專案經驗”對於時間的安排的能力是非常關鍵的，不管多小的專案，哪怕是48小時的Game Jam，從0到1完成一個完整遊戲的經驗，對於一個完整遊戲的進度安排也是十分有幫助的。

提到“完整專案經驗”，獨立開發者或許應該把“兒時夢想”級別的設想暫時擱置，先去做幾個沒那麼夢想的遊戲練手，畢竟大多數獨立開發者，做出來的前幾個遊戲的完成度和品質都比較一言難盡，而從中得到的經驗則是無比寶貴的。要是真有以之為人生理想級別的設想，可以先嚐試做機制類似的“原型”作品，一開始經驗不足的時候直接上手做出來一個不夠完善的作品，然後因為角色/故事已經用過了沒法重新做，就容易失去熱情。

計劃

和專業分工的團隊不同，單人開發勢必要一個人負責各個方面的任務。就像暑假作業數學做不下去了做英語，英語做不下去了做物理一樣，任務的多樣性可以保持積極性，畫畫畫累了寫程式，程式卡Bug了做設計，設計不知道怎麼下手了就畫畫，以“其他的工作”作為調劑進行休整，相比專注於一項任務，可以保持更長時間的工作效率。

但是這樣子也會降低專注度，尤其是程式，分散程式工作可能會導致經常要花時間去理解自己之前寫了什麼鬼東西，或者是出現同一個功能的變數寫了三次，三次的名字還都不一樣的情況。

在任務安排上，將任務明確地細分，可以經常性地通過“完成一個個小任務”來提高積極性。任務劃分太大，可能會感到無從下手，一個個零散的任務可以一步一步做下去。但是因為單人開發，尤其是缺乏完整專案經驗的時候，對於任務的預估往往會有巨大的誤差，難以準確地劃分任務。

因此，在製作出了一個包含了每條任務及各個任務對應的工作量的計劃表之後，我們要對“對任務工作量的評估”進行評估，簡單的方式就是記錄下每天完成的工作量與實際花在開發上的時間，對於工作中的業餘開發者來說每天能抽出的時間可能不太穩定，我們可以結合實際情況以三天或者一週為單位計算工作量。觀察一個週期內的工作進度推進是否穩定，並作出相應的調整。

美術

美術是很多獨立開發者之所以沒有成為獨立遊戲開發者的原因，大家通常都覺得畫畫是件很困難的事情，但實際試過之後，畫畫會比想象中的簡單不少。（當然了，如果有不會畫畫的人覺得畫畫是件很簡單的事情，那畫畫肯定會比想象中的難）

大家不用把畫畫當成非常困難的事情，要畫到職業畫師的水準當然是很困難，但畫到順眼/看得過去/畫風獨特的程度並沒有那麼難，就像《東方Project》的ZUN繪那樣，只要下決心去畫，總歸是不會在樹上吊死的。

相信自己能畫的信心很重要，這倒不是什麼精神論，而是相信的人會去畫，不相信的人不會去畫，這麼一個單純而根本的區別。比起一開始就覺得“哎呀我不行的我得去找可以用的素材”的人，願意捏著鼻子硬畫的人……雖說也畫不了多好吧，但他們能把遊戲做出來，而前者通常都會放棄。

美術的下限可以先用方塊湊數，上限可以像達芬奇那樣花四年畫一幅肖像，各種素材都可以慢慢打磨。素材的尺寸和UI設定相比更為關鍵，尺寸的改動往往會牽扯到很多素材，雖說為了調整尺寸再畫一遍能夠畫得更好，不過能夠避免的大改還是儘量避免為好。

音訊

音樂和音效要自己做出能用的水平就比較困難了，但是音樂和音效相比美術，有很多公共領域的古典樂等資源可以使用，或者是很多素材商店的資源包。作曲的技術比較困難，但是“安排合適的音樂”這項技術對外行人來說更為重要，在平時可以多進行積累，把潛在的可用bgm當工作時的bgm使用以感受氣氛，尋找合適安排的地方，或者乾脆依據音樂來設計場景也是可行的。雖然這話讓使用雨聲和室內環境音做bgm的筆者來說可能不太合適。

設計

設計大略可以分為核心機制和內容增補兩個方面，包括美術等工作的安排都要建立在核心機制的確立上。或許核心機制會常常改變，但是一開始必須要有一個完整可用的核心機制方案，以此為基礎設定之後的任務。

就像在核心機制確定前先憑感覺做成就係統最後不得不刪掉一大堆不在遊戲機制最終定案內的成就，或是設計了對逃跑的敵人有特效的招式但是到最後發現敵人逃跑的機制已經沒了一樣，內容的填充要基於核心機制的確立，“可能會有所變化”的任務可以放在“會導致變化”的任務後面。

大家可能都會害怕核心機制的改變導致之前做的工作被浪費，但不要為此把“之前做的工作”放在權衡”要不要改變核心機制”的天平上，那是團隊需要面臨的困擾，獨立開發者應該把改變核心機制的靈活性發揮到最大，畢竟優秀的遊戲往往不是一開始就順利地設計好，而是在不斷地改變和打磨中成型的。

程式

感謝現代科技的光速發展，大多數個人作品都可以省略優化的環節，使用粗糙的演算法實現想要的效果，相比一切都要斤斤計較的FC時代，現在的開發者要容易很多。

在實現方面是非常容易的，尤其是有相對專業的程式設計技術的人，在功能的實現上很難遇到多大的問題，即使是沒有什麼基礎的人，只要本著“沒有一萬個if解決不了的問題，如果有就再加一萬個”的精神，大多數功能都能順利實現。但是在Debug上就會遇到很多麻煩了，解決已知的Bug容易，而難以復現甚至不知道是否存在的Bug要麻煩得多。

對沒有專業基礎的程式來說，最常見的問題是不重視模組化，直接複製貼上公式和函式之類的東西，常常會出現“要改動一個數字，需要改動好幾個地方‘的現象，增加了工作量倒不是問題，遺漏某處的修改導致本應相同的部分出現了差異則會導致很多問題。凡是改一個數字需要改兩個地方的情況，最好儘可能地把它們修改成只需要改一個地方就行的形式，包括UI座標等變數。

對每個發現的Bug，以及做出的修改都要進行詳盡的記錄，在處理同類Bug，或者因為修改bug而導致的Bug會非常有用。

即使再單人的單人專案，在“測試“這項工作上還是要尋求大家的幫助。大家會提出很多根本沒有考慮到的問題，或者發現因為對自己的遊戲太熟根本發現不了的Bug。（比如筆者的朋友就拆掉了一個筆者從來沒拆過的建築觸發了Bug）

完成之後

獨立開發者，都會有個通病。

做完一個遊戲之後，心累得不想再看到這個遊戲，但是對做別的遊戲則充滿了動力。畢竟單人開發者大多數是“點子”驅動的，做新的遊戲的動力遠大於打磨和完善舊作的動力。不管是有潛力的點子也好出色的故事也好，短時間內都提不起勁去進一步加工。如果舊作大受歡迎還好說，反響一般的遊戲，吸引力是比不上“嘗試新的作品的”。就像Game Freak就算揹負罵名也要拋下寶可夢去做Town一樣，對本就熱衷於做遊戲的獨立開發者，做遊戲的重要性是遠大於完善遊戲的。當然，惡性Bug和承諾是一定要處理的。

完善舊作還是開發新作先放一邊，對舊作進行的總結和思考是必要的。回顧整個開發過程，總結記錄下開發過程中遇到的問題和解決的方式，不管是要完善也好新作也好，都能從中得到無可取代的經驗。


作者：茶多酚
來源：indienova
原地址：https://indienova.com/indie-game-development/street-fighter-frame-data-1/