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