主題
達人專欄
達人專欄
前言：
舉例來說，動作遊戲的人物基本都有跑、跳、攻擊、閃躲等方法，以前我做了一個工具來集中控制方法觸發的順序：開發者僅需在控制腳本上先預設幾種動作變數，填些他們的參數，之後就交給這個工具去排執行順序與冷卻時間等等。如此一來，開發者就可以專心地在呼叫動作與其他方法宣告，不用去管誰先誰後，不用去判斷該不該中斷目前行動等等問題。
但它有個缺點，就是資料帶不走！ 也就是這個「腳本跟上面的參數」和物件綁死了，一個不小心可能會因為Unity的Reload導致參數不見，或移植別的物件時某些參數又要重新調整等等，時時都活在「參數」會不會不見的恐懼中! (其實也沒那麼嚴重。)
因此，隨著這次的新開發，就來做個新架構解決這個問題吧！
舊工具的描述，都要成為過去了就不用認真看日文打甚麼了。 主要是在說明工具是如何透過「優先度」等參數控制玩家物件從Idle > Jump Start > Jump epic > Jump Fall > Jump End動作的，開發者僅需定義各動作的播放的動畫與參數，接著就交給此工具去排執行順序。
舉例來說，動作遊戲的人物基本都有跑、跳、攻擊、閃躲等方法，以前我做了一個工具來集中控制方法觸發的順序：開發者僅需在控制腳本上先預設幾種動作變數，填些他們的參數，之後就交給這個工具去排執行順序與冷卻時間等等。如此一來，開發者就可以專心地在呼叫動作與其他方法宣告，不用去管誰先誰後，不用去判斷該不該中斷目前行動等等問題。
但它有個缺點，就是資料帶不走！ 也就是這個「腳本跟上面的參數」和物件綁死了，一個不小心可能會因為Unity的Reload導致參數不見，或移植別的物件時某些參數又要重新調整等等，時時都活在「參數」會不會不見的恐懼中! (其實也沒那麼嚴重。)
因此，隨著這次的新開發，就來做個新架構解決這個問題吧！
舊工具的描述，
照慣例偷偷宣傳個人網站。
新架構，新概念!
以前的文章有介紹過「邏輯分離的資料驅動」，那時候我是在Unity打包好方法接口，以物件的方式傳給lua(分離邏輯端)，優點是Lua簡單上手、能像文本一樣跟物件打包帶走，缺點是接口必須事先定義好，且Unity不支援Lua使用動態include (在該文章中我用一個管理腳本回傳所需的接口模組，去模仿include的動作)，且真正的"方法"還是在Unity內，Lua只是分離了「使用方法的邏輯」而已，若哪天要改還是得從內部改。
因此，我思考如何將掛在物件上的腳本(包含類別變數的方法、呼叫等)做成分離的資料。最好的方法應該是做成dll，但若dll需要跟遊戲內的資料互動的話，就也得在dll去ref那個架構才行。 到最後會變成一群dll檔去做互動，遊戲只是載入與執行的容器。
最終設計出這個架構，以下慢慢解釋：
DLL是甚麼?
Windows 用戶在自己裝函式庫到開發環境時應該常常看到「dll遺失」的error吧。 DLL (Dynamic-link library (動態連結函式庫))，可以說是打包的函式庫，直覺來說跟exe差別在於exe啟動後他會去直行進入點的方法(例如Main()函數)，而dll就是可以用來存放方法的容器，需要時再從裡面找。
例如之前的專案，我在Unity中調用的OpenCV C++函式庫就是在跟Dll互動喔。
延伸閱讀：動態連結程式庫 (DLL) - Windows Client | Microsoft Learn
XML是什麼?
XML(可延伸標記式語言（Extensible Markup Language))，XML跟HTML一樣是標籤語言，常見於專案設定檔、網路API等等，詳細就不講古了單刀直入：「為什麼用XML?」
與最常拿來比較的"Json"來說，XML比Json老、比Json胖，但格式很明確、生態系完整。
來源:Unity and DLLs (what-could-possibly-go-wrong.com) 
新架構，新概念!
以前的文章有介紹過「邏輯分離的資料驅動」，那時候我是在Unity打包好方法接口，以物件的方式傳給lua(分離邏輯端)，優點是Lua簡單上手、能像文本一樣跟物件打包帶走，缺點是接口必須事先定義好，且Unity不支援Lua使用動態include (在該文章中我用一個管理腳本回傳所需的接口模組，去模仿include的動作)，且真正的"方法"還是在Unity內，Lua只是分離了「使用方法的邏輯」而已，若哪天要改還是得從內部改。
因此，我思考如何將掛在物件上的腳本(包含類別變數的方法、呼叫等)做成分離的資料。最好的方法應該是做成dll，但若dll需要跟遊戲內的資料互動的話，就也得在dll去ref那個架構才行。 到最後會變成一群dll檔去做互動，遊戲只是載入與執行的容器。
最終設計出這個架構，以下慢慢解釋：
DLL是甚麼?
Windows 用戶在自己裝函式庫到開發環境時應該常常看到「dll遺失」的error吧。 DLL (Dynamic-link library (動態連結函式庫))，可以說是打包的函式庫，直覺來說跟exe差別在於exe啟動後他會去直行進入點的方法(例如Main()函數)，而dll就是可以用來存放方法的容器，需要時再從裡面找。
例如之前的專案，我在Unity中調用的OpenCV C++函式庫就是在跟Dll互動喔。
延伸閱讀：動態連結程式庫 (DLL) - Windows Client | Microsoft Learn
XML是什麼?
XML(可延伸標記式語言（Extensible Markup Language))，XML跟HTML一樣是標籤語言，常見於專案設定檔、網路API等等，詳細就不講古了單刀直入：「為什麼用XML?」
與最常拿來比較的"Json"來說，XML比Json老、比Json胖，但格式很明確、生態系完整。
檔案、變數多了之後你可能會拼錯字、漏打等，若用Json就會Debug到死，當然可以自己做一個Json檢查器，但何不直接用XML的呢? XML有格式檢查語言DTD與Schema，前者比較老、簡單但能檢查的格式限制多，後者導入了類別的概念，能建立起縝密的架構。
例如DTD定義一性別屬性：
換成Schema寫法：
現在懂DTD比較「簡單」的意思了吧XD
不寫格式檢查可以嗎?
可以，執行上沒差，但痛苦一下寫完檢查檔，之後打xml就能有香香的自動提示功能喔 (VSC裝套件會自動檢查)。
實際使用
說明：遊戲中有兩個可互動物件：玩家跟大白球。 大白球平時會跟著玩家，玩家可以使用攻擊鍵1往前方丟出大白球，或用攻擊鍵2近戰打擊大白球。 若近戰打到大白球則玩家會往上彈。 再加上其他零碎功能如：播放動畫、打擊效果、打擊事件、落地檢查等等，「全部」都是分離邏輯處理的喔! 實際Unity內的物件上只有簡單掛著讀取Xml的Actor元件。
建立Interface
這邊的Interface是指系統與資料之間的溝通介面，類別並不是真的屬於Interface。
為了確保介面的獨立性，我創了一個新project。
定義介面類別：
為何使用partial class?
- interface / abstract class無法被xml Serialize解析。
- partial 比concert class 多一點擴充空間。
Unity端Load XML
簡單的範例XML文本：
讀取成功！
必要的耦合：Unity.dll
定義好溝通橋梁後開始寫獨立腳本，為了能操縱物件，勢必需要使用的Unity的類別與方法。
在UnityEditor下找到Unity.dll檔，加入project的ref清單。
來源:Unity and DLLs (what-could-possibly-go-wrong.com)基本方法 和 傳遞資料
XML定義呼叫名為"Idle"的方法。
XML內容
獨立腳本中定義Idle 的內容：
結果
動態載入dll並呼叫方法
邏輯：載入dll > 取得dll裡面定義的類別 > 實例話類別 > 呼叫方法。
範例: 傳遞GameObject資料
定義Setup函數，將Unity GameObject以 System.object的格式傳送。
結果:
後記：
篇幅有點長，先分段，下一篇會講解 「事件(event)」的邏輯分離喔!
偷偷透漏架構圖：
後記2:
如果撇除最近身體抱病，認真算起來這個工具開發2-3天(包含demo物件的方法)，以往製作一個角色動作要2天，現在只要2小時
。 感覺這樣程式的部分很快就搞定了，有、有點想...找有經驗的美術一起做QQ ((設計好難....
。 感覺這樣程式的部分很快就搞定了，有、有點想...找有經驗的美術一起做QQ ((設計好難....
