強，感謝分享開發心得 很寶貴
標題屬性框現在多了遊戲的名稱，稍微放多點要素很容易就到達字數上限了。
這回的開發內容主要是圍繞在狀態屬性的機制上，跟當初預想得一樣，與現有的系統整頓需要花上不少時間磨合。
今年最後兩個月預定要集中在敵人 AI 上，前言就不打太多了直接進正題：
※ 注意這次的動圖比較多
◆【效果覆寫】
標題塞不下，稍微進行了縮寫，原文大致上是「複數效果衝突設置」。
就功能而言，它主要的作用目標是「動畫播放事件」還有「音訊播放事件」兩項。
當同一種動畫或音效已經在播放中的場合，如果要再播放相同效果的話，要怎麼進行處理的設置。
原先的版本中，我只有製作能將特效事件設置為 [SOLO] 的屬性。
當該屬性被勾選時，任何重複的特效在播放時都會被忽略，直到原先播放中的特效結果為止。
然而此次要實現的新功能中，需要能夠將原有特效進行覆蓋的設置，故不得不對 [SOLO] 屬性進行調整，也就變成這次的複數效果衝突設置了。
老樣子先把屬性改成列舉的樣式：
原本 [SOLO] 屬性為 false 的場合就相當於 DuplicateConflictAction.None；true 即為 DuplicateConflictAction.Skip。
而這次要實現的功能是 DuplicateConflictAction.Override，總之就是在播放時檢查一下是不是已經有該特效存在，有的話就把舊的砍了，用新的去重新播放。
成功應用的實際例子，是當遊戲發生儲存事件時，所播放的存檔提示特效：
除了遊戲過程的存檔外，各類系統設置的存檔也在應用的範圍內。而系統設置的存檔是使用者可以在短時間內快速觸發的，存檔特效我相對做得還挺長，同時如果有多個同樣的特效重疊播放的話 (DuplicateConflictAction.None)，視覺效果上可以說是不太好。
略過 (DuplicateConflictAction.Skip) 則是會導致後來的特效沒有被播放出來，使用者會沒辦法得知後面的存檔行為有沒有成功實行。所以覆蓋 (DuplicateConflictAction.Override) 正是該特效所需要的衝突設置類型，當最新的存檔事件觸發時，即刻播放存檔特效，並移除舊有的部分。
◆【巢狀解析字串】
印象中我好像沒有把這個功能寫在小屋日誌裡，大致上說明一下「可解析字串」：
拿 Unity 本身來說，類似於常見的換行字元 '\n'，以及 TextMesh Pro 的 Rich Tags "<color=#005500>" 這種，可以在特定場合中起到調整文字的外觀或版面配置之類的功能。
然而內建的自然在功能還有種類上就會有所限制，所以自己早期就弄了個類似 Rich Tags 格式的「可解析字串」，它的格式類似於這樣：
一個字串中如果出現以前後綴符號包覆的內容，就會根據它標籤名稱指向的類型，轉換為相應的字串結果。有需要時，可再傳入若干個參數符號提供給解析處理的系統用。
這個機制是可以與前面提及的逸出字元或是 Rich Tags 共同使用的，前後綴符號是選用使用率較低而且能一目瞭然的字元，當然解析時這些都可以另外自訂就是。
常用的例子就是用來顯示操作圖示，由於操作鍵值會根據玩家的鍵位設置，以及當前的控制器類型而變，直接用 TextMesh Pro 預設的 <sprite> 標籤是不足以達到我們的需求的。
而自訂的可解析字串中，就能根據標籤類型，去轉換成對應的字串結果，最後再呈現至遊戲中：
然而當初的字串解析系統上，設計成只支援像是上圖那樣，解析標籤本身皆必須各為單一的獨立組別的格式。如果要在一個解析標籤組別中，加入其他的解析標籤組別，產生巢狀層級的格式的話，在舊版的解析處理上是會出錯的：
由於巢狀的概念出現，解析標籤中的層級數就會變得不明確，每個層級解析前後的字串長度也會產生更不可預期的變化，
程式設計上的概念是，同樣從字串開頭開始逐字元遍歷，當獲取到前綴符號時，將其位置記錄。隨後如果找到了後綴符號，就進行舊版的解析處理，這邊都還好。
但如果是在找到後綴符號前，又找到了另一組前綴符號，這就表示需要進入深入一個層級的巢狀解析處理。直到該巢狀的解析完成後，再把結果擲回上一個層級的解析過程來繼續處理，一直到所有字元皆處理完畢。
巢狀功能的優勢在於，無論是標籤名稱或是參數的欄位處，都可以變量樣式的方法來進行設置。下面是這次狀態屬性機制中，對特定狀態的動態說明內文的解析前文字摘錄：
這段文字是對「霸體」這個增益狀態的說明文字。遊戲內角色霸體有分為常駐跟臨時性的，文字的前段會先判定角色是否擁有臨時性霸體，如果有的話，就在霸體說明文前面加上它的持續時間。
條件判斷式直接用程式碼來判斷然後再組合文字固然簡單，但說明文字更重要的是隨時可以修改內文的靈活度，以及翻譯成其他語言的適應性，這就顯示出解析字串的重要了。
遊戲內呈現的結果如下：
◆【狀態屬性機制】
最早是重製計量條時 #14 就想實裝的東西，卻因為騰不出更充裕的時間導致一再延後，至今才總算完成。
由於就視覺上來說，直接上會看見狀態屬性圖示的，就屬玩家跟敵人計量條旁邊所存在的部分。
但計量條的尺寸還有排版位置會因為計量條的類型而有所變化，首要之務是製作能夠根據其規格來調整的屬性圖示控管物件。
第一時間先畫些能用來測試的圖示，狀態屬性大致上分類成增減益、狀態、能力還有特殊類，會根據其類型使用不同的外框來呈現。
Δ 生成與移除的效果會根據其類型而有所微調
圖示本身有支援計量與計數兩種量測用的顯示功能：
| 計量 | 計數 |
 |
 |
| 以圖示明暗進度來表示的樣式。 適合用於會隨時間倒數，或是逐步累進的效果。 |
以整數呈現來指示數值的樣式。 適合用於會產生數值疊加，或是需要明示該屬性狀態的數值時使用。 |
把圖示製作成單一的物件後，用來處理它們編排狀況的就是控管物件了。它會是獨立於計量條物件的插件功能，會在計量條與角色單位產生連結時，獲取角色的狀態屬性並反映出實質的結果。
下面是精英敵人與一般敵人的狀態圖標示例，它們計量條的寬高尺寸不同，在設置上的間距和一行內可顯示的狀態圖示數量也有所不同。
遊戲內的計量條是會根據玩家所在位置調整顯示方向的，這也會連帶調整狀態屬性的堆疊方向。其實有順帶把垂直堆疊的樣式給做出來，但現階段應該是用不上，做起來以防萬一吧。
至於當一個計量條上，存在複數角色單位的場合（特別是 Boss 計量條），狀態屬性不像是計量條是能夠直接量化顯示的，這時候會顯示專屬的狀態圖示來做為替代：
Δ 從綁定單一角色到複數角色後，計數的數值表示有多少角色在該計量條上。
玩家視覺上主要能看見的狀態屬性圖示大概就這樣，背後運作那些比較複雜的這邊就再不贅述，接下要來提及的是狀態屬性跟凝神機制的連動處理。
簡而言之就是，能在暫停選單介面中，查看場景內物件的細節跟資訊。
先說跟狀態屬性的連動處理，因為這是和角色物件本身掛勾的，所以也對角色的洞察資訊做出了調整。
Δ 當洞察到目標角色單位時，會一併顯示它的計量條。
若敵人所屬的組別或群體較為特別，除了在計量條旁邊列出專屬圖示外，洞察資訊會針對它來顯示更加詳細的內容。
狀態屬性會根據角色身上的存續排列，一一列出。當然，狀態屬性是有可能達到相當的數量，讓洞察時的效果說明文字超出整個遊戲畫面的場合。正常遊玩過程應該不常見才對，但還是得做出相應的對策才行。
這次的更新追加了洞察文字框的暫時隱藏，還有移動的功能，以確保玩家可以獲取到完整的資訊：
Δ 洞察文字框可能會遮擋到角色單位的計量條，能暫時隱藏來看個仔細。
Δ 洞察文字框多到超出整個畫面的場合，能捲動它來進行閱覽。
持續傷害目前預定有 5 種，除了固定的附帶傷害外，都會隨著積蓄的層疊等級附加額外的負面效果，當然這塊是屬於敵我通用的。不過部份的增減益還有持續傷害會等到數值平衡還有傷害公式調整時再補上，屆時實測起來也會比較方便。
另外，測試期間感覺凝神的生效範圍比預期的小，因此也把範圍一併給擴大了，現在大約是主要狀態列的下半側到遊戲畫面最底部。
過去兩個月用 Copilot 請教了不少程式上的問題，精準度的高低不好說，至少一些相對複雜的概念它現階段是做出不來的。
跟 ChatGPT 比起來，Copilot 的優勢看起來是能夠配合相關來源，透過搜尋引擎獲取極為近期的資訊。
缺點是感覺有點健忘，偶爾會接不上兩三次回覆前的內容，自顧自地又開一個新話題。
跟 AI 請教的好處就是，比較能拉下臉來問一些相對比較蠢的問題，像是一些程式初學時期可能會出現的那種疑問。
老實說這段時間體感起來已經比我大學時的教授教下來的還要豐富了，大學的課程普遍與業界脫軌，當初大三找教授問了不少 Unity 的問題，換來的幾乎全是似是而非的答案。
有部分的人提倡 AI 提供的資訊不能全盤接收，其實這相對於教師也是說得通的，畢竟也沒辦法保證教授那邊給的資訊是完全正確的，知識本來就是要將過自我的篩選跟辨讀，查證完再進而吸收與應用才是。
雜談完畢，差不多也該回去做事，下一篇進度就會是年底前發的了，屆時見囉。
