シナリオ重視ゲームの一般的制作フロー
ゲームシナリオの制作プロセスを、企画から実装、演出の最終調整まで含む一連のフローとしてまとめました。
これは、オープンワールドゲームやRPG、アクションアドベンチャー、アドベンチャーゲームと言った私が関わってきたシナリオ制作で実際に使ってきた経験を元にしています。
要するにあくまでシナリオ重視の特にコンシューマーライクなゲーム制作のフローです。ソーシャルゲームなどには当てはまらないかもしれませんがあしからず。
また、基本的な企画内容にGOが出たあとのプロセスです。
これは、ゲーム開発に携わる方々の参考になることを目指したものです。以下、具体的なステップを順を追って詳しく解説していきます。
① プロット作成
概要:
プロットはシナリオの設計図であり、物語の全体像や主要なイベント、ゲーム要素の配置を示すものです。
この段階で企画と物語の「コンセプト」や「ログライン」、「主人公の葛藤」、「キャラクターアーク」などの物語の骨格がしっかりと形成されていることが重要です。
私の場合ここでチュートリアル、ボス敵やプレイアブル要素などもざっくりと決めてしまいます。ここではそれを行わず後述する「箱書き」で行う方もいるでしょう。
なお、ゲーム制作においてはプロットを作らずに物語を作る「パンツァー」タイプの書き方は私は明確にNGだと思っています。
チームでゲームを作る以上、物語の方向性もわからず、ビジョンも見えず、物量も見えないようでは制作進行に大きな影響を及ぼします。物語の方向性や面白さがわからなければモチベーションにも良い影響はありません。
「プロットを作らなくていい」「プロットがない方が自由な発想で書けるし、定型的にならない」というのは、物語作りだけに限って言えばある側面では妥当性はなくはないですが、ことゲーム作りにおいてその主張はプロットを作る実力が無いライターの「言い訳」であり「甘え」です。
詳細:
目的: ゲーム全体の方向性を定め、物語の流れや主要な要素を決定します。チーム全体に共有し、ビジョンと物量の認識を握りスケジュールと予算を見積もることも目的です。
作成方法:物語の進行とゲーム要素の配置を論理的に整理します。
プロットは構造や構成に重きを置くため、面白さが伝わりにくい場合がありますが、それはこの段階では問題ありません。経験上、プロットの段階で面白さがメンバー全員に伝わるのは難しいです。
演出もつかない、絵も付かない、音声もない、ゲーム性も体験できない段階の設計図なので、物語的な想像力が必要だったり、物語の面白さを「感覚」ではなく「論理」で理解する能力が必要なので。注意点: プロットだけでは物語の魅力が完全に伝わらないことが多いですが、脚本段階でその面白さが補強されます。プロットでの不自然な展開は、脚本での工夫や演出によって解決できることが多いです。ただ過度に不自然な場合は後々修正が困難になる可能性があるので注意が必要です。ですので、メンバーはこの段階で物語のドラマ性に面白さを実感しにくくても過度に焦る必要はありません。PやD、あるいはスペシャリストの間で面白さの合意が取れており、物語の「コンセプト」や「ビジョン」、「ログライン」にキャッチーさやパワフルさ、明確さがあれば大丈夫です。
ただ、プロットの段階で面白いと評判になることもあります。レアですが。
発注物に関して:
プロットの段階でデザイン制作物の大まかな量を見積もり、変更が少ないものを先行発注します。
主要キャラクター、主な背景、などのアセットはこの段階である程度発注が可能です。
確度の低いものは脚本の段階で変更になる可能性があるため、待ってもらいましょう。優先度を付けて発注することが肝心です。
キャラクターの性格がプロットだけでは固まりきらない場合があるため、後の段階で追加発注が必要になることがあります。
箱書きについて:
プロットの後に「箱書き」を作成する場合もあります。これはプロットをさらに細かく展開し、登場するロケーションやキャラクターの詳細が明確にわかるようにするものです。
箱書きは「セリフのない脚本」といえるほどに、細かくシーンを分解して書き込んだ資料です。あとはもうこのままセリフとト書きを起こせばシナリオになるくらい精密に作り込みます。
プレイアブルがどこであるか、どこでどんなキャラが出て、どんな伏線がどこで展開されるかなどが事細かに記載されています。
箱書きの作成はやったほうが理想ですが、実のところ「やらない」現場が多いという印象です。もうプロットの段階で脚本に入ってしまうことが多いです。
より、構成を練り込む時間があるならば箱書きを作るとより精度の高い構成と、発注ができます。
ただ箱書きを作成しても脚本段階での変更も多く入ります。箱書きを作るかどうかは、プロジェクトの性質に応じて柔軟に対応することが望ましいです。
② 脚本作成(日本語)
概要:
脚本は、セリフやト書きが記載された「完全なシナリオ」であり、クエスト設計やユーザーの行動フローもここで決定されます。
詳細:
目的:
キャラクターのセリフや物語の進行を具体化し、シナリオとしての完成度を高めます。作成方法:
この段階で柱、ト書き、ゲーム上の指示、台詞などを作り込んでいきます。
この段階では読んで「あまり面白くない」場合はちょっと注意です。演出が付くことで面白さは2倍以上になると経験上感じています。
ただ、チームメンバーがみんな首をひねっているようでしたらちょっと冷静になって独りよがりなシナリオになっていないか見直してみてください。
外部ライターを使う場合、脚本は外部ライターの方に書いてもらい、ゲーム的な落とし込みは内部のシナリオディレクターやプランナーがやるというパターンもあります。この調整によってドラマ性や構成が大きく変わることもあるので、チーム内部にもシナリオに対する経験や知識、実績のある人間がいることが望ましいです。
ただし、物語は誰でも書けるものなので「わしでもできるわ、がはは!」と経験も知識もないのに甘く見て、「やれる」と判断しない方が良いです。シナリオは誰でも書けますが、面白いシナリオは誰にでも書けるわけではありません。
参考記事
外部ライターの方に書いてもらう場合、「内部で調整が入る可能性がある」ことはちゃんと伝えておきましょう。ライターもプライドを賭けて面白くするべく書いてくれているのでそういった合意が事前に無いと関係性が悪くなる可能性がありますし、ライターへの配慮は必要です。
注意点:
基本的なフォーマットをスクリプターやプログラマとすりあわせておきましょう。脚本はゲームエンジンに流し込んでいくことになりますが、フォーマットがすりあわせできていないと、手打ちでエンジンに取り込んだりする羽目になったり……あとが大変です。
誰にも相談せず自由に書いちゃ駄目です。脚本の段階で物語の面白さが完全に伝わらない場合もありますが、ゲームプレイやビジュアル演出が加わることで大きく変化することがあります。この段階での評価が低くても過度に不安を感じる必要はありません。ここでは独りよがりなシナリオになっていないかをよく確認しましょう。シナリオはしばしば独りよがりになりがちです。ライターの中でドラマが成り立っていても効果的にそれが脚本になっていなければ伝わりません。自分だけが面白いシナリオはただの自己満足なのです。シナリオに対する批判というものはしばしばシナリオそのものへの批判ではなく「自分の人格への攻撃だ」と錯覚してしまうことがあります。故に外部の意見に耳を閉ざしてしまいたくなりがちです。ですが、自分だけ面白いと感じるシナリオは自慰行為のようなものです。そういうのはチームではなく一人でやったほうが賢明でしょう。
ですがゲーム開発現場では何故かこの現象がしばしば発生します。内部のライターでシナリオに関して専門的な訓練を積まないままある程度の成功をしてしまい地位が築かれてしまうと、この現象に陥ってしまいがちです。開発現場の色々な人が「あれ、やばいよね」とシナリオについてこっそりと文句を言っているのにそのままリリースされ酷評されてしまうといった現象がしばしば起こります。こういった場合は、優秀な外部ライターを雇うなどを検討した方が良いかもしれません。
外部のライターの場合は、内部によるチェックは反証が入るので起こりにくいです。
シナリオへの意見や批判について:
脚本になると骨組みだったプロットに肉が付いて、面白さが伝わるようになってきます。
その一方で、脚本として完成度が高くても演出などのない脚本段階では、それでも「その面白さが伝わらない」ことはやはりあります。
こういった場合、ライターは開発内外から様々な意見、時には厳しい批判を受けることがあります。シナリオは意見を言いにくい側面と、誰でも意見を言いやすい側面を両方備えているのです。
しかし、自分自身脚本の完成度をの高さを客観的に感じており、なおかつディレクターともども確信を持てているにも関わらず批判が入る場合は注意深く対処していく必要があります。
意見に流されすぎないようにしよう。
客観的になり冷静になり、シナリオを見て「面白さ」の確信が持てるなら、柔軟になりつつも揺らがない自信と胆力も必要です。
ただしこれは「感情的」な判断ではいけません。理屈としてちゃんと面白さが伝わる確信が持てるかどうかが肝心です。
ただし頑固にならずちゃんとまっすぐ受け止めよう
一方で、何らかの要因で面白さが伝わっていないならばその原因を究明することも重要です。そして意見を言ってくれる人には感謝も必要です。
どうしても不安になる場合は、外部のライターやスクリプトドクターなど第三者の意見を仰ぐこともできますが、そういう場合は忖度せずハッキリと言ってくれる関係性や契約を結ぶことも重要です。
意見を言ってくれる人への感謝も忘れずに
意見をもらえるというのは基本的にありがたいことです。「言い方」の善し悪しはあるものの、それを「自分の人格への攻撃」だと捉えず、あくまで「作品そのものへの意見」として受け止め、作品をブラッシュアップするための試金石にしましょう。
発注物に関して:
プロット段階での発注物に加え、脚本段階で新たに必要なデザイン制作物が発生することが多いため、柔軟に対応します。
③ ゲームへの実装
概要:
脚本をもとに、ゲームエンジンに実装して、ゲームの進行フローを確認します。
詳細:
目的: ゲーム内での会話シーン、バトルシーンなどの進行を確認し、シナリオが意図通りに展開されることを目指します。
実装方法: まずはゲーム全体の流れを確認するため、演出の実装はこの段階では不要です。バグチェックや進行フローの検証が主な目的です。
この段階でシナリオを実装する上で必要になる機能などをスクリプターや企画に洗い出してもらいエンジニアなどに発注します。注意点: 実装段階で、脚本で想定されていなかった問題(例:「この流れだと実装が難しい」など)が発生することが多いため、レベルデザイナー的な視点を持つ人材の関与が必要です。また、そのことによってシナリオの調整が必要になることも多々あります。あくまで「ゲーム」ですので、「理想的なゲームデザイン」になるような調整は往々にしてありますし、やるべきです。
発注物に関して:
この段階で実装が始まるため、背景やモデルが必要になります。
ただし、完成されたアセットである必要はありません。仮モデルやダミーモデルでOKです。ただ、アセットのIDは本番同様にしておくなど、本実装の際に正式なモデルと簡単に差し替えられるよう準備が必要です。
④ 演出実装
概要:
演出を加え、ゲームの魅力を最大限に引き出す段階です。ここでゲームの面白さが具体的に体感できるようになります。
詳細:
目的: 演出を追加し、ゲーム内のシーンが意図通りに面白く感じられるようにする。
実装方法: 全ての演出を一度に実装するのではなく、章ごとに分けて効率的に進めます。カットシーンの外部委託も検討します。
カットシーンを作る場合は、各シーンでキャラクターがどう動くかを示す「演技プラン」または「キャラクター導線図」を作ることも多いです。どの場面に誰がいてどんなアセットがあって、どう動くかを指示する資料です。これがないとモーキャプ現場でアクターに正しい指示ができません。ぐだぐだになります。
用語の説明
演技プラン: シーンごとにキャラクターの動きや演技内容を詳細に計画した資料。主にアニメーションやモーションキャプチャーの現場で使用されます。
キャラクター動線図: キャラクターの動きの軌跡や配置を示した図で、どのように動くかを視覚的に確認するための資料。
モーションプラン: モーションキャプチャーを行う前に、キャラクターの動きの全体的な計画を立てるための資料。特にモーションキャプチャーのシーンでの利用が多いです。
発注物に関して:
この段階ではキャラクターイメージのわかるモデルや背景が必要になることが多いです。絵が無いと演出家が具体的な演出を想像しにくいためです。演出の進行に支障がないようにします。
ただし製品版相当のアセットである必要はありません。だいたい演出を付ける段階で製品版相当のアセットをそろえるのは難しいです。間に合わないです。
⑤ キャラクターデザイン発注
順番前後しますが……プロットおよび脚本の内容をもとに、必要な情報を資料化してデザイナーに発注します。
ラフを描いてもらい、そこからすりあわせて方向性を固めていきます。
ゲーム制作で面白いのはキャラクタービジュアルが入ることで物語がブラッシュアップにつながることがあるということです。ビジュアルがあることで、キャラクターが具体的にイメージされ生き生きと動き出すことが多々あります。ですので、キャラクターデザインなどはプロットの段階で発注し早い段階でこういった「創発的な効果」が生まれるような体制を築くと良いでしょう。
モブキャラなどの発注漏れが発生しやすいため、バッファを設けてコストを見積もることも大事です。
⑥ キャラモデル発注
キャラデザインが完成した段階で、モデル制作の発注を行います。
⑦ 背景発注
背景に加え、小物やオブジェクトの発注も含まれます。詳細な洗い出しは脚本が完成してからになります。
⑧ モーション発注
モーションキャプチャーが多用される場合は、演出リーダーがディレクションを担当するのが望ましいです。
モーションキャプチャーにおいては、接触やアクションなどモーションコストの増大の直結する要素がありますので専門的な観点からのディレクションが必要です。
⑨ BGM発注
脚本の完成後に急いで発注することが多いですが、プロットの段階で必要なBGMをリストアップし、事前に発注準備を進めることが効果的です。
⑩ 音声収録
概要:
ゲーム内で使用されるすべてのボイスを収録します。
詳細:
目的: 音声収録用の台本を準備し、効率的に収録を進める。
注意点: 脚本を作り際に、「台本をどうするのか?」まで話し合いましょう。音声収録の現場では「縦書きの台本」の提出を求められることが多いです。ですがゲーム制作で使っているゲームシナリオはこの形式になっていません。すると、縦書きフォーマットに落とし込む必要がでてきます。しかしゲームシナリオというのは膨大で、これを手作業でやると大変なことになります。
ですので、脚本のフォーマットを作る段階で自動的に縦書きのフォーマットに落とし込めるようすりあわせておくと後々地獄を見ずに済みます。
台本制作の自動化ツールを活用し、収録時の効率を向上させることが重要です。また音声収録のタイミングは後述する⑪の理由から「2回」あることが望ましいです。初稿で収録し、調整後に台詞の修正があった段階でもう1回収録を行うのです。ただし、予算のないタイトルだとこれが厳しいため、「音声のない台詞」で対応出来るような仕様を想定しておくことも有効です。
⑪ ユーザー行動の調整
ゲームを実際にプレイし、ユーザーが迷わずに進行できるように調整します。
割とこの段階でシナリオの調整が入ることも多いです。
ヒントが足りなかったり、次にどこ行って良いかわからなかったり、ボス敵が追加されたり……
なので、音声収録をもう一度行う必要が出てきたりもします。お金がかかる。
⑫ 誤字脱字チェック
誤字脱字は製品版に残らないよう、早期にチェックして修正する体制を整えます。
現場で二重三重でチェックをかけても誤字脱字は残ってしまうので優秀なチェッカーはありがたい。
「おかしな日本語」「使い方の間違っている日本語」などもここでチェックしてもらいましょう。指摘されるのは恥ずかしいですし、指摘される側も「プライドを傷つけるのではないか」と心配もするでしょうが、構いやしません。ユーザーの前にさらされる方がライターとしてはダメージです。あまりに多いと、「まとめサイト」などに載せられてしまう例もあります。
⑬ ローカライズ
ローカライズに必要な対応を行い、リリーススケジュールに合わせて調整します。
ローカライズを発注するのはシナリオが完全にFIXした後が望ましいです。
ただしゲーム開発だとこれが難しい!なぜなら、ゲームの多くのフェーズで、修正や調整、リライトが発生するからです。
なのでローカライズも「2回」ある方が望ましいです。
脚本執筆と同時に同時ローカライズをするパターンもありますが、わりと現場は地獄になります。終わりのないリライト、修正箇所が管理しきれなくなりローカライズチームも混乱……いや、優秀なプロマネなどがいれば大丈夫かもしれませんがお勧めはしません。
⑭ テキストFIX
演出やユーザー行動の調整、誤字脱字チェックなどの修正を反映します。
⑮ エフェクト対応
カットシーンや演出に必要なエフェクト(爆発、炎など)の対応を行います。
⑯ バトル発注
概要:
バトル発注は、ゲームの戦闘シーンを魅力的に演出するための重要な工程で、シナリオとバトルデザインの緊密な連携が求められます。
詳細:
目的
バトルシーンを効果的に設計し、適切なタイミングで適切な敵キャラクターやシチュエーションを配置することで、プレイヤーに最適な戦闘体験を提供することを目指します。
発注内容: シナリオ側からバトルチームに、キャラクターの設定を伝えます。使う魔法や能力、武器、格闘技などのイメージがあれば伝えます。ただ相手もバトルのスペシャリストなので、相談しながらキャラクターを造形していくことが望ましいです。
シナリオだけが偉すぎるタイトルだと、シナリオ側が勝手に敵を決めて、バトルチームがボスの差別化やコンセプト設計に困るといことも多々あります。ゲーム作りはチーム戦です!シナリオ重視のゲームだとライターがえらくなりすぎてシナリオに対しては「さわるべからず」になることもありますが、駄目です。シナリオ調整: 上述するボスなどの作成と被るところはありますが、バトル担当者の要望に合わせてシナリオを柔軟に調整することも重要です。例えば、シナリオの進行に応じて敵キャラクターやボス戦の配置を見直し、バトルシーンがより自然に物語の中に溶け込むようにします。シナリオライターには、このような柔軟な対応力が求められます。
事前調整: プロット段階でバトル担当者とすり合わせを行い、物語の適切なタイミングで適切な敵が登場するように計画を立てることが重要です。これにより、物語と戦闘の一貫性が保たれ、プレイヤーの没入感が高まります。