ゲームの終わり方を決める：クリア・エンドレス・周回

クリア型：終わりを用意することで生まれる緊張

クリア型は、明確な目標を達成した時点でゲームが終わる形式です。ボスを倒す、全ステージをクリアする、時間内にゴールに到達するといった設計がこれにあたります。

クリア型の最大の利点は、「終わり」がプレイヤーへの約束として機能することです。プレイヤーは「これを達成したら終わる」と分かっているからこそ、集中力を保ちやすく、進行に意味が生まれます。物語や演出と相性がよいのも、終点があるからです。エンディングというご褒美が設定できます。

設計で注意すべき点は、難易度曲線とゲームオーバー処理です。クリア型は失敗の扱いを最初に決める必要があります。「残機制でゲームオーバーまで戻す」「チェックポイントから再開する」「ペナルティなしで直前から続ける」のどれを選ぶかで、テンションの保ち方がまったく違います。カジュアルなブラウザゲームであれば、チェックポイント復帰かペナルティ軽減の設計が離脱を防ぎやすいです。

クリア型が向いているのは、次のような状況です。

• プレイヤーに達成感や解放感を届けたいとき
• 物語・演出・キャラクターをゲームの中核にしたいとき
• プレイ時間を10〜30分程度にコントロールしたいとき
• 初めてゲームを作る場合（終点があるとテストもしやすい）

エンドレス型：続くことが価値になる設計

エンドレス型は、ゲームオーバーになるまで続けることを前提とした形式です。スコアが上がり続け、ミスしたらそこで終わりというハイスコア競争がわかりやすい例です。

エンドレス型はリプレイしやすさが強みです。一回のプレイが短く終わっても「もう一回」が起きやすく、スコアランキングと組み合わせると他者との比較が動機になります。難易度を自動的に上げていく仕組み（スクロール速度の増加、敵の出現頻度の上昇など）を入れると、毎回の挑戦がわずかに違う体験になります。

設計の落とし穴は「緩やかな死」です。終わりに近づいていることをプレイヤーが体感しにくいと、ゲームオーバーが唐突に感じられます。速度の上昇・色の変化・効果音の変化など、「状況が厳しくなっていること」を段階的に知らせる演出が必要です。これがないと、達成感よりも理不尽さが残ります。

エンドレス型が向いているのは、次のような状況です。

• 反射神経・タイミング・操作精度を楽しんでもらうとき
• プレイ時間を問わず気軽に始めてほしいとき
• スコアランキングや競争をコンテンツの軸にしたいとき
• ゲームのループが短く、繰り返しても飽きない手触りがあるとき

逆に、エンドレス型は長い物語や複雑なパズルとは相性が悪いです。エンドレスにすることで「物語の続きが見たい」という動機が消えてしまうからです。

周回型：終わりの後にもう一周

周回型は、ゲームが一度終わった後に再び始まるか、意図的に繰り返しプレイすることで内容が変化する形式です。ローグライク・ローグライトと呼ばれるジャンルがその代表で、死んだら最初に戻るが成長要素や解放要素が残るという仕組みが典型です。

周回型の核心は「前回と少し違う今回」です。同じマップを同じ順序で歩くだけでは周回の価値がありません。ランダム要素（アイテム・敵配置・マップ生成）、前回の選択によって変わる展開、周回するたびに解放される新要素の少なくとも一つが必要です。

設計コストの観点では、周回型は三つの中で最も複雑です。クリア型とエンドレス型の要素を両方持ちながら、「もう一度やりたい理由」をゲーム内に仕込む必要があります。初めてゲームを作る場合は、周回型から始めるのは難易度が高いです。一方、短いクリア型ゲームに「周回要素」を追加する形なら、段階的に取り組めます。

周回型が向いているのは、次のような状況です。

• ランダム性や構築の楽しさをゲームの中心に置きたいとき
• 一周の長さは短いが、繰り返すことで発見があるとき
• プレイヤーに「攻略を研究してほしい」体験を想定しているとき
• クリア型として作ったゲームに寿命を追加したいとき

三つの形式を選ぶ判断基準

形式を選ぶときは、「プレイヤーに何を感じて終わってほしいか」から考えると整理しやすいです。

• 達成感・物語の余韻、向いている形式：クリア型
• 悔しさ・「もう一回」の衝動、向いている形式：エンドレス型
• 発見の喜び・「次はこうしよう」、向いている形式：周回型

次に、作れる規模と照らし合わせます。クリア型はゲームオーバーと終点の2点を正しく実装すれば成立します。エンドレス型は難易度上昇と終了判定の精度が仕上がりを左右します。周回型は変化を生む仕組みの設計が核になり、開発量が増えます。

また、一つのゲームに複数の形式を混ぜることも可能です。「クリア型の物語モードとエンドレスのスコアアタックモードを両方用意する」という構成は多くのゲームで見られます。ただし、初作であれば一形式に絞って完成させるほうが賢明です。二つ作ろうとして両方が中途半端になるリスクがあります。

実装前に確認しておくこと

形式が決まったら、コードを書く前に次の点を言語化しておくと設計がぶれません。

1. 終了条件を一文で書く　「体力が0になったとき」「全10ステージをクリアしたとき」のように、条件をひとつの文で表現できるか確認します。複数の条件が並ぶときは優先順位を決めます。
2. 失敗時の処理を決める　ゲームオーバー画面を出すのか、直前から再開するのか、最初から始まるのかを決め、それに合わせたデータ管理（どこまでのデータを保持するか）を決めます。
3. プレイ時間の目安を設定する　一回のプレイが平均何分になるかを想定します。想定より長い場合は中断・再開の仕組みが必要になることがあります。
4. 繰り返し遊ぶ理由があるか確認する　クリア型でも「全実績コンプリート」「タイムアタック」など周回の動機を用意するだけで、ゲームの寿命が伸びます。これを最初から設計に含めるかどうかを判断します。

次の行動

まず自分のゲームを「プレイヤーに何を感じて終わらせたいか」という一文で書き出し、それに対応する形式を選んでください。形式が決まったら、終了条件と失敗時の処理を箇条書きにしてから実装に入ると、後から仕組みを作り直す手間を減らせます。作ったゲームはアソバースにHTMLまたはZIPで投稿して公開できます。完成した一本を届けることが、次の設計を考える最良の出発点になります。