プログラマーの尾関です。
仕事の方が落ち着いたので、趣味のゲーム作りで脱出ゲームを作ってみました。
その過程で得られた、システム設計やゲームデザインの知見について書いてみたいと思います。

■作ったゲームの紹介

まずは作ったゲームの紹介です。Ver 1.00 はブログ内にうまく表示できなかったので、Ver 2.00 の紹介です。
・Ver 2.00

■脱出ゲームの基本システム

まず脱出ゲームを作るにあたって、既存のゲームをいくつか参考にしました。
参考になったゲームとしては、「脱出アドベンチャーシリーズ」や、「CRIMSON ROOM」などです。
典型的な脱出ゲームのシステムを模倣して、以下のシステムとしました。

• マウスクリックで画面内のオブジェクトを調べることができる
• 上下左右に移動カーソルがある場合は、それをクリックすると別の画面に移動できる
• アイテムを選んだ状態で画面をクリックするとアイテムを使うことができる

ゲームシステム

1つの画面を1シーンという単位として扱っています。

1. シーン情報の管理
2. クリックイベントの制御
3. イベントスクリプト

この3つが今回の脱出ゲームにおけるシステムの核となっています。

シーンの情報

1つのシーンには以下の情報を配置できるようにしました。

• 背景画像
• クリック可能なオブジェクトと画像
• クリックしたときに発生するイベントの制御
• 移動カーソルの情報

これらのデータを管理するために、設定ファイルを XML を用意しました。

データの詳細は以下の通りです。

• タグ：bg(背景)、obj(オブジェクト)、move(移動矢印)
• id: 識別用のID。”move” タグの表示方向の制御として使用 (left / up / right / down)
• image: 画像ファイル名
• x, y: 表示座標(左上)
• click: クリックしたときに発生するイベント。指定しない場合は発生しない
• on: 表示フラグ
• off: 非表示フラグ

“on” と “off” フラグの使い方が面白い仕組みになっていると思います。例えば先ほどの XML であれば、初期状態では、オブジェクト(obj)「1～5」が表示された状態です。
そしてフラグ「50」番が ON になると、それらは “off” が 50番に設定されているので、非表示となり、
オブジェクト「6～7」が表示されるようになります（onフラグが50番なので)。

なお、onフラグが 0 の場合は無条件で表示する項目です。

画面をクリックして調べる仕組み

背景とオブジェクト画像を合成して最終的な画面（シーン）を構成します。
画像の矩形そのものがあたり判定となっていて、クリックイベントを発生させるようにしました。

※それぞれのオブジェクトをクリックすると対応するイベントが発生

クリックイベントの制御

クリックイベントは “click” 属性に指定した名前に対応するスクリプトを実行するようにしています。
例えば先ほどの XML では、”001_sticker” / “001_knob” / “001_unlock” / “001_jump002” / “001_jump005″ が発生するイベント名です。

それぞれ対応するスクリプトを呼び出しています。

■001_sticker.txt

■001_knob.txt

■001_unlock.txt

■001_jump002.txt

■001_jump005.txt

これらのスクリプトは事前にコンバートを行い、文法エラーや未定義の定数や関数の呼び出しをしていないかチェックします。
そして「命令コード」＋「パラメータ」からなるアセンブラのような CSV ファイルを出力します。
（以下は、”001_knob.txt” をコンバートしたものです）

このように変換しておくと、実行プログラム側で字句解析や構文解析する必要がなく、楽に実行エンジンを実装できます。
またここでは CSVファイルとしましたが、実行速度が求められたり、メモリサイズを節約する場合には、バイナリデータにした方が良いかもしれませんね。

独自スクリプトを作るメリット

今回の脱出ゲームを作るために、スクリプト言語は Python で自作しました。
Lua を使ったり、プログラムに直接書いてもよいですが、自作言語は自由にカスタマイズできるのがメリットです。

例えば、LuaでフラグをONにする処理を書く場合、

というのがよくある書き方ですが、自作すると特殊な記号をフラグに割り当てることができます。

どちらが読みやすいのかは好みの問題ですが、個人的には後者の書き方がタイプ量が少なくて済むのがメリットと考えています。
（ただ % を剰余の演算子として扱うのが難しくなるデメリットがあるかもしれません)

なんにしても、自作することで自分がゲームを作るための最適な環境を選ぶことができるわけです。

■謎・パズルの作り方

謎・パズルは脱出ゲームを作るにあたって、とても重要な要素です。
当然ながら、ゲームの遊びのコア部分となるので、慎重に作る必要があります。

とはいえ、最初に脱出ゲームを作った際には、どの部分から作ればよいのかイメージができず苦労しました。

• 背景画像を先に作って、それに合う謎を用意するのか？
• 謎を作ってそれに合う画像を用意するのか？
• 得られるアイテムを基準に考えるのか？
• 他との謎との関連性を持たせるには？

考え始めると何も進みません…。
結局は、何でもいいから思いつくものを作って、ありものを組み合わせるくらいでよい、ということがわかりました。
（謎作成のプロではないし、趣味のゲームだからクオリティにこだわって完璧にする必要はない）

謎・パズル作成のために、よく使われる手法は「答えから逆算する」というものですね。
あと、ルールを決めてから問題を作るのも楽で良いです。
例えば「単語の穴あきパズル」というルールを決めてから、必要な情報を埋めていく、といったやり方も有効と思います。

完璧な問題を作る必要はないですが、一般的でない難しい言葉は使わないほうがいいのかもしれません。
あと「順序のある言葉の並び」は、パズルにしやすく使い勝手がよいですね。あいうえお順とか、星座の並びとか、朝昼夜とか…。

デジタルゲームでのパズルの作り方

リアル脱出ゲームの場合、アナログなので、図形を使うなど有機的なパズルを作りやすいです。
しかしデジタルゲームでは、判定部分を作るために固有のプログラムを書く必要があります。
そのため、アナログな判定は止めておいて、「数値入力」「文字入力」など汎用的に使える仕組みを作るのが楽な実装です。

ただ、これだけだと単調になるので、特殊な場面では専用のパズルを用意するのも良いかもしれませんね。

謎・パズルのデバッグ方法

謎・パズルについては、実際に解いてもらって感想をもらうのがデバッグ方法としては最適です。簡単なものであれば、誰でも解くことができるので問題ありませんが、難しいものは要注意となります。

例えば、数字をキーワードにして以下の問題を作成したときのことです

---

■以下のものに共通する数字は？

• Q
• 死刑囚
• お坊さん

 

 

 

 

↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓

 

 

 

 

 

 

答えは「12」です。

ただ、何人かに解いてもらったところ誰もわからず、答えを聞いても “Q” 以外はピンとこなかったそうです。また、Qと死刑囚がカードつながりなのに、突然 “お坊さん” というのも意味が分からない、という感想もありました。

ということで、問題をひねりすぎて “連想が難しいもの” を選んでしまったようです。
このあたりの難易度をどのあたりに設定するかというのは、やはり誰かに解いてもらわないとわからない気がします。
それにより、「あ、これはやりすぎたな」という感覚が少しずつ身につくわけです。

■最後に

実際に脱出ゲームを作ってみてわかったのは、慣れないうちはとにかく「試行錯誤の連続」ということです。
謎を作ってみては、「解き方がわかりにくい」「解くための手順に必要な情報が不足している」「何か今一つ足りない」といった問題が発生しては作り直す（画像やスクリプトの作り直し）という作業が発生します。
…そもそも解答が間違っていて、データの作り直しが発生…、なんてこともありました。

そのため、完璧を目指すとなかなか完成することが難しく、理想としているものに届かなくても「次回作で対応する」というやり方もありなのかな、と思いました。
仕事で作る場合のゲームは一度きりの勝負なのでそういったことはできませんが、趣味で作る分には大きく妥協しても完成させることで次につなげることができるわけです。

ちゃんと完成させれば、誰かにプレイしてもらって感想をもらうとモチベーションにもつながります。今回の脱出ゲームも社内のwikiで公開して、いくつか反応をもらっていてモチベーションにつながっているので、やっぱり完成させるのは大事だなぁ…と改めて思うわけです。

何か新しいことを始める場合に「トップダウン」「ボトムアップ」のアプローチがあると思います。

「トップダウン」をゲーム制作に当てはめると、最初にコンセプトを決めておいて、それをもとにゲームの部品を作る考え方です。
この作り方をすると、コンセプトに忠実なゲームとなり、無駄な工数を減らすことができます。最適な形でゲームを作ることができるため、多くのゲームデザイナーが推奨している作り方です。

それに対して「ボトムアップ」は作りたいゲームの場面や部品をまずは作って、後からそれぞれを組み合わせる、という考え方です。
ただ、組み合わせがうまくいかない場合にその部品を捨てることになるため、無駄な工数が発生しやすいです。

私の場合、どちらのアプローチを取るかは、着想段階のフィーリングで決まることが多いですが、作り慣れないジャンルを作る場合は「ボトムアップ」のアプローチがおすすめです。
というのも、ゲームを作る場合「無駄な作業はしたくない！」と考えてしまい、作り慣れないジャンルでも「トップダウン」で始めてしまい、設計に時間をかけすぎてゲームが完成しない、などということが発生しがちだからです。

何もない状態（知識が足りていない状態）から何かを作るのはとても大変な労力を必要とします。その場合、とにかく手を動かして遊べるものを作り、それがどこかで見たことあるゲームになったとしても、あまり気にせずにひとまず完成させます。

そして、誰かにプレイしてもらいフィードバックをもらって、より洗練されたものにしていく…、というアプローチが改めて大切だなぁ…と思った次第です。もしくはボトムアップ開発で得た経験を生かして、コンセプトを先に決めてトップダウンで作り始めるのも良いかもしれません。

ということで、脱出ゲームを作ってみた話でした。