※ゲームの世界観や操作方法をまとめています。ゲーム本体はページの下部にありますので、スクロールしてお楽しみください。
和風ののんびりとした雰囲気を楽しみながら、じっくり謎解きをしたい方向けの難易度（初心者〜中級者向け）に調整しています。ちょっとした空き時間の脳トレや、息抜きに最適です。
遊び方
・画面の下部にある左、右の◀▶マークをクリックまたはタップすることで、部屋を左右に移動できます。
・画面の下部にある下の▼マークをクリックまたはタップすることで、部屋を戻ることができます。
・気になる場所や怪しい物はどんどんタップしてください。意外なところにアイテムが隠されているかもしれません。
・アイテム欄のアイテムは、1回タップして選択状態（色が付いた状態）にすることで使用可能になります。
・選択した状態でもう一度タップすると拡大図が表示されます。
・アイテム同士をくっつけて、１つのアイテムになることがあります。
・オートセーブです。
タイトル画面の『つづきから』で入っていただくと、続きからプレイできます。
脱出のヒントは部屋のあちこちに隠されています。
もし謎解きに行き詰まってしまったら、一度その場所を離れて、別の部屋を探索し直してみるのが脱出のコツです。見逃していた小さな色の違いや、壁の模様が実は重要なヒントになっていることがよくあります。
「紙と鉛筆」をお手元に用意して、気づいたことをメモしながらプレイすると、意外な繋がりが見えてくるはずです。よりスムーズに謎解きを楽しめるかと思います。
※ゲームの読み込みに時間がかかる場合があります。画面が表示されるまで、そのまま数秒お待ちください。
↓↓↓ ゲームプレイはこちらから ↓↓↓
【今すぐプレイ】脱出ゲーム『庵』本体はこちら
製作舞台裏
ネタバレを含みます。ゲームをプレイされた後に興味のある方は読んでいただけると幸いです。
【このゲームに込めた想い】
今回の脱出ゲームは、私が以前から挑戦してみたかった「和」のテイストをベースに制作しました。
日本伝統の落ち着いた佇まい、独特の木や畳の柔らかさ、そしてどこかホッとするような静けさを持った空間。なんだか落ち着くんですよね。そうした「和風の美しさ」を、3D空間（Blender）の中に自分自身の手で構築してみたい、という純粋なデザインへの興味がこのゲームの出発点です。
何か深いメッセージを込めたというよりは、プレイヤーの皆さんに「シンプルに和の空気感を味わいながら、謎解きに没頭してほしい」という想いで作っています。グラフィックの色彩や、和室特有の光と影の表現など、視覚的に心地よい空間を目指しましたので、ゲームを通じてその雰囲気を少しでも楽しんでいただけたら嬉しいです。
「画像制作と微調整」という名の、終わりのない試行錯誤
2D脱出ゲームを作成するのにかかる時間は、どのくらいなのでしょう？毎日ゲーム作成に時間を割く、休日のみに作成する、開発環境や作業スタイルによって様々ですが、制作者としては「できれば効率よく、早く作りたい」というのが本音だと思います。
私が2D脱出ゲームを作るうえで、圧倒的に一番時間がかかるのは「グラフィック（画像）の作成」だと痛感しています。なぜなら、オブジェクトの「配置と見栄え」は絶対に一発では決まらないからです。
＜「庵」における試行錯誤の例＞
- [部屋１]４つの茶道具
- [庭１]長椅子の和菓子
- [２階部屋１]丸い箪笥の引き出し
これらを、プレイヤーが直感的に見つけてタップしやすい位置へと配置。さらに、引き出しを引いたときに中身が見えやすくなるよう、カメラを絶妙な角度に設定します……といった作業が膨大にあります。
＜時間がかかる理由＞
ツール（UnityやBlender）の使い方が分からないから時間がかかるのではありません。
「これでプレイヤーにちゃんとヒントが伝わるか？」「タップしたときにストレスのない配置になっているか？」を考え、何度もレンダリングや配置をやり直す「試行錯誤の回数」が、時間を吸い取っていくのです。「画像とカメラ調整」には想定の数倍の時間がかかります。しかし、ここが楽しくもあり、「手を抜けない重要な時間」だと考えています。
アイテム管理
本作のUnityでのシステム構築にあたって、一番こだわった（面倒くさい、そして泥臭く対応した）のがアイテム欄の管理方法です。
本来、脱出ゲームでアイテムの取得、使用、削除をスマートに行うには、C#の「List（リスト）型」や「配列」を使って、アイテムのデータを動的に管理するのが、一般的（かつスマートな方法）だと思います。List型（文字列指定）にすれば、スクリプトを一切書き直さずにUnity上だけで無限にアイテムを量産できるため、大幅な時短に繋がります。
しかし、List型（文字列指定）には「インスペクターへの直接入力による打ち間違い」で原因不明のバグが起きやすいという弱点もあります。
本作では、あえてすべてのアイテムを「enum（列挙型）」で定義し、1つの共通スクリプトを使い回して、Unityのインスペクター上でプルダウンから安全に選ぶ方式を採用しました。
＜スマートな方法よりも、確実な安全を＞
たしかに、List型（文字列指定）であっても、スペルミスがあった際にコンソールへログを出すようにプログラムしておけば、バグに気づくことは可能です。
しかし、私が目指したのは『ログが出るから直せる設計』ではなく、『最初からミスしようがない設計』でした。
ゲーム開発（特に個人開発）では、画像作りやギミック作成など、ただでさえ頭を使う作業が山積みです。そんな中で、アイテム名を打ち込むたびに「スペルミスはないか？」「大文字小文字は合っているか？」と、いらぬ心配をする時間をゼロにしたかったのです。
肥料（Item.Hiryo）を取った時など、一部のアイテムだけで動かしたい特殊なイベントに関しては、コード内で少し泥臭く対応していますが、個人開発の規模であれば、この『絶対に打ち間違いが発生しない選択式（enum）』でガチッと固める設計が、結果的に一番バグが出ず、精神衛生上も安全な開発に繋がったと感じています。
テストプレイを効率化する時短テクニック
画像作成やプログラムの調整など、どうしても泥臭く時間がかかる作業が多いからこそ、「削れるテストプレイの時間だけは徹底的に自動化・効率化する」という仕組み作りが重要になります。
脱出ゲームの後半の仕掛け（例えば、最後の茶道具のギミックなど）をテストする際、毎回スタート画面から律儀にプレイしていては時間がいくらあっても足りません。
そこで開発中は、プログラムに不具合がないかチェックする作業（デバッグ作業）を爆速にするために、以下のような「ボタン」をUnity内に用意していました。（※リリース版ではこのボタンは削除します）
- 特定の部屋（2階や庭など）へ一瞬で移動できるボタン
- 一瞬で必要なアイテム（鍵やボトル）が手に入るボタン
ゲーム後半のギミックであればあるほど、一瞬でスキップできる開発用の仕組みを最初の段階で仕込んでおくことが、結果的に大きな時短に繋がります。この地味な仕組みを作る数分のおかげで、トータルのテストプレイ時間を削減することができました。