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