箱庭・サンドボックスゲームの作り方：目標のない遊び
遊びをつくる執筆にClaudeを使用しています。
箱庭ゲームやサンドボックスゲームを作ろうとするとき、最初につまずくのは「ゴールをどこに置くか」ではなく、「ゴールを置かなくていい理由をどう説明するか」です。多くのゲーム制作の入門資料は「目的を明確にせよ」と教えますが、この種のゲームはその逆を意図的に選んでいます。 目標のない遊びが成立するのは、「操作することそのものが報酬になる」設計があるからです。プレイヤーは何かを達成するためではなく、システムに触れる感触を楽しむためにプレイします。この違いを理解していないと、「ゴールを外しただけで何も起きない、ただの空白」になります。 この記事では、箱庭・サンドボックスゲームに固有の設計上の問いを整理し、実際に動くものを作るまでの判断基準を示します。
この記事の目次
「目標がない」とはどういう意味か
まず言葉を整理します。箱庭・サンドボックスゲームには大きく二つの方向性があります。
一つは閉じた箱庭型で、あらかじめ用意された小さな世界の中でプレイヤーが自由に手を加えていくタイプです。庭を育てる、街を配置する、生き物を観察するといったゲームがこれにあたります。世界の外縁は決まっていますが、その内側では何をしてもよい。
もう一つは開いたサンドボックス型で、素材・ルール・地形をプレイヤー自身が組み合わせて何かを生成していくタイプです。建築・回路・農業・探索が混在する大規模なものが代表例です。
どちらも「クリア条件がない」という点は共通ですが、設計の難易度はまったく異なります。開いたサンドボックスは要素の組み合わせ爆発を制御するのが難しく、小規模な実装では破綻しやすい。箱庭型のほうが「作れるものの質」を担保しやすいため、初めて作るなら閉じた箱庭型から始めることをお勧めします。
「触れると何かが変わる」を最小単位で設計する
目標のないゲームで最も重要な設計原則は、インタラクションのたびに状態が変化し、その変化がプレイヤーに見えることです。
たとえば「木を植えると育つ」という単純な仕組みでも、以下のように段階を踏んで設計できます。
- クリックで木のオブジェクトが配置される（配置の手応え）
- 時間経過で木のサイズが変わる（変化の観察）
- 木が隣接すると葉の色が変わる（関係性の発見）
- 木が一定数になると新しい種類の木が出現する（予期しない変化）
この4段階のうち、最初の2ステップだけでも「箱庭として動くもの」は作れます。3・4は「発見の余地」を生む層で、リプレイを生みたいならここを増やします。作れるものの規模を決めるとき、この層をいくつ実装するかを先に決めておくと、設計が散らばりません。
失敗しやすいのは、最初から4の層を複数並べようとして、どの変化も浅くなることです。一つの変化を深く作るほうが、プレイヤーの滞在時間は伸びます。
プレイヤーが「何をしていいかわからない」問題への対処
目標がないゲームでよく起きる問題は、プレイヤーが最初の数秒で「何をすればいいかわからない」と感じて離脱することです。これはゴールがないせいではなく、最初の操作が提示されていないせいです。
解決策は「最初の一手を強制しないが、示す」設計です。具体的には次のいずれかの方法が有効です。
- 画面の中央に配置可能なオブジェクトを最初から置いておく。プレイヤーはそれをクリックすることで最初の操作を発見します。
- アニメーションで「触ってほしいもの」が動いている。静止した画面よりも動くものに人は手を伸ばします。
- カーソルが近づくとオブジェクトが反応する。ホバーだけでフィードバックを返すことで、「ここは触れる」とわかります。
チュートリアルテキストで「〇〇してみましょう」と書くより、これらの方法のほうが自然な誘導になります。テキスト指示は、プレイヤーに「これはゲームではなく説明書だ」と感じさせるリスクがあります。
時間と変化：ゲームを「生きているもの」にする
箱庭ゲームの大きな魅力の一つは、プレイヤーが操作していない間にも世界が動いていることです。これを実装するには、時間ベースの状態更新が必要になります。
ブラウザゲームであれば setInterval や requestAnimationFrame を使って定期的に状態を更新する仕組みが基本です。ここで注意すべきことが二つあります。
一つは変化の速度です。変化が速すぎるとプレイヤーは操作を追えず、遅すぎると変化に気づかず画面を閉じます。最初は「プレイヤーが30秒程度見ていれば変化に気づける」速度を目安に調整するのが現実的です。
もう一つはセッションをまたいだ保存です。箱庭ゲームは「続きから遊べること」が体験の質に直結します。ブラウザの localStorage を使えば、単純な状態（オブジェクトの配置や育ち具合）であれば比較的少ない実装量で保存できます。ただし、localStorage はブラウザのデータ削除で消えるため、プレイヤーにその前提を伝えておくことが誠実な設計です。より確実な保存を実現したい場合は、アソバースのSDKを利用したクラウドセーブの対応を検討する価値があります。
「完成」を決める基準
サンドボックスゲームは「どこまでも追加できる」構造を持つため、完成の判断が難しい種類のゲームです。作り続けているうちに機能が増え、コードが複雑になり、最終的に公開されないまま終わるケースは珍しくありません。
完成の判断基準として、次の問いを使うことをお勧めします。
- 5分間プレイして、プレイヤーが自分で次の行動を選べるか。 選べれば最低限のループは成立しています。
- 同じ状態からスタートして、毎回違う結果になるか。 完全に決定論的なら「作業」に近くなり、発見の余地がなくなります。
- 30秒ごとに何かが変化しているか。 変化の頻度が低すぎる場合、プレイヤーは離れます。
これらの三つを満たしていれば、機能が少なくても公開できる水準にあります。あとは実際に遊んでもらったフィードバックを受けて追加するほうが、一人で機能を積み上げるより効率的です。
箱庭・サンドボックスゲームは「未完成でも遊べる」という特性があります。むしろその特性を活かして早めに公開し、プレイヤーの反応を設計に取り込む進め方が、このジャンルには向いています。
次の行動
まず「一つのオブジェクトを配置すると何かが変わる」だけを動かすプロトタイプを作り、30秒間自分でプレイしてみてください。変化に気づけるか、次に何かしたいと感じるかを確認するのが最初の判断点です。動くものができたら、アソバースにHTMLファイルやZIPファイルとして投稿し、実際に他の人に触ってもらうことで、一人では気づけない「何をしていいかわからない」ポイントが見えてきます。
参考資料
- MDN Web Docs（localStorage・requestAnimationFrame の仕様）
- アソバース 公式ドキュメント（投稿方法・SDK対応の手順）
