※本記事にはアフィリエイトリンクを含みます。
新作の2Dプラットフォーマー「STATION OOPS」は、最初から今の形だったわけではありません。「アクションゲームを作ろう」というシンプルな思いつきから、何度か方向転換を経て、「敵のいない、パズル寄りの脱出ゲーム」という今の形にたどり着きました。この記事では、その企画段階での試行錯誤をまとめます。
前作からの流れと、規模感の基準
前作「波無島事件」は、Unityで作ったミステリーADV（アドベンチャーゲーム。会話やテキストを読み進めながら謎を解いていくジャンル）でした。今回はその次作にあたり、ジャンルを2Dプラットフォーマー（横方向に移動しながらジャンプで進んでいくアクションゲーム）に変えて開発しています。
企画にあたって基準にしたのが、個人開発で実際に成功している事例です。少人数・短期間で完成させたインディーゲームの実例を参考に、「自分たちの手が届く規模で、最後まで完成させられること」を最優先に据えました。壮大な企画を立てて途中で頓挫するより、小さくても完成させる方が価値があるという考え方です。
「アクション主体」から「優しい難易度」への方向転換
企画の最初期は、アクション性を前面に出したプラットフォーマーとして構想していました。ジャンプアクションの爽快感や、敵を倒す手応えを中心に据えるイメージです。
ですが検討を進める中で、「アクションゲームが得意でない人でもクリアできる優しい作りにしつつ、それでもちゃんと達成感は残したい」という軸を定めました。この軸を実現する方法として選んだのが、アクション×クイズ／謎解きのハイブリッド構成です。移動やジャンプの操作自体はシンプルにしておき、各ステージの「詰まりどころ」はアクションの難しさではなく、謎解きやギミックの発見に置く、という考え方です。
「敵キャラを出さない」という決断
方向転換の中でも大きかったのが、敵キャラクターを出さないという決断です。当初は敵キャラの登場を想定していました。それを途中で撤回した理由は2つあります。
1つ目は、優しい難易度というトーンと、敵によるダメージ演出が噛み合わないためです。「気軽に遊べる」ことを目指しているのに、敵に攻撃されてライフが減る仕組みを入れると、緊張感が生まれてしまい狙いとずれます。
2つ目は、実装の負荷を下げるためです。敵キャラクターを作るには、当たり判定の調整やAI（キャラクターを自動で動かす仕組み）の実装が必要になり、個人開発の身の丈規模から外れてしまいます。
この決断にあたって、障害物をすべて「施設の誤作動」という世界観設定でまとめたのが工夫した点です。敵として襲ってくるのではなく、宇宙ステーションの設備がおかしな動きをしている、という体裁にすることで、敵なしでも違和感のない世界観に仕上げました。
面ごとにギミックを変える「オムニバス構成」
ステージ構成は、オムニバス構成（各話・各章で全く違う題材を扱う構成のこと。ここでは面ごとに別々のギミックを1つずつ割り当てる作り方を指します）を採用しています。
具体的には、重力反転・配線パズル（ワイヤーを引っ張って操作するパズル）・サイズ変化という3つのギミックを、それぞれ別の面に割り当てました。ここに基本操作を学ぶチュートリアル面と、最終面のラスボス戦を加えた構成です。1つの面で1つの仕掛けに集中して遊べるので、プレイヤーが混乱しにくく、また開発側もステージごとに実装範囲を区切りやすいという利点があります。
タイトル「STATION OOPS」の由来
タイトルの「STATION OOPS」には、ちょっとした遊び心を仕込みました。正式名称を「Orbital Outpost for Prototype Systems（試作システムのための軌道前哨基地）」と設定したところ、その頭文字を並べると偶然「OOPS」になったのです。
英語で「OOPS」は「あっ、しまった」というニュアンスの言葉です。これが、施設のあちこちが誤作動を起こしているという世界観ともうまくリンクしたため、そのまま正式なタイトルとして採用しました。
まとめ・次回予告
今回は、STATION OOPSが「アクション主体」から「優しい難易度のアクション×パズル」へとたどり着くまでの企画段階の流れをまとめました。次回は、実際にGodot（今回採用したゲームエンジン）でプロジェクトを立ち上げ、最初のシーンを作っていく過程で起きたつまずきを紹介します。
Godotを自分でも触ってみたい方へ。今回のような「企画は決まったのにエンジン操作でつまずく」を避けたいなら、独学で手探りするより体系立てた講座で基礎を一気に固めてしまう方が近道です。
コメント