脱出ゲーム　庵

※ゲームの世界観や操作方法をまとめています。ゲーム本体はページの下部にありますので、スクロールしてお楽しみください。

和風ののんびりとした雰囲気を楽しみながら、じっくり謎解きをしたい方向けの難易度（初心者〜中級者向け）に調整しています。ちょっとした空き時間の脳トレや、息抜きに最適です。

↓↓↓ ゲームプレイはこちらから ↓↓↓

【今すぐプレイ】脱出ゲーム『庵』本体はこちら

制作日記

ネタバレを含みます。ゲームをプレイされた後に興味のある方は読んでいただけると幸いです。

【このゲームに込めた想い】
今回の脱出ゲームは、私が以前から挑戦してみたかった「和」のテイストをベースに制作しました。
日本伝統の落ち着いた佇まい、独特の木や畳の柔らかさ、そしてどこかホッとするような静けさを持った空間。なんだか落ち着くんですよね。そうした「和風の美しさ」を、3D空間（Blender）の中に自分自身の手で構築してみたい、という純粋なデザインへの興味がこのゲームの出発点です。
何か深いメッセージを込めたというよりは、プレイヤーの皆さんに「シンプルに和の空気感を味わいながら、謎解きに没頭してほしい」という想いで作っています。グラフィックの色彩や、和室特有の光と影の表現など、視覚的に心地よい空間を目指しましたので、ゲームを通じてその雰囲気を少しでも楽しんでいただけたら嬉しいです。

開発メモ

この制作日記は、Blender、Unity初心者の私が試行錯誤した過程を残すための備忘録です。紹介しているコードや設定は、必ずしも最適解や正解ではないかもしれませんが、「自分の環境ではこう動いた」という一つの事例として参考にしていただければ幸いです。

【Blender】ノード不要！プロパティだけで作る水饅頭マテリアル設定（EEVEE不透明の活用法）

はじめに

今回は、このゲームに登場する「水饅頭」をBlenderでどのように作ったのか、マテリアル設定を中心に詳しく解説しようと思います。

＜オブジェクトの作成＞
水饅頭のオブジェクトは、Cubeを横に２分割して、モディファイアーを追加 >細分化 > ビューポートのレベル数・レンダー供に３に設定してあります。餡になる部分を作ったら、それをコピー、拡大をして、外側になる部分を作りました。簡単に作ってあります。

＜使用エンジン＞
Blenderのレンダーエンジンは「Eevee」を使用します。
重い Cycles レンダラーと違って、パソコンへの負担が少なく、設定の変更が画面にサクサク反映されます。事前に画面右上、またはレンダープロパティ（カメラマーク）から、レンダーエンジンが「EEVEE」になっていることを確認しておいてください。

外側の生地のマテリアル設定

ゲームアイテムとして遠くから見ても形がハッキリ分かり、なおかつツルツル感を出すための数値を設定してみます。

※画面右側のマテリアルプロパティを開き、新規マテリアルを作って名前を 「Kuzuko」 にします。

ここからは、画面を少しずつスクロールしながら設定をしていきます！

パネルの上部：『ベースカラー』と『スペキュラー』の設定

まずはマテリアルを開いてすぐに見える、上側のエリアを設定します。

・　ベースカラー：純粋な白（#FFFFFF）にします
・　スペキュラー：初期値の0.5から 1.000 に引き上げます

パネル下部：『粗さ』と『クリアコート』『伝播』の設定

続いて、パネルを少し下にスクロールして、ツヤと透明感のベースになる中心エリアを設定します。

・　粗さ（Roughness）： 0.100 に下げます
・　クリアコート：ガッツリ 1.000 に上げます
・　クリアコートの粗さ： 0.100 にします
・　伝播（Transmission）： 0.950 に設定します

パネル一番下：　▼設定を開いて

スクロールして一番下にある「設定」項目を展開します。今回は公開中モデルとと同じ仕様にするため、あえて以下の設定のまま進めます。

・　ブレンドモード： 不透明
・　影のモード： 不透明
・　スクリーンスペース屈折： チェックを入れます。

💡 なぜ「不透明」のままにするの？
完全に透き通らせてしまうと背景に紛れて見づらくなってしまいます。あえて「不透明」のまま伝播やクリアコートを強くかけることで、「ゲーム内での見やすさ（視認性）」と「水饅頭らしいツヤツヤ感」を両立させることができます

背景（ワールド）の設定でツヤを引き立てる

画面右側のワールドプロパティ（真ん中あたりにある地球儀アイコン）を開きます。

・　カラー： 真っ黒（HSV 0.0）（ここの設定は真っ黒にしない方がよかったです。反省点です。）
・　強さ： 1.000

オブジェクトのサイズと光の当て方

箱に入った水饅頭をつるつるに見せるために、私が実際に作成したモデルの大きさと、ライトの配置と具体的な設定数値です。あくまで私の好みで作った設定です。ご了承ください。

オブジェクトの「寸法（サイズ）」

今回、私が作成した和菓子を入れた外箱は以下のサイズで作っています。画面右側のサイドバー（Nキー）の「寸法」から確認できます。

箱の寸法: 横（X）2.05m × 縦（Y）1.22m × 高さ（Z）0.278m

「えっ、水饅頭なのに約2メートル！？ デカすぎない？」と思った方もいるかもしれません。現実と同じ数センチのサイズで作ると、画面が小さすぎてめちゃくちゃ作りづらかったからです。他の和菓子のモデリング作業のしやすさを優先して、あえてBlenderの初期サイズに近い「大きめのメートルサイズ」で制作しました。

ライトの配置

Blender　Shift+Aでライトのポイントを作成します。

水饅頭を外箱に入れた状態で作る場合、箱の壁のせいで光が遮られ、暗くなりやすいという問題があります。そこで、画像のように水饅頭を上左右から包み込むように、複数のポイントライトを配置するのが最大のコツです。これにより、箱の邪魔な影を消しつつ、水饅頭全体を明るくプルプルに見せることができます。

ライトの設定数値

配置したポイントライトの具体的な設定は、以下のスクリーンショットの通りです。オブジェクトがを大きく作成しているので、設定するライトのパワーも「100W」、半径も「1m」という強めの数値が必要になります。

・　ライトの種類：ポイント
・　カラー：白
・　パワー：100 W
・　スペキュラー：1.00
・　半径：1 m
・　影：チェックを外す（オフ）

反省

水饅頭の餡は「サイダー」と「葡萄」にしました。今思えば、何故この色にしたんだろう・・・小豆餡ばかりになるのを避けたかったのだと思いたいところですが、当時は透明でツルツルした質感にこだわり過ぎていました。
よく考えたら「水饅頭ってそんなに透明だっけ？」と今になって思います。どちらかというと白濁した半透明な感じですよね。 というわけで、背景（ワールド）の設定にある「カラー」を変更してみました。
変更前：真っ黒（HSV 0.0）　変更後：真っ白（HS 0.0 V 1.0）
その結果が下の画像です。外側が白濁して、よりリアルな水饅頭に近づけたかと思います。

BlenderとUnityで作る、こだわりと効率化

「画像制作と微調整」という名の、終わりのない試行錯誤（Blenderでの作業）

私が2D脱出ゲームを作るうえで、圧倒的に一番時間がかかるのは 「グラフィック（画像）の作成」 だと痛感しています。 なぜなら、オブジェクトの「配置と見栄え」は絶対に一発では決まらないからです。具体的には、主に以下の3つの理由で時間が溶けていきます。

• 「見え方」の試行錯誤 ：プレイヤーが直感的に見つけてタップしやすい位置にあるか、引き出しを開けたときに中身がしっかり見える角度になっているかなど、絶妙な調整に手間がかかるため。
• 「ヒントの伝わりやすさ」の検証 ：配置したオブジェクトや背景の模様から、プレイヤーに意図した謎解きのヒントがちゃんと伝わるか確認・修正を繰り返すため。
• 「レンダリング・配置」の往復作業 ：頭の中のイメージを形にするために、BlenderとUnityを行き来して何度も配置し直す必要があるため。

ツール（UnityやBlender）の使い方が分からないから時間がかかるのではありません。「これでプレイヤーにストレスのない配置になっているか？」を考え、何度もやり直す「試行錯誤の回数」が時間を吸い取っていくのです。「画像とカメラ調整」には想定の数倍の時間がかかりますが、ここが楽しくもあり、「手を抜けない重要な時間」だと考えています。

例えばアイテム管理（Unityでの作業）

スクリプトのコードよりも安全性を優先した理由

本作のUnityでのシステム構築にあたって、一番こだわった（面倒くさい、そして泥臭く対応した）のがアイテム欄の管理方法です。
本来、脱出ゲームでアイテムの取得、使用、削除をスマートに行うには、C#の「List（リスト）型」や「配列」を使って、アイテムのデータを動的に管理するのが、一般的（かつスマートな方法）だと思います。List型（文字列指定）にすれば、スクリプトを一切書き直さずにUnity上だけで無限にアイテムを量産できるため、大幅な時短に繋がります。
しかし、List型（文字列指定）には「インスペクターへの直接入力による打ち間違い」で原因不明のバグが起きやすいという弱点もあります。

本作では、あえてすべてのアイテムを「enum（列挙型）」で定義し、1つの共通スクリプトを使い回して、Unityのインスペクター上でプルダウンから安全に選ぶ方式を採用しました。

スマートな方法よりも、確実な安全を

たしかに、List型（文字列指定）であっても、スペルミスがあった際にコンソールへログを出すようにプログラムしておけば、バグに気づくことは可能です。
しかし、私が目指したのは『ログが出るから直せる設計』ではなく、『最初からミスしようがない設計』でした。
ゲーム開発（特に個人開発）では、画像作りやギミック作成など、ただでさえ頭を使う作業が山積みです。そんな中で、アイテム名を打ち込むたびに「スペルミスはないか？」「大文字小文字は合っているか？」と、いらぬ心配をする時間をゼロにしたかったのです。
肥料（Item.Hiryo）を取った時など、一部のアイテムだけで動かしたい特殊なイベントに関しては、コード内で少し泥臭く対応していますが、個人開発の規模であれば、この『絶対に打ち間違いが発生しない選択式（enum）』でガチッと固める設計が、結果的に一番バグが出ず、精神衛生上も安全な開発に繋がったと感じています。

テストプレイを効率化する時短テクニック

画像作成やプログラムの調整など、どうしても泥臭く時間がかかる作業が多いからこそ、「削れるテストプレイの時間だけは徹底的に自動化・効率化する」という仕組み作りが重要になります。

脱出ゲームの後半の仕掛け（例えば、最後の茶道具のギミックなど）をテストする際、毎回スタート画面から律儀にプレイしていては時間がいくらあっても足りません。
そこで開発中は、プログラムに不具合がないかチェックする作業（デバッグ作業）を爆速にするために、以下のような「ボタン」をUnity内に用意していました。（※リリース版ではこのボタンは削除します）

• 特定の部屋（2階や庭など）へ一瞬で移動できるボタン
• 一瞬で必要なアイテム（鍵やボトル）が手に入るボタン

ゲーム後半のギミックであればあるほど、一瞬でスキップできる開発用の仕組みを最初の段階で仕込んでおくことが、結果的に大きな時短に繋がります。この地味な仕組みを作る数分のおかげで、トータルのテストプレイ時間を削減することができました。