ゲーム制作計画

はじめに#

なぜゲームなのか、という話も必要だと思います。

正直に言うと、そこに大げさな理由はありません。AIでコードを速く書く話はもう珍しくありませんし、多くの人がその変化をすでに体感していると思います。何を実際に出せる形で作るのか、という少しぜいたくな悩みから始まったのが、まさにゲーム開発でした。

以前なら、開発や運用のリソースだけを見ても、気軽に足を踏み入れられる領域ではありませんでした。ところが今は、あまり構えずに始めてみてもよい時代になったように感じます。しかも、自分でも楽しめて、仕事というより趣味に近い開発をやってみるのは、それなりにロマンのあることだとも思います。

前置きが長くなりました。今回は、私が進めてみたいゲームのジャンルと、なぜこの流れを選んだのかを整理してみます。

実装順序

なぜ最初のジャンルがストーリークイズなのか#

私が最初に選んだジャンルはストーリークイズです。ビジュアルノベルのように物語が進み、途中や最後に推理を解くことで経験値を得る構造です。このジャンルを最初に選んだ理由は単純です。面白さの中心は明らかに物語と推理にある一方で、運用負荷は比較的低く抑えられるからです。

ここではAIをあらゆる場所に入れる必要はありません。むしろそこが重要だと私は考えています。ストーリークイズでは、AIは主に 採点 と 制作補助 に寄せ、プレイそのものは人が設計したルールと演出の上に載せるのがよいと思っています。そうすることで運用が暴走しにくくなり、同時に作家が自分の作品を出版するモデルも試せます。

まだ初期段階ではありますが、実装の向きもすでにそちらへ寄っています。原稿をそのままDBに入れるのではなく、Markdown原稿 → パース → 台本補強 → プロンプト生成 → 翻訳 → import という制作パイプラインで、ストーリー制作にAIを最適化しようとしています。

source.md
-> parse-episode.py
-> script-doctor.py
-> prompt-gen.py
-> translate-story.py
-> /bo/story-quiz/games/import

ストーリークイズはどこまで実装されたのか#

現在のリポジトリ基準で見ると、ストーリークイズは単なるアイデア段階を少し超えたところまで来ています。プレイヤー向けにはゲーム一覧と詳細、セッション作成、再開、回答提出、エピローグ取得までつながるAPIがあり、バックオフィスにはゲーム、キャラクター、フェーズ、ブロック、クイズ、背景アセットを個別に管理する構造が入っています。さらにゲーム全体のデータをJSONで import, export する流れまでついているため、単発のゲームというより、出版可能なコンテンツ形式として扱われ始めています。

重要なのは、このジャンルが コンテンツデータ と プレイセッション を分離しながら育っていることです。1つのゲームはキャラクター、フェーズ、ブロック、クイズ、背景アセットに分かれ、セッション側では現在のフェーズ、現在のクイズ、使ったヒント、スコア、進行状態が別に管理されます。つまり、作者が作品を直す流れと、プレイヤーがそれを消費する流れは、すでに別レイヤーに分かれています。

採点も同じ哲学です。客観式は即時採点し、主観式は KEYWORD_ONLY, LLM_ONLY, HYBRID, MANUAL のような戦略とバックオフィスの確認フローに分かれています。私にとって重要なのは、AIが常に正しいことではありません。AIに任せられる問題だけをAIに任せ、それ以外は人が確認できる形で残す構造のほうです。

作品の出版実験に向けて、配信レイヤーも別に整えています。カバー画像やカード画像は public source path と preset ベースの thumbnail で配信し、Asset Studio では Story Quiz と Mystery のキャラクター資産や背景資産をまとめて扱えるようにしています。結局、ストーリークイズはゲームであると同時に、作品制作・検収・出版パイプライン の最初の実験場でもあります。

なぜ次がミステリーなのか#

ストーリークイズが 作者が設計した構造化された体験 に近いとすれば、ミステリーはそれよりずっと生きたジャンルです。プレイヤーは手がかりを読むだけで終わらず、役を持ち、会話し、互いを疑い、状況を更新し続けます。かなりマニアックなジャンルではありますが、うまく噛み合えばエンゲージメントはずっと深くなる可能性があります。

そして、まさにここでAIの比重が大きく上がります。ストーリークイズではAIを限定的に使ってもよいのですが、ミステリーではNPCの反応、尋問、ヒント補助、シナリオ補強といった領域が体験の中核にかなり近づきます。私はこのジャンルを、AIが本格的にプレイ体験の中へ入っていく第二段階 と見ています。

ミステリーはどこまで来ているのか#

並行して進めてきたこともあり、ミステリーもすでに小さなプロトタイプを目で確認できる段階まで来ています。プラットフォームAPIには、シナリオ照会、セッション作成と招待コード参加、準備状態、開始、フェーズ遷移、ノート、アイテム、尋問記録がつながっています。セッションはチケット、招待コード、プレイヤー一覧、状態遷移を基準に管理され、開始アイテム、開始ノート、開始尋問のようなデータも別にぶら下がっています。つまり、実際に1ゲーム回せるセッションモデル がまず先に固まっています。

制作側はさらに面白いです。ミステリーには Draft Scenario というバックオフィスの流れがあり、生成段階が CONCEPT → TRUTH → CHARACTERS → TIMELINE → CLUES → ROLEPLAY → WORLD_BUILDING → SYNOPSIS → PROLOGUE → EPILOGUE に分かれています。これは単なる文章生成ではありません。答えや動機、人物関係、アリバイ、手がかり、役割反応をそれぞれ独立したノードとして扱う方式です。私はこの構造が重要だと思っています。ミステリーでは格好いい文章よりも、まず 論理的一貫性 が先に来るべきだからです。

リアルタイム対話の側にも、すでに骨格があります。ゲームセッションチャットAPIにはキャラクターとの会話、SSEストリーミング応答、AI補助者チャットが入り、すべての会話は尋問履歴に保存されます。つまり、AIが答えを投げるだけの構造ではなく、セッションの中の記憶 として蓄積されるよう設計されています。この領域は、今後AI依存度が最も速く高まりそうな部分です。

MMORPGを最後の挑戦として見る理由#

MMORPGは、私にとって技術的な好奇心だけでなく、個人的な郷愁ともつながっています。昔長く遊んだリネージュのような感覚を、今の道具と構造でどこまで作り直せるのか試してみたかったのです。うまくいって商用化まで届けば理想ですが、その前にもっと重要なのは、これほど重いジャンルを今の開発方法でどこまで押し切れるのか という問いです。

また、MMORPG実装でも、ここまでに触れた仕組みを世界観、ストーリー、NPC設定などへ応用できる部分はかなり多いと思っています。

MMORPGは本当に実装できるのか#

驚くことに、現在の mmorpg-service も、すでに仕様ベースでかなりの量のコードが出ています。いまのコーディングエージェントの水準は、想像以上だと言ってよいと思います。ほんの数回のプロンプトで、リアルタイムMMORPGのクライアントとサーバーの両方が生成されてしまうからです。

ゲーム自体は、私がよく遊んでいたリネージュに近い形で実装する予定です。サーバー側には、Nettyベースのゲートウェイ、セッションマネージャー、Redisセッション同期、重複接続処理、ワールドとゾーン生成、ティックスケジューラ、マップとパスファインディング、AOI同期、戦闘ブロードキャスト、インベントリとショップ、ドロップとスポーンの流れがすでに実装され、別サービスとしてデプロイされています。

ランタイム側を見ると、GameWorld が複数の Zone を管理し、セッションとワールドのインデックスを分けてプレイヤーを紐づけます。モンスターは単なるスポーンオブジェクトではなく、IDLE, PATROL, CHASE, ATTACK, RETURN, DEAD といったFSM状態を持つランタイムエンティティとして管理されます。トリガーシステムは、罠ダメージ、呪文、台詞、チャットのようなワールド反応を直接実行します。そこにワールド時間と天候を別管理する WorldContinuum まで付いています。

はしごを作ろう#

ストーリークイズは、低い運用負荷で 作品出版 を試すジャンルです。ミステリーは、AIがプレイ体験の中に入る 役割ベース推理 を試すジャンルです。MMORPGは、最も重いリアルタイム世界で、今の開発方式がどこまで行けるかを試すジャンルです。

だからこの3つは別々のプロジェクトではなく、1本のはしごのようにつながっています。いちばん軽いジャンルでまず制作パイプラインと検収構造を整え、その次にAI相互作用の密度を高め、最後にリアルタイム世界まで登っていこうとしています。

結局、私が見たいのは単純です。AIのおかげでゲームをより速く作れるかではなく、AIをどこに置けば、人が最後まで責任を持てるゲームになるのか、ということです。Omniludeでゲームを作ることは、今の私にとってその問いを最も真剣に試す方法です。

おわりに#

これまでの投稿では、コーディングの変化やバックエンド構造について話してきました。今回の文章は、その構造の上で実際にどんなゲームを、どんな順番で作っていくのかに対する答えに近いものです。

次はこの中のどれか1つに絞って、ストーリークイズの出版パイプラインが実際にどう回っているのか、あるいはミステリーのAI尋問構造をどう設計しているのかを、もう少し具体的に掘り下げてみたいと思います。