ゲームシナリオ制作の最近のブログ記事

ゲームデータ制作の段取り 6

作成作業

仕様についてチェックする事が完了しますと、記入項目にそってデータを作っていきます。

データ作成に入りますと、ここからはスタッフのクリエイティブな能力を存分に発揮していくことになります。

ここでは決められたスケジュールないで満足のいくものが出来上がっていくように、下記のような事をチェックしながら作成作業を続けていきます。

また、一気に作成すると仕様の解釈に齟齬があった場合に膨大な修正がかかったりして大変なので、まずは少量のテストデータを作成し、問題が無い事を確認してから本格的な作業に入るほうが良いでしょう。

  • シナリオ仕様との妥当性
  • データ仕様との妥当性
  • クオリティチェック

シナリオ仕様との妥当性

  • シナリオ
  • キャラクター設定
  • 背景世界説明
  • アイテム設定
  • 用語指定
  • 表現規制

作成されたデータが上記の仕様にマッチしているかをチェックします。

データのチェックは必ず作成者以外の人が行います。

仕様にない記述があったり、仕様から外れるような記述があった場合は、ディレクターや担当者に確認をとり、修正するかそのまま行くかを判断します。

データ仕様との妥当性

データについてはゲームによって個別色々ありますが、これも必ず管理担当者がチェックを行うようにすべきです。

  • ユニークID
  • データのリレーション指定項目
  • 文字数
  • テキストコード
  • 改行コード
  • 挿入タグ・変数の仕様

また、作業者も管理担当者も、マクロやチェック用の簡単なプログラムを作る事をお勧めします。

機械的に確認する事は、チェック時間を大幅に減らせるだけでなく、チェックミスを減らし、時間と集中力をクリエイティブな方向に集中させる事ができ、より良いものが出来上がるようになります。

個人的には正規表現くらいは全員使えて欲しいな……なんて思ったりしてます。

いやね、だいたいの機械的チェックは正規表現使ってチェックすれば、あっという間にチェックすみますし、改行位置の全データ修正とかも一括修正してからフレーバー修正すれば、修正≒クオリティアップにつながると思ったりする事多々なんです。

納品

てなわけで色々完璧な準備と完璧な段取りをして、すんなり納品……

とはほとんどなりません(笑)

作業者が風邪ひいて倒れたり、牡蠣にあたったり、やる気なくしたりしてスケジュールがのびる場合があります。ので、多少バッファを設けてスケジュールを組んでおくのが吉ですね。

(それでも夏休みの宿題のように、最終日に頑張るのが人間の業かもしれませんが、それでも人類を信じてみたいとテーマらしい事を言ってここで一旦終わりにします)

ゲームデータ制作の段取り 5

注意する事

工数がかかる仕事

通常テキストデータを作成する際には発生しないのですが、下記のようなゲームについては必要な作業が追加されるものがあります。

主に専門性が高いジャンルを扱ったゲームや、歴史的事実にたがわないように作らなければならないゲーム、原作を扱ったゲームなどです。

これらのゲームは、作成する前に事前の調査が必要で、その為の資料をあつめたり、資料を作る必要があったりします。

また、データを作成した後で事実と間違っていないかチェックしたり、ある程度のデフォルメ表現をしたとしても、それが許容できる範囲であるか判断したりする作業が発生します。

昨今の「ネオ歴史もの」ではあまり重要視されていない傾向がありますが、ヘビーなファンがつきそうなコンテンツや、歴史のあるコンテンツではものすごく労力と神経を使うお仕事になります。

原作ものでは原作者チェックが入りますが、原作者様も大変忙しいので、なかなかチェックを入れられずにスケジュールがずれ込む事が多々あります。思い入れのあるキャラクターの口調については、かなり細かいチェックが入りますので、リテイク回数が多くなります。

  • 専門性の高いジャンル
  • 事実誤認が許されないもの
  • 原作もの
  • 事前調査が非常にかかるもの

まだちょっと続くんじゃ......もうちょっと......ちょっと......

ゲームデータ制作の段取り 4

データベース仕様書

テキストデータは、設定された一連のデータフォーマットに沿って作成されます。フォーマットから外れた書き方をしますと、画面上で正しく表示されなかったり、バグが発生したりしますので、データの仕様は必ず知っていなければならないものです。

普通は一つのデータの各項目にテキストを記述する形をとります。

データとデータの仕組みについての仕様を記した書類です。

データ全体の仕様と、データの各項目について記した仕様、データの運用について記した仕様などがあります。

データはプログラムに組み込まれて出力されますので、正しいデータの形を理解することで、効果的なテキストデータを作成する事ができるようになります。

また、使ってはならない文字や、改行の位置などがわかるようになりますので、画面で見ると格好悪くなる文字の並びになったりしないようにできます。

数値データやファイルデータは取扱いませんので、ここではそれらの事は割愛いたします。

チェックすべき項目

  • ユニークID
  • データのリレーション指定項目

ごくごくたまにユニークIDの無いデータベースが無いものをいただいたりしてびっくりする事があります。

ユニークIDというのは、「そのデータがもつ特有の背番号」って奴で、例えばエクセルの行ごとに固有の数字を割り振る、とかそういうものです。プログラムではユニークIDを検索して、それにつながるデータを呼び出すことになります。なので、このIDが無いとプログラムでは基本的にデータ参照ができない事になります。で、これが無いデータベース仕様をいただく事があるということです。

作業者としては、シナリオプロットの仕様や、イベントリストの仕様書などにユニークIDが記述されているので、それを見てシナリオの流れやイベントの内容を理解するんですが、その大切なユニークIDが無いので、イベントとの紐付ができないor特定できず、作業者が「どのイベントにデータが対応しているのかわからんよ(涙)」という事がおきたりします。

イベントがストーリー上繋がってたり、フラグによって分岐してたりすると、作業者はイベントの流れを追わなくてはならないんですが、データの対応が理解できないと仕事として終わってます。これやばいんで、一番最初にチェックしたい所です。

もしユニークIDが無い場合は、早急に問い合わせして仕様の修正をお願いした方が良いです。というか、どうやってプログラムは処理しているんだろう…と思ったりする事しきり。

データのリレーション指定については、例えば「登場する敵キャラクターID」のような項目があった場合、そこに記述されている敵キャラクターIDとキャラクターリストの資料がないと、どんな敵が相手となっているイベントなのかわからない、なんて事になったりします。

各項目のチェックすべき仕様

  • 文字数
  • テキストコード
  • 改行コード
  • 挿入タグ・変数の仕様

プログラム上で不都合な表示がされないようにする為の仕様を確認します。

項目内部には、テキスト記述についてのルールや、画面上で表示される文字数、画面幅から割り出される、改行箇所や行数といった仕様が要求されます。

テキストコードによって使用してはならない文字のルールもあったりします。特にwebゲームの場合はテキストコードと機種依存文字の関係が重要になります。

画面サイズによって、一行で表示できる文字の数がかわります。また、一回のテキスト表示で表示できる行数も決定されておりますので、その仕様も必要です。



まだちょっと続くんじゃ

ゲームデータ制作の段取り 3

シナリオ仕様書

ゲームデータ作成に使われる仕様書は以下のようなものです

  • シナリオ
  • キャラクター設定
  • 背景世界説明
  • アイテム設定
  • 用語指定
  • 表現規制

    これはあくまでキャラクターの設定が乗っているだけなので、シナリオ全体に関する資料や、書式などに関する資料は別途必要ですね。

シナリオ

ゲーム内でのシナリオです。今回はゲーム内(インゲームと呼んだりします)でのテキストデータ作成ですので、ステージ間に表示されるようなシナリオイベントとかは含みません。インゲームに表示されるエビソードと顛末を記述した書類になります。

インゲームのテキストデータを作成する際に使われる資料は、プロットと箱書きです。

ゲームデータ作成は、用意されたデータフォーマットとゲーム展開に沿ってテキストを記述する所が通常のシナリオ作成とは異なります。

ちなみにここら辺の用語とフォーマットは業界的にまとまっていないものが多いですので、作業を確認する際には特に念入りに確認する必要があると思います。

プロットとは

プロットとは、 全体のストーリー構成を書いて全体を見渡せるようにしたものです。

一つの項目に一つの話の固まりを入れる形になります。

それぞれの項目にテーマや舞台設定、登場人物、出来事がわかるように書きます。

箱書きとは

箱書きとは、1つのシーンの内容を箇条書きで書き、それを筋の流れを見やすくする為に箱の中に書き込みます。

箱はエクセルシートのセル一つと考えると分かりやすいでしょう。

箱書きの例
シーンNo.概要登場人物場所
102
  • 王国軍兵士が店からリンゴを万引きする
  • 店のおやじが引き止めるが、兵士から殴られる
  • ラング、店のおやじを助ける
  • ラング
  • 店のおやじ
  • 王国軍兵士A
城下町の八百屋

台詞は書かず、ストーリーの流れがわかるように書きます。

1シーンごとに1箱書きますので、100シーンあったら100箱書かなくてはなりません。

全体が出来たところで、客観的にストーリー構成を眺める事ができるようになります。

箱書きの効用は、話の構成を客観的にはっきりさせることです。

もう一つの効用は各シーンの間における時間経過を確認することができます。

箱書きを書くと、各構成が客観的に理解できるので、構成とライティングが分業されてもシナリオの意図に沿ってライティングができます。

キャラクター設定

登場するキャラクターの設定書類です。

キャラクター設定資料には、キャラクターの名前・性別・年齢・口調・一人称・人間関係・ストーリー内の本人の目的・ゲーム中におけるポジションなど多岐にわたります。

通常はグラフィックイメージが添付されている事が多く、テキストで設定を伝えきれない部分はグラフィックで理解できるようにしてあります。

背景世界説明

地理情報や歴史情報など、ストーリーの背景となる情報です。

国や土地の固有名詞、政治や軍事組織の名称や形態、ステージの風景や植生といったものが、キャラクターのセリフから発せられます。

背景世界によってキャラクターは価値観や周辺情報を与えられ、台詞の内容に彩りを与えます。

例えば、背景世界が無い場合のセリフが

「俺は山から来た巨人を味方と迎え撃った」

となっていた場合、背景世界の資料があれば、テキストライターは

「俺はアストラ山脈から来た氷の巨人をグリーンドラゴン騎士団と共に谷川岳で迎え撃った」

と書く事ができるようになります。

アイテム設定

特殊なアイテムに関する情報です。主人公やその他のキャラクターが特別に保有しているキーとなるアイテムです。

特殊な効果や、ストーリー上での立ち位置があったりしますので、その場合にはアイテム設定が必要となります。

用語指定

ゲーム内で使用されるゲーム世界観特有の単語に関する解説です。

世界観特有の単語はプレイヤーの混乱を避けるため、あまり多く作るべきではないと思います。

しかしどうしても現実では伝えられない言葉や、世界の雰囲気を伝える為に必要な言葉については作る必要があります。

ゲームは多くの人で作るものですので、スタッフ共有の為に単語用語の設定書類を作ります。

形としては辞書のようなフォーマットが多いです。

表現規制

書くべきではない表現のリストです。

  • 現代の法律や公序良俗に反する恐れのある表現
  • 世界観にマッチしない表現
  • プレイヤー層にマッチしない表現

などがあります。

例えばターゲットプレイヤーが小学生の場合は、難しい漢字が並ぶ言葉は読みづらいので避けるべきです。日本では問題ないかもしれないが海外では問題のある表現というものも避けるべきでしょう。

ローカライズの話になりますが、日本で作った英語名称が海外でのスラングで卑猥なものを指す、なんて事もありますので注意が必要ですね。


まだまだ続くよママン

ゲームデータ制作の段取り 2

ゲームデータ作成に必要なもの

ゲームデータを作る時には事前にいくつかの資料が必要になります。

基本的にはゲームの内容とか世界観とか、ゲームのデータ内容がわかるものが必要となり、データ作成者はそれらの資料をもとにしてテキストを作成していきます。

下記に記したものが必要な資料になります。これらが無い場合には、データ作成の前に下記の資料を作成する作業が必要になります。

たまに「仕様書は無いんですが、データを作成していただけませんでしょうか?」というご相談をいただいたりするのですが、その際には仕様書を作っていただくか、こちらで仕様書を作る必要があります、と説明しています。「仕様書無しでデータを作ってください。仕様書作成費用無しで」という事があった場合は......書類の依存関係を説明しなければならなくなります。何故資料が必要かは後述します。

必要なものリスト

  • 企画書
  • ゲーム仕様書
  • シナリオ仕様書
  • データベース仕様書

企画書

ゲームの概要を記述した書類。

企画書といっても、事業計画とかの情報は必要なく、主にゲームシステムやゲームの世界観が伝わるものが要求されます。

特に作成するデータを使用する箇所の、システム的な概要とプレイヤーに伝えたいフレーバーがわかるものが必要となります。

ゲーム仕様書

  • プレイシステム
  • 画面仕様書
  • ゲーム内用語の指定
  • パラメータの説明

といったような部分が必要になります。

プレイシステム

データを使う箇所は主にゲームのプレイ部分であるので、プレイ内容について説明している仕様書が必要となります。

プログラム的な仕様については必要ないのですが、画面挙動やボイス発生とか、データが実際に使用される実情が把握できるものが嬉しいですね。

画面仕様書

作成されたテキストデータが画面にどのように表示されるかを確認する為に必要です。

表示サイズから適切なテキスト表現や文言を割出します。

例えば、小さな文字をたくさん表示するウィンドウの場合、画数の多い漢字を乱用する事を避けたり、一瞥するだけで理解できる単語を使用したりするなどの判断ができるようになります

ゲーム内用語の指定

ゲーム内用語についても定義が必要です。開発時に各担当者間で修正や追加といった作業が発生するのですが、用語がまちまちな為に違う場所を修正してしまったり、余計なものを作ってしまったりして開発が混乱してしまう事が無いように、言葉の定義はしっかりしておく必要があります。

「知ってて当然」と思ってしまうと思わぬ落とし穴になる、という事がよくあります。て言うか、むしろフラグです。

パラメータの説明

使われるデータやゲーム中で使用される各パラメータの説明です。

ゲーム内で、どう処理されているかを理解する必要があるものも多いですので、各種パラメータについての説明があると、テキストを書く時に適切に記述ができます。

まだかかりそうです。続く~

ゲームデータ制作の段取り 1

うちの会社ではゲームシナリオ制作の中でデータ作成というものをしてます。

結構案件によって作業がまちまちになってしまいがちなので、ここで一般的な段取りを書いてみます。

データ作成とは?

シナリオ制作業務

世界観設定
ゲーム世界の基本的ルールを設定する作業
プロット作成
ゲーム世界の物語を作成する作業
シナリオ作成
物語からシナリオパートのテキストを作成する作業
データ作成
物語からゲームパートのテキストを作成する作業

 

ゲームはシナリオパート以外にも、プレイヤーが実際にプレイする最中にもテキストが多数表示されます。

例えばアクションゲームのプレイ中に出る、ボスキャラと戦う前口上とか、スキル発動する時のセリフとか、数十文字程度でおさまりそうなテキストです。

ゲーム中のテキストなので、ゲーム展開によって内容が変動したりするので、ゲーム仕様を理解しなければならない所が難易度の高い所ですね。

カードゲームだと、カードの枚数だけデータがあり、しかも状態によって出力されるテキストがいっぱいあります。

ゲームデータの例

エクセルデータとかで、各項目にテキストデータが書き込まれているのが一般的です。

例えるならばこんなかんじです。

名前 スキル名 フレーバー イベント 勝利
エリザ 秘密のダンス 酒場で踊り子をしている。
裏の顔は現政権に抗う反体制派のメンバーの一員。
酒場では王国軍のクズ兵士を接待し諜報活動をしている。
ここは、ぼうやの来るところじゃないわ はっきりいって邪魔!
ケーレブ 五月雨切り 特権区で暮らす貴族の坊ちゃん。
主人公と出会い主人公に興味をいだく。
そんなぁ~......また今日も特訓ですかぁ~? 御師匠!今日もわたしは元気です!

 

ゲームシナリオ制作業務で作られるデータ作成と、プランニング業務で作られるデータ作成は違っていて、結構「データ作成」という言葉で混同されたりします。

其々のデータ作成の違いはこんなかんじです。

ただ、ゲームや会社によって業務分担が変わったりしますので、これでスッキリしないのも難しい所です。

業務分担
フレーバーテキストシナリオ
イベントセリフシナリオ
バトル時セリフシナリオ
属性設定プランニング
パラメータ数値プランニング
レアリティプランニング

シナリオ業務としてパラメータ数値を入れたりする事もありますが、ほとんど「仮に入れる」程度の仕事になります。

特に属性・数値・レアリティ等のバランスをとったりする仕事はプランニングのお仕事になります。

 

ちょっと長くなってしまったので、続きます

プロット無しでシナリオ制作・・・?

「プロット作成は結構ですので、シナリオだけ納品してください。予算はシナリオ代だけで結構ですよね?」

と言われたらどうしよう......という話がありました。

社内で軽く議論。

まあ基本的にありえない、というのはおいといて、どのような例えで説得しようか、と。

私「絵を下書き無しでパツ描きするようなものですよ」

仮想客「上野の公園とかでやってる人いるじゃないですか」

私「ぐぬぬ......あ、でもノーリテイクですよ?」

仮想客「あ、それで結構です」

その後絶対リテイク来るに1000ペリカ。というか、リテイク減らす為にもプロット必要じゃないですか。本末転倒ですよ。

という訳で結構悩みました。

色々と意見が出ましたが、

私「私はお医者さん。これから貴方を手術します。」

仮想客「はい」

私「検査しません。レントゲンとりません。術前術後の説明しません。いきなり切ります」

仮想客「もし治らなかったら?」

私「何回でも切りますよ!勿論検査無しで!!」

という例えを出したら、社内では「結構近いかも」と言われました。

何回もリテイクしてたら、確かにお客様にも出血を強いりまくりですね~......。

メインページ | アーカイブ | ゲーム開発 »