[Unity] #05: アセットを活用した街づくり + Unity6 トラブル回避（シーン上書き事故・他）

はじめに

昨日は、ダウンして一日寝てました。
疲労がたまっていたようで、死んだように朝から晩まで、晩から朝までずっと就寝。

前回の続きで、余り無理をせず、取り合えず街を作ろうとフリーで公開されているアセット類を並べてみましたが、驚くほど簡単に街が出来てしまいます。

途中トラブルもあったのでその情報も含め記事にまとめてみます。

アセットにもよりますが、衝突判定や、スロープの上り下りなどもコードを一切書かずに動いてしまうので、Three.jsと比べると物凄く楽にゲームを作る事ができます。

今回も前回に続いて、コードを1行も書いてないです。

Three.jsでゲームを作らず、Unityなどのゲームエンジンでの開発を推奨する人が多い理由が、実際につかってみて良くわかりました。
Unityを使うと物理演算など難しい事を一切考えずに開発をする事が出来てしまいます。

ただ、カメラの制御は手つかずの為、また折を見てキャラクターに追従するカメラの実装を試したいと思います。

というか、ほんとシンプルなゲームならあっという間にできてしまうのではないかと思う程‥。

概要

前回の記事では、UniVRM + Starter Assets を使って VRMキャラクターをUnityで動かす最短ルートをまとめた。

今回はその続きとして、

  • 実際に街（箱庭）を作ってみた
  • 無料アセットだけで十分すぎるほど揃った
  • Unity 6 特有のUI変更に何度もハマった
  • そして 「シーン上書き事故」 という致命的トラブルを踏んだ

という 1日の実体験ログを、 備忘録＋回避マニュアルとしてまとめ。

Three.js経験者がUnityを触るとき、かなりの確率で同じところにハマる？

1. Unityの街づくりは「置くだけ」で成立する

ローポリ系の無料アセットを使えば、街は本当に数十分で形になる。

今回作った街は、以下の要素だけで構成している。

  • 建物
  • 木
  • フェンス
  • 樽
  • 風車

いずれも Asset Store の無料素材。 やったことは、ほぼ ドラッグ＆ドロップでSceneに配置するだけ。

Three.jsで同じことをやろうとすると、

  • モデル読み込み
  • 座標計算
  • 回転の調整
  • スケール調整
  • 当たり判定（bounding box / collider 相当）の自作

と、コード量が一気に増える。

Unityでは、これらは ほぼ最初から用意されている前提機能なので、 「街を作る」こと自体に集中できる。

Three.js と比べて不要になった作業

Three.jsで街を作っていたときに必須だった作業は、 Unityではほぼ意識しなくてよかった。

  • 座標計算
  • 回転調整ロジック
  • スケール補正
  • 当たり判定の自作

Collider と Transform が標準で機能するため、 「動かしたら登れた」「傾斜も普通に歩けた」という状態になる。

この時点で、 「ゲームとして成立する最低条件」はすでに満たされている。

気づいたこと（Three.js経験者向け）

実際に触ってみて、特に相性が良いと感じた点。

  • スケール・回転・位置は Inspector で数値入力
  • -180 や 1.2 のような 意味のある数値を入れると後で修正が楽
  • Three.jsで JSON ベースのパラメータ管理に慣れていると、Unityの Transform 操作は直感的

Sceneビューで感覚的に動かして、 最後に Inspector で数値を整える、という流れが一番安定する。

Three.jsで「全部コードで制御していた人」ほど、 Unityのこの作業フローは むしろ楽に感じるはず。

2. 無料アセットは「普通に使える」どころか十分すぎる

「無料＝お試し」ではなく、普通にゲームが作れるクオリティ。

今回使った素材はすべて無料だが、 以下の点で有料アセットと遜色がないレベル。

  • 中世ファンタジー系の充実度が異常に高い → 家、酒場、柵、樽、街灯、風車、井戸…すべて揃う
  • ローポリは軽く、見た目の統一感が出しやすい → 単体で置いても破綻しにくい
  • 数を置いてもパフォーマンス問題が出にくい → 草原に建物20個並べても普通に動く

Unity Asset Store の無料素材だけで、 「街1つ＋周辺フィールド」くらいなら余裕で構築できる。

Three.jsと比較して感じたこと

Three.jsで同じ規模の街を作ろうとすると、

  • モデル探す
  • エクスポート・変換
  • シーンに読み込む
  • 素材ごとに調整
  • 衝突（BoundingBox）を自力でつける

という 毎回の初期準備が重い。

Unityでは：

  • 「Import」→ そのまま Drag & Drop
  • Collider は付いているか、付けられる
  • URPでも数分で変換できる
  • ライティングは自動で効く

街のプロトタイプ（雰囲気づくり） なら、Unityの無料アセットでも十分。

小規模RPG・VR体験なら無料で完結する

実際に触ってみると、

家・木・柵・樽・地形・風車・NPC このあたりが揃えば、 もう小さな街は普通に「世界」に見えてくる。

VRで歩くだけでも “体験” として成立する密度になった。

商用レベルのRPGは別として、 個人開発の

  • 探索ゲーム
  • フィールド散策
  • VRアクション
  • クエスト付きの小規模RPG

は、無料素材だけでも十分。

3. 紫（ピンク）になるアセットは壊れていない

症状

  • アセットを配置すると、紫色（ピンク）で表示される

見た目としては「テクスチャが消えた」「素材が壊れた」ように見えるが、 これは アセットの破損ではない。

原因（Unity 6 / URP でよく起きる）

  • アセット側が Built-in Render Pipeline 用のシェーダーを前提としている
  • プロジェクト側は URP（Universal Render Pipeline） を使用している

この シェーダーの不一致 が紫表示の正体。

Unityでは、 “対応していないシェーダー” を読み込むと紫になる という仕様がある。

Unity 6 での正しい対処法（確定）

Unity 6 系では変換ツールの場所と動作が変わっている。

以下の操作で、 Built-in → URP 用にシェーダーを一括変換できる。

Window → Rendering → Render Pipeline Converter

設定：

  • 上部プルダウン：Built-in to URP
  • ✔ Material Upgrade にチェック
  • Initialize Converters を押す
  • すべて「準備OK」になったら Convert Assets

これでプロジェクト内の

  • Built-in Shader
  • Built-in Material

が URP 用にアップグレードされるため、 紫（ピンク）問題は完全に解消される。

注意点（誤解しがち）

  • テクスチャが無いわけではない
  • アセットが古いわけでもない
  • 破損でもない
  • 単に「シェーダーが違う」というだけ

URPプロジェクトでは “古い無料アセットはほぼ確実に紫になる” と思っておくと安心。

4. Unity 6 のUIは情報が古いと全部ズレる

Unity 6（特に 6.2～6.3 系）は、 UI・メニュー構成がこれまでと大きく変わっている。

その結果、ネット検索で出てくる情報の多くが Unity 2020～2022 の前提になっており、 そのまま信じると 確実に迷う。

ハマった点（実際に引っかかったもの）

  • Edit → Grid and Snap Settings がない
  • Edit → Snapping... もない
  • Scene内で右クリックしても Create Empty が出ない
  • “昔のUnityでは当たり前にあった場所” に何もない

どれも 存在が消えたのではなく、場所が移動しただけ。

正解（Unity 6.3系）

Unity 6 系では、 コンテキスト（右クリック）依存の操作が減り、「明示的なUI」に統合された。

✔ Empty GameObject（グループ化）はここ

  • Hierarchy 左上の「＋」ボタン
  • または Ctrl + Shift + N

右クリックから作れる時代は終わった。

✔ Snap 設定は「上部ツールバー」に集約

  • Move / Rotate / Scale を選んだ時 → Sceneビュー左上に “Snap 値” が出る

  • ここで

    • Move Snap（1, 2 など）
    • Rotate Snap（45° / 90°）
    • Scale Snap を調整する

昔のような メニュー項目としての Snapping 設定は消えた。

まとめ

  • Unity 6 は従来のUnityとUI構造が違う
  • 検索結果（Unity 2020〜2022）と比較すると混乱する
  • 右クリックメニューは縮小されている
  • SnapやEmpty作成は ツールバー側に移動

Unity 6 で作業するなら、 「古いUI記事は当てにならない」と割り切る方が安全。

5. オブジェクトが増えすぎたら「Empty GameObjectで整理」

Unity には フォルダのように階層だけを整理する機能は存在しない。 その代わり、Empty GameObject を使って “フォルダ兼コンテナ” として管理するのが標準的なやり方。

具体的には：

  • Hierarchy 左上の「＋」
  • または Ctrl + Shift + N で Empty GameObject を作る
  • そこに関連するオブジェクトをまとめて入れる

例：

Fences
 ├ Fence_01
 ├ Fence_02
 └ Fence_03

これは “Unity流のグループ化” として、 大規模になればなるほど欠かせないテクニック。

メリット

  • Hierarchyが一気に見やすくなる → 街・地形・建物・木のように分類できる
  • 親オブジェクトを動かすだけで一括移動できる → 柵の列や、木のゾーンなど、まとめて位置を変えられる
  • フォルダ（Empty）ごと複製できる → 「この島1区画を丸ごとCtrl+D」みたいな使い方が可能
  • Prefab化で量産可能 →「柵のセット」「建物＋樽＋柵」のような“ブロック構造”を使い回せる

この方法に慣れると、 街の一部を数秒でコピーして別エリアに作ることができる。

注意点（ここ重要）

※ 親の Position は (0,0,0) にしてから入れるのが安全

理由：

  • 子オブジェクトは 親を基準にしたローカル座標に変わる
  • 親の位置がズレていると、 子を移動した時の直感がズレる（意図しない位置になる）

特に Three.js で “すべてがワールド座標” だった人ほど、 このローカル座標の概念で混乱しやすい。

Unityでは：

  • ワールド座標で配置
  • まとめたい時に → Empty を 0,0,0 にしてから子にする

が最も安全で扱いやすい。

三次元マップを作るなら、グループ化は最初に覚えるべきスキル

街・森・道・フィールドを作る時、 「同じパーツを繰り返す」のが自然になる。

Emptyで分類すると、

  • 木のエリアを3秒で複製
  • 柵の列を一括配置
  • 建物＋小物の“セット”をPrefab化
  • 島や区画をまとめて移動・回転

など、ステージ制作の速度が10倍以上になる。

Unityは「個別に置いていく」よりも、 “まとまりを作って量産する” ほうが圧倒的に楽。

6. 【最重要】アセット導入でシーンが上書きされる事故

これは今回いちばん致命的で、 Unityを触る人が高確率で一度は踏む地雷。

しかも、 「Unityが壊れた」「データが消えた」と勘違いしやすい。

実際に起きたこと

作業の流れはこうだった。

  • アセットをインポート
  • インポート時に警告ダイアログが表示された
  • 内容を深く見ずに OK
  • SampleScene.unity がアセット付属のデモシーンで上書き
  • 作っていた街が消えたように見える

Undo では戻らず、 Unity上からは 元のシーンが存在しないように見える。

この時点で、かなり焦る。

何が起きていたのか（実態）

実際に起きていたのは、

  • 自分の作業シーン：SampleScene.unity
  • アセット側にも：SampleScene.unity（Demo / Example 用）

という ファイル名の衝突。

インポート時の警告は、

「既存のファイルを上書きしますが、よろしいですか？」

という意味だった。

つまり、

  • Unityが勝手に壊したわけでも
  • アセットが悪さをしたわけでもなく

SampleScene という“危険な名前”を使っていたことが原因。

なぜ SampleScene が特に危険なのか

SampleScene.unity は、

  • Unityが最初から用意しているデフォルトシーン
  • 多くのアセットが デモ用に同じ名前を使う
  • Unity側も特別扱いしている

という、事故が起きやすい名前。

そのため、

SampleScene を作業用に使うのは地雷

と言われることが多い。

「街が消えた」は本当か？

重要なのはここ。

  • シーンが上書きされた＝Assets が消えたわけではない
  • Prefab、モデル、マテリアル、スクリプトは残っている
  • 失われたのは「配置情報（Scene）」だけ

今回は Git を使っていたため、

git restore Assets/Scenes/SampleScene.unity

で 完全に復旧できた。

Gitがなかった場合でも、 素材そのものは残るため「作り直し不能」にはならない。

まとめ（この章の要点）

  • アセット導入時、Scene ファイルは普通に上書きされる
  • SampleScene.unity を作業に使うのは非常に危険
  • 警告ダイアログは「本当に上書きする」警告
  • Unityの不具合ではなく、仕様による事故

この事故を知っているかどうかで、 Unityの安心感はまったく変わる。

7. シーン上書き事故の回避ルール（必須）

この章だけは「知識」ではなく 運用ルール。 守れば事故はほぼ起きない。

① SampleScene を絶対に使わない（最重要）

プロジェクトを開いたら 最初にやること。

File → Save As → Sandbox.unity（など）
  • 作業用シーンは必ず別名で保存する
  • SampleScene.unity は 作業に使わない
  • 不要なら 削除しても問題ない

SampleScene は Unity・アセット双方から 上書きされやすい名前。

② インポート時に Scene ファイルを必ず確認する

Package Import の一覧に、以下が含まれていたら注意。

  • SampleScene.unity
  • DemoScene.unity
  • ExampleScene.unity

作業中のシーンと関係ない場合は、必ずチェックを外す。

特に、

  • アセットの「見本用シーン」
  • チュートリアル用デモ

は、不要なことがほとんど。

③ 警告ダイアログを無視しない

インポート中に出る警告：

  • File already exists
  • This will overwrite

これは 「見た目だけの注意」ではない。

→ 本当に上書きされる

意味が分からなければ、その場でキャンセルして問題ない。

④ Import 前に Git で commit（最強）

今回の事故は Git があったおかげで完全復旧できた。

git restore Assets/Scenes/SampleScene.unity
  • Scene はテキストファイル
  • Git と相性が非常に良い
  • Scene事故は Gitがあるかどうかで天国と地獄が分かれる

Git があれば：

  • 事故 → 経験 Git がなければ：
  • 事故 → トラウマ

になる。

この章のまとめ

  • SampleScene は作業に使わない
  • インポート時の Scene は必ず確認
  • 警告は本気で警告
  • Git は保険ではなく 必須装備

Unity は強力だが、 シーン管理だけは雑に扱うと即死する。

8. 細かいけど効いたテクニック集

街づくりをやってみて、 「これ知ってるだけで作業効率が跳ね上がる」 と感じた小技をまとめておく。

✔ Inspector で数値入力（回転・スケール・位置）

Sceneビューでドラッグするよりも、 最終的には Inspector で数値を直接入れる方が正確。

  • 回転は -180 や 45 といったキリの良い値が後で楽
  • スケールは 1.2 のように意味ある倍率で統一しておくと崩れにくい

Three.js で数値管理していた人はこの方法が最も相性が良い。

✔ Ctrl + D で「親ごと」複製が強い

Empty GameObject（フォルダ代わり）ごと複製すれば：

  • 柵の列
  • 木の区画
  • 家＋樽のセット

みたいな“ブロック”を一瞬で量産できる。

Prefab化しなくても、 地形パーツの量産は Ctrl+D が最速。

✔ Empty（フォルダ）ごと Prefab 化

街のレイアウト作りでは、 個々のオブジェクトより “セット”をPrefab化する 方が強い。

例：

HouseSet
 ├ House_01
 ├ Barrel_02
 └ Fence_03

これ一式を Prefab にしておけば：

  • 街の別エリアにそのまま複製
  • シーンをまたいで再利用
  • 修正が必要なら Prefab 側で一括更新

Unityの本領が出る。

✔ 背景物は「ブロック単位」で考える

木や柵、樽、石ころを個別に置くより、

  • 小さい“塊”
  • 2〜3個の“セット”

を組んで、それを繰り返した方が スピードも整合性も倍増する。

よく使うパターン：

  • 木3本セット
  • 柵＋木の境界セット
  • 家＋小物（樽・木箱・ランタン）セット

ブロック化すると街づくりのペースが爆上がりする。

✔ Vキー（頂点スナップ）は今後必須

Unityで地形や建物をぴったり合わせたい時は：

  • V を押しながらドラッグ → 頂点スナップ

これだけで、

  • 柵をぴったり連結
  • 地面と段差を綺麗に合わせる
  • 建物を正確に並べる

などの作業が一瞬で終わる。

“浮いてる”問題の9割は V スナップで解決する。