世界で自分だけのポケモンの生成

概要

ゲームの途中で入力した六つの言葉から、AIが新種のポケモンを生成する。数分後、その新種は草むらに現れ、プレイヤーは出会い、捕まえ、ニックネームをつけられる。姿や名前だけでなく、タイプ、種族値、技、ゲーム内で扱うデータまでを、その場で組み立てる研究プロトタイプを制作した。

プロトタイプでは、会話、言葉の入力、バックグラウンドでの生成、野生での遭遇、捕獲、命名までを、ゲームを止めずに一つの体験としてつないだ。新種は、単なる画像ではなく、既存のゲームシステムが扱える種族として登録される。

この取り組みで中心に置いたのは、生成モデルそのものではない。ゲームバランスや見た目の整合性を守る条件を人間が設計し、その範囲だけをAIに探索させる「生成の枠組み」である。さらに、自分だけの生成物なら本当に愛着が生まれるのかを、自らプレイして予備的に検討した。

問い —— 唯一無二なら、愛着は生まれるか

ゲームには、キャラクターを選び、育て、名前をつけることで「自分だけの存在」にしていく楽しさがある。しかし、その出発点は開発者が用意した選択肢の中にある。生成AIによって、出発点そのものからプレイヤー固有の存在を作れたとき、愛着はさらに強くなるのだろうか。

この問いを確かめるには、画像を一枚生成するだけでは足りない。生成された存在がゲームの世界に入り、出会い、捕まえ、その後も使えることが必要になる。そこで、プレイヤーの関与が異なる二つの入口を用意した。おじいさんに話しかけると入力なしで生成され、おばあさんに話しかけるとプレイヤーが六つの言葉を選ぶ。最初に話しかけた側で、そのプレイの生成方法が決まる。

このプロトタイプの目的は、愛着について結論を出すことではない。生成物を通常のゲーム体験へ統合する基盤を作り、今後比較できる条件を見つけることにある。

プレイの流れ

以下は、プレイヤーが言葉を選ぶ「関与生成」の流れである。トウカの森でおばあさんに話しかけ、ゲームにもともとある「かんたんかいわ」で六つの言葉を選ぶ。遊びを続けているあいだに生成が進み、準備が整うと鳴き声が聞こえる。草むらへ入ると新種が現れ、通常の野生ポケモンと同じ操作で捕獲できる。名前、タイプ、種族値、技、正面・背面のバトルスプライト、手持ちアイコンは、実行ごとに生成される。一連の動作は デモ動画でも確認できる。

設計課題 —— 自由に生成すると、ゲームが壊れる

AIが新しいキャラクターを考えられることと、そのキャラクターがゲームの中で成立することは別の問題である。能力が高すぎれば難易度が崩れ、タイプと技が噛み合わなければ育てにくい。見た目が複雑すぎれば、64×64ピクセルのスプライトに変換したときに形を読み取れなくなる。

一方、すべてを固定してしまえば、実行するたびに異なるものが生まれる意味がない。必要なのは、AIの自由をなくすことではなく、遊びとして守るべき部分と、変化を許す部分を分けることだった。

そこで、デザインの対象を一匹のポケモンではなく、ポケモンを生成できる空間へ移した。人間が目的、制約、禁止事項、検証方法を定義し、AIはその内側で候補を具体化する。これは、私のデザイン哲学である制約型デザインを、動くプロトタイプとして試したものである。

アプローチ —— 生成物ではなく、生成条件をデザインする

LLMには自由文を書かせず、名前、タイプ、種族値、技、体型、色といった決められた項目だけを埋めさせる。出力はそのまま採用せず、バリデータで検査する。違反があれば、どの規則を破ったかをモデルへ返し、条件を満たすまで生成し直す。

1. 人間が境界を決める。 ゲームバランス、画面上で読める形、避けるべき表現を、検査可能な規則にする。
2. AIが候補を具体化する。 プレイヤーの言葉を手がかりに、許可された項目の値を提案する。
3. 機械が規則を検証する。 数値、技の組み合わせ、禁止表現などを、自動で判定する。
4. 違反だけをフィードバックする。 条件を満たさない候補は理由とともに差し戻し、再生成する。

遊びを守る制約。 種族値合計は280〜360の範囲とし、各能力にも上下限を置いた。技はゲームのソースから抽出し、その種族のタイプまたはノーマルタイプに絞る。さらに、一撃必殺、自爆、固定ダメージ、過度に強い技を除外し、攻撃技の数やタイプ一致技の有無も検査する。捕獲率や成長速度などは固定し、生成による違いが比較できる範囲に収まるようにした。

見た目を守る制約。 体型は小さなスプライトでも輪郭を保ちやすい候補から選び、色と特徴の語彙も限定した。人間的な特徴、流血、武器、文字などは除外する。最後に「一体だけ」「全身」「余分な手足を作らない」といった破綻防止の条件を、画像生成の指示へ必ず加える。

ある記録では、モデルが最初に種族値合計380の案を出した。枠組みは違反を検出して再生成を促し、最終的に320の仕様へ収束した。重要なのは、良い結果が偶然出ることではなく、枠から外れた結果を採用しない工程を設計したことである。

体験をゲームの内側で完結させる

プレイヤーが触れるのは、ゲーム内の会話、言葉の選択、草むらでの遭遇だけである。生成のために別の画面を開く必要はない。一方、計算量の大きい処理はPC上のPythonプロセスが担当し、ゲームとはファイルを介して連携する。mGBA上のLuaスクリプトが両者を橋渡しすることで、既存のゲームらしい操作感と外部AIの処理を分離した。

1. 仕様を作る。 ローカルの言語モデルが六つの言葉を、検証済みの種族データへ変換する。
2. 姿を作る。 画像モデルが参照イラストを描き、そこから正面、背面、手持ちアイコンを一貫した姿で生成する。
3. ゲーム用データへ変換する。 画像を15色に減色し、GBAが扱えるスプライトとパレットへ変換・圧縮する。
4. 実行中のゲームへ反映する。 予約しておいた領域へデータを書き込み、ゲームを再起動せずに新種を登場させる。

同じデータをディスクにも書くため、反映した種族はゲームを読み込み直しても残る。生成は一度きりで、取り消せない。遭遇から逃げたり負けたりした場合は世界に残るが、倒してしまえば二度と現れない。この不可逆性も、「世界に一匹だけ」という意味を体験に持たせるための設計である。

プロトタイプで確認できたこと

これは一人で制作した実現可能性の検証であり、完成したゲームやユーザー実験ではない。到達点と未検証の範囲を、次のように分けている。

• 動作を確認した範囲。 ゲーム内の会話、六つの言葉の入力、バックグラウンド生成、実行中のゲームへの反映、野生での遭遇、捕獲、ニックネーム入力までを、mGBA上で一気通貫に確認した。
• 比較のために実装したもの。 入力なしの「受動生成」と、言葉を選ぶ「関与生成」の二つの入口を用意し、会話や遭遇、捕獲などを記録できるようにした。
• 基盤はあるが、通しで未検証の範囲。 捕獲後のレベル上げ、技の習得、バトル、ボックスへの保存、セーブ後の継続利用は既存システムに接続しているが、長時間のプレイを通した検証は行っていない。
• 未実装の範囲。 進化先をその場で生成する機能と、複数の参加者による愛着の比較実験は、今後の課題として残した。

自分で試した結果 —— 唯一無二であるだけでは、愛着は生まれなかった

自分でプロトタイプをプレイした限りでは、生成されたポケモンへ強い愛着は生まれなかった。これは実装者本人一人の所感であり、一般化できる実験結果ではない。ただし、次に何を変えて比較すべきかを考える手がかりにはなった。

愛着を左右しそうな条件は、二つある。

• 生成物のクオリティ。 見た目や設定に魅力を感じられる水準を超えなければ、「世界に一匹だけ」という希少性だけでは愛着を支えられない。
• 関与の深さ。 六つの言葉を選ぶだけでは、結果を「自分で作った」より「届けられた」と感じた。関与感を生むのは入力の量ではなく、選び直す、比較する、手直しする、結果へ責任を持つといった制作過程の質だと考えられる。

対照になったのが、ゲーム用の自動生成とは別に、複数の生成AIとの対話と手作業を重ねて作った「ハナギツネ」である。候補を見比べ、直し、納得できる形まで作り込んだこのキャラクターには愛着がある。十分なクオリティと、試行錯誤を含む関与の両方があったためだと考えている。

このプロトタイプは、「生成コンテンツは愛着を生むか」という問いに答えたものではない。曖昧だった問いを、生成物のクオリティと関与の深さという、意図して変えられる二つの要素へ分けた。次の検証では、制作過程に選択、比較、修正を組み込み、生成物の品質を一定水準にそろえた上で、複数の参加者による比較が必要になる。

実装

生成パイプライン、制約と検証の枠組み、GBA向けのデータ変換、ゲーム側の変更内容は、GitHubリポジトリで公開している。