Unityの“元標準”描画基盤「ビルトインRP」、段階的に廃止へ。HDRPも新機能打ち止め、URP集中方針に
by AUTOMATON
2月末にUnityから発表がありました。
いま開発中のゲームはUnity2022.3のBRPで作っていました。
あえて古いバージョンとBRPを選んで、今後の開発テンプレートにしようとしていたので、衝撃が走りました…
今すぐというわけではないにしても将来的に廃止ならば、今のうちにURPに移行せざるを得ません。
URPだとかBRPだとか良く分かりませんが、分からないなりにBRPの方がとっつきやすい感じがして選んでいました。
いままでのUnityデータは全部作り直しなので、
どうせならばUnityバージョンも「6」に変えて、URPで再開発です。
マジかよ、とほほ…
エディター使用中メモリ量
なにはともあれ、Unity6000.3URP3Dでのメモリ使用量が気になってタスクマネージャーを起動。
前の開発では2G超えていましたが、今回はなんと4G越えてきました( ﾟДﾟ)！
まずは肥大化エンジンとの戦いになります。
なんとか使用メモリを減らそうと奮闘してみましたが、2Gスタートの4～5G安定喰いというのがデフォルトのようです。
時代的・PC的にはまぁ普通になってきているというのは分かりますが、
それでもほとんど使ってない・使わない機能が内部で動いてるかと思うと、
もう少し何とかならないのかなぁと気になってしまいます。
（6.3でメモリ使用量が跳ね上がった、との噂も）
自分のPCは16Gしか積んでないので、予想以上にキツキツ状態です(´･ω･`)
初期での奮闘については新規プロジェクト、メモリ使用量の軽減【Unity6】で詳しく説明しています。
2Dスプライトへの影付け
URPを避けていた理由の一つは、「2Ｄスプライトへの影付け方法」もあります。
BRPでの方法がとても理想的だったので、それができそうもないURPを敬遠していました。
独自のshaderを作成しているので、自分には中身をいじれません。
しかし今はAiツールがあるので、記述は任せられることに気がつき、早速URP用に改造をしてもらうことに。
影付けは比較的簡単にできました。
しかし、表面に影を映す（スプライトの影をスプライトに映す）ことがなかなかできずClaudeと大喧嘩です。
長時間の激闘の末、
「今本当にそれが必要か考えて。できないんだからまずは他の事から始めるべきです。」と言われる始末…ｗ
途中で、自分で影設定を落としていたのを忘れて、
「影がガタガタになってます。原因はなんでしょうか？」なんて質問して、泥沼な時間も過ごしました…
この段階では、表面への影反映は諦めて（素直に言う通りにしている）違う作業をしていました。
しかし、何かの拍子にデフォルトMaterialを適用したら、普通に理想の影付けになって、唖然としました。
結論：デフォルトの新規Materialの適用で良かった。
BRPでは独自Shaderを使っていたので、その改造ばかりに気を取られました。
いとも簡単にできたことに驚きと憔悴です。
URPでの影付けについては2Dスプライトに影をつける【URP】で詳しく説明しています。
負荷・メモリ使用の分析
エディターのメモリ5Gを渋々受け入れていましたが、やはり気になります。
どうにか軽減できないかと、そこでまた開発が一時中断しました。
デフォルトのURP・ライティング設定
Gemini（Claudeと大喧嘩したから、というわけではありませんｗ）に軽減方法を聞きだしたところ、
URPの設定・ライティングの設定などの見直しなども有効だというので、
初期設定でオンになっているものを根こそぎオフにしてみましたが、効果なし。
もちろんチンプンカンプン。
言われるがままに不必要なものを変更していく。
エディターのメモリ分析「MemoryProfiler」
効果ないことを告げると、「MemoryProfiler」で分析してみたら？と提案してくれました。
エディター開発中に使用しているメモリの内訳が分かるというので、さっそく導入して計測開始です。
想像通り「テクスチャ」が大部分を占めていましたが、
意外にも「フォント」も大きく割り当てられていました。
心当たりはあります。
フォントアセットを作る際の、膨大な文字数とアトラスサイズ8,192。
多分使わないであろう漢字などを削除し（7,272 → 2,601）
簡易日本語バージョンにして、アトラスサイズも2048にして再登録です。
亜哀挨愛曖悪握圧扱宛嵐安案暗以伊衣位囲医依委威為畏胃尉異移萎偉椅彙意違維慰遺緯域育一壱逸茨芋引印因咽姻員院淫陰飲隠韻右宇羽雨唄鬱畝浦運雲永泳英映栄営詠影鋭衛易疫益液駅悦越謁閲円延沿炎怨宴媛援園煙猿遠鉛塩演縁艶汚王凹央応往押旺欧殴桜翁奥横岡屋億憶臆虞乙俺卸音恩温穏下化火加可仮何花佳価果河苛科架夏家荷華菓貨渦過嫁暇禍靴寡歌箇稼課蚊牙瓦我画芽賀雅餓介回灰会快戒改怪拐悔海界皆械絵開階塊楷解潰壊懐諧貝外劾害崖涯街慨蓋該概骸垣柿各角拡革格核殻郭覚較隔閣確獲嚇穫学岳楽額顎掛潟括活喝渇割葛滑褐轄且株釜鎌刈干刊甘汗缶完肝官冠巻看陥乾勘患貫寒喚堪換敢棺款間閑勧寛幹感漢慣管関歓監緩憾還館環簡観韓艦鑑丸含岸岩玩眼頑顔願企伎危机気岐希忌汽奇祈季紀軌既記起飢鬼帰基寄規亀喜幾揮期棋貴棄毀旗器畿輝機騎技宜偽欺義疑儀戯擬犠議菊吉喫詰却客脚逆虐九久及弓丘旧休吸朽臼求究泣急級糾宮救球給嗅窮牛去巨居拒拠挙虚許距魚御漁凶共叫狂京享供協況峡挟狭恐恭胸脅強教郷境橋矯鏡競響驚仰暁業凝曲局極玉巾斤均近金菌勤琴筋僅禁緊錦謹襟吟銀区句苦駆具惧愚空偶遇隅串屈掘窟熊繰君訓勲薫軍郡群兄刑形系径茎係型契計恵啓掲渓経蛍敬景軽傾携継詣慶憬稽憩警鶏芸迎鯨隙劇撃激桁欠穴血決結傑潔月犬件見券肩建研県倹兼剣拳軒健険圏堅検嫌献絹遣権憲賢謙鍵繭顕験懸元幻玄言弦限原現舷減源厳己戸古呼固股虎孤弧故枯個庫湖雇誇鼓錮顧五互午呉後娯悟碁語誤護口工公勾孔功巧広甲交光向后好江考行坑孝抗攻更効幸拘肯侯厚恒洪皇紅荒郊香候校耕航貢降高康控梗黄喉慌港硬絞項溝鉱構綱酵稿興衡鋼講購乞号合拷剛傲豪克告谷刻国黒穀酷獄骨駒込頃今困昆恨根婚混痕紺魂墾懇左佐沙査砂唆差詐鎖座挫才再災妻采砕宰栽彩採済祭斎細菜最裁債催塞歳載際埼在材剤財罪崎作削昨柵索策酢搾錯咲冊札刷刹拶殺察撮擦雑皿三山参桟蚕惨産傘散算酸賛残斬暫士子支止氏仕史司四市矢旨死糸至伺志私使刺始姉枝祉肢姿思指施師恣紙脂視紫詞歯嗣試詩資飼誌雌摯賜諮示字寺次耳自似児事侍治持時滋慈辞磁餌璽鹿式識軸七叱失室疾執湿嫉漆質実芝写社車舎者射捨赦斜煮遮謝邪蛇尺借酌釈爵若弱寂手主守朱取狩首殊珠酒腫種趣寿受呪授需儒樹収囚州舟秀周宗拾秋臭修袖終羞習週就衆集愁酬醜蹴襲十汁充住柔重従渋銃獣縦叔祝宿淑粛縮塾熟出述術俊春瞬旬巡盾准殉純循順準潤遵処初所書庶暑署緒諸女如助序叙徐除小升少召匠床抄肖尚招承昇松沼昭宵将消症祥称笑唱商渉章紹訟勝掌晶焼焦硝粧詔証象傷奨照詳彰障憧衝賞償礁鐘上丈冗条状乗城浄剰常情場畳蒸縄壌嬢錠譲醸色拭食植殖飾触嘱織職辱尻心申伸臣芯身辛侵信津神唇娠振浸真針深紳進森診寝慎新審震薪親人刃仁尽迅甚陣尋腎須図水吹垂炊帥粋衰推酔遂睡穂随髄枢崇数据杉裾寸瀬是井世正生成西声制姓征性青斉政星牲省凄逝清盛婿晴勢聖誠精製誓静請整醒税夕斥石赤昔析席脊隻惜戚責跡積績籍切折拙窃接設雪摂節説舌絶千川仙占先宣専泉浅洗染扇栓旋船戦煎羨腺詮践箋銭潜線遷選薦繊鮮全前善然禅漸膳繕狙阻祖租素措粗組疎訴塑遡礎双壮早争走奏相荘草送倉捜挿桑巣掃曹曽爽窓創喪痩葬装僧想層総遭槽踪操燥霜騒藻造像増憎蔵贈臓即束足促則息捉速側測俗族属賊続卒率存村孫尊損遜他多汰打妥唾堕惰駄太対体耐待怠胎退帯泰堆袋逮替貸隊滞態戴大代台第題滝宅択沢卓拓託濯諾濁但達脱奪棚誰丹旦担単炭胆探淡短嘆端綻誕鍛団男段断弾暖談壇地池知値恥致遅痴稚置緻竹畜逐蓄築秩窒茶着嫡中仲虫沖宙忠抽注昼柱衷酎鋳駐著貯丁弔庁兆町長挑帳張彫眺釣頂鳥朝貼超腸跳徴嘲潮澄調聴懲直勅捗沈珍朕陳賃鎮追椎墜通痛塚漬坪爪鶴低呈廷弟定底抵邸亭貞帝訂庭逓停偵堤提程艇締諦泥的笛摘滴適敵溺迭哲鉄徹撤天典店点展添転填田伝殿電斗吐妬徒途都渡塗賭土奴努度怒刀冬灯当投豆東到逃倒凍唐島桃討透党悼盗陶塔搭棟湯痘登答等筒統稲踏糖頭謄藤闘騰同洞胴動堂童道働銅導瞳峠匿特得督徳篤毒独読栃凸突届屯豚頓貪鈍曇丼那奈内梨謎鍋南軟難二尼弐匂肉虹日入乳尿任妊忍認寧熱年念捻粘燃悩納能脳農濃把波派破覇馬婆罵拝杯背肺俳配排敗廃輩売倍梅培陪媒買賠白伯拍泊迫剥舶博薄麦漠縛爆箱箸畑肌八鉢発髪伐抜罰閥反半氾犯帆汎伴判坂阪板版班畔般販斑飯搬煩頒範繁藩晩番蛮盤比皮妃否批彼披肥非卑飛疲秘被悲扉費碑罷避尾眉美備微鼻膝肘匹必泌筆姫百氷表俵票評漂標苗秒病描猫品浜貧賓頻敏瓶不夫父付布扶府怖阜附訃負赴浮婦符富普腐敷膚賦譜侮武部舞封風伏服副幅復福腹複覆払沸仏物粉紛雰噴墳憤奮分文聞丙平兵併並柄陛閉塀幣弊蔽餅米壁璧癖別蔑片辺返変偏遍編弁便勉歩保哺捕補舗母募墓慕暮簿方包芳邦奉宝抱放法泡胞俸倣峰砲崩訪報蜂豊飽褒縫亡乏忙坊妨忘防房肪某冒剖紡望傍帽棒貿貌暴膨謀頬北木朴牧睦僕墨撲没勃堀本奔翻凡盆麻摩磨魔毎妹枚昧埋幕膜枕又末抹万満慢漫未味魅岬密蜜脈妙民眠矛務無夢霧娘名命明迷冥盟銘鳴滅免面綿麺茂模毛妄盲耗猛網目黙門紋問冶夜野弥厄役約訳薬躍闇由油喩愉諭輸癒唯友有勇幽悠郵湧猶裕遊雄誘憂融優与予余誉預幼用羊妖洋要容庸揚揺葉陽溶腰様瘍踊窯養擁謡曜抑沃浴欲翌翼拉裸羅来雷頼絡落酪辣乱卵覧濫藍欄吏利里理痢裏履璃離陸立律慄略柳流留竜粒隆硫侶旅虜慮了両良料涼猟陵量僚領寮療瞭糧力緑林厘倫輪隣臨瑠涙累塁類令礼冷励戻例鈴零霊隷齢麗暦歴列劣烈裂恋連廉練錬呂炉賂路露老労弄郎朗浪廊楼漏籠六録麓論和話賄脇惑枠湾腕、。，．・：；？！゛゜´｀¨＾￣
＿ヽヾゝゞ〃仝々〆〇ー―‐／＼～∥｜…‥‘’“”（）〔〕［］｛｝〈〉《》「」『』【】＋－±×÷＝≠＜＞≦≧∞∴♂♀°′″℃￥＄￠￡％＃＆＊＠§◆□■△▲▽▼☆★○●◎◇※〒→←↑↓♪◯０１２３４５６７８９ＡＢＣＤＥＦＧＨＩＪＫＬＭＮＯＰＱＲＳＴＵＶＷＸＹＺａｂｃｄｅｆｇｈｉｊｋｌｍｎｏｐｑｒｓｔｕｖｗｘｙｚぁあぃいぅうぇえぉおかがきぎくぐけげこごさざしじすずせぜそぞただちぢっつづてでとどなにぬねのはばぱひびぴふぶぷへべぺほぼぽまみむめもゃやゅゆょよらりるれろゎわゐゑをんァアィイゥウェエォオカガキギクグケゲコゴサザシジスズセゼソゾタダチヂッツヅテデトドナニヌネノハバパヒビピフブプヘベペホボポマミムメモャヤュユョヨラリルレロヮワヰヱヲンヴヵヶ─━!”#$`”‘①②③④⑤⑥⑦⑧⑨⑩⑪⑫⑬⑭⑮⑯⑰⑱⑲⑳≒0@P`p!1AQaq”2BRbr#3CScs$4DTdt%5EUeu&6FVfv’7GWgw(8HXhx)9IYiy*:JZjz+;K[k{,<L\l|-=M]m}.>N^n~/?O_o
MemoryProfilerについてはエディター使用時のメモリ解析【Unity6】で詳しく説明しています。
Statisticsチェック
その他の見るべき数値も教えてくれました。
「Gmae」ウィンドウの右端に「Statistics」情報を表示する「Stats」があるので、
常に表示しておくのも良いかと思います。
Batches / Tris / SetPassCalls / FPS の数値を気にしながら、
テクスチャや3Dモデル・2Dスプライトのサイズや配置をしていきます。
Statistics情報については
Statisticsチェック（Batches / Tris / SetPassCalls / FPS）で詳しく説明しています。
軽量化の試行
すべてやり直しだったので、最終的に行うつもりだった3Dモデルやスプライトの軽量化も行うことにしました。
テクスチャのサイズやその他の設定にて、Batches / Tris / SetPassCalls を軽減できないかを試行錯誤しています。
ハリボテ化
壁や床も3Dモデルにしていたので、思い切ってすべて2Dスプライトにしてみようと試みました。
すでにスプライトにも影を付けることができたので、3Dモデルにこだわる必要はないのである。
これは超絶な軽量化になるはずです。
9スライスを使って、柱の軽量化も狙います。
しかしここにきて「レイヤー」問題がぶつかってきました。
床のX軸と壁・柱のY軸をすべてスプライトで疑似3D化していくと、カメラ方向によって、見え方がバラバラになります。
レイヤーの数値で優先順位を決めることはできますが、角度によっての優先順位が違うため制御不能です…
机なども加わると収拾がつかなくなりますね。
この時点ですべてスプライト化は断念しました。
しかし、できればこれが一番良い作戦なので、頭の片隅に入れておくことにします。
テクスチャ・スライス
Unityには複数のスプライトをまとめておいて、スライスして使用することができます。
複数に分かれていると、それぞれ呼び出すたびに複数分の負荷やメモリを消費します。
それを1つにすることで、呼び出し回数を1回にし、負荷軽減を狙うものです。
いっけん良さそうな作戦ですが、この方法にも落とし穴がありました。
例えば、スライスした一枚の壁を非アクティブにし、再びアクティブにした場合、
その一部の画像だけの表示非表示にはならず、裏ではまとまっている画像すべてを消去・呼び出しすることになるので、
負荷・メモリ使用量ともに大きくなるということです。
つまりこの方法をとるときは、
使用しているテクスチャを呼び出したらそのまま表示しているもの（Staticオブジェクト）か、
一回の消去で終わらせるものに限るということになります。
ダイナミックに使用するつもりはなくても、小物なども合わせてしまうと、演出上、変更するかもしれないし、
そのたびに、まとまったシートを編集するのも手間がかかります。
負荷軽減には役立つ方法ですが、緻密な設計が必要になりそうです。
Atlas化
スライス方法を断念していると、Geminiによる別提案がありました。
スライス化は緻密な設計が必要で大変だけれど、
バラバラのスプライトをビルドする際に、1つの画像に自動的にまとめてくれる方法があるとのこと。
つまり、最初からまとめておくと使い勝手が悪いので、最後にまとめれば効率も良い、ということです。
この方法は「SpriteAtlas」というもので、任意のスプライト・任意のフォルダを指定できます。
これも良さそうな方法ですが、結局は一部のアクティブ・非アクティブに対して、
まとまったものを裏ですべて呼ぶ出すことになるので、スライス化のときの緻密な計画というものが発生します。
こちらはまとめる手間が省ける、といったところでしょうか。
使いどころが決まっていれば強力です。
開発終了間近になればStaticとDynamicのオブジェクトが落ち着いていると思うので、
うまい具合にまとめることができるかもしれません。
3Dモデル・軽量化
Unityでは、
スプライトやテクスチャのサイズは「2のべき乗（2.4.8.16.32.64.128.256.512.1024.2048）」が良いらしく、
Unity側で画像圧縮を使用する場合もサイズを合わせる必要があります。
なので、もともと自由に作ってしまった3Dモデルとテクスチャを作り直してみることにしました。
もとのモデルを目安に、サイズを16倍数を意識して再構築していきます。
ハリボテ化は断念しましたが、
今回は壁や床を板ポリにし、机などの3Ｄモデルのいらない部分（裏や底）も削っていきます。
縦横の柱も同じ1本を使いまわす作戦にしました。
流し台と机の凹みもなくして真四角にしました。
それ以外は、3Dモデルをやめて、スプライトにします。板ポリにすらしません。
よりチープに！
2D寄りになってきたのも、良い感じです。
全体サイズも縮小されて、元データ的には軽くなったと思います。
前は、各壁にも4面が存在していたので、1面になってスッキリしました。
改修のついでに、キャラクターの方も「2のべき乗」を意識してのサイズ変更（実際は透明部分の拡大）をします。
画像の区分けも「目（頭）3枚」「口（身体）3枚」から「目3枚」「口3枚」「身体1枚」に変更。
身体部分を削って軽量化しましたが、描画自体は2枚から3枚になるので、良いのか悪いのか…
ライトベイク
ライティングの影響で表示されている影処理を事前に「焼き付ける」方法です。
ライトティング設定には、「Realtime」「Mixed」「Baked」の3つがります。
デフォルトは「Realtime」になっていて、常にライト計算をし続けて、影処理をする設定になっています。
「Baked」にして影を事前に「焼き付ける」ことによって、スタート時だけの処理にすることができます。
処理負荷軽減方法の1つです。
弱点としては、
- 動かすオブジェクトには効かない
- 動かす予定のない、止まっている背景や小物をしっかりと決めておく
というところでしょうか。
ライティングに関しては奥が深そうなので、そのうちに詳細を学ぶことになりそうです。
ちなみにこの「ベイク」は、動かないすべてのオブジェクトのStaticチェックをして、ボタン1つで行うことが可能です。
クリアや再ベイクも、ボタン1つの操作なのでとても簡単です。
ライティングは負荷が高いので、そもそもの影付けを減らしたりしながら、仕上げに「ベイク」をしておきましょう。
オクルージョン
カメラに移っていないオブジェクトを非表示にして、カメラに映ったときだけ表示する方法です。
これも処理負荷軽減方法の1つになります。
このオクルージョンも、ライトベイクと同じように、static属性のものにだけ有効です。
こちらもボタン1つでクリアと再ベイクができます。
画像だと分かりにくいですが、
カメラに写っているものは表示され、移動して視点が変わると、見えていないオブジェクトが自動で非表示になっています。
上記の画像の左側を見て気がつくかと思いますが、
「前に壁があるのに、教室の中のものは映ってるじゃん！」となっています。
実際、1番軽減したい部分が軽減できていませんでした。
理由は、「動く扉」にあります。
ベイクは、動く（予定）オブジェクトには適用できないので、扉の部分は実際は透明な空間が開いています。
つまり扉を表示してはいても、カメラは透視状態で、部屋の中は丸見えというわけです。
そういうときの解決法もしっかりありました。
「Occlusion Portal」というコンポーネントを追加して、透明な壁を作ることによりカメラを騙します。
少し大きめのサイズにしておくのがコツみたいです。
ちょっとした隙間からカメラで見えてしまうことを防ぎます。
（どのくらいの隙間を見逃すかという設定もオクルージョンにあるので、併用で考える必要があります）
しかし、ちょっと大きくしただけでは効果がなかったので、ドデカくしました。
処理負荷的にはサイズは関係ないとのことなので遠慮なく。
この透明壁をスクリプトで制御して、扉が空いたときにオフにすれば、後ろの背景が表示されるようになります。
これで1番気になっていたスタート時の負荷が軽減されました。
が、実際の動きを見てみると、結局は後ろの背景が表示されるときに負荷が高くなるので、
スタート時に高いか、途中が高いか、の違いでしかないことに気がつきます。
そしてGeminiに言われます。
「今の段階で気にすることなくて、むしろオクルージョンすることで負荷が増す場合があるよ」と…
この技術もまた今回は見送ることにしました。
将来的に、部屋数が5～10とかになった場合とかには使えそうなので、覚えておくことにします。
カメラ距離
今回、1番に効果的かつ超簡単だった軽減です。
「カメラ距離」には「near（近く）」「far（遠く）」の設定があり、
デフォルトでの「far（遠く）」が「1000」あります。
デフォルト設定を疑ってなかったので、気がつくのが遅くなりましたが、これが過剰設定でありました。
実際の自分のゲーム画面で調べてみると、20～30数値で部屋全体を見渡すことができました。
これだけで「Batches」のスタート数値「130」が「100以下」になりました。
こういうことを始めに知りたかったですね…
Unity知識0の個人開発のつらいところ(´･ω･`)
それでも今の時代、Aiのおかげで劇的にいろいろと知ることができているので、ほんとに助かっています。
別提案などで新スキルを教えてくれるのも、とても頼もしいです。
最終結果
BRPからURPでの作り直しも、なんとかノベルパートの復元まで戻ってきました。
軽減作業も含めて、遠回りもしましたが、いったん落ち着きました。
負荷的に1番の課題は、廊下側と教室側の境界で1番負荷が高くなる、というところでしょうか。
3D空間の意味付けのためにも、できるだけシームレスにしています。
トレードオフな感じになっていますね。
そしてオクルージョンさせるよりも、
シンプルにオブジェクトの非アクティブ・アクティブで良い、という結論にも達したので、
カメラで見えてる・見えてないを自分で判断して、消すことにしました。
扉を開けるあたりの最大負荷がやはり気になります。
そして負荷が下がったところをさらに下げたところで？とはなりますが、そこは軽減を追及していきましょう。
その分のメモリは解放されるはずですから。
これがベースで、ここからはポストエフェクトやら演出やらで足し算作業になっていきます。
しかし、そういった効果もオンオフできるような仕組みにしておくのが良さそうです。
今の時代、というか、ソフトウェア開発の性質上、そこまでして軽減してもコスト的に合わないということらしいですが、
（大袈裟に言うと、1秒速くするために3か月かけるとかナンセンス、といった意味で）
自分の作品雰囲気として「低スペックで動く」ということに重きを置いてしまいがちであり、
プレイしてくれそうな方たちのPCもなんとなく、愛着ある古いPCを使ってそうなのでｗ
そうであるならば2Dにするのが手っ取り早いのですが、それはそれというジレンマですね(´･ω･`)
ともあれUnity6000.3URP3Dでもやれそうな手応えを得られたのは収穫です。
今回のことだけでも、宝の持ち腐れ機能がたっぷりあるのに気づかされました。
大規模開発であるからこそ活きる機能であることも痛感しました。
ここまできたら「演出」に取り掛かりたいですが、
（ちょっとやりかけて、自分が開発で一番好きなのはこの演出部分かもと再認識）
次は、
システム面（サウンド・ログ・早送り・セーブ）などのテンプレートが作れるのかどうか、の挑戦になりそうです。
「探索パート」「論争パート」「他ノベルパート」の再開発も残っていることは考えないようにしておきます。
おまけチップス
ここまでUnityを使っていて、微妙に気になったことが解決できたので紹介しておきます。
ショートカットでの新規オブジェクトの位置変更
新規オブジェクトをコンテクストメニューで作成すると
Position X「0」Y「0」Z「0」になりますが、
ショートカットキーの「Ctrl」+「Shift」+「N」で作成すると、カメラ位置を参照にして変な数値で作成されます。
オブジェクトを新規作成した場合、「…」での「Reset」がUnity使いのたしなみらしいのですが、
日が浅い自分にはたしなみになりそうもなかったので、
Position X「0」Y「0」Z「0」になるように設定変更することにしました。
Unityでの「Editor」フォルダーは特別な存在らしいので、扱いに注意が必要みたいですが、
それ専用のスクリプトを置くことで、エディター自体をいろいろとカスタムできるようです。
Position0の新規オブジェクトが作れるショートカットが追加されてご満悦です。
被っていた元ショートカットに上書きしてやりました。
インスペクターのエレメント表記変更
インスペクターでのリスト表記で「Element 0」から追加されていく場合、
数が増えると中身が視認しづらくなる問題がありました。
自分の場合は「変数」でその状態になっていたので、そこのところを改造できないかと模索しました。
こちらも「Editor」フォルダーに専用のスクリプトを入れて解決できました。
これでリストが閉じた状態でも、中身の「指定オブジェクト」と「変数」を確認できます♪
Unityプロジェクトのバックアップ方法
本来ならば「Git」などでのバックアップが普通らしいですが、設定とかややっこしいと聞いて敬遠しています。
いままでもこれからも男は黙ってZip圧縮方式をとっていきましょう。どうせ個人ですし。
しかし以前のUnity2022.3BRPのときはそれでもまぁ、よかったのですが、
今回のUnity6000.3URPをそのまま圧縮しようとしたら、ファイル数・ファイルサイズ（2～3G）が大きすぎ、
毎回これはやってられない状態になりました。おもにキャッシュである「Library」が原因。
どうしたものかとGeminに相談したところ、
Zipバックアップの「黄金の3点ルール」を教えてもらいました。
「Assets」「Packages」「ProjectSettings」の3つだけで良いらしいです。
「UserSettings」も欲しいので4つをさっそく圧縮してみます。
3G近くあった圧縮が6.5Mに超減少♪
あっという間で楽々になりました！
そもそもキャッシュである「Library」を取っておく必要はなく、
エディターの調子が悪いときは、削除してからの再起動がよいので、その手もよく使うようになりました。
簡単操作でバックアップを忘れずに！( *˙ω˙*)و
コメント