ゲームの企画って… 令和版

数年前に公開したスライドの、AI登場以降のゲームプランナーのやることに関する覚書、展望です。
詳細は、プロジェクトごと、企業ごとなどで変わってくるので、大まかにはこのようなものではないか…という内容になっています。

Transcript

1. ゲームの企画って… 令和版 By 島西弘行
2. 趣旨 昔作成した、ゲーム企画（ビデオゲーム）の仕事に関しての資 料で、現代版を作って復習しておきたかった。 ついでに、やることが増加した上に、今後はAI関連の業務も入 り込んでくる展望があるので、そこも踏まえてこれからどうす べきか？ 個人でも、組織でも役立てる考え方を、最低限自分の中で改め ておきたい。 前回の資料：https://www.slideshare.net/slideshow/ss-22238533
3. 注意書き 本書自体も、いくつかAIを使ってます。 ※特に要素のリストアップなど… 最終的には自分で監修したものになっていますが、これもAIの 現場での使い方に近い形になっていくのかなと思っています。 また、正しいこと、正解を記載しているわけではないので、 そのあたりはご注意ください。 ※どちらかというと、正解を探すための資料の認識
4. 項目リスト • 企画の核 • 前回の復習 • 前回から今までの経験で増えた業務 • 過去のAI活用について • これからのAIについて • これからの「なにするの？」 • 著作権から見る分け方
5. 企画の核
6. 企画の核 まず、一応ゲーム企画の大まかな役割をリストアップ。 具体的な作業以前に、なぜプランナーがやるのかの大元として。 • ゲームの目的を定義する • プレイヤー体験を設計する • 問題を発見し、解決する • 価値を創造する • 意思決定の中心に立つ
7. 企画の核 実作業的な書き方では、役割次第ではあるけど、こうなっていく。 • 新規ゲームの企画 • 新規性の創造 • 体験設計 • 世界観の思想 • UI制約の決定 • ゲームループの核 • 方向性の決定 • プレイヤー心理の設計 • 最終判断
8. 前回の復習
9. 前回の復習 かつて、こういう図を作った https://www.slideshare.net/slideshow/ss-22238533
10. 前回の復習 こんな感じで分類していた。 結構、幅広くなるけど、小規模開発で あれば、これを一人でやることもあり うる…みたいな話で、普通一人でやら ない。 それはプログラマもビジュアルもサウ ンドも専門家がいるから同様。 おまけで57項目に及ぶ、ゲーム開発 の役割を一言でコメントしてまとめ ていた。 ※実際に57人必要というわけではな く、一人がいくつも兼任し、一つの 項目に複数人いるのが普通の開発
11. 前回から今までの経験で増えた業務
12. 前回から今までの経験で増えた業務 支払い機能のフロー ゲーム内で金銭のやり取りをする場合のフロー作成。どういうフロー であればお金・電子マネーを利用した後、通常フローを設定するか、 エラーフローを設定するか、またそれらの画面フローの作成。実装者 やそれらの機器に関する専門の人とのやり取りが重要。 別端末の連携仕様 実ゲームプレイの本体と、情報集積用のターミナル機の連携、それら ゲーム機とモバイルアプリとの連携をした仕様の作成もある。
13. 前回から今までの経験で増えた業務 ネットワーク機能 通信対戦など、ほかのユーザーとのつながりに関わる機能全体の仕様 に関して。ネットワークモードの開始、終了の流れ、エラー時の対応、 処理など。 ネットワークは領域的にシステム設計に入るが、一定程度の独立をさ せたほうが進めやすい。 ネットワークイベント運営 ネットワークの部分的派生。リリース後、時限開始～終了するイベン トの運営設計。ソーシャルゲームではもう当然に存在する要素。海外 向けではUTCベースでリアルタイムのものを考慮していく。 開催スケジュールも全部一人で決めることもある。
14. 前回から今までの経験で増えた業務 サーバー関連のゲーム仕様対応 ネットワークの派生。サーバーそのものの管理は専門が行っていたが、 専門の人とやり取りするための一定以上の理解と知識が必要になる。 何を更新するのか、何のデータが保存されて、何のデータが利用でき るのか、それを確認して、ゲーム側と合わせてネットワーク仕様を作 成する。 ボイス収録現場参加 シナリオの部分派生。自分自身では参加していないが、プランナーも ゲーム側の担当として、ボイス収録に立ち会う必要が出てくる。また、 そのための台本作成もプランナーの作業。
15. 前回から今までの経験で増えた業務 ローカライズ 翻訳そのもの…ではなく、ローカライズされたテキストとゲームをつ なぐ役割。テキストIDを用意して、IDごとにリージョン・言語で変更 される言語を設定する。翻訳依頼用の資料も用意する。 テキストウィンドウ次第で改行に関して各言語の考慮、禁則やノーブ レイクスペース、スペースや記号のルールなども影響する。 代入用テキストの表記指定なども考える部分が出てくる。 本来ならフォントなどのように、テキスト以外のローカライズ対応も あるが、それらは主にデザインと共有する。 また、チェック時や実機での設定方法の把握も必要になる。 領域的にシナリオに入るが、一定程度の独立をさせたほうが進めやす い。
16. 過去のAI活用について
17. 過去のAI活用について 〜2023のAI活用 ゲームデザイン部分以外は、補助的な内容が大部分。例えば… • NPCの行動 • テスト • リソース生成の補正 • 翻訳 • アイデア出し • 画像生成のラフ • コード補助
18. これからのAIについて
19. これからのAIについて 2024〜のAI活用 企画の“作業”を代替し、企画の“判断”を補強する存在。例えば… • 仕様書の自動生成 • シナリオの自動生成 • NPCの自動会話 • レベルの自動生成 • バランス調整の自動化 • QAの自動化 • 運営判断の自動化 • 著作権チェックの自動化 • チーム間の情報共有の自動化
20. これからのAIについて AIに任せる・任せないを決める 人間 ゲームの仕様に関するその「目的」 そのゲームの「新規性」 何を「体験」させるか ゲームのUI遷移の「構造」 ゲームに使用するデータの「意味」 リソースの作成の「方針」 AI ゲームの「目的」に沿った仕様書作成 ゲームの「新規性」を反映した仕様 「体験」のための要素の列挙 UI遷移の「構造」に沿った画面生成 ゲームの「意味」に沿ったデータ作成 ゲームの「方針」に基づいた各種生成
21. これからのAIについて AIの不得意分野も把握する 現在AIの不得手な分野を把握することで、滞りない業務とする。 • AIは目的を自分で作れない • AIは新規性を作れない • AIは体験を理解できない • AIは判断できない • AIは構造を自分で変えられない • AIは自律的に進化しない
22. これからのAIについて AIの失敗例も把握しておく 現在AI開発でよくある失敗をもとに、任せてはいけない部分の確認。 • AIに新規ゲーム案を作らせて劣化コピーになった • AIに仕様書を作らせて全部作り直しになった • AIにコード生成を任せてバグ地獄になった • AIにUI案を任せて使えないUIができた • AIにプロジェクト管理を任せて進行が破綻した
23. これからの「なにするの？」
24. これからの「なにするの？」 AI+プランナー業務 開発規模次第になるが、AIへの理解が必須になる。 小規模開発であれば、自分が直接AIを活用する。 大規模開発であれば、おそらく選任のAI技師のような役職（現代AI以 前のAIとはまた別）が用意されるので、彼らとのやり取りが可能にな るように、AIに任せる範囲や内容、用途を決める。 どちらにしても、AIに任せるための仕様書（もしくは違う形でも情報 の提供）は必要。 例えば、理想に近いプレイ動画やプロトタイプをAIで作成した場合は、 その作成の元となった情報がベースになると考えられる。
25. これからの「なにするの？」 AIに任せるまでのプランナーの業務 AIに任せるための、作業全体にまたがった細やかな資料作成と判断 • 根本的な仕様書概要書作成 • シナリオのプロット、方針、根幹部分のキャラクター設定 • NPCの配置基礎設定類 • レベルの方針決定 • バランス調整の方針決定 • QA用のチェック項目リストアップ • 運営判断の基準作り • 権利関係の基本的なチェック • 情報共有の整備 …etc
26. これからの「なにするの？」 簡単なフロー図 仕様目的 シナリオのプロット NPCの配置基礎設定 レベル生成の方針 運営判断の基準 情報共有の整備 …etc 仕様書 実装方針 シナリオライティング NPCの配置 レベル生成 運営処理設定 情報共有処理設定 …etc 実装 チェック シナリオ最終チェック NPCの配置チェック レベル最終チェック 運営処理チェック 情報共有 …etc
27. これからの「なにするの？」 まとめると 結局やるべきことは、核部分については今までとあまり変わらない。 いったん作業となる部分をAIに依頼できるかどうか？ これを自分で、もしくはAIのトップに確認してAIでやらせる部分の指 定（協議が必要なら協議）を行う。 そのために、何をどこまで作ればAI任せにできるかの線を見極める。 そのための自身のAIへの学習が必要になる。 これまでは、これはコマンドプロンプトでできないか、Excel関数で対 応できないか、マクロを使えないか…などの自動化を考えていたが、 そういう部分がAIに置き換わっていく（時にはその判断自体も）。
28. これからの「なにするの？」 補足 基本的には、周囲もプレイヤーもAIを使う場面も増えてくる。 初めから見越した対応は難しいものの、作業中にそういった場面も多 くなってくるのではないかと考えられる。 特に未発表作品の情報や個人情報など、機密とされる情報が入ったも のは、組織的にクラウドLLMによるAIの利用がNGになる場合が多いと 思われるため、それは利用時に確認できるようにしたい。 逆に、いざAIが使用不可の状況になった時でも、面倒な作業だけで済 むようにしたい。
29. 著作権から見る分け方
30. 著作権から見る分け方 ゲームは著作物になりうるので、必要な部分で著作権をもつ作りで考える 情報公開時やリリース時に著作物としてコンテンツを守ることを踏まえて、 AIに任せる部分を考える。 なぜ著作権を想定するのか？ １・ 他者の著作権を侵害している可能性があるため。 ２・ 他者がAI生成を用いて類似したものを作成した場合、情報公開した画像、動 画およびゲームの一部を、著作権を根拠として権利の主張が通らない可能 性があるため。
31. 著作権から見る分け方 著作権を「守る」側で考える 生成AIで作成した画像や動画は、生成時の指定が近いと同じような結果が出 やすい（基本的には統計結果からのベターを選ぶ形になるので、類似しや すい）。 リリースした情報やゲームが、我々の著作物であるという主張は、著作権 を所有する根拠がなければならない。それがないと、意に反した各著作物 の使用を止めることができない可能性が高い。 問題発生時は法務担当による対応となるが、それをできるだけ避けるため、 それら権利関係の問題点に関して一次チェック（最終判断は法務担当）と して最新の情報を確認し、不要な係争を避ける選択を行う。
32. 著作権から見る分け方 作成開始時から、どこをリリース側の著作物として守るか考慮することで、 自然にAIに任せる部分と、プランナーが取り仕切る部分を分けやすい。 AIに任せる範囲 著作権を主張する必要性の低い（要するに、リリース側にとって利用されても、 真似されても、あまり問題のない）要素に対しては、生成AIは有効に作用する と思われる。 この中には、フォントやエフェクト、SEも含まれうるが、これらのデータは案 外作風に影響があるため、本当にAIで対応していいのかどうかは判断する必要 がある。 また、翻訳についても、特に作品固有の固有名詞がある場合は、AIに完全に任 せるにはまだ時期尚早のため、見極めが肝心になる。大部分をAIが担うにして も、言語使用文化への理解の深い翻訳者が最終判断を下す必要はある（改行と かも含めて）。
33. 著作権から見る分け方 AIに任せた後の結果から逆算して、任せる範囲を考える。 部門があればその責任者に任せるし、責任者もどう任せるか考える必要も出る。 どの程度AIに任せるか 処理の内部がどうなっているか（サウンドの効果やモデリングのボーン、処理 のコードなど）、各種権利が通るのであれば、AIに任せる形になっていく。も ちろん、ミドルウェアで補足したり、微調整の部分も残っていく。 いずれにしても、作品の質を上げるためには何でもAIに任せるのではなく、ス ペシャリストの判断が必要になる。 ただゲームが作りたい、品質はもちろん、権利の主張はおろか、リリースしな くてもいい…そういうものであれば、練習と割り切ってバンバン使っていいと は思う（やった）。
34. おわりに
35. おわりに 結局なにすればいいんだよ！ • まずどんなAI活用してでもどんな小さなものでもいいので、何 らかの形でプレイできるゲームを一人で作る • 他人を混ぜてゲームを作る • 連携力、開発技術を手に入れてから、作りたいものおよびAIへ の移譲範囲を見極めていく • 繰り返して作る段階で必要なものを見極めていく 昔から言われてたことで、ゲーム開発ツールがAIに置き換わっただけでは …という気持ちもなくはない。
36. おわりに 個人的な感想として… • 結局今も昔も、「どんな形でもいいので」ひとまず一人でゲー ムを作れない人はあんまりプランナーには向かないと思う… • 逆に言えば、なんでもいいから作れた（そしてそのゲームで遊 んである程度満足できた）人は向いてると思う… • 一人で作っても作りたいものにならない場合に、複数開発、ま たは企業での開発に進むというのが健全かな… • というかほかのルートが未だにあまり想像できない… • あと、AIは一番やってほしいことこそ苦手だったりするような 気がしている…
37. では、新しいゲームで会いましょう！