製作心得 - Note

獨立開發時遇到的問題,需要注意的事項,對遊戲開發有興趣的話請往下讀。
Some quick note about problems you might encounter while making your own game. Read more if you are interested in game developing.

連續喊停的兩個專案

張貼者:2012年10月11日 上午7:17Mike Chuang

就在不久前我們喊停了兩個專案,分別是翻桌吧!歐吉桑跟小小大戰爭。

翻桌吧!歐吉桑在製作過程中就不斷遭遇到各種的問題,包含遊戲介面的修修改改跟核心玩法的不確定性,雖然各個預定的功能都實裝到遊戲中了但是就是哪邊不太對勁。直到最後我們開發小組不約而同的提出重新審視這個專案的想法,最後決定將他廢棄掉。

小小大戰爭的故事比較沒有那麼波折,主要是原本認為可以完成的核心系統運做的狀況不如預期,在遇到翻桌吧!歐吉桑的那種狀況之後,我們再度感到苗頭不對,為了避免犯下同樣的錯誤我們毅然喊停。

在短短地一個月內連續將兩個專案喊停的情況在我們創立以來還是第一次發生,一個專案喊停的理由可以有很多,但是能不能有喊停的勇氣又是另外一回事。不過到現在我仍然認為將這兩個專案停下來的決定仍然是正確的。就算我們硬是把遊戲做出來了,其中花費的精力跟成品可能都還是無法讓人滿意吧。

能夠這麼毅然的將專案中斷主要也是採用了橫向開發的好處,將整個系統的概念先嘗試著做出來看看可行性,然後再重點強化各個細節的部份。因為沒有太過深入某個特定的功能,只要覺得核心概念不可行便可毅然捨去,如果作縱向的單一系統強化(像是UI或者升級系統等等)而沒及早發現核心的錯誤,那麼到時想割捨可就困難多了吧。

從膝蓋中箭的失敗獲得的經驗

張貼者:2012年3月24日 下午4:09Mike Chuang

三月22號,膝蓋中箭的遊戲釋出之後獲得不甚理想的反應,針對這次的失敗進行以下的檢討。

原本預計的製作時間是兩個禮拜,不過因為人物數量過多以及動作調整太花時間的關係花了一個半月才搞定。在收到的回報中大部份的人都覺得太過單調,當機報告就更不用說了。

這次的主要問題出在目標族群的定義失敗,既然是以上古捲軸的梗來做遊戲代表大部分的玩家都是有一定的遊戲經歷,以這個角度切入來說,一個過於簡單的遊戲是無法滿足這個族群的需要。相對的,如果是一般的休閒玩家則無法理解上古捲軸的梗,所以在這個地方就已經失敗了。

再來是系統的穩定度問題。光是遊戲本身沒有那麼有趣也就算了,一直跳出遊戲才是讓人最惱火的地方吧,加上我們比較有特色的人物都放在二三關裡面,如果在第一關就跳出的話那會覺得這遊戲更無聊。這邊最大的失誤在於沒有足夠的測試數據,雖然在幾台測試機上沒有出現太大的問題,不過畢竟市面上的手機種類型號還是太多了,針對這點必須做更多的檢討跟測試。
遊戲本身的不明跳出原因仍然無法解明,進行記憶體偵錯也沒有發現奇怪的地方,這點我怕在未來恐怕會遇到,只是目前不知道問題所在也就沒有半髮姐決問題,這邊可能也只能先把這個問題放一邊了。

所以說這次的釋出有幾個學習要點:
1. 確認好目標族群 - 以手機使用者來說大部分的人都有一定遊戲經歷,遊戲過於簡單容易讓人覺得單調
2. 開發規則而不是內容 - 花了大量的時間作出來的內容可能一下子就被玩完了,不管怎麼做都追不過玩的速度,因此要做出耐玩的規則才是製作的重點
3. 簡單遊戲不討喜 - 同第一點,手機不是給三歲小孩的玩具,目標族群不要搞錯了
4. 需要更多的測試資料來確認系統穩定性 - 釋出之前要進行封閉測試,光是一兩台開發機跟模擬器是不夠的

第二次釋出的感想

張貼者:2012年1月30日 下午4:10Mike Chuang

在2012.1.25的時候我們做出了第二次的釋出,跟第一次釋出的情況一樣,預計釋出的東西跟實際釋出的東西有著相當的落差。

原本是打算按照第一次的守城模式加上一些建築的概念,不過鑑於系統穩定度的關係我們刪減了許多設計,像是炸彈跟可破壞的物品,最後連建築物這個新的概念都捨棄掉了。在內容嚴重不足的情況只能將遊戲類型轉型成計分制的多人競賽類型。

鑑於上次釋出遇到的問題,這次我們將遊戲除錯期延長到一個月,但事實證明時間不代表一切。就算有一個月的除錯時間,我們仍然有著技術上的缺陷,無法解決的問題不管過了多久還是無法解決。所以到最後我們決定把無法解決的部份全部捨棄,以穩定性為最優先考量,畢竟就算內容再怎麼豐富,一下子就當掉根本就談不上游玩。

那麼稍微反省一下這次的釋出吧。

我們這次做對的事情在於系統穩定度的提昇,捨去了許多不穩定以及可能導致當機的設計,將穩定度進行最大的提高,但是美中不足的是最後仍然沒有達到百分之百的系統穩定度。而在最後一刻的遊戲模式轉換我認為算是作對的的事情,因為捨去了過多的系統內容導致守城類型內容過於單調,轉換成計分賽的類型可將較少的內容作到較多的可玩內容。至於提前做除錯的動作也給我們許多緩衝時間來進行轉型動作,雖然當初的系統穩定度提昇的目標沒有達成,不過至少多給我們一些時間了解到哪些系統可作哪些不可做。

這次做錯的事情在於對部份系統的過度堅持以及低估了當機問題的複雜度。本來以為當機的問題在進行多緒的修正就可以解決了,沒想到物理也是導致當機的問題之一。新換的物理引擎也帶來許多的問題,雖然在系統效能上有所提昇,但是在穩定度上去帶來了意外的災難。對於不熟的系統不應該直接套用在現有的專案中,先進行各種測試之後再整合進來這一點這次算是徹底了解了。

經過這兩次釋出後我們體認到以目前的能力無法進行系統的穩定度修正,重新整理整個專案也不見得能夠保證不會有同樣的問題出現,因此我們決定停止目前的PC平台開發,轉為手機上的平台開發,希望新的開始不要重蹈之前的錯誤,也希望大家能繼續支持我們。

第一次釋出的感想

張貼者:2011年11月2日 下午6:47Mike Chuang

2011.11.1釋出的版本事實上跟原本預計要釋出的東西有相當大的出入,原本是打算採用洞穴+陷阱的冒險遊戲概念,但是由於目標的不明確以及模型的產出不順利,中途硬是把冒險模式轉成守城的概念。

隨著時間的推移感覺製作相當順利,經過了幾次的SVN整合之後我們程式合併的熟練度也越來越高,雖然有幾次的整合遇到難解的bug,但最後都順利解決了。這時距離預計釋出時間還有一個多禮拜的時間,我們以為可以提前釋出的時候,問題發生了。

由於我們在測試的時候用的是debug版本,使用release版的時候不知道是因為效能提昇還是什麼原因,本來不會當機的地方突然當的亂七八糟,網路的複雜度加上多緒執行的錯誤用法導致系統的穩定度在崩潰邊緣遊走,好不容易release版也順利執行的時候,最終的exe釋出版卻又出現了之前release版的問題。這次我們失去了系統的除錯工具,無可奈何之下只能靠著嘗試錯誤的方法除錯,最終釋出時仍然是沒有除錯完全。

這次作對的事情是轉換遊戲模式的決定,如果按照之前的洞穴冒險的話可能會導致更多的進度拖延以及更多的系統問題,靠著將遊戲內容精簡化之後才有時間處理許多重大的系統穩定度問題。

這次做錯的事情應該是太低估了多緒程式跟網路的複雜度,沒有留下充足的時間除錯以及沒有事先規劃好製作的內容導致了最後的成品穩定度不夠。

不管怎麼說這次的釋出讓我受益良多,希望在下一版的時候能活用這次學到的知識與教訓。

修正與重作的抉擇

張貼者:2011年7月31日 下午6:07Mike Chuang   [ 已更新 2011年7月31日 下午6:16 ]

這個月以來重做了不少系統,像是人物的控制器跟地圖編輯器等等。對於現有的程式到底要進行修正還是進行重作呢?我想主要還是根據未來的擴展需求吧。

像我之前的人物控制器是用許多條件分歧構成,對於初始來說並沒有什麼不便,但是當我要加入敵方角色時問題就接踵而出了。一開始我嘗試著去修正舊的程式碼看看能不能增加擴充性,但是最後還是以失敗告終。

事實上這種條件分歧多的設計本來就該用一些比較好的設計模式像是策略模式或是狀態模式來做,這也是所謂年輕時所犯下的錯誤吧。總之,如果覺得光是修正程式碼並不足以應付未來的擴充性修正的話,也許從基底的部份將整個構思重製成更有擴充性的設計會更好。

程式碼,一行之差決定生死

張貼者:2011年6月29日 上午2:05Mike Chuang

最近在修bug的時候又重新體認了一次這句話。

事情起因是這樣的,因為遊戲中人物以及各式物品都綁有物理運算用的物件,在刪除人物的時候也會刪除掉這些物件。當我刪除掉人物的時候,系統回報說刪除物理物件錯誤,無法刪除物件,但是當我直接刪除掉物理物件時又沒有問題。查了很久之後才發現原來是刪除順序在搞鬼。

當刪除人物的時候是先把人物的物件刪除,然後再刪除物理物件,因為物理物件有依賴人物的物件,所以當人物已經被刪除的時候,在刪除物理物件就會跳出錯誤回報。接下來要作的事情就簡單了,把刪除物理物件的指令移到刪除人物物件之前,所有的問題就迎刃而解,沒有複雜的算式,沒有多行程式的修正,沒有新程式的追加,就只是把程式碼的位置往前移了一行。

因為電腦只懂得按照指令行事,所以讓順序變得重要,一些平常覺得順序不怎麼重要的事情一到程式碼中就需要排的井然有序,這也算是寫程式的醍醐味吧。

遊戲風格對遊戲的影響

張貼者:2011年6月19日 上午3:15Mike Chuang   [ 已更新 2011年6月29日 下午10:04 ]

在談論這個主題之前我想各位應該會想先看看這段影片


我個人認為遊戲風格決定未來遊戲製作的走向,任何抉擇的判定也都需要根據遊戲風格來判斷。

假設我們是製作偏寫實類型的遊戲,像是現代戰爭那種,那麼除了畫面寫實之外其他很多的元素也都要跟著寫實:場景音效,物理判定,人物語音等等諸如此類的東西,一但有某個小環節失誤了就會導致整體的感覺被破壞。

如果我們打算製作比較卡通風格的遊戲,那麼當然也要避免遊戲中出現過於寫實的畫面。因為遊戲是偏向卡通風格的原因,物理系統可以作得稍微誇張一點,像人物可以跳的比自己的身高多個三四倍之類的設定在這邊是可以接受的。值得注意的地方是誇張不等於可以亂搞,太超乎常理的設定仍有可能造成玩家反感,像是當人物把球往前丟,球卻隨機的上下左右移動這樣的設計會讓人感到困惑。

寫實遊戲最大的優點是因為遊戲中的一切跟現實的體感非常接近玩家容易有帶入感,但這不代表卡通風格的遊戲就不會讓玩家有帶入感,只要將故事情境運用得當,簡單的線條也能帶給玩家不錯的體感。

那麼要如何決定自己遊戲的風格呢?一般來說,獨立開發者會選擇比較偏向卡通的美術風格,最主要的原因是卡通風格允許的失誤範圍比較大,在沒有太多經費的情況下通常很難做出能跟大廠比較的寫實風格美術。如果想製作寫實風格的遊戲的話需要先評估一下做出來的內容會不會掉入恐怖谷,或是做出來的畫面是否能趕的上市面上大廠的水準。如果自認可以做出驚豔大眾的畫面的話不妨放手一搏以畫面一決勝負,如果沒有此般能力的話建議你從非寫實風格的遊戲開始做起。

我認為遊戲終究是遊戲而不是電影,追求把畫面展現的繽紛多彩固然重要,但是如果因此失去遊戲帶給人們樂趣的本質的話倒不如把精神心力放在遊戲樂趣的研究上。

獨立開發就像魚與熊掌不能兼得,你決定好你的遊戲風格了嗎?

角色定位

張貼者:2011年6月14日 下午5:47Mike Chuang   [ 已更新 2011年6月14日 下午10:01 ]

羅馬不是一天造成的,大型遊戲也不是一人能造成的,在一頭栽入遊戲製作的世界之前,定位好自己的角色算是挺重要的第一步。

製作一款遊戲通常需要幾個不同角色,像是遊戲企劃,程式人員,美術人員以及音樂人員。

遊戲企劃:
可以說是最重要也可以說是最不重要的職位。良好的遊戲沒有不能沒有良好的規劃,但光有企劃沒有實行力也只是空談。一般而言,企劃需要負責的事情有許多,從最大綱的世界觀構成到最細部的遊戲平衡數值規劃,同時必須要有能跟美術人員以及程式人員溝通的能力。

程式人員:
程式分成許多種類,根據製作的遊戲種類不同會需要不同種類的程式人員,一般都會需要的是遊戲核心編寫,UI編寫,音效編寫等等。如果要製作具有網路類型的遊戲則可能會額外需要網路系統編寫以及資料庫編寫,當然有時候也會需要各式編輯器的編寫等等。

美術人員:
美術分兩大種類,2D跟3D。2D美術通常負責背景圖,材質貼圖,UI跟人物立繪等等,3D美術則是負責遊戲中的模型建構,像是人物模型,怪獸模型,地形,建築物,花草樹木等。根據遊戲的風格種類不同,需要製作的模型精細度,材質精細度都會有所差異,保持整體風格是製作上的重點。

音樂人員:
從遊戲音效到背景音樂都是由音樂人員製作,大型的商業製作團隊可能會有整隻樂團來負責遊戲中的音樂,不過一般獨立開發而言音樂通常由一兩人擔當。

想要獨立開發的話,一人身兼數種角色的能力是必要的,但是只要找到最適合自己的角色定位並將他最大極限化就能更快速的製作一款自己理想中的遊戲。

1-8 of 8