はじめに
本ブログを見ていただきありがとうございます。
ゲームデザイン課の浅倉です。
ロジカルビートにゲームデザイン課なんてあったっけ？と思ったあなた。
ロジカルビートについて詳しい方ですね。
これからもロジカルビートの応援をよろしくお願いします。
さて、ひっそり立ち上がったゲームデザイン課ですが、通常業務の他にも社内活動として社内向けにゲームデザインの勉強会がございます。
それはゲームデザイナー（ここではプランナーも含む）だけではなく、ゲームデザイナーと一緒に仕事をする仲間と仕事がやりやすくなるように考えた内容です。
ロジカルビートならではの内容を盛り込みつつ、ゲームを作っている業界の仲間たちにも【役立ててもらいたい】という願いを込めました。
今回はその中から一つ【管理を考えたテキストデータベースの作成方法】を紹介します。
地味なお題ですが、テキストを制作する側とテキストを実装する側の大幅な作業ストレスの軽減につながりますのでお付き合いいただけると幸いです。
目標
本内容は、管理しやすいテキストデータベースを作成できるようになることを目標といたします。
今回の資料では 【Google Sheets】を使用させていただきますが、
表計算アプリであればどのアプリでも流用が効くように、できる限り汎用性が高い方法を紹介したいと考えています。
管理しやすいテキストデータベースの必要性
そもそも、何故、管理しやすいテキストデータベースが必要なのかについて説明させてください。
| テキストデータベースとは | ゲームシステムやゲームの基礎的なすべての単語をまとめたもの |
| 管理とは | テキストデータベースが常に最新の状態を維持する事 |
テキストデータベースはいわゆるゲームの辞書、管理は辞書を常に最新版にしておくことです。
当たり前ですが、テキストデータベースは最初から完成しているわけではありません。
テキストの担当者が一つ一つの単語を決定し、地道に登録しています。
日々増えていくテキストを管理し続けるのは大変ですが、その結果、仕様書を作るゲームデザイナーやプランナー、テキストを実装をするプログラマー、テキストのＱＡを行うスタッフなど、プロジェクトに携わるすべてのスタッフが 正しいテキスト情報を各自が得られるようになります。
もしテキストデータベースを作らなければどうなるのか？
一つの事例を紹介します。
【スタートボタンを押すと画面が遷移する】と仕様書に書いてあるのに、
実際のゲーム画面を見ると該当するテキストがないケースです。
上図に添付されているゲーム画面をパっと見ただけだと【どこ？】と私なら思います。もちろん、【Lets Play!!!】がそれであると気が付くでしょう。
いや、わからないこともあるかもしれません。
何故こうなったのか？
一番最初は【スタートボタン】となっていたが、それがデザインやプログラム的な要因があり【Lets Play!!!】に変わってしまった。
そして、その変更が仕様書に反映されてなかったと考えられます。
テキストデータベースが管理されていなければこの変化を知っている人は変更にかかわった人だけになり、実装を行う現場では【仕様書と違うんだけど、どっちが正しいの？】というテキストの確認作業が発生します。
テキストの担当者もその都度スタッフに指示をする作業が発生し、その際の伝達ミスの可能性も生まれ、芋づる式に手間が増える可能性をはらんでいるます。
管理されたテキストデータベースがあれば、事例のようなことも、現場ですぐに確認し完結することができます。
つまり、無駄な作業工数を減らし、ミスの発生個所を減らせるから、 管理されたテキストデータベース が必要なのです。
下準備
作る前に、まずは下準備としてデータベースに必要な項目を書き出します。
必要な項目とは、管理を行うための要素です。
テキストは更新が発生する可能性が高い為、更新した情報がすぐわかるようにして、現在のテキストが最新だとわかるようにすることが大事です。
実際に項目例を出します。
| 更新日 | 更新があったら記載する。 更新日と更新内容を記載してください。 |
| 単語ID | 単語を分けるための文字列。 |
| コードID | ※プログラムに入れるとき、単語IDでは 不都合が発生する場合のみ使用 。 |
| 翻訳ID | ※翻訳時のみに使用する文字列。 翻訳ファイルとテキストファイルが違う、複数言語対応で、 言語毎にIDが別になる場合、等で使用する 。 |
| 基礎名詞 | 最初に設定した共通単語 （攻撃、魔法、話す、走る、等） |
| 名詞ジャンル | この名詞が何を指しているかを記載します。 後述する管理方法のために追加します。 |
| 固有名詞 | 基礎名詞をゲームにカルチャライズした固有名詞 。 （攻撃力→ATK、回復魔法01→テアッテ、剣001→鉄の剣、等） |
| 文字数 | 単語の文字数です。 フォントタイプやUI作成時の干渉などを考量する場合に使用します。 |
| 翻訳 | 固有名詞を翻訳する。列は言語ごとに追加。 |
| 備考 | 注意事項を記載 （例、怪しい男、男、青年等の翻訳したとき同音になる、 地域によって名称が変わる場合、等） |
上記は、開発をしながらテキストを更新し、管理するために必要だと考えた項目です。
ゲームによってはもっと必要な項目があるでしょう。逆にもっと内容を削る必要があるかもしれません。
必要がない項目はブランクにしておいて問題はないと思いますので、もし、自分で項目を考えるのが大変だ、というときは、上記をそのまま使用し、プロジェクトに合う用カスタマイズしてみてください。
作り方
さぁ、実際に各項目に中身を記載をしていきます。
管理をするには、ルールを決めることが大事です。
上記の図では下記のルールを設けました。
- 各シートごとにジャンルを分け更新をする
- 基礎名詞と単語IDをまず決める
- 更新日は固有名詞を決めた日とする
- 固有名詞を更新した場合は内容と日付をセルの中に追記する
基礎名詞と単語IDを最初に決め、固有名詞を入れたら、その日を更新日として記載します。
上記の理由として、基礎名詞と単語IDは変更しないが、固有名詞は変更する可能性があるため、更新日を書いていきます。
更新内容は、現在のテキストが最新かどうかの判断をする大事な情報ですので、上書きではなく追記することを徹底してください。
テキスト管理ツール
以上がテキストデータベースの作り方となります。
しかし、上記は全て手動で行われており、ダブルチェック、トリプルチェックをはじめ、いかに確認体制を整えようと、更新の漏れなどのミスは防げないでしょう。
そこで、ミスが発生することを前提として、対象のミスをシステム的に検知するツールを考えてみます。
【課題】
‐更新ミスが発生した場合、直ぐに認知できない
‐ミスの発生日が特定できない
【目的】
‐ミスを発見しやすくする
‐その場で修正できるようにする
‐いつ発生したかわかるようにする
課題を克服し目的を達成するために、ツールを使った作業フローを考えます。
1.テキストデータベースを更新
2.ツールにインポートさせる
3.該当箇所を、ゲーム画面で確認
4.問題がない場合はゲームに反映する
5.問題がある場合、その場で修正し、csvファイルにてエクスポート
6.テキストデータベースに5のCSVファイルをインポートさせる
テキストデータベースでテキストの更新を行うが、実際にゲーム画面に反映させてチェックする形です。
フローを考えたら、実際のツールの画面の構成を作ってみましょう。
このツールができることを紹介します。
- テキストにマウスオーバーすると簡易ダイアログが表示
- テキストをダブルクリックしてテキスト情報を獲得
- テキストを直接更新できる
- テキストを更新した場合は更新日時が保持される
- 更新したテキスト内容と更新日時を反映させたデータベースファイルをエクスポートできる
- テキストの更新内容をゲーム内に反映させる
以上が、今回考えたテキスト管理ツールです。テキストの更新がツール上で行え、更新状況なども追えるようにすれば、誤った更新や間違いなども発見が簡単になると想定しています。
担当者が多い場合は更新者のログを残すために、ツールにはアカウントによるログイン管理もあったほうがいいかもしれません。
様々なケースが考えられるので、それらはプロジェクトの規模で柔軟に対応してください。
ツールの仕様書を作るとき
ツールにとって大事なのは目的と用途です。
エンジニアの作業工数がかかるものになるので、その時間を使ってでも作るべきなのかどうか。自分で判断できない時はディレクターやプロデューサーに相談するべきでしょう。
作ることが決まれば仕様書を作ることは難しくないと思います。
繰り返しになりますが、ポイントは 目的と用途です 。
・何をする（できる）ツールなのか？
・このツールを使うのは誰なのか？
作ったことが無いツールの仕様書とは言え、結局は皆さんが作りなれているであろう仕様書でしかありません。怖がらずツールの仕様書を作ることに挑戦してください。
最後に
いかがだったでしょうか？管理を考えたテキストデータベースの作り方の参考になったでしょうか？
最初の構想段階だとツールの話は考えてなかったのですが、流れで書いてしまいました。こちらも役に立ったらと願うばかりです。
元も子もない話になってしまいますが、最初から完璧なテキストデータベースを作れれば、管理しやすいかどうかを考える必要はありません。
ですが、そんなものが開発初期からあるプロジェクトはほとんど存在しないでしょう。
開発中に必ず足りなかったり変更となる単語が出てきます。修正や追加を行い、再び確認を行うという作業サイクルを繰り返さなければいけません。
テキストは単純ですが、ユーザーが直接見るところであり、コンプライアンスのチェックが多く入る場所です。
どんなに練りこんだ世界観も1ワードで崩れることがあることを留意してください。本ブログは、それを防ぐためのシステムであり、それを作るためのきっかけなのです。
テキストデータベースを作ったことがない方も、作らずに開発を進めている方も、このブログを読んだ機会に作ってみてはいかがでしょうか。
では！良き開発ライフを！
【免責事項】
本サイトでの情報を利用することによる損害等に対し、
株式会社ロジカルビートは一切の責任を負いません。
