# Challenge 1: Scripting Needs.

[ <- UCP Programmer 筆記目錄](https://hackmd.io/@DirtyLeon/rJsYpPxqJg)

:::info
ChatGPT:
本篇文章探討遊戲開發中的需求文件與元件類別圖的重要性。需求文件旨在以簡潔明瞭的方式記錄遊戲的關鍵特性，使非工程師也能透過圖片與文字理解設計概念。元件類別圖則協助工程師理解程式架構，促進團隊協作與開發效率。
:::

本次課題的主要目的是讓工程師依據官方提供的Requirement Document 設計出Scripting Diagram 出來。
有了Scripting Diagram，工程師就能更有效率的理解程式的設計架構，提升製作的效率。

## 1. Requirement Document

Requirement Document 與Design Document 不同，Req Doc 是紀錄遊戲最重要的重點摘要。像是更簡單的概念說明書一樣，讀起來的感覺應像是研究心得報告。

ReqDoc 不需要寫得像Design Doc 一樣複雜，而是應該要寫得簡單，盡可能讓非工程師能夠透過圖片與文字理解遊戲設計的Features.

ex:
- 遊戲介面設計(遊戲開始畫面、暫停畫面... etc)
- 遊戲畫面
- 遊戲角色的移動方式
- 遊戲中開槍的功能如何運作與判定
- 敵人或可攻擊的物件是如何運作的
- 假如敵人是被設計成由多個小石頭所組成的隕石，而且被擊毀時會自動分裂，那你可以附上一張隕石的截圖來方便讓人理解這個隕石的設計架構。
- 遊戲過關 或 GameOver 的判斷機制

透過ReqDoc 所統整的資訊，遊戲設計師就可以進一步的寫出**元件類別圖表**(Component & Classes Diagram, CCD.)

## 2. Component & Classes Diagram

<p align="center">
<img src="https://hackmd.io/_uploads/S1cYB7lcye.png" height=250/>
<img src="https://hackmd.io/_uploads/rJ9BOmg91g.png" height=250/>
</p>

<p style="text-align:center">
圖: 簡化版小精靈範例。
左為ReqDoc, 右為CCD
</p>

元件類別圖表(CCD) 是能夠讓工程師重新整理並理解程式設計架構的設計圖。工程師可以透過CCD 統整出資料的流向、元件與類別所負責的內容、物件的對應關係等設計架構。

CCD 並不代表整個遊戲或Project 的設計文件，它的作用是讓工程師獨自作業或是多人協作時能夠更容易理解程式設計架構。

圖例說明:
- 方塊為Component，可加入文字描述說明
- 灰色箭頭 [ -> ] 代表資料傳遞方向
- 黑色箭頭 [ -> ] 代表該物件底下的子物件
- 黑色括弧 [ -( ] 代表該物件所產生(Instantiate) 的物件

---

### - Component 說明

<p style="text-align:center">圖(1)</p>

在設計CCD 時，應說明各區塊所負責的功能。如```GameManager.cs``` 應掌控玩家目前的遊戲資料、得分、生命等，並且透過箭頭說明GameManager 會與哪些Component 進行互動。

在圖(1)中，可以看到GameManager 負責掌控大多數的遊戲資料，並且將資料傳給三個負責控制UI 的不同Component。

圖(1)::架構
- `GameManager.cs` 應負責掌握全域的資訊，如當前遊戲狀態、分數、玩家生命數... etc.
- 各項UI 應負責的各項功能
- `PanelIntro.cs` 為遊戲開始畫面，應有 **開始遊戲** 按鈕
- `PanelLevel.cs` 為常駐介面，應在遊戲過程中常駐顯示玩家資訊
- `PanelGameOver.cs` 為GameOver 介面，應顯示得分與重玩按鈕

---

### - 進一步組織架構

當某個區塊可能會產生多個GameObject 到場景中時，對於比較沒有特殊作用的GameObject(如靜態物件) 可以省略不特別記錄在CCD 當中。
例如下圖圖(2)中的```GameLevelLayout``` 會依據關卡資訊產生地圖，其中就會產生可撿取道具、敵人、牆壁等GameObject. 但是牆壁這些物件並沒有自己的Class，在實作中單純只是阻擋玩家移動的Collider，因此這種較為靜態的物件可以不用特別記錄成Diagram.

<!--  -->
<p style="text-align:center">圖(2)</p>

圖(2)::架構
- ```GameLevelLayout.cs``` 讀取Level 資訊產生以下GameObject:
- ```PowerPellet.cs``` 道具，玩家撿取後可以反擊敵人
- ```PointPellet.cs``` 道具，玩家撿取後可以增加分數
- ```PacMan.cs``` 玩家角色，負責動畫、移動、死亡與重生機制
- **Ghost**: 敵人角色，由```Ghost.cs```與```GhostAI.cs```組成
- ```Ghost.cs``` 負責動畫、移動、死亡與重生機制
- ```GhostAI.cs``` 敵人AI，負責尋路追捕玩家
- **牆壁**: 障礙物，實際上並沒有任何獨立運作的邏輯或觸發的功能，因此在圖表中被省略

在圖(2)中較為特別的是，**Ghost** 敵人物件是由```Ghost.cs```與```GhostAI.cs```兩個Component 所組合而成的Prefab，因此在圖表中他們是以垂直的方式組合在一起，以表示他們是同一個物件中的多個Component。

---

### - 簡化、合併與重複利用Component

在上述範例中，如圖(2)，出現了很多相同且重複的標籤被貼在許多區塊底下，如黃色的```AODSGS```。這些標籤其實也是Component，只是被定義在範例圖片以外的部分而沒有被列出而已。然而這些Component 是可以被重複被使用在其他區塊上的，例如```ScreenWrap```，簡寫成SW，他的功能是讓遊戲物件碰觸到地圖的邊界後，會出現在地圖相對的另一端。玩家和敵人都具有SW 的行為模式，所以可以把SW 的功能獨立做成一個Component附加在玩家與敵人身上，而不需要把這項功能分別寫在```PacMan.cs``` 與```Ghost.cs```兩次。

標籤Component 說明:
- AODSGS: ActiveOnlyDuringSomeGameStates
    使遊戲物件只在特定的遊戲階段才被啟用。
- SW: ScreenWrap
    使遊戲物件在碰到地圖邊界時會移動到地圖相對的另一端。
    如碰到地圖最右邊的邊界時，將物件瞬間移動到地圖的最左邊邊界。

## 3. 課題作業

本次課題的作業是透過提供的AsteraX 遊戲的Requirement Document 設計出CCD。以下是講師所提供的建議:

- Combine shared behaviour across multiple GameObjects into a single Component.
- Scriptable Objects allow artists to replace assets.

---

### 資源連結

- [Challenge 1 Assignment](https://drive.google.com/file/d/1lcoxy0CWimL0pHdEiUfIfOT_bIG8Gla0/view?usp=drive_link)
- [AsteraX Requirements Doc](https://drive.google.com/file/d/1YoqssMhTyv8UzjCuojPJupvRO04isN8j/view?usp=drive_link)
- [Example: Pac-Man CCD](https://drive.google.com/file/d/1G1hs4wc9_1ts_M9IU6uIUVpcAmR7eijw/view?usp=sharing)