# 設計模式與遊戲開發的完美結合 - 戰爭開始
此文檔純粹為本書之讀書心得，若有興趣請至[天瓏書局](https://www.tenlong.com.tw/products/9789864340835?list_name=t-%E8%A8%AD%E8%A8%88%E6%A8%A1%E5%BC%8F)購買。
同場加映: [鴨仔大大的心得](https://douduck08.wordpress.com/2016/08/10/when-i-first-time-use-design-pattern/)、[淺墨大神的Github](https://github.com/QianMo/Unity-Design-Pattern)
:::info
**[part1 : 設計模式與遊戲設計 +基礎系統(上)](/rRnpqbQFRY2VQrGuN7xSjQ)**:mega:
**[Part2 : 基礎系統(下)](/crMMLhU4Sg6MK2B3BX-TrQ)**
**[Part3 : 角色的設計(上)](/80AlZxlvTOmPgpx-KNToEQ)**
**[Part3-2 : 角色的設計(下)](/DiP_doU3Si2Czq4RDfjzQg)**
**[part4 : 角色的產生](/jQl7Iu7sQGCqoqQayT_tCA)**
**[part5 : 戰爭開始](/RZqXsKC0QqSTyR65DePN_A)**
**[part6 : 輔助系統](/8u-WT-dhSgiclRUbplvCWg)**
**[part7 : 調整與最佳化](/iORzUj4KQnqf5gGykIljRw)**
:::

## Chap17 Unity的介面設計 - Composite組合模式
### 17.1 玩家介面設計
#### 使用者介面
**UI: User Interface**
廣義是指: **使用者跟系統之間交換資訊的媒介**，系統透過UI告訴使用者，系統內部目前狀況；使用者透過UI下達操作指令或資訊給系統。
而遊戲中的UI將定義縮小為**螢幕畫面上的資訊呈現及玩家操作**。

「**階層式管理架構**」一般稱為「樹狀結構」，Unity對GameObject的管理便是使用樹狀結構，而組合模式的說明更能了解此架構的特色，
### 17.2 組合模式(Composite)
#### 定義
> 將物件以樹狀結構組合，用以表現部分-全體的階層關係。組合模式讓客戶端在操作個別物件或組合物件時是一致的。
> > [name=GoF]
#### UML
* **Compenent(元件介面)**
* 定義階層式結構中，每一個節點可以使用的操作方法
* **Composite(組合節點)**
* 根節點
* 會有葉節點
* 實作Compenent中與子節點操作相關的方法，EX.Add、Remove、GetChild
* **Leaf(葉節點)**
* 沒有子節點的最終節點
* 實作Compenent的基本行為，對於子節點操作相關的方法可以不實作、也可以提出警告或例外

using UnityEngine;
using System.Collections.Generic;

namespace DesignPattern_Composite
{
	// 複合體內含物件之介面
	public abstract class IComponent
	{
		protected string m_Value;
		public abstract void Operation();	// 一般操作
		// 加入節點
		public virtual void Add( IComponent theComponent)
		{
			Debug.LogWarning("子類別沒實作");
		}			
		// 移除節點
		public virtual void Remove( IComponent theComponent)
		{
			Debug.LogWarning("子類別沒實作");
		}		
		// 取得子節點
		public virtual IComponent GetChild(int Index)
		{
			Debug.LogWarning("子類別沒實作");
			return null;
		}	
	}

	// 代表複合結構之終端物件
	public class Leaf : IComponent
	{
		public Leaf(string Value)
		{
			m_Value = Value;
		}
		public override void Operation()
		{
			Debug.Log("Leaf["+ m_Value +"]執行Operation()");
		}
	}

	// 代表複合結構的節點之行為
	public class Composite : IComponent
	{
		List<IComponent> m_Childs = new List<IComponent>();

		public Composite(string Value)
		{
			m_Value = Value;
		}

		// 一般操作
		public override void Operation()
		{
			Debug.Log("Composite["+m_Value+"]");
			foreach(IComponent theComponent in m_Childs)
				theComponent.Operation();
		}

		// 加入節點
		public override void Add( IComponent theComponent)
		{
			m_Childs.Add ( theComponent );
		}		

		// 移除節點
		public override void Remove( IComponent theComponent)
		{
			m_Childs.Remove( theComponent );
		}		

		// 取得子節點
		public override IComponent GetChild(int Index)
		{
			return m_Childs[Index];
		}
	}
}

public class CompositeTest : MonoBehaviour {
    void Start () {
        //UnitTest();
        UnitTest2();
    }
    
    void UnitTest () {

        // 根節點
        IComponent theRoot = new Composite("Root");
        theRoot.Add ( new Leaf("Leaf1"));
        theRoot.Add ( new Leaf("Leaf2"));
        
        // 子節點1
        IComponent theChild1 = new Composite("Child1");
        theChild1.Add ( new Leaf("Child1.Leaf1"));
        theChild1.Add ( new Leaf("Child1.Leaf2"));
        theRoot.Add (theChild1);
        
        // 子節點2
        IComponent theChild2 = new Composite("Child2");
        theChild2.Add ( new Leaf("Child2.Leaf1"));
        theChild2.Add ( new Leaf("Child2.Leaf2"));
        theChild2.Add ( new Leaf("Child2.Leaf3"));
        theRoot.Add (theChild2);
        
        // 顯示
        theRoot.Operation();
    }
    
    void UnitTest2 () {
        // 根節點
        IComponent theRoot = new Composite("Root");        
        // 產生一最終節點
        IComponent theLeaf1 = new Leaf("Leaf1");        
        // 加入節點
        theLeaf1.Add ( new Leaf("Leaf2") );  // 錯誤
    }
}

### 17.3 Unity遊戲物件的Hierarchy管理
#### Hierarchy管理
透過Hierarchy可以查看目前GameObject的階層關係:
開發者可以對這些遊戲物件進行新增、刪除、調整與其他遊戲物件的關係...等操作而它們都有一個無法刪除的Component - Transform元件

其中，Transform元件提供幾個還GO階層相關的方法與變數:
* 變數
* **ChildCound**: 代表當前GameObject節點下方有幾個子節點
* **hierarchyCount**: 代表在當前GameObject所處**相互關聯的樹狀結構**中，存在的層次數目。(相互關聯的樹狀結構指的是：以Hierarchy面板中的一個頂層GameObject作為根節點出發的一棵樹。任何一個GameObject都會存在於一棵樹中。)因此可以預想的是，這個樹狀結構中的任意一個節點的hierarchyCount屬性都是相同的。
* **hierarchyCapacity**:代表當前所在的樹的層次容量。就是這棵樹最大可以容納的節點數目，從整個樹中的任意一個節點訪問此屬性，所獲取的層次容量都是相同的。
* **parent**: 獲得當前節點的父節點，返回一個Transform對象。當此parent為null時，就代表自己已經是頂層節點，也即樹狀結構中的根節點了。
* **root**: 獲得當前樹狀結構中的根節點。
* 方法
* **DetachChildren**: 分離子節點，意思就是將當前節點下方的所有直接子節點都分離出去，讓他們成為根節點。有n個子節點，將產生n棵新的樹。
* **Find**: 尋找子元件
* **GetChild**: 使用Index取回子元件
* **IsChlidOf**: 判斷某個Transform是否為其子元件
* **SetParent**: 設定某個Transform為其父元件

#### 有效地取得UI元件
如何在Runtime(Playmode)去取得UI元件的GameObject，根據元件期望的互動方式，在指定相對應的行為。
大部份開發者會使用GameObject.Find()的方式來搜尋，但有一些問題:
* 效能問題: GameObject.Find()會訪問所有Hierarchy上的物件，一但場景上物件過多，且大量呼叫GameObject.Find()，就會有效能問題
* 名稱重複: GameObject.Find()無法預期會傳回哪一個物件，及容易產生Bug

因次這裡使用另一種折衷方案:
1. GameObject.Find()找尋Canvas，並確保場景只有唯一一個名稱為Canvas的物件。可以透過Hierarchy來搜尋是否唯一。
2. 在透過Canvas中的Transform的階層化管理，去搜尋底下的遊戲物件，在透過**介面群組**，將搜尋範圍縮小，並在搜尋工具中加入**重複名稱的警告**，讓物件搜尋更有效率及正確。

#### 遊戲UI的實作

// 遊戲使用者界面
public abstract class IUserInterface
{
	protected PBaseDefenseGame  m_PBDGame = null;
	protected GameObject m_RootUI = null;
	private bool        m_bActive = true;
	public IUserInterface( PBaseDefenseGame PBDGame )
	{
		m_PBDGame = PBDGame;
	}

	public bool IsVisible()
	{
		return m_bActive;
	}

	public virtual void Show()
	{
		m_RootUI.SetActive(true);
		m_bActive = true;
	}

	public virtual void Hide()
	{
		m_RootUI.SetActive(false);
		m_bActive = false;
	}

	public virtual void Initialize(){}
	public virtual void Release(){}
	public virtual void Update(){}

}

public class PBaseDefenseGame
{
    // 界面
    private CampInfoUI m_CampInfoUI = null;                // 兵營界面
    private SoldierInfoUI m_SoldierInfoUI = null;        // 戰士資訊界面
    private GameStateInfoUI m_GameStateInfoUI = null;    // 遊戲狀態界面
    private GamePauseUI m_GamePauseUI = null;            // 遊戲暫停界面
}


### 17.4 結論
#### 優點
* 介面與功能分離: 倘若UI都只是單純負責**顯示設定及版面配置**，並**沒有綁定其它腳本**的話，就符合此要素，增加可重用性。EX.登入介面、公司版權頁...
* 工作切分更容易: 腳本從UI元件上拔除，更容易讓美術、企劃去設計版面
* 介面更動不影響專案: 除了名稱不能變動外，其他UI改動不容易影響專案架構
#### 缺點
* 元件名稱重複: 在搜尋工具中加入**重複名稱的警告**，讓物件搜尋更有效率及正確。
* 元件更名不易: 在搜尋工具中加入**無法取得物件警告**，並提示名稱無法更動的條件。
## Chap18 兵營系統及兵營訊息顯示
### 18.1 兵營系統
### 18.2 兵營系統的組成

### 18.3 初始化兵營系統
### 18.4 兵營資訊的顯示流程

## Chap19 兵營訓練單位 - Command命令模式
### 19.1 兵營介面上的命令
### 19.2 命令模式(Command)
#### 定義
#### UML

### 19.3 使用命令模式(Command)來實作兵營訓練角色
### 19.4 命令模式遇到變化
### 19.5 結論
#### 優點
#### 注意事項
#### 與其他模式合作

## Chap20 關卡設計 - Chain of Responsibility責任練模式
### 20.1 關卡設計
### 20.2 責任練模式(Chain of Responsibility)
#### 定義
#### UML

### 20.3 使用責任練模式(Chain of Responsibility)來關卡設計
### 20.4 責任練模式遇到變化
### 20.5 結論
#### 優點
#### 注意事項
#### 與其他模式合作