UnityIN 共筆部落: [客座投稿] 海盜尋寶 (Pirate and Treasure)：十天，與自己的Game Jam競賽

身為一個獨立遊戲開發者，時常會遇到對遊戲開發有興趣的朋友們對我說，他們也想寫自己的遊戲但總是沒時間。我自己的經驗是：要開發一款好遊戲很難，但開發一款遊戲卻很容易，然而大多數人卻都卡在後者。所以我自己做了一個實驗，測試開發一款遊戲所需要多久時間。最後的成果是:

成品：iOS APP 遊戲『海盜尋寶』(英文名稱是 Pirate and Treasure)
總開發時間：10天
總花費：2萬新台幣(不包含我自己的工錢...)

這篇網誌記錄整個開發過程，希望能對獨立遊戲開發同好有所幫助。

第 1 天
確立開發目標：1. 必須在一個星期之內完成一款遊戲。2. 必須是個 iOS APP 遊戲。因為我只會寫程式，所以之前的開發流程是先規劃遊戲，等規劃完成之後，美術和音樂等遊戲素材再和其他工作室合作。但這種做法需要密切溝通，有時只是改個小地方，一來一回就是一個禮拜。這次為了趕時間只好捨棄之前的開發流程，想了很久決定先由弱點著手，採用另一種開發方式，那就是：不事先規劃，先蒐集素材再由素材決定遊戲。
首先我到圖庫網站隨意瀏覽，看到風格有興趣的圖先記錄下來 (圖庫網站都有light box功能，可以標註喜歡的圖)。然而圖庫最大的問題是缺乏主題，通常圖都只有一張，很難有足夠一系列的圖搭配整體 UI 和遊戲物件。所以我再以有興趣的圖案主題搜尋，即使不是相同作者，但若風格接近也把它記錄下來。最後雖然有幾個主題因為圖案數量不足被捨棄，但終於找到圖案數量足夠的主題：海盜。

第 2~3 天
美術的問題算是解決了，再來就是音樂。剛好手邊有兩首之前一款暫停開發遊戲的音樂，加上時間有限我也懶得到音樂網站挑，所以直接使用。素材有了，但問題是素材無法要求修改或追加，所以開發決策變的很簡單，那就是選擇一個遊戲類型，而且只能利用現有素材把遊戲兜出來。一開始想過很多種遊戲類型：角色扮演、機智問答...等等，但都因為遊戲素材不足而作罷。最後終於想到：踩地雷。
程式技術部分，因為 Cocos2D 我已經一陣子沒碰了，外加踩地雷對動作性要求不高，所以決定採用我最熟悉的 HTML5 + PhoneGap。開始寫程式！這個階段因為時間很趕，所以我只要一確定方案可行就直接採用，根本沒有想過比較幾種方案的優缺點。

(一開始的遊戲畫面)

第 4 天
因為沒有預設的遊戲規劃，有時反而會在開發過程中因為素材的搭配激發靈感。本來是設計類似魔法寶石的玩法，遊戲開始就進入關卡畫面，完成一關之後會直接進入更難的下一關。
但在開發過程中，不斷看著關卡背景的尋寶地圖再加上背景音樂，突然覺得如果能在地圖上開著海盜船應該很好玩，衡量開發時間後，立刻改成類似 Puzzle Quest 的遊戲模式，可以在地圖上自由選擇關卡的機制。

另外一個例子就是插旗子。一般採地雷遊戲都可以標註旗子避免誤踩地雷，程式寫完後覺得旗子的圖案很單調，所以改成小海盜的圖，結果後來衍生為小海盜會陣亡，而且海盜人數可以買賣的機制。

(這個階段因為還不知道素材是否能搭配，所以圖案都是先套用圖庫網站上面的預覽圖，有很醜的浮水印)

第 5~7 天
遊戲流程大致完成。但圖案還是用預覽圖，而且因為沒有規劃程式很髒亂快要寫不下去了，所以正式購買圖庫的圖，外加決定程式重寫。程式重寫的過程中順便檢討遊戲機制，來不及的直接砍掉，不合理的補強。

第 8~9 天
程式重寫終於完成，美術部分也改成正式授權圖案，開始請朋友幫忙測試。這段期間除了修改 Bug 之外，開始進行遊戲拋光(polish)的動作。把一些小圖示加上陰影、簡化流程、加上新手教學...等。另外因為文字數量不多，決定一起發行英文版，開始進行翻譯。雖然因為重寫超過了當初的時程規劃，不過也沒辦法...

(為了Debug，顯示除錯資訊)

第 10 天
Bug 總算修完了，並針對試玩的建議調整難易度。終於可以打開 XCode, 用PhoneGap把遊戲包裝成APP。順便測試一下IAP是否運作正常(因為只有APP可以測試)。自己玩APP兩個小時，測試各種狀況是否運作正常，中間再改了幾個地方，最後終於檢查沒問題了，送審。

(最後修改的Bug: 雲會亂飄...)

心得：
雖然後來發生了因為被測試出無限洗錢密技，急急忙忙修改過重新送審事件，但總體而言這個遊戲一共花了10天完成。大家一定會有疑問：這麼趕的情況下，遊戲品質會好嗎？老實說這次我自己也覺得品質有很大的改善空間，但我還是很肯定這種開發方式，以下是心得：

1. 人人都希望開發心目中的夢幻遊戲，但在沒有限制的情況下，規劃出來幾乎都是永遠無法完成、超越魔獸世界的大作。要克服人性的弱點，只有給自己足夠的限制，才能強迫自己面對現實，開始動手做符合目前階段能力的作品。我認為時間是最好的限制因素 (當然開發預算也可以，但因為大家都沒有很多錢就別提了...)。雖然有可能會因此犧牲品質，但總比到了80歲還在喊想做遊戲但沒時間好多了。

2. 限制會激發靈感。若不是這次的種種限制，我永遠不知道遊戲可以這麼開發。長期在業界工作的人通常會不知不覺被各種最佳實踐(Best Practice)所影響，然而那些工作流程幾乎都是大公司發展出來的，不一定適用於獨立開發者，因為照那種方式進行你的資源永遠不夠。可能只有給自己不可思議的限制才有辦法突破這些觀念。

3. 玩家只有實際玩之後才能說出優缺點，拿著文件問別人好不好玩一點意義也沒有。其實就連開發人員也一樣，很多功能我自己實際玩之後才發現沒有當初想的有趣。若規劃與試玩的之間週期越長，砍掉重練的成本越高。其實遊戲一完成，我就已經知道整個遊戲的優缺點，也有了開發2代的靈感。然而這些靈感想法幾乎都是在開發過程中產生的，沒有親自動手做，我想我永遠無法體會那麼細緻的設計差異。

4. 最後再談品質。我想若要追求品質，同樣的流程再多跑幾輪就好了。因為最後上架的成品可能是好幾輪的成果，對開發人員已經算是遊戲的第2代或第3代，品質應該會很洗鍊。同樣的事，第二次做一定比第一次好！

結論：
這次經驗我學到了很多，而且我相信下一次會表現的更好。也許每個人的狀況不同，但請給自己一個不可思議的時間限制，然後立刻動手。我想不論最後結果如何，都應該會有很多收穫。例如參加料理比賽，人人都覺得自己若端出鮑魚龍蝦就穩贏了，但現實生活中無法每次都有那麼多資源，通常你的材料只有剩菜剩飯，若無法有效利用那就連參賽的機會都沒有。任何事只要有了開始就會有希望。祝大家好運。

若有人要試試 10天之內開發的遊戲品質如何，可以按這裡下載。