從期末到新學期初，從專案收尾到開新案的一篇。
手機遊戲
專題題目是手機遊戲，所以要 build 到 android 上，這是我第一次 Build 手機版，找了一些教學參考。就不解釋過程了，很多參考能看，紀錄一下自己的除錯紀錄。
※剖析套件時遇到問題
Build 完 APK 安裝時的問題，手機顯示剖析套件時遇到問題，解決方法是降低建置設置的 Minimum API Level。
※報錯資訊
有些問題可能是 Build 才會出現的，但手機版 Build 沒有 Log 可以看。找資料後發現可以用 Logcat 插件，在手機 USB 除錯模式下玩會把 Log 顯示到這個視窗上，剩下就一般的除錯了。
※存讀檔
組員寫的存讀檔是用
System.IO 寫入 StreammingAssets 資料夾存的，Window 上沒問題，但手機寫入文件會有些限制，導致 Build 後遊戲沒辦法正常存讀。
還好這次專案前有確保他對 DI 有概念了，存讀檔有用 interface 做出接口，他的系統是繼承介面實作的。除錯起來容易多，我繼承後改用另一個存讀方案 (PlayerPrefs)，直接替換使用的系統就好，接口不變其他部分都不影響。
阿…偉大的 Dependency Injection
只有截圖，畢竟聲音我也沒法再這展示 :P
做的時候朋友也推了一個音效素材庫
魔王魂，下次看看。
※發布
原本 Build 好後打算放到 Google Play 上，不熟流程，花了幾週填資料，最後成功發布了...封閉測試版。
頁面是有了，但封測版只有指定信箱的白名單能玩，所以你們搜也搜不到。
至於正式版要 12 個測試人員連續測試 14 天才給過，我不確定連續測試的判斷標準是啥，但感覺很麻煩就先算了==
阿發還是要發的，雖然沒啥能玩的內容，但畢竟是組員們努力出的作品，發出來算給大家一個交待吧，所以我改放到
Itch.io 上，還 Build 了不用下載的網頁版。
可以用網頁玩，但存檔功能好像又壞了…雖然也沒差就是了，至於網頁手機跑不動的話可以載 APK 安裝噢。
※網頁版
Unity Build 網頁版上到
Itch.io 也蠻容易的，一樣資料很多這裡不贅述。也沒遇到什麼問題，只是要把色彩空間從 Linear 轉換成 Gamma 害我天空盒參數炸掉而已。
※社群
有在弄，真的，快弄完了，下個月初就能發了，感謝組員的努力。
我還弄了一個 PV 工具，可以方便組員設置物件或播放某些效果。
等社群內容都完成，發出後就真的告一段落了…
多人遊戲
三下的小專題題目是多人遊戲，原本是想重用美術資源，做一個在多顆星球上跳來跳去和打架的類任天堂大亂鬥遊戲，或分屏的星球塔防對戰（或合作）遊戲。不考慮聯網，雖然去年研究過 Photon 但技術成本真的太高了。
這是原本的想法啦，但在經過上學期的…嗯…顯然是挫折的挫折、人事變動、主美的千字報告和開會後我重新思考了一切。
首先，當然，讓遊戲好玩是第一目標。
畢竟我們是遊戲系，專題也要做遊戲， 所以遊戲本身的有趣程度會直接影響士氣，我最好放棄一些非必要的執著，把工作和權力分出去，把重點放在提出有價值的點子。
然後就是對題目的思考了，到底怎樣算是多人遊戲？
當然定義上很簡單，就是玩家不只一個。
但這樣似乎大多遊戲都能多人，先不論技術面，至少設計面大多單機遊戲要加入一個 2P 也不是不行，要說的話，其實很多多人遊戲也是「單人遊戲加上多人」而已，例如生存工藝類。
更多玩家只是 emm…讓遊戲更好玩？
就是一種「一起玩更好玩」的遊戲，但機制上單人和多人沒有什麼具體差異。
或一些合作遊戲也只是把一個解謎機制拆開，放在兩個地方，或許對機制有影響，但總覺得有些硬要，但情節說不通或機制上沒這種必要。
我…不希望用這種方式設計。
因為顯然大多遊戲都有辦法硬做成多人，設計門檻是相對低的。
但還是強調，不是說這種遊戲就不好或他們的設計師都很懶惰不創新，當然不是，因為客觀上就有很多好玩又大賣的「硬要的多人遊戲」。
我想避免只有一個原因：對手太多。
門檻低造成的現象就是競爭對手多，而競爭激烈導致的就是上限不斷提高。
沒錯，簡單來說就是…
在這賽道沒啥機會贏 (›´ω`‹ )
畢竟嘛…多人遊戲也不是我有愛的類型，作為一個孤僻仔，對既不是多人生存派對遊戲玩家也不是競技遊戲玩家，還會 playing Don’t Starve Together by alone 的我來說，真的沒特別偏好多人遊戲，我愛的是 RogueLike、模擬經營、沙盒之類的。
寒假初討論時主美也是一語道破：
「你想做大亂鬥類，那你玩大亂鬥嗎？」
我不玩，也不知道客群想要的是什麼，講越心虛==
所以我也開始探索其他可能性，有什麼遊戲是真正本質上、從機制層面是需要有一個以上的玩家呢？而不是能多人的單人遊戲？
合作或競技（競爭）類？但這都只是表面類型而已。
重點在人，精確說是人與人之間的互動，之前聽產學案主評論《喀拉喀拉》時也說到，即使是派對遊戲也不能太緊湊，要留對話的空間給玩家，有對話才有互動，有互動才有戲劇性。
所以怎麼打造有趣的玩家互動呢？
開完會後的午睡，我想到上個暑假的研究專案《太空漂流》，我看到小島在星空中漂流，抵達一顆又一顆的星球，遊戲的構想開始浮現…
沒錯，一個有成功案例但競爭對手又相對稀少的領域。
並且我們核心機制也有足夠差異，多人要素無論在機制或在情節上都有其合理性，不用硬把一個謎題拆成兩半，同時也能像上述兩款一樣，只要一個玩家買就能玩。
總之有想法後我兩天刻出核心機制的原型，拋棄式的，只有最最核心的玩法，然後先跟主美測試，兩小時的過程直接加了三個新東西，也找到設計的關鍵方向，主美的意見幫助巨大。
定期開會讓所有人玩過後迴響也算正面，其中一組還在原型就表現出我期望的玩家互動（即戲劇性），像剛開始遊戲就問隊友「你他媽在哪」之類的 ww
所以，講那麼多遊戲到底是要玩啥？
祕密 :P
所以這段時間可能也不會有啥圖 :PPPP
總之計畫是這樣的，這個專案會直接當畢專做，所以進度安排會有些變動。上學期因為是學期小專，所以規劃上更重視作品的整體完整度（賣相），但這學期我們會先把重點放在機制本身，視覺上只會到能測試原型的程度。
如果進度符合預期，下個暑假前會弄出一個能驗證完整機制的原型，到時會在找外部的前輩、朋友試玩，蒐集回饋後四年級修改並完整美術表現。
敬請期待 :D
原型
雖然學校進度要等第三、四周才開始專案，但在方向明確的情況我們第一週就能開始了。先嘗試寫了新企劃書，但可能是經驗不夠吧，開了五六份文件，又寫又刪了好幾次才找到方向。
這次專案的小組成員為：AngusChan（我）、ChiyukiO3O、Natsu37、Avis Shih、izumige、HuaShang。
※企劃
在人事變動後主要企劃跟程式都是我負責，但也相對把部分管理工作、設計、文書交給組員了，不然真的扛不起。
這次的優勢（至少對我而言是優勢）是可以邊做程式邊寫系統企劃，不用多一層溝通成本或考慮實作難度，部分設計也可以從技術需求回推。畢竟主要專業不是企劃，光從書面就要把東西都設計好真的太難了，還是從自己熟悉的領域開始更自在。
這次專案嘗試使用 Unity6，畢竟 why not？
※架構
企劃不能分享，所以也來談程式吧，上學期遊戲主系統是組員負責的，我才半年沒碰就感覺有些生疏了，好在重新熟悉也很快。
上學期手遊專案原本有採用，但為了省事後來也砍了 (´・ω・`)
※ServiceLocator
四層個層級之間的主要溝通方式是 ServiceLocator，用 Type 儲存提供服務的系統，再提供給有需要的對象，因為泛型約束不能填 interface，所以是用 where T : class 再加運行時的 IsInterface 檢查。
一些全域系統會在遊戲初始化時註冊進 ServiceLocator，隨機、資料庫、輸入方案等等，使用者只能透過 ServiceLocator 取得抽象接口，而只要接口不變，之後要替換系統都不影響使用，模組化萬歲！
ServiceLocator 主要是給各項主系統用的，底下的子系統還是靠建構函式注入。雖然手動注入很麻煩，但目前還沒接觸 Zenject 這種自動注入框架，所以也沒辦法。
※資料庫
雖然是原型，但還是要做一些資料格式的定義和設定，包括遊戲物件的定義集或遊戲系統設置的配備製表。
通常這些東西會用 Excel 表格化處理，之前也寫過能自動把 Google Sheet 下載成 Json 的腳本，但設計初期很多東西變來變去或需要增減，每次小改數值都要去調整表格、改下載腳本後再下載有些繁瑣。
所以我決定先拿 ScriptableObject 湊合著用，無論改變格式或數值都能馬上有效果，接口化也讓我之後轉換到正式表格輕鬆的多。
※場景載入
一樣用多場景方案，但這次要講的是 Hierarchy 的摺疊問題。Unity 每次載入新場景都會預設把 Hierarchy 的場景和物件摺疊起來，而每次測試、尤其是前期很多除錯資訊要從 Inspector 看時都得一個個把他們展開看。
雖然不是什麼大問題，但重複無意義動作 N 百次是真的會中風==
這問題從 2019 版就有人討論過了，Unity6 還是照舊，還好有人在貼文提供解法，就是在物件上加一個能 Ping + 選取物件的腳本，這樣場景載入後 Hierarchy 就會被自動展開。
一個小 QOL 但讓我測試起來舒服多了，參考資料：
※流程管理
之前我都用 Enum 狀態機管理遊戲流程，這次換種做法，把流程函式用 Queue 存起來，每個流程可以重複執行直到 return true 後再進入下一個，切換遊戲狀態時就把新狀態要執行的動作輸入即可。
Inspector 還能看到目前流程和待執行的流程。Delegate 沒辦法序列化，這是另外用一個 string list 顯示的。
原本是給 GameManager 管理全局流程，但我發現各別遊戲系統的流程也能用就用了，反正 new 一個新物件就能單獨用。
※玩家輸入
鍵盤滑鼠啥的，這次試用新版 Input System，舊版 Unity6 好像也棄用了，資料很好找這裡就不詳細解釋了，只講跟架構有關的部分。
因為機制的關係玩家需要操控很多種東西，相同輸入（按鍵）在不同情況下有不同效果，為了維護性也是把輸入檢測用介面分離出來。
這樣未來要替換輸入方案也不會被影響，雖然不太可能換就是了。和平的一天又過去了，感謝 Dependency Injection 的努力。
時間過好快，再一個月小屋就六週年了，這陣子也想通一些事，我可能找出一切的根源了，包括自己一直以來問題、今年的狀況之類的，剛好在回顧文可以解釋，時機上也蠻戲劇性的。
總之一切正在好起來 : )
就醬，愛你們。
創作內容
【學習】發布、分工和多人遊戲
--- 重點文章 --- (0)
