AIと一緒にゲーム開発仕様書を作ってみた
前回の記事では、UnityとCodexを導入して、
ついに画面上の「Work」という四角形を右へ動かすことができました。
見た目はただの四角形。
ゲームと呼ぶにはまだ程遠い状態です。
それでも、
「AIに指示すれば、本当にUnity上で何かを作れる」
ということは分かりました。
ここで私は、少し欲が出てきます。
このままゲームの構想を全部Codexに伝えれば、一気に作れるのでは？
そこでChatGPTに相談したところ、返ってきた答えは、
「できる。ただし、いきなり全部作らせるのではなく、まずゲーム設計書を作った方がいい」
というものでした。
正直、ゲームを作るのに「仕様書」まで必要なのか？とも思いました。
でも、機械設計者として考えてみれば、
仕様も決まっていないのに図面を描き始める方がおかしい。
ということで今回は、AIと一緒にゲーム開発仕様書 Ver.1.0を作ってみることにしました。
ゲーム開発でも、まずは仕様を決めるらしい
ChatGPTから最初に出てきた仕様書の構成は、
かなり本格的でした。
- ゲーム概要
- コンセプト
- 世界観
- ゲームループ
- ゲームシステム
- ステージ構成
- 部品システム
- 設計評価
- ゲームバランス
- UI設計
- アニメーション
- セーブデータ
- 開発ルール
- フォルダ構成
- ロードマップ
など。
最初にこれを見たときは、
「いや、いきなり多すぎない？」
というのが正直な感想です。
まだ四角形が右に動いただけです。
コンベアもありません。
加工機もありません。
ゲーム画面すらまともにありません。
それなのに、第15章まである仕様書を作ろうとしています。
でもChatGPTから、
この仕様書が、ゲーム開発で最も価値のある資産になる。
と言われました。
プログラムを書くことよりも、
「何を面白いゲームにするのかを決める方が難しい」という話です。
ここは機械設計でも少し似ています。
CADで図面を描くことより、その前段階で、
「そもそもどんな機械にするのか」を決める方が難しい。
ゲームも同じなのかもしれません。
最初に決めるべきは「何が面白いゲームなのか」
仕様書を作る中で、最初にChatGPTから聞かれたのが、
「このゲームで、何を面白さの中心にするのか？」ということでした。
いわゆる、コアゲームループです。
コアゲームループとは、プレイヤーがゲームの中で繰り返す基本的な行動のこと。
今回のゲームであれば、単純に、
コンベアを配置する
↓
ワークを流す
↓
ゴールする
だけでは弱い。
そこでChatGPTから提案されたのが、
- 依頼を受ける
- 設計する
- 試運転する
- 問題を発見する
- 改善する
- 納品する
という流れでした。
これを見たとき、「これはかなり機械設計っぽい」と思いました。
実際の設備設計でも、いきなり完成するわけではありません。
- 要求仕様を確認する。
- 構想する。
- 設計する。
- 試運転する。
- 問題があれば修正する。
- 最終的に設備を完成させる。
この流れを、そのままゲームに落とし込むイメージです。
一番面白くしたいのは「試運転して改善する」ところ
特に気に入ったのが、試運転 → 問題発見 → 改善という部分です。
設備を配置して終わりではありません。
実際にスタートボタンを押して、自分が設計したラインを動かしてみる。
すると、
そこで、「どこが悪い？」と考える。
- 設備を入れ替える。
- 配置を変える。
- もう一度試運転する。
- そして今度はうまく流れる。
この、自分で作ったものが改善されていく感覚を
ゲームの面白さにしたいと思いました。
機械設計でも、試運転で想定通りに動いた瞬間はかなり気持ちがいいものです。
そこをゲームでも再現できれば、かなり自分好みのゲームになりそうです。
ゲームの中心は「トレードオフ」にしたい
コアゲームループの方向性は決まりました。
ただ、これだけではまだ、
「何を考えるゲームなのか」
が弱い気がしました。
そこで私から、
こんな要望を出しました。
ゲーム性の部分は、コストと性能のトレードオフにフォーカスしたい。
例えば5個くらいの部品があって、それぞれ性能やサイズやコストが違う。
重要なところにはコストをかけて、必要のないところは安い部品を使う。
できるだけ最低限のコストで仕様を満たすゲームにしたい。
これが、今回のゲームの方向性をかなり決めることになります。
高性能な設備を使えばクリアできる。でも、それでは面白くない
例えば、あるステージで、
「1分間に10個のワークを処理してください」
という要求があったとします。
全部一番高い設備を使えば、簡単にクリアできるかもしれません。
でも、それでは設計する意味がありません。
そこで、各設備に、性能と価格とサイズを設定します。
例えば、
| 設備 | 性能 | コスト | サイズ |
|---|---|---|---|
| コンベアA | 低 | 100 | 小 |
| コンベアB | 中 | 200 | 中 |
| コンベアC | 高 | 400 | 大 |
のようなイメージです。
性能が高ければ、
当然コストも高い。
サイズも大きい。
だから、全部高性能にすれば、要求仕様は簡単に満たせる。
でも、お金がかかるしスペースも使う。
逆に、安い設備ばかり使えば、コストは下がる。
しかし、今度は性能不足でクリアできない。
この間で、ちょうどいい設計を探す。
ここをゲームにしたいと思いました。
一言で表すと「最小コストで、要求仕様を満たせ。」
ChatGPTとのやり取りの中で、ゲームコンセプトを一言にすると、こんな言葉が出てきました。
最小コストで、要求仕様を満たせ。
かなり分かりやすい。もう一つ出てきたのが、
設計とは、性能ではなく最適解を探す仕事である。
という言葉です。機械設計では、
性能が高ければ何でもいいわけではありません。
必要以上に大きなモーターを使えば、当然コストやサイズは上がります。
必要以上に頑丈な部品を使えば、重量も価格も上がります。
逆に、安くしすぎれば、強度不足や能力不足になる。
だから、要求された性能を満たす範囲で、どこまで無駄を削れるか。
この考え方を、ゲームの中心に置くことにしました。
「どこにお金をかけるか」を考えるゲーム
個人的に面白いと思ったのが、単純に、安い部品を使えば勝ちではないことです。
重要なのは、
どこにコストをかけて、どこでコストを抑えるか
例えば、加工機がボトルネックになっているなら、加工機には高性能品を使う。
一方で、能力に余裕のあるコンベアは、安いものでも十分かもしれません。
すべてを均等に高性能にするのではなく、必要なところだけにコストを投入する。
これなら、プレイヤーごとに考え方が変わります。
ここで、今回のゲームが単なる「コンベアをつなぐゲーム」から、
「設計判断を楽しむゲーム」に少し近づいた気がしました。
このゲームには「正解」が複数ある
もう一つ、今回の仕様を考えていて気に入ったのが、
正解を一つにしなくてもいいということです。
例えば、同じ要求仕様でも…
いろいろな設計が考えられます。
もちろん、最低限クリアしなければならない要求仕様はあります。
でも、そこへ到達する方法は一つではない。
これは、機械設計の仕事にもかなり近いと思います。
同じ仕様書を渡しても、設計者によって出来上がる機械は違います。
ゲームでも、「答えを当てる」のではなく、
「自分なりの最適解を作る」という方向にしたいと思いました。
仕様を満たすだけでは高評価にならない
ここまでの内容を、仕様書の文章として整理すると、こんな形になりました。
プレイヤーは、要求仕様を満たす設備を設計する。
しかし、要求仕様を満たすだけでは高評価にならない。
高評価を得るには、
必要な性能を維持しながら、不要なコストを削減すること
が重要である。
各部品には性能と価格が設定されており、
「どこにコストをかけ、どこでコストを抑えるか」
がゲームの中心的な意思決定となる。
プレイヤーは試運転と改善を繰り返し、
最小コストで要求仕様を満たす最適設計を目指す。
まだゲームはほとんど完成していません。
でも、この文章ができたことで、
「何を作ればいいのか」がかなり明確になりました。
Codexに任せるためにも、仕様書が必要だった
ここで、なぜゲーム仕様書が重要なのかも少し分かってきました。
Codexは、プログラムを書くことはできます。
でも、「自分がどんなゲームを作りたいのか」
までは勝手に決めてくれません。
例えば、
コンベアを作って
だけでは、
など、
決めることがたくさんあります。
つまり、AIにゲーム制作を任せるほど、
こちら側は、仕様を明確にする必要があるということです。
最初は、
「AIなら勝手にいい感じに作ってくれるのでは？」
くらいに思っていました。
でも実際には、AIに任せるためには、人間側が、
何を作りたいのかをきちんと言語化する必要がある。
ここは今回のゲーム制作で、かなり重要な気付きでした。
機械設計とゲーム制作、意外と似ているかもしれない
ゲーム仕様書を作っていると、少しずつ、
普段の仕事との共通点が見えてきました。
- 要求仕様を決める。
- 構想を考える。
- 設備を選ぶ。
- コストを考える。
- 試運転する。
- 問題が出る。
- 改善する。
そして納品する。
これは、
ゲームの中だけではありません。
今、自分自身がやっているゲーム開発そのものも同じ流れです。
ゲームを設計して、Codexに作ってもらう。Unityで動かす。
問題があれば修正する。
そして少しずつ完成へ近づける。
ゲームの中でも設計。
ゲームを作る過程でも設計。
なんだか、だんだん機械設計者らしいゲーム開発になってきました。
ゲームの「設計図」がようやくでき始めた
今回、ゲーム開発仕様書 Ver.1.0を作り始めたことで、
ようやく今回作りたいゲームの中心が見えてきました。
ゲームの基本ループは、
依頼 → 設計 → 試運転 → 問題発見 → 改善 → 納品
そして、ゲーム性の中心は、コストと性能のトレードオフ。
目指すのは、最小コストで要求仕様を満たす最適設計。
まだ設備もほとんどありません。
ステージもありません。
UIもありません。
でも、
第4回までの
「とりあえず四角形を動かす」
という状態から、
今回初めて、「どんなゲームを作るのか」
を言葉として決めることができました。
次は、この仕様書を実際のゲームにしていく
仕様が決まったら、次は実装です。
まず必要なのは、ゲームの土台になるフィールド。
どこにでも自由に設備を置けるようにするのではなく、
マス目の中にコンベアや設備を配置できるようにした方が、
パズルゲームとして分かりやすそうです。
そこで次に作ることになったのが、12×8のグリッド。
ここから、
ただの四角形が動いていただけのUnity画面が、少しずつ
「工場パズルゲームの画面」
へ変わり始めます。
次回は、
【第6回】工場パズルの土台となる「グリッド」を作ってみた
というところから、いよいよ本格的なゲーム画面作りに進んでいきます。
コメント