ゲーム開発は仕様書より先に“遊び”を作ってもいい？

私のXの過去ポストを元にブログへ書き起こしてます

ゲームを作るとき、最初に何を作るでしょうか。

企画書でしょうか。

仕様書でしょうか。

画面遷移図でしょうか。

もちろんどれも必要になります。

でもゲーム制作の現場ではもっと早い段階で

「遊びそのもの」を先に作ってしまうやり方があります。

いわゆるホワイトボックスやグレーボックスと呼ばれます。

見た目はほとんど完成していない状態です。

キャラクターは四角でもいい。

敵も仮のモデルでいい。

背景もなくていい。

大事なのは

「このルールで実際に遊んだとき面白いか？」

を確かめられることです。

ゲームの企画は、文章だけでは分からないことがかなりあります。

たとえば

「敵の攻撃を避けながら、タイミングを図り反撃する」

と仕様書に書けば、それらしく見えます（このような指示を仕様に書くとまあ怒られますが…）

でも実際に制作して動かしてみると

敵の攻撃を待つ時間が長くて退屈だったり

避けるだけで簡単に勝ててしまったり

逆に反撃できる時間が短すぎてストレスになったりします。

文章として成立していても、遊びとして成立しているとは限りません。

だから私は可能なら早い段階で触ってみたい。

そして

「ここは面白い」

「ここは思っていたのと違う」

「この仕組みはいらないかもしれない」

ということを実際に遊びながら見つけていきます。

これは企画を軽視しているわけではありません。

むしろ逆で、企画を確かめるために作るという感覚に近いです。

特に小規模開発では最初から細かい仕様を全部決めようとすると

その仕様を作ること自体にかなり時間を使います。

そしてあとから実際に触ってみて

「これ、あまり面白くないな」

となったとき、作り込んだものが多いほど捨てるのが難しくなります。

やはりどうしても

「ここまで作ったんだから使いたい」

と思ってしまいます。

だからこそ、まだ簡単に壊せる段階で試す。

見た目が悪くてもいい。

完成度が低くてもいい。

面白くなかったら捨てられる状態で遊ぶ。

この考えは重要で開発手法の中では主流となっているともいえます。

もちろん大人数で開発するゲームでは事情が違います。

ラインがストップしないように誰が何を作るのか予め共有するために仕様書や発注書が必要ですし、エンジニアやデザイナー、アーティストなど多くの人が同時に動く現場では文章やイメージ先行でどのようなもの作るかを先に決めておかなければならないこともあります。

だから「仕様書はいらない」という話ではありません。

私が言いたいのは、

仕様書を書くこととゲームを考えることは同じではない。

ということです。

ゲームの企画で一番確かめたいのは、最終的に画面の中で起きることです。

プレイヤーが操作して、何かが起きて、それを見て次の行動を考える。

その繰り返しがなぜ楽しいのか。

そこをあまり確認しないまま本仕様に向かうのは危険なシグナルです。

今やUEやUnityなどゲームエンジンもかなり身近になりました。

一人や少人数で作るなら最初から綺麗なゲームを目指さなくても

いいと思います。

四角と丸だけでもいい。

まず

「これ、もう少し遊んでみたいな」

と思えるところまで作ってみる。

それから仕様を整理しても遅くはありません。

企画書や仕様書の中で先に面白さを定義してもいいですが

その実証としてゲームを実際に遊びながら考えてもいい。

今更そんなこと当たり前と言われそうですが

私は今も「そんなこと」まで立ち返って考えたりします。