Geminiでゲームバランスを分析する｜CSV・Python計算・実プレイの分け方

記録する値は、調整したい問いから選ぶ

最初の問いを「どのステージで急に難しくなるか」とするなら、ステージの識別子、クリアしたか、所要時間、試行回数が候補になります。入力の問題を調べるなら、操作方式や端末の区分も必要かもしれません。何でも記録するのではなく、今回の判断に必要な項目を決めます。個人を識別する情報は目的に必要かを別に考えましょう。

時間は単位をそろえます。秒とミリ秒を混ぜると、差を正しく読めません。失敗したプレイの時間をクリア時間へ混ぜるかどうかも決めます。途中でやめた記録、練習の記録、仕様が違う旧版の記録を区別します。データを集めてから曖昧な行をすべて削るのではなく、扱い方を記録します。

以下は制作中のローカル記録を想定した簡略な例です。公開ゲームの利用状況を集めるなら、記録の目的と保存先を別に設計します。本記事では実際のプレイヤーのデータを集計した結果を示していません。自分の作品で記録した値を、どのように分析へ渡すかという手順を説明しています。

version,stage,attempt,cleared,duration_seconds,input_type
1,stage-a,1,false,12,keyboard
1,stage-a,2,true,28,keyboard
1,stage-b,1,false,15,touch
// 例示用の数値。実測データではありません。

Python計算で確かめる対象を、先に指定する

Googleの公式資料で確認したGemini APIのcode executionは、Pythonコードを生成して実行する機能です。JavaScriptのコードを出力させても、その機能でブラウザの動作を試したことにはなりません。利用するモデルや入出力の条件は最新の資料を確認し、計算に使うデータと目的を明確にします。

依頼は「ステージごとの成功数と試行数を集計し、成功した行だけの所要時間の中央値を出す」のように具体化します。平均だけでは、極端に長い一件の影響を受けることがあります。どの行を対象にしたか、欠けた値をどう扱ったかも出力してもらいます。グラフがある場合も、集計表を一緒に確認しましょう。

時間のかかる全探索や大量の試行は、実行環境の制約を踏まえて分けます。公式資料には実行時間などの制約が記載されています。小さなデータで計算の内容を確かめ、必要なら手元の環境で同じ計算を実行できる形を残します。数字が返っただけで、想定する計算が行われたと判断しないようにします。

元の行と計算結果を照合する

AIが作った集計は、少数の行を手で計算して確認します。試行数が元の件数と合うか、成功した行だけを使ったか、失敗した時間が混ざっていないかを調べます。対象外の記録があるなら、何件を除いたかを確認します。グラフの見た目が自然でも、対象の選び方が違えば判断も変わります。

試行回数が少ないステージの割合は、参考にする範囲を狭くします。一回失敗した記録だけで、全員にとって難しいとは言えません。パソコンとタッチ操作の違いも、操作した人やプレイ回数が違えば単純に比較できません。数値の差と、その差が生まれた条件を一緒に読みましょう。

GoogleのStructured outputsは、構造を指定して結果を受け取るための別の選択肢です。集計結果をゲームの管理画面へ渡すなら、項目を決めて検証する方法を検討できます。ただし、整ったJSONで返ることと、集計式や判断が正しいことは別です。元のデータとの照合を省く理由にはしません。

調整する値を一つ選び、実プレイへ戻る

数字を見て次の案を選ぶときは、敵の速さ、制限時間、障害物の数を同時に変えすぎないようにします。一つのステージで一つの値を変更し、どの版のデータかを記録します。クリア率だけでなく、失敗した理由が分かるか、再挑戦したくなるかを実際に触って確認します。遊びの目的に合う変化かが大切です。

成功率を上げることだけが、ゲームバランスの目標とは限りません。短い挑戦を繰り返す作品では、失敗後の待ち時間を減らす調整が効くかもしれません。考えるパズルなら、答えを簡単にする前に説明を見直す方法もあります。分析結果を結論として受け取らず、次に試す仮説を作る材料として使いましょう。

変更後は、以前と同じ種類の条件を含めて確認します。キーボードだけで見た調整をタッチでも試し、最初のプレイと再挑戦の両方を見ます。Pythonの集計では、音の開始、画面の重なり、指の操作感までは確かめられません。計算の確認とブラウザでの操作を分けて記録すると、次の改良につなげやすくなります。