整個四月都在地震的感覺，沒辦法想像住花蓮的感覺是怎麼樣的。
右半邊的基本上都比較直觀：
∎ 場景名稱
∎ 開圖率
∎ 總遊戲時間
∎ 存檔日期
現階段大概就這些資訊會顯示於存檔欄位上，有可能會再進行調整。
繼續來去忙，這塊完成後大概會接軌到標題畫面。有標題後就能進行實質上的讀檔測試了。
說到標題，我總該得打算確立遊戲的名稱了，至少有個主標題吧，往後寫日誌或宣傳會比較方便。
先這樣嘿
921 的時候年紀太小，403 就是有印象以來體感最大的了，家中也出現少見的因地震導致雜物掉落或位移的狀況，當下也是怕爆。
四月除了天災外，家裡也有些狀況。
上一篇文有提到外婆過世的事，兩周前親戚才告知我們，外婆那邊的負債狀況有點牙敗，它們那邊打算拋棄繼承所以才來通知順位下方的我們。
只能說真會挑時間，而且離可以聲請拋棄繼承的最後期限也剩不到 10 天。家人對遺產繼承的權益是一竅不通，也沒有限定繼承的概念，還不停搬出十幾年前那種，剛出社會就被遺產負債壓到無力償還的新聞給我。又加上它們連上網查資料都不會，不意外自己這邊要負責處理這塊。
中間把各類文件辦妥完，總而言之最後是壓在截止日前兩天，才委託同住於外婆戶籍地的親戚到地方法院聲請完畢。
雖然告一段落了，但對於心神上的負擔還是存在的。
好久沒畫勇造了，上一次繪製已經是 2018 年的事。
當初是想說還沒有任何淫夢為主題的勇造，所以才畫了一套野獸先輩的。
有著流行文化迷因的加成，做為第一次上架的勇造來說，銷售量感覺還挺可觀的。
※ 4月11日時的截圖
各類種族還有差分都會算做上架一件。
最讓我意外的是有少數人使用紅利來進行購買，不會是不小心按錯的吧…？
這次畫的是同人遊戲《Demons Roots》中的主角，遊戲本身是一月的時候破的，劇情好到會忘記是在玩黃遊。
跟前作一樣，後面就索性把全CG、音樂還有成就都收集完了。
當初破完時就有繪製勇造的打算了，只是到上個月底才騰出額外的時間來。
在下一篇日誌發文前，有在這篇日誌下留言的這邊都會送這套勇造，哪怕只留一個"卡"也沒關係，就當作有看到這行文字的回饋。
是說太久沒畫都忘了有一些投稿上的規格限制，除了勇造的素體要完全遮蔽外，還有先前畫野獸先輩沒有遇到的，單品 10 KB 大小的限制。
這次身體的色數還有尺寸都較為複雜，最後是把用來遮蔽素體的額外背景給精簡化才勉強壓在 10 KB 以內。
跟以往不同的，還有上傳介面多了個作者備註欄，大概就是說如果你畫的勇造主題是二創的話，需要附上原作連結這樣。
還沒續作玩我要死了 
貼個沒有用來遮蔽素體用的圖層拆解版：
◆【物品／商店選單介面】
繼前一篇文，總算是把相關的交互操作給搞定了。
包括物品的使用、捨棄、買賣、消耗物品的脫著…等等。當對應的操作無效時，操作提示會顯示為暗化，若仍執意進行該操作，也會產生對應的提示來告知是哪些狀況所導致的。
※ 當前的物品圖示及說明皆為開發測試之用
Δ（解析度較高的版本）
先前的物品使用都是透過快捷鍵來觸發，為了迎合物品介面，又多了從選單中使用物品的操作，故在物品使用時機的判定還有 UI 的反饋上都做出了一些額外的調整。
物品買賣時等場合，可透過撥碼的方式來決定數量，也額外設置了能直接選為最大值或歸零的控制鍵。
另外在對指定的物品實行操作所產生的確認提示框中，對物品的圖示做了浮動的效果，應該看起來會比較沒那麼死板。
Δ（解析度較高的版本）
圖示浮動的主要想法是來自於 DVD 的標題彈跳，只是這裡的反彈角度是隨機的，跟入射角無關。
◆【存讀檔介面】
如題，整體的方向還有圖示的繪製已經搞定，同樣也是交互操作的部分未完。
屆時「開始新遊戲」也會與此介面相關，會要求玩家選擇一個欄位，往後遊戲的自動存檔皆會應用於該欄位上。
∎ [因應存檔損毀]
除非玩家竄改存檔檔案本身失敗、存檔過程中斷電或是其他極為少見的例外，否則正常遊戲過程中存檔不應該會發生損毀的狀況。現階段如果存讀檔時發現檔案損毀的話，會將對應檔案進行標記、重新命名並移至備份的資料夾，隨後是重新生成一個對應的存檔檔案來繼續遊戲。若真的不幸發生壞檔的話，通常這邊也是沒轍，畢竟在讀寫上本身就出了問題，這邊的補救措施僅是確保遊戲在後續能正常進行而已。往後上架 Steam 之後有雲端備份則是另外一回事，相關的存檔救援方式就能去參考網路文章了吧。
Δ 存檔損毀時的自動備份資料夾
∎ [局部截圖]
主要是做為存檔的預覽圖之用。Unity 內建有數種能對當前畫面進行截圖的方法，就我查到的主要方法大致上有以下三種：
簡單有效地截取該幀的"整個"遊戲畫面，並儲存為 .png 圖像檔案至指定路徑。這裡不需要整個畫面的截圖，徒增存檔容量外，將 .png 圖像反過來載入並顯示於遊戲中，開銷會比後面提及的方法來得大。
可以獲取特定攝影機所渲染的像素，應用於像是能夠截出沒有 UI 的效果畫面。目前專案中的視差圖層正是以不同攝影機來達成的，若要透過此方法截出一張正常畫面的圖的話，反倒是把過程給複雜化了。
可以截取畫面中特定範圍的像素，並將其儲存為紋理資料。將該資料直接進行儲存，略過編碼為 .png 格式的過程，在遊戲中載入效能上也來得好些。ReadPixels 需要在畫面渲染結束後才能正常實行，否則會產生相關的錯誤訊息。一般可透過協程 (Coroutine) 搭上 WaitForEndOfFrame 來進行。
故③為此次用來實行存檔預覽圖效果的方案。
但問題還不只這些，Unity 截圖出來的是「畫面的尺寸」，假設玩家是在 1920×1080 解析度時進行遊戲，截圖也會有相應比例的像素大小。
這也就影響到將截圖檔案讀取到遊戲中，並呈現於畫面上的過程。故需要額外儲存該截圖像素大小的資訊，以及在不同解析度的情況下，對該截圖的縮放比例的處理。
這對像素風格這類會有等比縮放需求的遊戲格為重要，不太容易透過言傳，後面大略上地貼一些過程圖還有結果：
Δ 於2倍畫面縮放（960×540）時進行局部截圖，並將該縮放比例儲存於對應的遊戲存檔中。
Δ 載入該截圖並縮放至對應比例，以適應遊戲本身的畫面大小。（圖例為4倍縮放, 1920×1080）
現在局部截圖的功能已經完善，就可以應用於存檔欄位的上面了：
畫面中只先保留單一個存檔欄位，背景即為局部截圖的存檔預覽圖。
左半邊的資訊為：
∎ 存檔編號
∎ NewGame+現階段是預設有 10 個存檔欄位，單機遊戲又有自動存檔功能的，應該是不需要過多個欄位吧…？
∎ 基恩數量周目數的標記，反正先做起來放。
∎ 裝備魂札與獲取數玩家所持有貨幣總數，「基恩」是遊戲中的貨幣名稱及單位。
右半邊的基本上都比較直觀：
∎ 場景名稱
∎ 開圖率
∎ 總遊戲時間
∎ 存檔日期
現階段大概就這些資訊會顯示於存檔欄位上，有可能會再進行調整。
繼續來去忙，這塊完成後大概會接軌到標題畫面。有標題後就能進行實質上的讀檔測試了。
說到標題，我總該得打算確立遊戲的名稱了，至少有個主標題吧，往後寫日誌或宣傳會比較方便。
先這樣嘿
