ゲーム制作プロジェクトの立ち上げと最初の相談
今日から新しく、自作ゲームを作ってみるためのプロジェクトを立ち上げました。
まずは作業を始める前に、いま使っているAntigravityの環境から、
親フォルダにある共通データベースや各種システムへアクセスできるかを確認しました。
起動用のスクリプトや接続設定を通じて無事に連携できていることが分かったので、
さっそく作りたいゲームの企画についてAIと相談を始めることにしました。
今回作ってみたいと考えているのは、Steamで手に取りやすい低価格帯で出せる2Dゲームです。
ボリュームとしては1週間ほど気軽に遊べるくらいを想定していて、
普段は放置で進めながら、育てた編成でダンジョンやボスに挑む形をイメージしています。
また、通常の画面だけでなく、ボタンを押して小窓モードに切り替えられるようにして、
他の作業をしながら時々様子を見られるような設計にしたいと考えました。
ゲームの核になる仕組みとしては、主に次の3つの要素を組み合わせたいと思っています。
・パネルを線で繋いで攻撃やスキルの条件分岐を組むフローチャート構築
・ドロップした改造パーツをはめ込んで性能を変えるスキルカスタマイズ
・育てた編成データを呼び出して1対1で戦わせる非同期の擬似対戦
一問一答の窮屈さと仕様書管理の試行錯誤
質問のペース配分と音声入力の誤変換
最初は頭の中にあるアイデアを一度に詰め込んでAIに伝えたのですが、
そうするとAIからも確認事項や質問が一度にいくつも返ってきてしまいました。
複数の質問に対してまとめて回答を考えるのは意外と大変だったため、
まずは一問一答のような形で、1つずつ順番に決めていきたいとお願いしました。
ただ、実際に一問一答で進めてみると、今度は別のやりづらさが出てきました。
1つの質問に答えると機械的にすぐ次の話題へ進んでしまうため、
気になっている部分をもう少し深掘りして相談したい時に、話が途切れてしまうのです。
そこで改めて、複数のバラバラな質問を同時に投げないでほしいという意味であり、
今話している1つのテーマは納得いくまで一緒に深掘りしてほしいと伝え直しました。
また、今回は音声入力を使いながらチャットで相談を進めていたため、
誤変換に気づかないまま送信してしまう場面も何度かありました。
小窓モードがコマンドモードになったり、1対1のタイマンが怠慢になったりしていましたが、
前後の文脈からAIが意図を汲み取って確認してくれたので、そのまま話を続けられました。
膨らむ仕様書を分割して管理する仕組み
やり取りが増えるにつれて気になったのが、決まった内容をどう残しておくかという点です。
ゲーム制作は大掛かりな作業になるので、細かいやり取りの中で要点が薄れないように、
決まった仕様を随時書き留める仕様書の管理体制を早めに作ってもらいました。
最初は1つのマスター仕様書にすべてまとめる形でしたが、今後設定が膨らむと読みづらくなるため、
マスターは全体の目次に留めて、リソースやスキル、画面設計ごとに分割する運用に変えました。
AIの場当たり的な実装への不安と拡張性のルール化
ある程度の骨格が見えてきたところで、開発ツールにはGodot Engineを選ぶことにしました。
あわせて、親フォルダに作ってある自律会議の仕組みを動かしてもらい、
この企画とエンジンの相性や、開発途中でつまずきそうな問題点を事前に洗い出してもらいました。
大量の敵を出した時の処理負荷への備えや、セーブデータの安全な扱い方など、
作り始める前に知っておくべき注意点を仕様書に組み込めたのは大きな収穫でした。
なお、擬似対戦で相手プレイヤーに手動移動で逃げ回られる問題も会議で指摘されましたが、
そこも含めてホーミングなどで狩り取る防衛用の編成を組む方が面白いと考え、
あえてシステム側での過剰な救済対策は入れない方針に決めました。
一方で、実際のプログラム制作をほぼAIに任せるにあたって、1つ強い懸念がありました。
これまでAIと作業してきた感触として、何も制約を設けないまま指示を出すと、
目の前の仕様通りに最短で動かすことばかりが優先されがちだと感じていたからです。
その場しのぎの書き方でプログラムのあちこちが絡み合ってしまうと、
後からスキルツリーの形を変えたり新要素を足したりする時に、修正が大変になってしまいます。
この不安をそのままAIに伝えて、いざコードを書く段階に入る前の常時適用ルールとして、
メンテナンスや拡張のしやすさを最優先にする方針を指示書ファイルに明記してもらいました。
当初は少額の追加コンテンツを最初から別売りで並べる案も考えていたのですが、
Steamでの見え方や評価のされ方を踏まえて、初期開発分はすべて製品版に含めることにし、
後から新キャラクターをデータ追加だけで足せるデータ駆動設計にしておくことにしました。
仕様を詰める中でぶつかった迷いと順番の見直し
スキルツリーと改造パーツの取捨選択
細かい仕様を詰める段階では、ゲームとしての面白さと複雑さのバランスで何度も迷いました。
たとえばスキルツリーを作る際、単純に攻撃力が上がるだけの強化項目ばかりにしてしまうと、
せっかくパネルを配線して行動順を組む意味が薄れてしまうのではないかという疑問がありました。
これについては、炎上状態の敵に毒をかけると上限が増えるといったように、
組んだ手順通りにスキルが噛み合った時だけ強い相乗効果が出る設計にすることで解決しました。
また、スキルの改造システムについても、効果の数値をスライダーで細かく調整する案や、
強化用のチップをマーケットで売買できる仕組みなどを一時は考えていました。
しかし、自動周回する外部業者の対策や、稼げるゲームという余計な色がつく懸念があるほか、
何より気軽に遊べなくなってしまうため、ドロップしたパーツをはめ込むシンプルな方式に絞りました。
キャラクター設定を中断してステータスを先に決める
さらに夕方になって、初期キャラクターの個性を1人ずつ決めようとしたところで手が止まりました。
魔法職や物理職の特徴を考えようにも、そもそも攻撃や防御にどんなステータスが存在するのかを、
先に決めておかないと比較や議論ができないことに気づいたからです。
そこでキャラクター設定を一旦中断し、先にステータスの土台から整理し直すことにしました。
AIと議論を重ねながら、ステータスや計算ルールを次のように整理しました。
・防御面はHPとシールドに加え、防御力を1つにまとめて回避力も採用する
・回避系スキルツリーの上位に、急所への直撃を防ぐクリティカル無効化を配置する
・対人戦で相手のクリティカル起点コンボを潰さないよう、内部判定は残して追加倍率だけゼロにする
・スキルの連射はMPと体力の枯渇で自然に制限されるため、汎用速度は作らず最小間隔だけ設ける
特にクリティカル無効化の内部処理については、発生判定ごと消してしまうと、
クリティカル発生を条件にした相手のビルドまで完全に機能停止させてしまうため、
ダメージ倍率だけを打ち消す形に落ち着いたのは、とても納得感のある整理でした。
今日のまとめと仕様設計から学んだこと
ステータスの土台が固まったことで、中断していた初期キャラクターの設計にも戻ることができました。
最初はキャラクターごとに得意ステータスの初期値を高くするイメージでいたのですが、
それだとゲーム終盤で数値が大きく伸びた時に、初期値の差が埋もれてしまいます。
そこで、全キャラクター共通の基礎値に対して職業ごとの倍率をかける方式に変更しました。
これなら終盤まで個性が残りやすく、後から倍率の数字を1箇所直すだけでバランス調整もできます。
また、フローチャートの配線画面も、際限なく組めると難易度が高くなりすぎるため、
出力パネルに容量制限を設けて、Pythonのようなループ処理などのパネルを使いながら、
より少ない容量で効率よく同じ動きを作るリファクタリングの遊びを取り入れることにしました。
朝から夕方まで丸1日かけて30回以上のやり取りを重ねましたが、今日学んだことは大きく3つあります。
・AIとの壁打ちでは、複数テーマの同時質問を禁止して1テーマずつ深掘りするルールが機能すること
・仕様書をテーマ別に分割し、常時適用の指示書ファイルで拡張性重視の制約を先に掛けておくこと
・細部の味付けに入る前に、ステータスの種類のような土台の順番を人間側で立ち止まって見直すこと
まだコードを1行も書いていない段階ではありますが、焦って作り始める前に、
自分がどういうゲームを作りたいのかと、後から手入れしやすくするための前提を整理できました。
次回からは残っているキャラクターの吟味や、まだ決まっていない細部の仕様を引き続き詰めていきます。