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

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

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

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

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

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

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

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

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


"システム要件"

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

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

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

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

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

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

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

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

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


"各種リソース数"

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

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

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


"ゲームデザイン"

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

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

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

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

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

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


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

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

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

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

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

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

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

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

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

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



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