主題
要熱死了
今年夏天體感比往年來得還晚，但不變的是一樣熱爛。
這次的進(jìn)度全都和存讀檔處理的機(jī)制上有關(guān)，雖然場景切換還有存檔處理都是先前寫好的，但組合起來才發(fā)現(xiàn)漏洞可以說是滿天飛，很確定這段期間有一半以上都是在進(jìn)行除錯(cuò)。
也因如此，很可惜來不及把標(biāo)題介面的雛形給一併完成，只好做為下一篇的進(jìn)度內(nèi)容了。
◆【連續(xù)地形標(biāo)記】
這個(gè)功能主要用途是獲取一個(gè)場景之中，將所有地勢具連續(xù)性質(zhì)的地形進(jìn)行分組、標(biāo)記並儲存之用。
能夠應(yīng)用的範(fàn)疇還挺多的，比方說在存讀檔處理中，如果僅僅只是記錄玩家所在的座標(biāo)處的話，是有可能出現(xiàn)潛在的問題。
像是一個(gè)場景在版本更新之後產(chǎn)生了地勢的變化，原先存檔的座標(biāo)處已經(jīng)被地形所掩蓋，這麼一來讀檔直接把玩家設(shè)置在該處的話，玩家整個(gè)就卡在地形裡面了。
除了玩家座標(biāo)之外，可以改用來記錄玩家所接觸的連續(xù)地形標(biāo)記，版本更新前後確保該標(biāo)記能夠留存，並隨著地形而變化，讀取存檔時(shí)就改為以擁有該標(biāo)記的地形為玩家生成處即可。
倘若存檔中真的遺失了該標(biāo)記，或是原有的標(biāo)記地形已不復(fù)存在，也可以用儲存的玩家座標(biāo)，改為取用離此座標(biāo)最接近的其他標(biāo)記地形來替代，能夠確保玩家不會在讀檔之後出現(xiàn)在不該出現(xiàn)的地方。
至於連續(xù)地形的判別，使用的是以前寫的地形射線判定功能，稍微有點(diǎn)複雜但可以參考：[遊戲開發(fā)日誌 #5]
Δ 連續(xù)地形生成控管物件
Δ 進(jìn)度可視覺化的標(biāo)記生成過程
如果略過可視化效果的話，不用半秒就能刷新完成。
所生成的標(biāo)記其實(shí)就是附著於地形上的 EdgeCollider，故它們也能夠手動來進(jìn)行啟用、移除，亦或是合併及拆解。
連續(xù)地形標(biāo)記的功用還能運(yùn)用於，像是角色物件掉入了落穴陷阱後，隨後要進(jìn)行重生位置的參考位置，即為回到角色最後所接觸的地形標(biāo)記上。
我不確定其他橫向平臺遊戲是怎麼樣處理這塊的，應(yīng)該不會是每個(gè)地形都手動設(shè)置重生點(diǎn)吧，那感覺也太累人了。
自己寫程式有個(gè)要點(diǎn)就是，能讓程式自動幫你處理好的部分，絕不去進(jìn)行手動調(diào)整。
往後連續(xù)地形標(biāo)記還會做為敵人 AI 用來追跡目標(biāo)角色的參考來源，至少不會是以前畢業(yè)製作作品那樣，讓敵人 AI 隨機(jī)進(jìn)行跳躍，運(yùn)氣好的話可以跳到玩家所處的平臺位置這樣的。
此部分的功能我會在今年把它實(shí)裝完成，目標(biāo)是弄出個(gè)即便玩家在平臺之間瘋狂跑跳，也能追得上的敵人 AI。
Δ 現(xiàn)階段的臨時(shí) AI 不會有主動跳躍的操作，用意是為了避免隨機(jī)跳到不該到達(dá)的地方。
有了連續(xù)地形標(biāo)記之後，往後就能進(jìn)而用來控制 AI 的行動範(fàn)圍了。
◆【場景載入／卸載流程調(diào)整】
場景切換的主要架構(gòu)已經(jīng)是寫好了有段相當(dāng)時(shí)間的東西了，印象中那個(gè)時(shí)候才剛接觸協(xié)程 (Coroutine) 的概念。
這次回去檢視主要是發(fā)現(xiàn)異步載入場景的功能寫得不夠有彈性，每逢有場景正在進(jìn)行異步載入期間，就必須等待它們?nèi)枯d入完成後，才能進(jìn)行其他額外的場景載入及卸載處理。
但現(xiàn)在存讀檔功能即將實(shí)裝，玩家將會有可能在場景還在讀取的期間，馬上又載入了其他存檔，這樣勢必會產(chǎn)生不必要的等待時(shí)間，以及可能的潛在漏洞。
故調(diào)整方向會是，將待載入的場景存進(jìn)額外的 HashSet 集合中，載入場景的協(xié)程本身則是會持續(xù)到該集合內(nèi)的所有場景載入完畢（包含提前從集合中移除），或是被強(qiáng)制中止而結(jié)束。
舊版中還有一個(gè)漏洞，就是場景載入期間若出現(xiàn)了超時(shí)而讀取失敗的場合，將會有可能產(chǎn)生額外的廢棄資料而不被釋放掉。
這次的進(jìn)度有處理了這一部分，會在載入場景是一併檢視是否有明明尚未載入，但卻存在著與該場景的同名廢棄資料。如果是的話，會先將這些廢棄資料進(jìn)行移除，再嘗試進(jìn)行該場景的載入。
是說在正常遊玩的場合下，應(yīng)該很難會出現(xiàn)場景載入失敗或超時(shí)的狀況。
至少就現(xiàn)在我一個(gè)場景中的物件量來說，可以說是一些規(guī)格較為低階的電腦也能夠輕鬆?wèi)?yīng)付的，也已經(jīng)透過我那臺退役 9 年老電腦的 i7-4790 + GTX750 來順跑過好幾遍。
當(dāng)初有製作讀圖過場進(jìn)度條的預(yù)定，看來是可以簡化成小型指示圖標(biāo)的樣式了。
◆【存讀檔介面完成】
如題，除了存讀檔之外，屆時(shí)開始新遊戲也會透過同樣的介面來實(shí)行：
讀取檔案的功能已經(jīng)能夠正常使用，前幾篇日誌所提及的物品、異魂還有場景互動物件等等的，都能夠按照存檔內(nèi)容來如實(shí)反映。
同時(shí)也是這段期間前後漏洞修復(fù)最多的元兇，以前測試時(shí)都是固定同個(gè)存檔欄位是還好，但現(xiàn)在能有複數(shù)個(gè)欄位來彼此交互進(jìn)行存讀檔處理，
途中才發(fā)現(xiàn)怎麼某個(gè)物品不見、特定數(shù)值漏掉，甚至截圖檔案缺失等等的，前後修了一堆東西才終於能正常運(yùn)行，我整個(gè)好感動。
我考量了一段時(shí)間，除了原有的存檔刪除功能之外，最後還是決定把存檔的複製及移動功能開放給玩家使用。
雖然遊戲的過程中，原意是盡量讓玩家不要去頻繁讀取舊有檔案，來改變既有的結(jié)果，所以才採用了全程自動存檔的樣式。
不過玩家可能或多或少還是會想在特定的進(jìn)度進(jìn)行備份，不怕玩家直接去動存檔檔案，但想說會擔(dān)心一個(gè)沒弄好導(dǎo)致存檔缺失、毀損或出現(xiàn)漏洞等狀況。
故遊戲內(nèi)建的存檔複製跟移動都將會進(jìn)行保留，透過相應(yīng)操作來再製存檔檔案的風(fēng)險(xiǎn)是最低的了，另外應(yīng)留意相關(guān)操作僅限於標(biāo)題畫面才能進(jìn)行。
Δ 覆蓋既有檔案都會先行詢問
此外，這次寫了個(gè)類別來簡化原本顯得很冗長的變量讀寫欄位，原先寫個(gè)變量的讀寫處理是長這樣的：
若變量未初始化則嘗試從存檔中獲取，調(diào)整該變量的值則將其寫入至存檔上。
讀寫處理也是得額外弄個(gè)方法來處理，需要自訂讀寫的目標(biāo)欄位，還有存檔值的解析及寫入方法：
現(xiàn)在存讀檔功能已經(jīng)完善，故需要更為簡化的寫法來節(jié)約時(shí)間，反正就是把上圖的內(nèi)容塞進(jìn)一個(gè)類別來處理：
只要定義存讀檔所使用的索引鍵值名稱後，就能直接透過該欄位來進(jìn)行存讀處理。
當(dāng)然這個(gè)簡化版能處理的主要是那些較為單純的變量讀寫欄位，如果來個(gè)複雜一點(diǎn)的，像是讀寫期間要額外處理或是判定的話，還是得回去弄那個(gè)較為冗長的做法。
接下來得製作標(biāo)題介面了，考量到需要跟現(xiàn)有的介面進(jìn)行接合，整體方向應(yīng)該會與當(dāng)前的暫停選單相近。
背景應(yīng)該會用現(xiàn)有的素材去弄個(gè)較為單純的動態(tài)效果，反正是暫時(shí)性的，從簡為上。
遊戲的主標(biāo)題已經(jīng)決定好，預(yù)定是遊戲中玩家所在世界的名稱，所以會再搭上副標(biāo)題（未定）來提高辨識度，等標(biāo)題介面完成看能不能配上 Logo 之類的再公開。
先這樣，希望整合介面的過程不會又跳出太多奇奇怪怪的漏洞就好。
