推 LIONDODO:先推再看 08/06 13:22
推 hsufong:不錯的經驗談阿 08/06 22:35
→ qazp741:不錯 08/09 22:53
推 HSUFIT:很實用的經驗分享，謝謝你 :) 08/13 22:48
推 rocklobster:想自己做遊戲的人推 08/27 03:44
→ rocklobster:能不能細說花費部分?? 圖庫網站哪裡找?? 08/28 15:18
轉貼自 CSC Studio
如何用10天開發一個遊戲APP
http://csc-studio.tumblr.com/post/28588890981/10-app
如果有興趣的 可以看原文 有完整圖片 與遊戲檔可以下載試玩
-----------------------------------------------------------------------------
為一個獨立遊戲開發者，時常會遇到對遊戲開發有興趣的朋友們對我說，他們也想寫自己
的遊戲但總是沒時間。我自己的經驗是：要開發一款好遊戲很難，但開發一款遊戲卻很容
易，然而大多數人卻都卡在後者。所以我自己做了一個實驗，測試開發一款遊戲所需要多
久時間。最後的成果是:
成品：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代，品質應該會很洗鍊
。同樣的事，第二次做一定比第一次好！
結論
這次經驗我學到了很多，而且我相信下一次會表現的更好。也許每個人的狀況不同，但請
給自己一個不可思議的時間限制，然後立刻動手。我想不論最後結果如何，都應該會有很
多收穫。例如參加料理比賽，人人都覺得自己若端出鮑魚龍蝦就穩贏了，但現實生活中無
法每次都有那麼多資源，通常你的材料只有剩菜剩飯，若無法有效利用那就連參賽的機會
都沒有。任何事只要有了開始就會有希望。祝大家好運。
--
※ 發信站: 批踢踢實業坊(ptt.cc)
◆ From: 123.240.195.178