上架一款遊戲,與沒人提的上架之後的事情

· 3334 字 · 7 分鐘

花了幾個月甚至幾年,做完遊戲,修了大小 Bug,遊戲上市了。故事就到這邊結束了。

autopanic zero

這是我曾經有過的預期,但隨著年紀增長「固有想法通常是錯的」反而成為了全新的直覺。開始懷疑自己每一個想法,想清楚這只是個沒驗證的假設還是有證據的理論顯得很重要,對於一款遊戲的生命週期來說更是如此,畢竟遊戲作為媒介有太多獨特性質,像是:

  • 做出完美的遊戲幾乎不可能,因此上市後必然要面對更多的檢驗,並且要有能動態調整的彈性,相較之下影視作品的製程到了影片上映就基本上結束了(除非討論各種補拍的導演剪輯版)。
  • 花費在與玩家的雙向溝通的時間比影視作品都還要高,玩家對於開發者要能持續溝通的期待也比較高(不太有人會追著影視創作者踹共,通常成品結果一翻兩瞪眼)。

在已知這樣的未知的未知的風險下,《自動混亂:零式》就是我拿來探索這塊領域的手段。一年前上架的《自動混亂:零式》是刻意準備的上架驗證工具,因為它有以下性質:

  • 是個我認為好玩的遊戲(過了一年還是我個人打發時間會拿出來玩的作品)
  • 是個生涯週期幾乎沒人玩我也不會心痛的作品,再怎麼說總工期也沒有很長
  • 是個不至於沒玩家,但因為刻意不行銷所以玩家數會偏少的作品

最後這一點尤其重要,因為作為個人開發者的行動時間受限,更何況不是全職進行。如果一口氣要面對大量資訊轟炸的話根本無法反應 XD 有很多人問過為什麼《自動混亂:零式》沒做過任何公開行銷,這就是理由。

總之快經過了一年,是時候來提一下我的發現了,開始囉!

多國語言很麻煩 🔗

在往下提任何一件事情之前,必須要先提多國語言。理由很簡單:因為下面的每一件事情都要乘以語言數。

patch note eng

patch note tch

更新紀錄也要跟語言同步

無論是純粹的遊戲內文本,還是外部的溝通內容,每一件事情都最低限度必須要跟語言數同步。而翻譯本身可能還是最小的問題,想像一下任何一個發消息的操作,操作本身也要乘以語言數。而當然下一個就是……

多平台經營很麻煩 🔗

這邊要講的甚至不是什麼手機、家機、PC、macOS 同步(不過一樣有相同的問題),而是單純的「發佈消息的管道」總數就代表有多少個額外操作要做,例如說《自動混亂:零式》的主要消息公布有兩個管道:

  • Steam
  • Discord 兩個語言伺服器(你看看,小遊戲經營什麼兩語言伺服器自找麻煩)

patch note discord

Discord 有自己獨立的更新紀錄發佈管道

管道數根據團隊不同還可以繼續增加,X(Twitter)、噗浪、FB、IG,純社群參與性的 Reddit、巴哈姆特與 PTT,而製作影片內容的話還有 YouTube、抖音等等。好一點的情況下平台可能有 API 可以串接程式直接統一發佈訊息,或我想應該有第三方在做整合,但差一點的情況下可能都得仰賴人力進行。以我的情境來說,Discord 可以用 WebHook 去打訊息到指定頻道(順便推薦一下《換影循跡 Bionic Bay》開發者小峰做的輔助工具),但 Steam 後台最低限度也得打開消息發佈介面,才能匯入 CSV 或 XML。

而其中 Discord 支援的是 Markdown 語法,Steam 支援的是 BBcode,這又進一步增加了麻煩。因此我後續決定以 Markdown 為主體寫更新紀錄,然後做自動轉換成 BBcode。

markdown

bbcode

另一方面同理也可以提到說追蹤玩家的消息的手段過於零碎:沒辦法把 Steam 討論板、Steam 評論跟 Discord 訊息輕易地整併成一個訊息串讓我掃過去,也會希望可以追蹤潛在的玩家心得文(例如 PTT 至少也是有一篇),變成有大量的時間被浪費在海巡通常沒有人討論的各處,但又怕玩家有急事要找我(還確實真的遇上幾次所以又更加深錯失恐懼症)。

而當然這又不得不提到說:

製作更新紀錄很麻煩 🔗

當然這比較像是我的個人問題。只要使用版本管理,有乖乖管理製程寫 commit 訊息的話,其實最簡單的方式就是撈兩個版本之間的 commit 差異,將 commit 訊息重新整理就好,像這樣自動撈出來砍掉內部訊息就好:

better commit log

不過我個人通常的 Commit 長這樣:

git commit

就變成邊做功能邊手寫更新紀錄比較快 XD

爛架構害人一世 🔗

雖然玩家希望、我個人也想要有機會幫《自動混亂:零式》追加遊戲本身的內容更新,但是在非全職的開發時間內,大半只能被錯誤修正、體驗改善類吃滿。其中一個被大幅度排擠的就是我始終想要幫《零式》補上一些額外音樂與正式的美術素材,但因為這方面的內容產出對我來說都很費時,所以就被不斷地後推。「爛架構害人一世」指的既是上市後會繼續消耗產能資源,讓內容更新跟開發下一款的時間被錯誤修正吃掉以外,也同時是等到有餘力可以考慮內容更新時,不得不考慮追加後反而導致更多錯誤發生的可能性。

而《自動混亂:零式》作為一個實驗上架的工具,還有一個最後的目的,就是我要實驗性地為它做一次大規模內容更新。在過去的一年期間我開始搜集一些費時會比較顯著但我個人想做的更新內容,預期要抓一個餘裕比較多的時間一口氣處理完。其中內容包含了:

  • 美術更新
  • 追加音效
  • 追加音樂
  • 大規模遊戲體驗改進
  • 既有機制調整
  • 潛在追加新機制、新裝備與原本有考慮要做的額外文本

最後得出了「會很痛苦」的結論,既有的東西做重新平衡與調整都還在可行範圍內,要實作新內容就會持續地遭受過去的我的時間差攻擊背刺。有複數個新增要素都有實作到一半,但全部在實裝前就被迫放棄了。讓我可以繼續正視開發出一個完整框架的必要性,不只是因為程式開發者的精神潔癖,也是為了能夠精神正常地進行開發與上市後維護作業的必要條件。實驗後也得出了從現在的新架構去重新開發一次《自動混亂:零式》大概會比更新既有作品到目標狀態更簡單的結論。

old framework

《零式》用的舊框架只能用是膠帶捆起來的一團亂形容,反覆持續出現的錯誤是忘記把新的設定值補進去跟使用者介面同步的區塊

better framework

正在開發中的新框架可以用很乾淨的方式自動偵測數值變動,避免發生一樣的事情

沒溝通清楚遊戲意圖會讓玩家誤會 🔗

如果玩家覺得遊戲是 A 類型,當 A 類型來玩也以 A 類型為基礎評價,但遊戲實際的設計目的是 B,就很容易讓玩家留下負面印象並進而留下負評。以《自動混亂:零式》為例,基於倖存者系作品熱潮下,玩家看到遊戲畫面的期待可能是以各自玩過的倖存者系遊戲為主。但實務上《自動混亂:零式》設計目的抓在緊迫生存感,玩家比較不容易產生倖存者系作品用彈幕狂殺敵人的結果,進入此狀態時通常接近一場戰鬥的尾聲。即便商店描述上我個人覺得很清楚,完全沒有說這是倖存者系作品,也還是因此吃到了相關的負評:

negative review

「這不是款自動戰鬥遊戲該有的設計」,雖然商店頁面完全沒這樣宣傳

當然也可以說玩家很壞,不過責任是雙向的,所以出現這個負評之後我就全面改寫商店描述,強調遊戲的難度設計跟「不是倖存者系作品」。

不過最低限度遇上這種情境也可以算是有建設性的負評,實際上告知了「呈現給玩家看的表面可能有問題」。除此之外還會有一種負評情境出現:

會有完全惡意的羞辱性攻擊 🔗

原本我的基本假設是「嘿我做了一款應該不差的遊戲免費放給大家玩,清楚地說了是怎樣的遊戲,要嘛玩家有興趣玩不至於討厭、要嘛沒興趣就不玩,又沒收錢應該不會有人刻意來攻擊我吧」,想說秉持著完全的善意應該可以得到善意對待吧?總之又是個驗證了沒驗證的假設通常是錯的狀況。

https://steamcommunity.com/profiles/76561198030784015/recommended/1423670/

實際上《自動混亂:零式》還是遭遇了純粹的羞辱性負評,剛看到的時候真的是可以感受到血液衝腦程度的生氣。但現在就可以想通會這樣做的人大概也是完全沒有做瞄準就在隨機犯案,自己在意的本身就是對方的目的了,不能落入圈套 XD 就可以笑笑看看了。

但可惡啊評論總數這麼低多一個負評都讓好評比大幅下降!

結語(?) 🔗

即便是一款基本上沒什麼人玩的小遊戲,還是滿明確地揭示出小團隊產能不足的問題,因此也讓我認真整頓了各種自動化流程、更好的更新紀錄整理方式等,在未來認真面對時才不至於因為瞬間轟炸招致精神疲勞,也才能避免干擾到真正能讓遊戲變更好的錯誤修正、內容更新等的產能需求。可以預期就算是一款完全沒被注意到的作品中都能遭遇到這些事情,能有機會推出一款面對更多群眾的作品時,必然會是遭遇到十倍、百倍、千倍的版本。

而以一個默默放在網路上的專案,玩家數雖然不多,但各種遊玩時數超過十小時跟一路破關到最高難度的玩家出現讓我非常的受寵若驚。甚至最近還突然獲得了官方 Steam Deck 認證,對於一款玩家沒破千人的小遊戲能突然被認證實在是在意料之外 XD 畢竟許多更早推出、玩家數更多的作品都沒有。

Steam Deck verified

如果是不知道哪位 Valve 員工突然發現這款遊戲決定幫它做認證的話,希望你玩得開心!

而如果看著這篇文章的你恰巧玩過《自動混亂:零式》,希望你玩得開心!

總之話不多說,該繼續開發了!