# 音遊開發心得分享

---

# 自我介紹

----

我是逢甲大學遊戲開發社的創社者，也是初代的社長，你們可以叫我AllForPadko或是創遊User(平平子這樣稱呼我)，現已卸任，所以在DC群組的身分是英靈，像現在就是被現任社長用令咒命令我進行此次的報告。

----

圖-在TSGDF中向前行政院院長張善政推廣平平子的美好

----

我從高二開始使用Unity開發遊戲，距今五年了吧，我一直一個人開發遊戲，所以全領域都略懂，包含3D建模(雕刻、綁骨、動畫、材質)、Live2D、粒子動畫、2D骨骼動畫等。

----

好像蠻多人聽到我開發了5年就會開始問我為什麼做遊戲?有什麼理由嗎?
我在這裡統一做個回答好了。

----

## 做遊戲的理由?

----


----

不過喜歡一件事根本不需要理由吧?

我想做就做，跟吃飯睡覺一樣，遊戲創作或開發就只是一種本能而已，難不成你會去想吃飯的理由嗎?
(可能會有人回問可是不吃飯會餓死之類的吧，我不做遊戲就會自殺阿，兩邊的結果都是死阿)

這是我的答案，我希望不要有人再問我這類的問題...

----

再問了下去的話，我只會回答:

----


----

你心中有艾恩葛朗特嗎?

----

幹話講多了，總之這次的主題是介紹音遊開發上面的經驗和心得。

---

# 前因後果

----

## Game Jam

----

Game Jam 是一個開發遊戲的有趣活動，參加者要在短時間內和其他陌生的遊戲開發者合作，根據特定主題製作出一款遊戲。

----

## FCU Game Jam

----

我們社團也會不定期舉辦這種活動，目前預計在下學期跟元智遊戲開發社展開一場跨校的大型Game Jam活動。
詳情可參照之前的簡報:
https://hackmd.io/@-sozKcyYR1usQsCoRhFr-A/BygCB85I5#/

----

原本這款遊戲是在我們社團舉辦的Game Jam活動上製作的，原本的想法也不是做阿平的遊戲，而是一款夸黑遊戲...

不過後來因為各種專題轟炸和期末考週的關係，根本做不完... 最後成品根本沒達到音樂節奏遊戲的程度，沒有照著節奏打拍子...空阿哭啊

之前的計畫，我錯了，夸粉不要炎上我:
https://hackmd.io/@-sozKcyYR1usQsCoRhFr-A/Syngv9XD9

----

## Kuso Game Jam

----

Kuso Game Jam也是一場Game Jam的活動，只是他的主題是糞遊戲，顧名思義就是專做糞Game的Game Jam，這邊給你們看他們這屆的主題影片你就會懂了。

----

這是這次的主題:
<iframe width="560" height="315" src="https://www.youtube.com/embed/fArc8ZdnuRg" title="YouTube video player" frameborder="0" allow="accelerometer; autoplay; clipboard-write; encrypted-media; gyroscope; picture-in-picture" allowfullscreen></iframe>

超級...意義不明
而開發時長為兩天內

----

而我會參加是因為Kuso Game Jam開始的當天，剛好滑巴哈滑到，然後還有跟春魚箱合作，可以自由運用我最愛的阿平欸，就把所有東西都改成阿平的形狀了，做了這款平平子不是你婆(不是你婆，是我婆，懂？)。

這邊由於時間只有兩天的關係，所以在無可奈何下只好使用較為簡單的方式，就是播音樂，然後紀錄按下按鍵的時間。

----

## 簡易的譜面生成

----

這不能算是編輯器，他只能做到紀錄玩家按下按鍵的時間點，並把時間都紀錄在一個檔案(json)中，遊玩遊戲時，讀取檔案(json)用這些時間點來生成音符，音符會在你敲擊的時間點移動到判定點的位置，判定時對這個音符進行判定就行了。

----

優點：很快速，可以不用考慮很多製作編輯器的邏輯。
缺點：不準確，而且容錯率低只要生成的一個音符敲錯，就要重做。

----

## 正式的譜面編輯器

----

一個正式的譜面編輯器，可參考OSU，其概念是透過BPM(每分鐘節拍數)來將節拍劃分出格子，提供一個可視化介面，以方便作譜者針對這些格子進行編輯。

----

OSU中的譜面編輯器:

----

我的譜面編輯器:

----

優點:較為準確，且就算敲錯也可以在編輯器裡進行修復。
缺點:較為複雜，尤其是如果你打算提供給玩家使用，就必須花很多心力來進行調整。

----

## 已經製作好的譜面編輯器

----

可參考這個Github的譜面編輯器，不過語法上來說大量應用UniRx這個框架，所以使用前，要先看懂UniRx的概念，不然絕對改不動。

譜面編輯器和下落式音遊的Github專案:
https://github.com/Ggross98/Unity-RhythmLane

----

也可以參考一些音遊大作Osu和Jubeat，它們都有開源在Github上面，可以看他們如何製作的，使用了什麼技術之類的。

Cytoid(Cytus模擬器)的Github專案:
https://github.com/Cytoid/Cytoid

---

# 譜面設計上的一些問題

----

## 大量音符移動造成的性能問題

----

在音樂遊戲中，大量音符會隨著節奏往判定點進行移動，這大量的物件，如果一個個進行位移的話，十分消耗性能，所以通常會將其全放到一個遊戲物件底下作為子物件，父物件移動時，就會帶動所有子物件(音符)。

----

在我的音遊中，就是在五個判定點底下建立一個父物件，將所有音符作為子物件生成在裡面，生成完後就根據譜面的流動速度，將父物件往下拉，帶動音符們一起移動。

----


----

此外這些音符的圖像，也會是一個消耗，所以可以用一個Mask(遮罩)，來讓畫面以外的音符都不顯示，可以盡量降低消耗。

----

有必要的話也可以考慮使用物件池的方式來設計，預先將音符物件放在場景以及池中，有需要再去池中找到閒置的音符，並讓它掉落，達到重複利用同一物件的目的。

---

# 未來計畫

----

我其實想做的是一款類似於OSU的社群式音遊，提供一個譜面編輯器給玩家編輯，然後目前玩法部分，還想透過將動畫編輯器提供給玩家，讓玩家可以對判定點和玩家本身製作動畫，並可插入一些可互動的圖片，而這些譜面都會上傳在資料庫上面共享，打開遊戲就可以遊玩任何其他人上傳的譜面。

----

除了譜面外，還想提供一個故事編輯器，讓玩家可以利用它來製作出各種故事，並提供節點編輯工具，可以任意的在故事情節中插入不同玩法，就是說可能選擇了什麼選項，觸發了戰鬥的情節，就透過音遊方式的分數來決定是否獲勝之類的，以決定故事的結局走向。

----

## VR音遊

----

由於這是我的畢專的關係，所以勢必要結合一些VR的應用，才能給學校一些交代。

----

有聽過Beat Saber嗎?
<iframe width="560" height="315" src="https://www.youtube.com/embed/21z3_LxWacA?start=17" title="YouTube video player" frameborder="0" allow="accelerometer; autoplay; clipboard-write; encrypted-media; gyroscope; picture-in-picture" allowfullscreen></iframe>

----

目前的想法之一是做一個拳擊版的Beat Saber，會由平平子用拳頭解決飛過來User(音符)之類的，然後拳拳到肉，每打一下都把User打成肉醬瘋狂噴血這樣，至於譜面則是採用原本的5K，譜面編輯器做好的譜面也能直接用在這裡。

----

另外一個想法會稍微困難一些，做完上述還有時間的話才會去實作，想要做個Tetote Connect的VR版，就可以跟阿平一起共舞了喔耶。

----

Tetote Connect的玩法:
<iframe width="560" height="315" src="https://www.youtube.com/embed/FhA05gIetec?start=2239" title="YouTube video player" frameborder="0" allow="accelerometer; autoplay; clipboard-write; encrypted-media; gyroscope; picture-in-picture" allowfullscreen></iframe>

----

## VR音遊的相關建模

----

https://drive.google.com/drive/folders/1igaGwQ1Pr5hSJRAu30YV-IjHE9Tb9Yz8?usp=sharing

---

# 設計模式

----

設計模式是用於解決通用問題，並讓代碼結構更清晰的設計程式的方式，不只是遊戲開發，可以廣泛應用在各種軟體上面，這個部分太學術了，只會稍微介紹一下，有興趣的可以自己查查看。

----

基本上如果你想開發一定規模的遊戲，比如說有數十種角色，幾百種技能的話，這個就屬於必備的技能了。

----

因為就算你有物件導向觀念好了，沒有設計模式概念的話，程式碼中類別與類別間會互相依賴，你無法統一管理的情況下，就會變成牽一髮就要動全身的狀態，改動一個小部分功能，就要在各個依賴類別中到處查找到處修改，是一件浪費心力的事。

----

But說了這麼多，設計模式其實屬於你事前知道你也不會懂要怎麼用的東西，他們的概念可能蠻簡單的，可是沒實際寫過碰過壁，你可能根本不會知道用這些的好處在哪裡，然後學校不教，學校不重視，畢竟學校也沒有什麼龐大的專案可以應用到。

----

我會建議新手在沒有碰過這些東西，沒辦法把技能樹往上點的情況下(習得設計模式、各種強大插件UniRx、UniTask等的使用、以及Shader著色器編程等)，盡量不要想要畫大餅，做一個什麼超大遊戲，能一步步做出小遊戲(尤其是在小遊戲做出自己的玩法上)，然後去研究鑽研技術以提升開發效率會是比較理想的一個方向。

----

## 單例模式以及單例泛型(模板):

----

概念為對自己建立一個唯一存在的物件實體 (Instance)，其他對象就可以藉由Instance來訪問內部細節。

----

實現起來就幾行的事而已

----

不過每個類別都這樣寫一遍也很麻煩，所以可以考慮使用泛型(模板)的功能來實現，T可以代表任意類別，如果不存在的話則會直接新增一個腳本在遊戲場景上。

----


----

我的音遊專案用單例模式來方便對所有需要取用的唯一對象進行存取，只要這個對象會被外部進行訪問，那就讓他繼承單例泛型類，然後其他對象就可以直接透過instance去獲得他。

----

## 中介者模式：

----

舉例來說，在班級中，如果有任一個同學想要與大家溝通的話，就需要藉由班長或老師來向大家傳話，以程式來看的話，會變成交互調用的依賴情況，越多對象要溝通就會越亂，程式要改起來也很麻煩，不如將所有同學加入一個DC群或Line群，這個群組就是一個中介者，所有的溝通就可以藉由中介者向對象間進行溝通，要改動也只需改動中介者一個人。

----

圖-互相依賴噁心的物件關係圖

----

圖-由中介者統一管理的物件們

----

我的音遊專案每個系統都由一個中介者管理，系統與系統間，則是中介者與中介者進行溝通，兩者內部溝通的細節通過private隱藏起來，只關心雙方溝通的部分，就是外觀模式的概念。

----

具體實現可參考此文章:
https://blog.csdn.net/qq_40120946/article/details/122136241

----

## 狀態模式：

----

在程式碼中，如果有一堆情況需要判斷的話(複雜的判斷)，難不成你會寫幾百個if或switch來判斷？這樣會大幅降低可讀性且難以進行擴展，這時候就需要狀態模式了。

----

狀態模式可以在Context定義狀態，並藉由抽象狀態類(介面類)，來進行狀態的擴展，每個狀態都可以寫在一個獨立的子類中。

----

在這個音遊項目中，主要用於場景管理上面，每個場景都代表一個狀態。

具體實現可參考此文章:
https://zhuanlan.zhihu.com/p/85095810

----

## 命令模式:

----

如果你想要所有操作都可以撤銷(undo)和重做(redo)的話，就可以使用這個模式。

----

他事前將命令封裝成一個對象，這個對象包含undo和redo時要做什麼的方法，然後定義一個命令的管理類別，分別在其中建立undo跟redo的堆疊Stack。

----

當你進行新增這個命令時(可能新增一個物品與角色之類的)，就會將這些命令都先存到UndoStack之中

如果你反悔按下了Ctrl+Z就會先執行Undo方法(新增這個命令對應的就是移除，所以Undo方法會把新增出來的物件進行移除的操作)，然後從UndoStack中執行Pop將堆疊的尾端移出，將其移動到RedoStack裡面

之後如果你再度反悔，就可以藉由Ctrl+Shift+Z執行重做，從RedoStack取出對象後，執行Redo方法，把Undo時移除的物件，進行新增回來的動作。

----


----

在我的音遊專案中，應用在譜面編輯器的節點製作上面，要是編輯錯的話，讓編輯者可以後悔進行撤銷和重做等。

----

具體實現可參考此文章:
https://blog.csdn.net/Altair_alpha/article/details/113603566

---

# 套件和框架使用

----

## UniRx

----

是一種編程框架，專注於解決時間異步的邏輯處理，使異步邏輯的實現更加簡潔和優雅。

----

Rx意思是響應式擴展，響應式指的是觀察者模式的實現以及與定時相關操作，擴展指的是LINQ的資料操作，簡單來說就是他把大部分資料都轉為了觀察者，並使用被觀察者對這些觀察者進行訂閱的動作，並可使用Linq的語法從觀察者中選擇、過濾出資料，這些資料在得到時，又會被轉為數據流，數據流用以判斷資料是否傳輸失敗，以及要怎麼處理等等。

----

我的音遊中，譜面編輯器中所有的資料處理都使用這種方式來處理，有點程度的Unity開發者都會使用這種寫法，像Github開源的那些Jubeat、Cytoid等。

----

具體使用可參考這兩篇文章:
https://www.bilibili.com/read/cv15236973/
https://stonelzp.github.io/unirx-learning-note/

----

## Dotween

----

一種動畫插件，Unity其實有內建Animation可以透過可視化的方式使用錄製按鈕來建立關鍵幀。（使用方式類似於AE，不過當然沒有內建這麼多特效效果。）

----

然後Dotween其實是一種程序向的動畫製作工具，它提供了各種語法處理物件的位移、旋轉、震動等等動畫，並可透過動畫曲線製作出有感覺(?)的動畫，這邊我也不太會講，所以直接帶這篇介紹[打擊感的文章](https://gnn.gamer.com.tw/detail.php?sn=125251)來講，可看到經由動畫曲線的動畫，是具有輕重緩和的，感人帶來的視覺感受也不一樣。

----

在這款音遊中，我應用在主角移動到判定點進行攻擊的動畫上，由於之後我想讓判定點可以到處移動，主角的位置也變成可以變動。

所以主角移動的動畫，就不會是固定的位置，移動的位置會隨著判定點而改變，所以我先計算判定點上、下、左、右、上左、上右、下左、下右等八個位置，並計算他們哪個與主角的距離最短，就把最短的位置傳給Dotween，使用DoMove的語法讓主角在指定時間(0.1秒)移動過去。

----

具體使用可參考此文章:
https://medium.com/ericzhan-publication/unity%E7%AD%86%E8%A8%98-%E6%89%8B%E6%8A%8A%E6%89%8B%E5%B8%B6%E4%BD%A0%E8%B5%B0%E9%80%B2dotween%E7%9A%84%E4%B8%96%E7%95%8C-307b9682dbd8

---

# 最後

----

有什麼問題都不要問我，不論是競程或AI以及遊戲開發都請找現任社長的Eason，他什麼都會他超強!

----

最後的最後...我們遊戲開發社有個優良的傳統...

----

那就是...社長女裝!

----

為了招募下屆的幹部，只要在下學期的社員大會湊齊幹部人選，當屆社長就必須女裝表示祝賀!

----

聽好了現任社長的Eason，我是第一個犧牲品...當然也不會是最後一個...!