之前花了一段時間做了明日方舟的二創遊戲，應該是有些人玩，不過沒有太多回響。
老實說蠻在預料內的，不過下次我應該考慮在做這種過關式的遊戲時要做成網頁板，因為說真的不是每個人都會去點下載還要等解壓縮，可能他們還會對UNITY啟動檔有安全性疑慮...
不過這次做遊戲的過程中已學到了一些事，像是
1.下次絕對要把UI顯示跟遊戲道具內部程式碼分開-
那時候一開始在規劃程式的時候沒想那麼多，就把每個不同道具和成就都做成Prefab，
結果在改道具結構時就吃到苦頭了，我有大概50個道具，結果我為了換一張售出圖，每個Prefab都要改
改到快吐了==。
還是盡量以Scriptable Object來管理像是道具名、價格、要引用的腳本等等，然後UI再做一個固定的Prefab等生成時再指定Scriptable Object就好。
2.介面、繼承是真的好用-
雖然我這次幾乎都只用繼承(因為道具成就那些功能都比較單一)，以後應該會改成用介面來或的更高的拓展性。
共同基底功能(購買、獲得等等)寫好後依據不同道具功能做擴張的特性真的用的挺爽的
3.劇情編輯器的製作/CSV轉換腳本(找不到電腦你的GIF，暫時用我的推特內容)-
以前我在跟我朋友做遊戲的時候，我劇本真的是一句一句手動填的
所以我這次就在想，不行，我一定要省去這腦癱步驟，太浪費時間了。
剛好工作的時候有碰了點Python，知道了有CSV、TSV檔這種東西
而且Google也支援把試算表XML輸出成CSV與TSV檔。
所以思路就變成，我這個對話功能要有什麼，目前因為沒有太多特效所以很好處理
就分成 角色名(中/英文)、台詞(中/英文)、是否顯示頭像跟表情
4.UNITY WebGL 自帶的問題-
美術部分-
然後選擇，TSV輸出-
(CSV是用英文逗號","隔開，這對英文腳本是可怕的致命傷，因為這樣在後面分解時會亂掉)
最後在腳本中分割即可
(題外話，這裡其實我能直接用 \t 只是來分割tab空格，但我那時不知道為啥執意要把它換成分號==??)
最後再把生產出來的Scriptable Object放到我的劇本編輯器裡檢查就可以了。
劇本編輯器也支援編輯功能所以能順便改，不過有一點自己不滿意的是角色表情要另外讀
以後如果還有用到再改掉吧。
4.UNITY WebGL 自帶的問題-
1.他不支援Async(有夠要命，幹，只能全改成Ienumerable，而且Ienumerable還不能一次執行多個)
2.因不明原因聲音會壞掉或爆音，把聲音檔轉成16bit可以解決這問題(也要注意輸出Hz)。
3.UNITY內建字體Arial輸出到網頁板會無法顯示中文，請用Noto sans TC 或其他支援中文的字體
4.測試WebGL要按Build and run才行
5.設計模式(Design Pattern)的引入-
這次使用到的主要是狀態模式跟中介者模式。
原本最一開始草稿版關卡流程有複雜的邏輯，我把它全部寫在同一個腳本裡，我到後面發現這樣不行，會和以前做RPG的時候走一樣的路結果程式變超難管理且難以復用，所以把整個關卡流程切成了-
遊戲選單、角色選擇、畫面淡入淡出、遊戲中、遊戲暫停、關卡結算、商店購買、暫停、資料儲存、
CG撥放 等狀態，然後透過狀態切換管理器來切換狀態、
再把每個狀態開始、結束的邏輯寫在個別狀態腳本裡，這樣所有狀態就變得很好管理，不用在那邊找半天。
中介者模式則是用來當作所有系統中間的橋樑、我有聲音、分數計算、存檔等等系統，我總不可能每個系統裡都引用其他系統，這樣一旦其中一個系統修改，我會改到暴斃。
所以我用一個中介者腳本，裡面引用了所有系統的功能，這樣其他系統只要叫中介者執行其他系統的功能就好，我之後改系統只要改中介者和系統就好。
不過這模式有個缺點就是中介者腳本會越來越肥、肥死，所以以後如果做的遊戲系統更大我就要再想想。
美術部分-
美術部分就...還好，就是要畫很久，超累的
這些大概就是我這次做遊戲的一些紀錄(大部分好像都是程式)
UI是第一次做，不過做的真的很鳥，可能以後還要讀UI設計相關的東西
推廣部分-
這我一直都不太會，也是之後要注意的地方(如果我還真的要做下一款遊戲的話)
這些大概就是我這次做遊戲的一些紀錄(大部分好像都是程式)
至於這篇文章為啥那麼晚打是因為我在做完遊戲後去完成了一個我在一月時接到的P站委託
https://www.pixiv.net/artworks/116770543 <-連結 因為是委託我就不貼在其他網站只給連結
第一次接到委託真的有點嚇到，因為之前想委的都是委託R18帳、但我都沒接
結果突然本帳接到正式的P站委託，所以我過年後到現在有空閒時間都在幾乎都在拚這張圖，現在也算是能休息一下了，我可能要想想之後下班那些時間要幹啥其他的事情。
大概就這樣!
達人
