《NetDive》

· 3769 字 · 8 分鐘

《NetDive》是個完全隨機的專案,毫無預謀,突然成行,然後就做完了。

好啦其實也沒那麼快,實際上從五月決定要做到完工也還是隔了三個月,但真要說製作時間的話大概就是三週全職的工時而已,大部分還是因為外務太忙導致。

總之做都做完了,該寫一篇文回顧一下開發吧。

所以是怎麼突然 🔗

總之今年四月已經是忙得不可開交的狀態下,突然我的朋友小峰決定傳給了我一個連結,連結是一款名為《NodeBuster》的遊戲的 Steam 頁面。

NodeBuster》簡而言之是一款自稱「實驗性增量遊戲」的作品,在撰寫此文的時候有高達 12,108 則評論以及 97% 好評。所以說「實驗性增量遊戲」到底是什麼?這樣的作品是怎麼賣個幾十萬套的?然後再加上我好歹也是做了極簡風圖形遊戲做了這麼久了,要說對這樣的作品沒興趣實在是不可能。價格也便宜,就買來玩玩看吧!

總之破完之後也挺滿意的,老實說增量遊戲並不是我平常會玩的作品(一部份是因為知道自己的自制力有多薄弱),但聽著輕鬆的音樂配著莫名有爽感的音效殺個幾小時也是不錯的!不過破完之後我也還是有很多困惑無法理解:《NodeBuster》是一款你隨時都會損血、攻擊敵人也會損血的作品,遊戲設計上雖然可以理解,但再怎麼說這款作品中的玩家也不過就是操控個準心滿無法理解這個損血的概念從哪而來。於是我就繼續往下挖掘,發現了一款名為《To the Core》的遊戲。《To The Core》就很好理解了,扮演鑽洞機的玩家無論是閒置還是鑽洞都會耗油,於是就讓我釋懷了。

職業病之下自然而然想說自己會怎樣做一款同類型的作品。接著就突然想到手上確實有一個故事可以用這樣的機制講述,另外手上正在開發中的遊戲框架也缺乏一個更動作導向的作品來驗證(當時正在開發的是一款比較接近視覺小說的作品),再加上增量遊戲整體來說結構性很明確,配合兩三小時的預估時長讓我想想不會花太久就能完成。總之大概就是這樣的背景下開始製作的。

故事 🔗

也算是相對近期才理解了自己的遊戲製作偏好,實際上真正在意的是「用有趣的方式講有趣的故事」。而我腦中一直有一個與所謂 AI 末世有關的故事,但我一直沒有決定好具體來說世界毀滅的理由是什麼。最主要的障礙源於我不想要再講又一個討厭人類的 AI 或者是暴走戰爭機器的故事,畢竟這種故事都已經講到爛了。

而在想像說要怎麼解釋「受到傷害」與「隨時間會受到傷害」的概念時,我腦中滿自然地浮現了某種「潛入資料流」的意象,可能會與資料碰撞而產生損害(雖然現實世界資料傳輸不是這樣運作的,但總之)。而又想說是怎樣的程式在攔截這些封包資料呢?有沒有可能出於某種好奇心甚至於善意的版本?於是我就突然想到了一個關於 AI 學習怎樣成為人類的故事,就這樣順著做下去了。

通常我是挺堅持盡快讓玩家開玩的設計,不過因為增量遊戲如果做中途的打斷感覺並不是很暢快,所以我就用了老套的開頭、結尾過場,再加上額外文本補足的設計方式。

機制 🔗

一般來說增量遊戲是不特別做機制的,但顯然所謂的「實驗性增量遊戲」的「實驗」點就是跨出純粹的數值成長設計,加入更有機制感的部分。總之最後做成清版射擊遊戲的樣貌其實挺自然的,但還是有兩個理由可以提:

  • 我不打算要模仿《NodeBuster》本身,我不是來做複製品更當然不是劣等版的。但因為會同樣採用極簡風視覺,加上《NodeBuster》雖然沒有真的很管他的設定卻也還是算數位風,我必須要做一個概念上大相徑庭的設計區隔開來兩者(雖然我想比較還是很難避免)。
  • 我對《NodeBuster》的效能表現有一點意見,使用清版射擊遊戲製作其實有點自動能解決這個問題,後面再多提。

總之這樣的理由下去設計也產生了一些缺點:例如說技術上來說這是個從《NodeBuster》二維的玩家決策空間變成一維的設計。實務上來說也不是不能做成一個更正統的清版射擊遊戲,不過畢竟我沒有要花在這款上面太久,以及我自己假設玩家整體來說只是想要多一點佔用腦容量的遊戲機制而已,而不是真的想要在這邊玩到一款挑戰性很高的遊戲。

Gameplay

由於我對增量遊戲的理解也幾乎停在《Cookie Clicker》類型的,後來也就多研究看看相似的遊戲做了什麼。我發現原來這類型遊戲通常還有所謂的「Prestige」系統,讓你在某些條件下重玩遊戲但是換取一些永久性加速的效果。這類型設計讓玩家決策上多了一層「什麼時候重設?」的考量拔河,我認為是很有趣的動態。另外我也玩到了一款叫做《Digseum》的遊戲,這款遊戲除了讓我的手按滑鼠按到痛以外,也向我展現了這種重設機制帶著強大的能力重來時的爽感可以有多高。

視覺設計 🔗

說真的我也沒太多好說的。再怎麼說我可是打從開始做遊戲以來就只做過「極簡圖形」、跟某種意義的「數位風」的作品啊?!但總之我就大概著重在想要呈現斑斕的色彩,還有多元一點的背景的部分。

不過也還是有一點值得一提,那就是我很早確定我需要呈現出一個很強烈的潛入、浮出水面的意象。不過這部分其實幾乎是在完成開發前後才製作的。

Dive

另外對於技能樹的設計倒是有個小故事可以講。技能樹的分布是固定的,也有想過做成動態心智圖不過最後還是饒過自己了。這株固定的技能樹是用隨機散落點,接著考慮技能之間的銜接關係後收緊與排斥開彼此後做出來的。效果還算不錯吧!不過一開始寫的時候還意外讓技能樹游走,整個笑死。

Swimming Skill Tree

效能 🔗

對於效能表現來說我很早就確定有兩件事情要達到:

  • 我希望遊戲在 Steam Deck 上能用 800p/90FPS 執行
  • 我希望我能用極端誇張的物件量來創造視覺上的爽感

前者是因為我擁有著一台 Steam Deck OLED,光是這件事就有讓我想要達到 90FPS 跟支援高動態範圍表現的強迫症。第二點則是省視說我總之沒有創造出太多細節的能力,所以我要創造出能讓人信服的視覺就要仰賴一些技巧,而這次我想要發揮「數大便是美」的手段。

總之為了榨取最大的效能,這次是我第一次好好把資料整個和 Unity 引擎抽離開來換取資料在記憶體上的連續性,然後全面地攤平整個 Hierarchy 避免物件從屬帶來的效能損耗。老實說這樣還是稍微有點不夠,但正常遊玩已經基本上鎖在 90FPS 了,只有最極端的物件量下才會達不到(至於如果鎖在 60FPS 的話就輕輕鬆鬆)。也有想過說要不要用所謂的 Big Fat Struct 式寫法,但看來現在的寫法即便面對 3000+ 物件量都還算綽綽有餘,也讓我滿確定至少我的個人專案不太可能會發展到需要用上 ECS 的時候。

另外關於前述清版射擊遊戲對效能的幫助:主要是相對於《NodeBuster》因為要讓玩家拾取掉落物而沒有辦法做精密的卸載,而在遊戲中後期相當需要農的時候必須放置一陣子再回來收菜時,Steam Deck 的效能就撐不住會卡死 XD 清版射擊遊戲風格的設計讓我有很明確的遊戲空間,可以確保物件脫離螢幕範圍就把它銷燬。當然這也代表說使用超寬螢幕的玩家自然而然會帶上比較高的效能需求,但都用這麼寬的螢幕了應該要配好一點的配備吧!

至於物理方面,所有的物理表現都是假造出來的,因為我想要可以精確控制碰撞彈跳的表現。當然物理判定本身還是直接用 Unity 內建的,一開始 Rigidbody 是使用 Continuous Dynamic 模式進行偵測,不過因為總計算費時略高於我能接受的程度,所以就換用 Continuous Speculative 了,反正因為遊戲性的關係碰撞判定也沒有很一定要這麼準確。

音效設計 🔗

自上次認真進行音效設計已經過了滿久了。《自動混亂》的音效是沒經驗的我用一週密集作業產出的成果然後就沒再動過了,後續《自動混亂:零式》就延續下去沒改動,也還是有點抱歉因為有玩家抱怨《零式》的音效表現不夠舒適。

我原本是使用一款 Resonic Player 進行音效管理,不過因為一些因素我現在大多在 macOS 上面開發,但是 Resonic 並不支援。後來想起之前做《九日》音效設計的朋友曾經向我建議過一款「Soundly」,發現支援 macOS 之後我就趁勢使用看看。

Soundly 對 Fmod 與 Wwise 都有很好的直接整合,經過一些調查後似乎也是唯一的音效管理軟體有做相關支援的。雖然免費版被給定了一個只能存放最多 10000 個音效檔案的限制,而且搜尋的時候還會故意塞給你付費雲端資料庫的檔案干擾你之後再說請訂閱喔!這部分是有點爛,但畢竟人家也是要活的商業公司,只能這樣了。另外 Soundly 有可以搜尋相似的音效的功能(不過要先跑過一次整個資料庫的分析),然後也意外有免費版可以使用的對話音效檔產生器功能。

使用 Soundly 的工作流很順:找到音效、選擇音效、接著就可以按一個快捷鍵快速地傳送進去 Fmod 專案檔裡面。總之《NetDive》的音效基本上是在半天內完成的,我對結果算相當滿意。這應該算是 Soundly 的實用性的證明,以及或許經過這些年我也確實有音效設計能力上的成長吧。

為一款增量遊戲設計音效倒是有自己的獨特困擾:要謹慎平衡於吵鬧、爽快以及無聊之間,稍微有所偏差就沒救。我想更好的做法可能是準備一套動態系統可以調整音量與音效檔案,面對各種場面平衡出最好的音場,不過我想了一陣子之後沒有立刻想到很直覺好懂的做法,總之這款就普通的定版在偶爾爽快但總之不要讓人惱怒的程度。

另外有個有趣的事情是,其中一個試玩玩家提到他覺得 lofi 風音樂配碰撞聲聽起來很像餐廳裡的感覺,我覺得這個觀察很有趣,所以最後打磨的階段就更直直往這個意象去做設計。

結語 🔗

《NetDive》是一個我玩得很開心的專案。規格明確、迭代快速,這次的專案規劃上幾乎是個全遊戲包含設計都寫在純 C# 內的作品,Unity 只是拿來顯示的工具,這樣的設計下讓開發上的可靠度極高,或至少不可靠的部分都是我自己造成的看得到修得好。原訂五月內完成的專案拖到八月是有點不幸,但單就工時來說可以說是超乎想像地短,如果之後的作品都能用這樣的節奏開發就好了!