第六屆 DIY Game Jam 回顧
從第三屆開始,到今年舉辦的第六屆,我參加 DIY Game Jam 也兩年了。起初只是想說試試看參加時程比較長的 game jam(為期一個月而非兩三天),或許可以幫助自己產出更完整的作品,後來想到這或許是個帶社團學弟妹累積經驗的好機會,於是就在高中社團內詢問是否有人感興趣參與。(第四、六屆都是如此)
然後今年的數學創傷串串隊就成立了,由四位數創社的現任及卸任幹部組成,參加了第六屆 DIY Game Jam。接著就來聊聊這一屆的開發歷程吧,留個紀錄讓以後的自己有機會檢視可以如何改進。
發想
本屆活動的主題 "跳脫 Jump Outside",並且加了一段小小的...說明?
₍ᐢ ̥ ̮ ̥ᐢ₎ *:・。 ₍ ᐢ. ̫ .⑅ᐢ ₎ ₍ᐢ.ˬ.⑅ᐢ₎ ₍ ᐢ. ̫ .⑅ᐢ ₎
換個角度想,至少框能帶走 -- by 宇宙兔飛碟公司
我個人對於這個概念的詮釋是要跳脫框架思考,不要侷限於既定的想法,使用不同的角度去觀察的話可能會有不一樣的發現。我認為符合這種主題的遊戲有 There is No Game: Wrong Dimension 和臺灣學生團隊開發的 Mirror xd 等,雖然我沒玩過 Mirror xd,對於遊戲內容的認知來自於宣傳的影片,但我覺得看起來是同一類型的遊戲。不幸的是在我想要下載試玩版的時候載點已經掛了,並且看開發團隊的 FB 粉專也不像是有繼續開發的樣子,令人難過。
看到主題之後,我第一個 idea 是想做一款要想盡各種辦法關掉的遊戲,對應到主題的概念的話就是要 "跳脫" 出遊戲,而各種非常規離開遊戲的方法,也就是對應到我認為主題中的跳脫框架思考。其實去年的 DIY Game Jam 我也是想到有點類似的主題,要在遊戲中製造各種 "驚喜",例如說 UI 其實是遊戲道具的一種;玩家和遊戲的互動會延伸到執行檔之外等等,但後來礙於實習以及技術力的限制等,我並未成功的設計出我理想的玩法。可能是這種理由,我便沒有將這個想法告知其他人。
活動剛開始那陣子,由於家裡剛好出了點狀況所以我並未參與遊戲概念的發想,是學弟妹們一同討論大致的構想,之後結論是這個:
未來的某一天,某個位於地下幾百公尺的實驗室發生了意外,該機構所研究的奈米機器人大量外洩,強大的機器人如同蝗蟲一般,將會摧毀掉觸及到的所有事物,實驗室的科學家為了活下去,必須逃脫地下實驗室,一步步往上爬……
meanwhile, 機器人不斷地往地面侵噬,往上爬的途中也不斷地有掉落物
類似小朋友下樓梯的玩法,不過是往上走,一些額外的機制包含途中會有掉落的障礙物,特殊的地板和玩家會有點特殊能力(一些數據或是移動機制的變化之類的)。聽起來不算太複雜,所以我就大概切一下程式的模組:
- 角色:可以移動,要有血量可以被扣血
- 關卡
- 障礙物:關卡中會從上方掉落,砸到玩家會扣血
- 平台:要能夠生成平台供玩家往上跳
- 機器人:會一直往上移動的邪惡奈米機器人,碰到玩家會讓他 GG
- UI:各種 UI,本來想說我都自己做掉就好,所以沒再細分
- 有空再做:道具、特殊的平台
大家就依照這個分工去開發。
BTW,小朋友下樓梯這遊戲的原文是 NS-Shaft(資料來源),我在跟 ChatGPT 討論遊戲想法的時候跟他講小朋友下樓梯他會聽不懂。
開發
接著就開始為期大約兩週的開發了,我本來想說就跟學校專案差不多以一至兩週做為同步進度的週期應該還可以,但實際執行過後發現這樣的效果其實不大好,經過了約一週之後才出現了我們專案的第一個針對遊戲邏輯撰寫的 commit。
造成這現象的成因可能有很多,像是投入的時間不足,對於工具不夠熟悉或是 spec 不夠明確等等,然而以我的能力其實不大確定應該如何處理比較適當。若是跟 NOJ 一樣,是打算長期投入開發的 side project,我認為一週才做出改動修個 issue 倒是無傷大雅,大家可以慢慢磨合找出適合團隊的步調,但在 game jam 這種需要快速打造原型的場合,我們的時間並不多,在這時候離成果發表已經剩下約半個月了。對此我認為比較快速的修正方式是讓開發流程更同步一些,這樣大家應該能夠比較好同步 context,避免互相依賴造成的拖延,因此在第二次開會時提議我們需要找出一些能夠同步開發的時間。
會後我們敲定了幾個時段,希望在這些時間製作可以讓開發比較順利,但實際嘗試之後發現效果也不算太理想,這邊我認為有幾個可能的原因:
- game jam 開發的優先度不夠:可能是因為適逢開學及連假、還有學測申請等原因,大家在活動期間並沒有辦法非常專注在開發上,以我的狀況來說,為了處理跨校選課而要從台北搭車至新竹,就花了比較多的時間。
- 約定的時間段太長:雖然說是要找一些特定時間一起開發,但像是 "週四晚上" 這種極長的區間,大家在沒辦法抽出很多時間開發時便會造成難以同步的狀況。
- 沒有花足夠多的時間定義介面:可能是因為通常我在開發專案時跟團隊成員磨合了比較久,而且大家也有一定經驗了,所以寫出來的 code 通常不會太難串接。但在這次 game jam 的狀況中似乎大家的相依性拆得不是很乾淨,這也造成了溝通成本的上升。
因此我認為這次在帶領團隊方面我做得不好,本意是希望能夠讓學弟妹累積開發經驗,但效果卻比我預期的差很多,成品不能帶給大家足夠的成就感。最後有不少內容都是在截止前約 30 個小時內趕出來的,以為期長達一個月的 game jam 來說,這顯然是個糟糕的時間分配,整個開發過程缺乏迭代,東西做出來就上了。
學習
雖然這次參加,我認為不是個成功的嘗試,但我還是有學到一些知識,對於參加 game jam 來說算是達成部分目標了,畢竟我參與這類活動,通常主要是為了交流跟學習,像是第三屆 DIY Game Jam 中嘗試使用 Godot 來開發,還有某年 GGJ 與室友一起嘗試在 game jam 中用 python 幫遊戲寫 socket server(雖然也失敗了)。
Krita 動畫功能
我大多時候都使用 Krita 作畫,而在遊戲中蠻常有繪製動畫的需求,在以前我是比較土炮的幫每個 frame 分出獨立的圖層再一一匯出,這顯然是個不好 scale 的工作流程,於是在這次 game jam 我便決定好好學習 Krita 的相關功能,這部教學影片我覺得挺不錯的,基本功能說明的足夠清楚,也展示了一些動畫的技巧,並且是使用 Krita 5.0 做為示範,版本足夠新。而他的英文咬字我覺得也很清晰,不開字幕也能夠比較沒壓力的看完,推薦給想要使用 Krita 做逐幀動畫的人。
Unity URP Camera Stacking
這次專案因為我畫圖實在是太慢了,評估自己沒辦法成功畫完素材,所以想用比較偷懶的方式來做背景,像是 Cyberrupt 那樣的幾何風格對我來說就不會花太多時間,成品畫出來大概像這樣:
我在背景加上了一些方塊,跟有點未來感的圈圈(?),想要營造出一種實驗室正在崩壞的感覺。然而畫面張力感覺還是不足,所以我就嘗試加上了一些 post processing,希望可以讓畫面好看一點。但在加完之後我發現把效果套用在整個畫面的話,會讓畫面失焦,不好區分前後景,因此便想尋找如何將 post processing 套用至部份物件上。
最後在 StackOverflow 上面找到了這篇回答建議可以使用 URP 提供的 Camera Stacking 功能。我把前後景拆開使用不同 camera 去 render 之後,在背景補上 bloom 跟 depth of field 給他一點模糊的效果,成品如下圖:
雖然有進步,但我認為還有進步空間,或許再增加一些不同的動畫是個解法?像是讓一些物件撞到之後會變成碎片消失在黑暗中之類的,增添一種環境在逐漸崩塌的印象。關於這種遊戲畫面氛圍的營造,我最近翻到 DK 大大寫得這篇文章認為很值得參考,之後再來仔細研究看看。
結論
經過這次的活動,我認知到了自己想要帶領學弟妹參加 game jam 還言之過早,雖然我自認在 web 開發領域累積了一點經驗,應該可以把他們帶到遊戲開發上,但回顧大學這五年來遊戲開發的歷程,我認為自己在遊戲開發上更像是會 "說" 程式而非寫程式,我或許知道某些知識,但我卻沒有在自己開發的遊戲中親手寫過一些可用的程式碼,去驗證我的想法是否可以解決問題。
經過這陣子的思考,我認為自己還應該多多修練,回頭檢視以前 game jam 留下的一些專案,這些作品比較不需要讓我面對自己不擅長的遊戲設計,可以更專注在工程上,也彌補自己沒有把這些成品做完的遺憾。
當然除了技術面的問題,我認為在專案的時程規劃還有規格制定等也需要加強,增進 game client 的開發能力會有一定的幫助,但除此之外我並沒有很好的想法,還需要一些時間來摸索相關的知識。
最後附上 itch.io 上的專案連結,雖然是個完成度不高的作品,但至少它算是可以玩吧,希望有朝一日我能夠完善它,給自己一個交代。