以前書いた通り、それぞれ発注できる数は仕様(予算)で決まっています。が、CGの枚数は総数で数えていますので、この時点(発注前)であれば各枚数の微調整が可能です。イベント絵を減らして立ち絵を増やしたり、プロットから背景が想定以上に必要なことが判明して泣く泣くイベント絵を削って背景に回したり、なんて事も場合に寄ってはあります。企画の方向性を鑑みて判断します。フルプライス(小売り値8800円クラスのタイトル)だと、立ち絵とイベント絵合わせて80枚が下限の目安です。背景はそれらとは価格が違うので(つまり原画家に描かせるか否か)、枚数計算が微妙に違います。そしてBGMは、スタッフにBGMに対する思い入れがない限りは、もっとも圧迫される部分であったりもします。

ここの作業は、基本的にシナリオライターが行います。俺はそうでした。余所さんでは他の方がする事もあるかもしれませんが……複数人ですることもある工程です。主にキャラ毎サブライター制を取っている場合です。その場合は、各キャラの立ち絵とイベント絵の字コンテは、担当ライターが書くことになります。移動用背景やBGM発注でも、サブライターとして欲しい物がある時は、当然意見を伝えます。

実作業ですが、まず立ち絵の作業から入ります。エロゲ制作の中でもっとも時間が掛かるのが、グラフィックリソースの作成ですが、後々の動作チェックや体験版作成の事を考えると、基本的なパーツである、立ち絵と移動用背景がもっとも早い段階で欲しいグラフィックリソースだからです。なので、なるたけ短い期間で作ろうとすると、

立ち絵字コンテ　→　移動用背景字コンテ　→　イベント絵字コンテ　→　BGM発注書

の順で作ることになります。原画家が内部にいる場合、その絵を描き出すまでは差し替えができる、と思って"イベント絵字コンテ"の完成が最後になることもありますが。

"立ち絵字コンテ"
背景と組み合わせて使う、人物のみの絵を、文字で表現した物です。ポーズ、表情、服装について書きます。この時点ではキャラクターデザインが上がっていないことが多いので、原画家のイメージを狭めないよう、あまり細かくは書きません。また、様々な場面で使うことを想定して、特徴がありすぎる表情やポーズにはしないようにします。が、キャラクターの性格を考慮して、ポーズや表情の付け方(笑い方や怒り方には、キャラ性が表れます。口を押さえて笑うか、大口開けて笑うか、等)を考えつつはしますが、キャラデザの方には、そこを敢えて無視してキャラらしさを出して貰いたい……と思うのは我が儘でしょうか？

ちなみにここで、経験のない方にはわかりにくいかもしれませんが、「カット」という概念が出てきます。「カット」とは線画の数え方なのですが、同じ線画をベースにして少しの描き直しだけでできる線画は、ベースの線画と「同じカット」として扱います。"少しの"とは、"表情の違い"くらいです。そして「同じカット」のCGは一枚のCGとして扱いますので、表情が増えても予算に変化はなかったりします。……とは言っても作業量は増えるので、非常識な数の表情差分になると代金を請求されます(通常＋喜怒哀楽＋1,2くらいなら許されるかなぁ)。また、ポーズが変わったり、服装が違ったりすると、別カット扱いになります。これは線画の修正量よりも、着色の際の手間が多いためです。また時間差分(昼パターン、夜パターンとか)は、同カット扱いです。

字コンテの書き方も、上記のカット単位で書きます。カット毎に、ベース(の説明)＋差分(ベースとの違いの説明),差分(ベースとの違いの説明)...と書いていきます。立ち絵の場合は、ベースではポーズと表情、差分では表情、です。ポーズや服装が変わったら、別カットにして同じようにポーズと表情差分を書いていきます。

他のポーズや服装と同じ表情でも、最終的にCGにしてもらうなら、ちゃんと書きます。言ってみれば字コンテは、最終的なグラフィックリソースがどれくらいになるか？　の基礎資料だからです。グラフィックリソースの進行管理は、字コンテ(から割り出されたCG枚数)を元に行います。

ただし、時間帯毎に立ち絵のCGを用意する事がありますが(昼と夕方じゃ色合いが違うからー)、これを字コンテにすると、くだらないコピペをする羽目になりますから、別紙に「それぞれ昼・夕・夜の色パターンを作って」と書き添えて済ませます。それで済まない連中は勘弁です。大きいサイズや小さいサイズを作るときもそんな感じです。

あと、重要な事に"ファイル名"があります。同じファイル名のCGがあると困った事になりますので、重複しないように気をつけます。とは言っても、だいたい

立ち絵を示すコード　＋　キャラクターのコード　＋　服装のコード　＋　表情のコード

という文字列になりますが。これはファイル名の命名規則は仕様で決められているので(仕様の解説時には書きそびれた気がしますが)、それに従って機械的に命名します。その方が管理しやすいですから……って俺が理系畑だからですかね？

"イベント絵字コンテ"
立ち絵と同様にカット単位で書いていきます。表情は同じカット、ポーズや服装が変わったら、同じ構図,レイアウトでも別カットです。背景が異なる時も別カットです。強引にねじ込んで同カットにさせたことはありますが(苦笑。絵のサイズが立ち絵よりも大きいので、差分の数は立ち絵よりも厳しい扱いになります。最近のエロゲは、1カットにつき、2.3枚の差分は当たり前ですが、みんな頑張りすぎですよ……

エッチシーンで表示するイベント絵も、当たり前ですがここで指定します。つまり、エッチシーンの構成は、この時から想定します。そのヒロインにぴったりなエッチシーン、外せないお約束、どんな表情で感じるのか、フィニッシュの体位は……など、エロゲを作るうえでもっとも楽しい時間かもしれません(笑。

工程の概要でも書いたように、俺はシーンイメージよりも具体的な説明(構図,レイアウトや主要なオブジェクトの位置)を書くようにしています。本当はイメージだけ伝えて、原画家にふくらませて欲しいのですが、打ち合わせや伝達コストを考えると、どうしても具体的な説明の方が手間が掛からないからです。だから原画家さんのラフが、こちらの指定を無視したもので上がってくると、「わかってくれてるっ！」と嬉しくなります。

ちなみにイベント絵のうち、原画家は人物線画のみ描く場合が多いです。背景は別の人が描くので、背景についてもそれなりに書いておきます。移動用背景と共通な場合はそのことを付記し、そうでない場合はそうでない旨を書いたうえでどんな場所かを書きます。

"移動用背景字コンテ"
立ち絵と組み合わせて使用する背景CGの字コンテです。こちらも他と同様にカット単位で書きますが、キャラはいないので表情差分はありません。時間帯差分と、モブ(背景にいるキャラと無関係な人間たち)の有無のみです。モブがいる場合は、どんなモブかの説明も書きます。

"BGM発注書"
作曲担当者に、ゲーム中で使用するBGMがどのような曲であるかを伝える指示書です。企画のイメージ、そこから想起される音楽全体の雰囲気と、各楽曲についての説明があります。ボーカル曲がある場合も指定しておきます。

各楽曲には、ファイル名,楽曲の説明,使用意図,曲の長さ,などを説明として書きます。使用する楽器やテンポなど具体的に書くこともありますが、俺は音楽に詳しくないので、CGとは違って純粋にイメージでしか発注できません。ほんと、悔しいです。Keyさんのゲームとかやると絶望します……嫉妬します……

ボーカル曲は、フルコーラスとは別にショートバージョンも同時に作ってもらいます。発注書には別ファイルとして書いておきます。もっとも、ゲームに収録されるのはショートバージョンのみの場合が多いですが。これ、ショートしか作ってもらわなかった場合、安くなるんですかね……

以上、それぞれについて上長(まあディレクターだ)のOKが出れば、完成です。で、最後に"絵コンテ"について。

"絵コンテ"は、原画作業に入る前に、字コンテの情報を具体的に"絵(ラフ)"にした物を作る作業です。絵コンテの絵を描く人と原画家が同じ場合、絵コンテ作業をしない場合もあり、絵コンテと偽ってラフを描く事もありますが、違う人の場合、絵コンテ作家と字コンテ作成者が打ち合わせを行い、イメージを伝えたうえでレイアウト絵を描きます。

これは、立ち絵,イベント絵,移動用背景のいずれにも行いますが、また、イベント絵のみに行うこともあります。なんと言いますか、俺自身も色んなパターンを経験したので、一概には言いづらいです。

人物のポーズと表情、構図とオブジェクトのレイアウトがイメージできる程度の、本当にラフい絵を描きます。まれに具体的に(漫画の1コマくらいに)描き込まれた絵が来る時もあります。差分については、ベースと異なる部分だけ描きます。上がった絵について字コンテ作成者が確認をし、問題なければ納品、あった場合はリテイクし、問題なくなるまで詰めていきます。納品された絵を字コンテに貼り付ければ、絵コンテの完成です。ちなみに字コンテも絵コンテも、最終的にはexcelファイルとかになります。自分用には印刷しますけど。

何のために絵コンテを作るのか？

難しい問題です。絵コンテがあろうとなかろうと、原画家は線画に入る前にラフを描きます。絵コンテがある場合は絵コンテに従って、ない場合は字コンテ作成者と打ち合わせたうえでラフを描きます。原画家は絵コンテがあった方が楽だと言いますが、工程は増えていますので、絵コンテによって原画家のラフ起こしの時間が十分に縮小されていなければ、絵コンテの意味はどれほどあるのか……。絵コンテの過程で字コンテのミスが発見されることもありますが、そんなクロスチェック的な機能で良いのか？　字コンテ作成者と原画家の距離が十分に近ければ、絵コンテは必要ないのではないか？　思うことは色々ありますが、サンプリングが少ないので判断できません。俺は外注の原画家との仕事が多かったので、基本、絵コンテを作っていました。

と、今回はここまで。

2008-04-06

エロゲを技術論的に共有する　続の三　『プロット作成』

雑談エロゲ

今回は"2.プロット作成"についてです。

エロゲのプロットとは、ゲーム中に出てくる(システムメッセージ以外の)全てのテキストについて、その概要を記した物です。ゲームのジャンルによって書式や必要な要素も違ってくると思いますが、ここではADVのプロットについて書こうと思います。エロゲはADVが多いですし、他のジャンルにしてもADVな流れの上に乗っていることがやはり多いから……と、俺の経験的な問題で。

ADVの場合、ゲーム中のほぼ全てのイベント(ゲーム内で起きるあらゆる事象――ゲームエンジンの動作的な――を指します)はスクリプトに記述されるので、つまり、ゲームの動作のほぼ全てがシナリオに帰属することになり、結果、プロットにはゲームの開始から終了までのシークエンスが書かれます。これを業界的に(？)"箱書き"と言います。"プロット"の別表現でもありますが……。ただし、"箱書き"にはシーンの内容は書いておらず、そこにシーンがあることを示すだけです。

何のためにそのような物を作るのかと言うと、プロット作成を複数のシナリオライターで行うことがあるからです。攻略ヒロインが多かったり、人数をかけてでも制作期間を短縮したい時には良く行われます。この場合、メインのシナリオライター全体の構成を決め、箱書きを作り、個々のシーンは担当ライターが内容を書く、という体制になります。しかし他ライターが書いたプロットの中身を把握することが難しくなりますので、他ライターのシーンが別のライターのシーンの分岐の理由になったりなどの、複雑な分岐構造にはならないようにします。管理要素を増やしては「制作期間の圧縮」という目的の妨げになってしまいますから。

さて、実際の作業についてです。

現在のエロゲは、一つのスタートから複数のエンディングに分かれていく、フォーク型のシナリオ構造が主流ですが、この「あるプロローグから始まり、選択肢を選んでいくうちに特定のヒロインのエピローグに辿り着く」という形式を実現するために、まず、仕様書の各キャラのあらすじを整理して物語の転機となるシーンを割り出します。それらキャラ毎の重要なシーンは、順に一本道でユーザーに見せると酷く矛盾した物語になるものなので、特別の状況(ハーレム状態のような)を除いては、選択肢等を利用して一つの話の中では重複しないように配置します。イメージ的にはこんな感じです。

以上の大まかなシナリオ構造は、シナリオ全体の基本的な枠組みとなります。この枠組みの形には、ツリー型、ちょうちん型などいくつかあります(名称は俺流)。前述の図はツリー型のイメージです。この枠組みをさらに細かく、ゲーム中の実際のシーン単位まで書き込んだ物が"フローチャート"です。実物のフローチャートは図よりももっと入り組んでいますし、分岐管理フラグが設定してあり、そのフラグによる分岐もありますけれど。

またプロットの方にも、それら同様の細かい指定を、シーン内容と共に書いていきます。プロットは、テキストを書くライターへの指示書、という性格が強くはありますが、その他にも分岐を管理するのに使ったり(分岐パターンが抜けてたりする場合もあるので)、テキスト作成の進捗管理にも使います(プロットのシーン数を元に進行度を把握する)。なので、シーン内容が書き込まれていない"箱書き"だけでも、プロジェクトの管理には重要です。そういう他人が読んでもストーリーが分からないプロットは「俺プロット」などと言ったりしますが。笑。

もっとも"箱書き"のみだと、次回に述べる予定の"3.字コンテ作成"の際に困る(必要な背景やイベント絵がわからなかったりして、汎用的な背景しか用意できなかったり、イベント絵が表示されるシーンが連続してしまったり、バランスの悪いことになったりする)ので、なるべくなら「誰が、どこで、どんなことを、したのか」くらいは欲しいところです。

作業としては以上なのですが、8000円とかの価格で売られるようなエロゲは、シーン数で2〜300シーンほどになり、プロットもプレーンテキストで200キロバイトくらいになったりします。200キロバイトというのは400字詰め原稿用紙で400枚くらいなので、結構な量ですからそこまで時間を掛けられない時は、やはり"箱書き"だけで済ませます。最低でも"箱書き"は用意すべきです。それすらないと、シナリオ作成の進行度すら計れず管理もままならず、締め切りに間に合わなくなったり……。

最後に書式的なことを。プロットの各シーンには、"ファイル名""そのシーンに登場するキャラクター""シーンの時間帯""シーンの場所""シーンの概要"という基本情報と、シーンの具体的な内容、次に行くべきファイル名を書きます。あくまで俺はこの書式だったという程度の意味ですが、参考になれば良いのですが。

プロットの項はこれで終わりですが、「シナリオの構成法」のような教則的なことを期待されていた方がいたら申し訳ありません。そういうアプローチは苦手なので……

2008-04-06

ひねもすのたりのたりかな

アイデアはサイコロの目に似ている。欲しい目が出るまで何度も振るのだ。ただし、サイコロを振れる時間は有限で、振れるサイコロの種類はその人の経験に依るのである。

2008-03-29

エロゲを技術論的に共有する　続の二

エロゲ雑談

ニュースサイトさんに取り上げられたようで、いつになくページビューが回っております。興味を惹いただけの甲斐がエントリにあれば良いのですが、今のところまだまだ共有どころこかただの工程説明になってしまっているのが心苦しい限りです。が、今しばらくは説明にお付き合いくださればと思います。説明の順番にはなんら意図がありませんので、「どれそれから説明して欲しい！」というご意見があれば承ります。質問なども受け付けようと思いますが……トラバなりなんなり送っていただければ対応する感じで。

さて前回、「次からは具体的な作業について書きたい」と書きましたが、その前に各工程の分業体制・作業順を整理すべきと思いましたので、まずはそっちを書こうと思います。

こちらの図を見てください。

いい加減な図で申し訳ありませんが、作業の流れを図式化したものです。横に並んでいる物は、同時並行に作業をしている工程です。各工程の縦の長さは、工程の作業時間を意図していますが、図式化のためにかなり抽象化しています(工程が並行していることを示すため)ので、実際の作業時間とは異なっていることに注意してください。また色分けは、タスクを主にこなす役職で分けています。つまり、

グリーン……ディレクター、プログラマ
オレンジ……シナリオライター、メッセージライター
ブルー……原画家、グラフィッカー
イエロー……サウンドクリエーター
レッド……音声ディレクター、レコーディングエンジニア、声優

という感じです。プロジェクト運営のためには他にも色んな役職が存在しますが、ここでは、その辺りを全部"ディレクター"に背負って貰っています。

5のリソース作製が、複数の作業を含んでしまっているためにいびつになっていますが、この図から複数の作業が並行して行われていることが分かっていただけると思います。さらに言えば、クリティカルパスの存在も想像できますが……工程管理や開発の手法については、この一連のエントリの最終的な結論として語れればいい、という感じで今は無視します。というか、そういう物をみんなで見つけていけたらいいね、が目的なのですが。笑。

流れを理解していただいたところで本題に入りましょう。今回は"仕様の決定"についてです。
この工程に関わるスタッフは、ディレクター、プログラマ、シナリオライタ−、企画者、です。企画者は、今までの議論に出てこないスタッフですが、大抵はディレクターかシナリオライターです。たまに原画家である場合もあります。プロジェクトの発案者なので、仕様策定に関わらないことはまずありません。
ここでの作業内容は、

キャラクター設定
世界観設定
物語のあらすじ
システム要件
各種リソース数
ゲームデザイン

を決めることだと書きました。では、それぞれの作業について述べようと思います。

"システム要件"

今から作ろうとするゲームの完成に何が必要か？　を詰めていく作業です。それらはADVなのかSLGなのかRPGなのかPZLなのかで変わりますが、

ユーザーが見るもの、聞くもの
ユーザーが操作すること
ゲームエンジンの挙動

を想定しつつ考えます。具体的には、画面解像度、インターフェース、コンフィグ、画面エフェクト及びスクリプト命令、が挙げられます。ADV以外であれば、戦闘やパズルの部分などの設計も考えます。

ここで言うインターフェースとは、マウスやキーボードといった入力デバイスへの対応から、ノベル形式かメッセージフレーム形式かという選択まで、広い範囲を示します。入力デバイスへの対応はユーザーのプレイアビリティ(遊びやすさ)に密接に関係しますが、直感的にはセーブやロードの面倒さと考えると、想像しやすいかもしれません。特にセーブとロードは「２操作で可能にすべし」と俺は言っています。笑。３操作になるとユーザーからの「面倒だ」という意見が目立つからです。他には読み返し機能の使い方、音声のリピートやスキップ機能、一行文字数＆一画面行数やメッセージフレームの消し方、等々の具体的な動作を決めます。「このボタン(画面に表示されたボタンを模したCG部分)をマウスクリックすると、セーブ画面がモニタに表示される」という具合に。

またノベル形式(画面全体にテキストが表示される形式)かメッセージフレーム形式(画面の一部にテキストが表示される形式)かで、必要なインターフェースの要素も変わります。ノベル形式ならば、CGの上にに何％の透過率でテキストを重ねるのか、セーブやロードといったコンフィグ操作はどうするのか、を考えますし、メッセージフレーム形式であれば、コンフィグ操作用のボタンをいくつ、どのように配置するのか、を考えます。選択肢を使うなら、選択肢をどう表示するかも(メッセージウィンドウ内に収めてしまうか、別フレームを用意するか、はたまたコマンド選択式ADVのような外枠を用意するかもしれない)。

この辺りのことは、ディレクターやプログラマが決定する範囲なので、俺では詳しく書きにくいのと、細かくするともの凄いことになりそうなので「ユーザーが遊びやすくするために、どんな機能を付けて、どう制御するのかを決める」と、抽象化しておきます。ADVなエロゲの場合、基本スタイルが確立されているので既存タイトルを踏襲することが多いです。だからといって手を抜くと「クソシステム。藁」となじられますので要注意。

画面エフェクトとスクリプト命令は、画面に表示されるCGに対してどのような加工をするか？　とそれを実行するための命令の書式を決めます。プログラマとスクリプターが相談し、互いにやりやすい書式にします。やってみたい画面エフェクトがある場合も相談します。エフェクト関係は、CGに対するものに限らず、ゲームエンジンに依存する部分が多いのでそれに詳しいスタッフが必要となります。そのようなスタッフがいない場合は、把握できる範囲のことしか出来なくなります。シナリオライターにとっては、どのようなエフェクトが使えるかが、テキストの書き方に多少影響を及ぼすので、以後の作業に入る前に把握できるとありがたい要素です。

地味に供給メディアの選択も重要です。最近はDVDに移行していますが、ゲームの容量が4.7GBを超えて良いかどうかは主に音声に関して問題となってきます。インストールされたエロゲのフォルダを覗いてみるとわかりますが、実は音声はグラフィックに次いで(時にはそれを超えて)大きなファイルだからです。細かくは音声関係の際に述べます。

これら"システム要件"は、最初に決めなければならない事柄でありつつも、リソースを作るスタッフの多くには無関係だったりするので、解像度や形式、スクリプトに関わること以外は、開発のうしろの方まで未決定で引きずられることもあります。

"各種リソース数"

CG数、BGM数、SE数、テキストサイズ、を決めます。多分に与えられた予算に依存するところであり、企画立案時に想定していることであり、「このくらいの規模のエロゲにしますよー」という意思表示ですので、ここではほとんど弄りようがありません。

CG数は、イベント絵の数、立ち絵の数、背景(立ち絵表示時に使うもの)の数、を決めますが、他にも、アイキャッチや日付変更処理用などの特殊用途のものがある場合は、ちゃんとカウントしておかないと後で困る場合があります。メッセージフレームやコンフィグ画面に、それ用のCGを使うなら、それも勘案しておきます。

BGM(ボーカル曲含む)数もやはり予算に依存しますが、SEは、過去作で使ったSE(SEは、サウンドクリエイターから使用権ごと買い取る場合が多い)やフリーの音源をライブラリ化していることもあるので、予算に依存しない場合もあります。

"ゲームデザイン"

企画によって千差万別であり、俺では多くを語れません。ただADVの場合、ゲームの初回起動時からゲーム終了(いわゆるコンプリートという表現でも可)までの、ユーザーにさせることを考えることがあります。ループシナリオだったり、あるルートをクリアしないと開かないルートがあったり、ADAMSだったり、マルチサイトシステムだったり、です。そういう企画固有のアイデアが盛り込まれる場合は、その具体的な動作を考えねばなりません。

ループや鍵付きルート程度であれば、シナリオライターがプロット作成時にコントロールすれば良いですが、ADAMSなどになるとプログラマとの話し合いが必要になります。RPGやSLGは無論ですし、障害としてミニゲームを入れる場合にも、です。

いずれにせよ重要なのは、

入力待ち　→　ユーザーの入力　→　入力に対する内部処理　→　処理結果の表示　→　入力待ち

というサイクルを意識し、それぞれで起きる出来事を過不足なく書き出しておくことです。フローチャートを作ると良いでしょう。さらに言えば「それは本当に面白いのか？」と自分に問いかけることも。

アイデア自体は企画者が思いついたものだと思いますが、実装を行うのは、該当するリソースを作るスタッフです。アイデアマンと実装者が異なる場合は、本当によく話し合って決めるべきです。アイデア投げっぱなしは、互いの不満を増大させる結果になりかねません。

"キャラクター設定"、"世界観設定"、"物語のあらすじ"

この三つは、俺的に不可分だと考えているので、まとめて書きます。特にエロゲの場合は、企画の根幹を成す重要な作業となります。基本的には、企画書(に書かれた様々な情報。主に企画意図とテーマを重要視する)を読んだシナリオライターが、叩き台を作り、プロデューサー、ディレクター、時には他のライターなどを交えた会議を行い、決定稿が出るまで修正し、作り込んでいきます。シナリオライターが複数参加している場合(メインライター、サブライターなどと呼んだりも)、キャラ毎の担当ライターを設定し、それぞれが叩き台を作ることもあります。

ここで決められたことは、キャラクターデザインや各種デザインに決定的な影響を及ぼすので、非常に重要です。また制作の各工程において常に参照されることを考慮して、読みやすくまとめた書き方を心がけます。広報・営業資料として使われ、そのまま外部の人に読まれる場合もあります。特にデザインスタッフには確実に読まれますので、凝った言い回しはせず、意図が正確に伝わるようにします。しかし敢えて曖昧に書くことで、読み手の解釈による広がりを期待することも……ありますかね？　そういうのもありですかね？

まとめて書いているように、実作業としてもキャラ・世界観・物語は並行して作ります。企画意図によって重点は異なりますが(キャラの魅力を前面に立てた企画もあれば、世界観や物語・ゲームデザインを前面に立てる企画もあります)、立てる部分がより引き立つように他の要素を構築する必要があるからです。エロゲ、特に純愛ドラマ系のものは、キャラを最前面に立てつつ、世界観として特殊な状況をわずかに込めることが多いです。それがキャラをよりよく引き立てるからですが。

また、作るときはまとめて作りはしますが、先にライター毎に分担することもあると書いたように、決定の判断は、各キャラ、世界観、物語、それぞれになされます。ヒロインＡのキャラはＯＫだけどＢは駄目、さらにはＡのキャラは良いけど物語は駄目、物語はいいけど世界観が微妙、とかな状況が発生します。そのため、Ａのキャラと物語に依存した世界観設定にしてしまったため、他ヒロインが世界観に依らない物語になったりもします。メインヒロインとは別にトゥルーヒロインが生まれるのはこのせい……だとは限りません(とお茶を濁しておきます)。企画の意図に、強力に全体を統一しようとする意思――例えばミステリ系やループ系で、全シナリオを読み解くことで全体像が見えてくるようにするのが目的の企画――がない場合、全体の方向性はシナリオライター(叩き台を中心に作るスタッフ)に一任されます。

なので各設定の決定稿が出た後でも、企画意図とキャラ配置のバランスを考えて微調整します。どう考えるかは、世にある様々な(シナリオやキャラクターに関する)教則本に詳しいと思うのでここでは述べません。あるいは各工程の解説が終わったあとで。

そうやって出来上がった各設定は、

キャラ設定……各キャラにつきA4で1〜2枚
世界観設定……現代を舞台にした学園モノなら、せいぜいA4で2枚
物語……各ヒロインにつきA4で、これもやっぱり2枚

くらいの資料となります。中身としては、シナリオライターが、テキスト完成までを想像するのに十分(とその時点で判断する)な物が詰め込まれます。キャラ設定であれば、年齢や性格、簡単な外見、趣味、好物などの個人情報に類するプロフィール、口調や他のキャラとの関係性です。出生から現在に至るまでの主な出来事まであれば、キャラをイメージするのに非常に役に立ちますが、そこまで作り込めるかは時間との戦いです。つまるところ、テキストの予定量と企画規模による、ということです。全体のテキスト量が1M程度の企画では、細かく設定したキャラを書き込める分量ではないため、設定に掛けた時間の分だけコストが無駄になるからです。……というか、ここで時間使った分、本テキストの執筆時間が減るんだから。予算はすでに決まってるんだからケツは変わんないのよ、ケツは。あとね、結局テキストを書いているうちにキャラや物語なんて、どんどん変わって行くもんなんだから。あきらめが肝心よ、あきらめが。

だからといって、設定を作った本人の頭の中にキャラ情報が残っている状態(資料が不足していたり、専門的知識・経験を要求しすぎる設定)は危険です。エロゲの面白さが、制作スタッフの属人的要素に依る部分が大きいのは確かですが、仕様の段階からそこに依存しているとプロジェクト破綻の遠因となりかねません。はじめに書いた通り、「誰にでも理解できること」が大切です。

以上、"仕様の決定"について長々と書いてきましたが、読み返す気にもならないくらい無駄なことを書いてますね……もっとまとまった内容を書ければ良かったのですが。次回以降はもうちょっと頑張りたいです。