EXCELとゲーム翻訳者の仲介役！ felixノススメ
あんなに期待していたLocalizeDirectはどうも翻訳メモリやら用語集の統合ができないようです。それじゃフィルタ機能以外に翻訳者に利点がないよ… という感じで、業界のデファクトスタンダードはEXCELなんだなと再認識したので、自衛措置として「EXCELの天下はしばらく続く」という前提のもとに自分の作業環境をさっさと整えようということになりました。
探すにあたってのテーマは「用語集や既存訳を脳みその中に展開して」作業しなくていいようにしてくれるツール。本当はQAチェックができたり、バージョン管理ができるようなソフトがあればいいんだろうけれど、そのあたりは今回は諦める。ひたすらに、「EXCEL上で最低限のCATテクノロジーが使えるツール」を探しました。
そうして見つかったのがFelixというツール。こいつは基本Wordで使うものみたいですが、Excelにも対応しており（この他PowerPointにも対応している）、自分の求める具体的な要件をほぼ全て満たしていました。
要件とは
- EXCELのまま作業できる=ツール専用の作業ファイル形式に変換しなくてもよい
- 翻訳メモリと用語集を参照し、マッチを表示してくれる（どちらも自動で）
この2点だけ。なぜこの2点なのかは以降で説明します。
「EXCELファイルに対応していて、かつ作業ファイルに変換しない」がなぜ要件か
これを説明するには、まず「なぜゲーム翻訳はEXCELで行われているのか？」と「変換することの短所とは？」を説明する必要があるので、箇条書きにまとめてみます。
なぜゲーム翻訳はEXCELで行われているのか？
- String ID、原語、訳語、補足情報など、1レコードに入れる情報が大量にあるし、そのカスタマイズ性が高い
- レコード数が大量にあるが、編集も頻繁に入るので、誰でも編集できる形式が求められる
- 開発時に制作した資料を流用したりするにはEXCELが便利だから。誰でも使えるみんなのEXCEL!
CATツールの変換機能とは？
- 例えば XLS→XLIFFのようなもの。
- CATツールのエディタで開くファイルは、多くの場合「多言語データを扱うための専用形式」に変換される。例えばSDL TRADOSではTTX、SDLXではITD、SDL TらドsStudioではSDLXLIFF、Open Language ToolsならXLIFFなど。
- ゲームの翻訳対象ファイルは「なんちゃってデータベース」のように使われるため、翻訳対象のセルは1列だけに集中していることが多い(A列:GUID、B列:String ID、C列:原文、D列:翻訳文など)。
- CATツールは基本的に「文書の中身は全部翻訳するもの」として扱うので、一部だけを翻訳可能な状態にすることはできない。迂回策として「翻訳対象外文字列を "非表示" や"隠し文字 (Word)" に設定してから変換する」方法もあるが、これではせっかく用意されているString IDや文脈情報などの情報を参照しながら翻訳ができない。
つまり
- 開発者が用意してくれる文脈情報は、翻訳対象文字列の隣のセルにあることが多い。
- そして多くの翻訳支援ツールでは変換やらのせいでそれが見えなくなる、ないし見えにくくなる。
- だから文脈情報を全部見るにはEXCEL上で直接翻訳メモリを参照できないと無理。
という理由で、上のふたつが要件になったわけです。そしてFelixは両方をクリアしてるンス。
felixの紹介
- http://felix-cat.com/
- 価格は 350 USD。
- 評価版DLはこちら
- 開発は日本在住の外国人開発者の方がやってるみたいです。
- ユーザーフォーラムは http://groups.google.com/group/felix-users
概要は興味のある方のみ、公式ページをご覧ください。LYEはEXCEL上でゲーム翻訳するときにどれだけ翻訳者が助かるかの話しかしません。
なぜそんなにお気に入りなの？
- だって「文脈に関する情報を確認しながら仕事ができる」んだよ！
- なのにちゃんと既存訳文と用語集を自動ルックアップしてくれる！
※原文/訳文はFallout3 DLCのファン翻訳からお借りしました - 範囲ドラック選択→メニューで[グロッサリ/翻訳メモリに一括登録]すれば用語集や翻訳メモリをサクっと作成/更新できる! 新規案件のスタートアップが楽！
- EXCELファイルを変にいじらないので、「翻訳ベンダーが採用していなくても、翻訳者が勝手に使ってしまえばいい！」
- 地味に良い点として、用語集の検索条件にFuzzy一致率が設定ができる(Apples が用語集にあったら、Apple が出てきてもルックアップしてくれる)
逆に欠点は？
- QAツールがない。用語集準拠チェックと表記スタイルチェックが付いたらうれしいけれど、現状だとれはマクロやら外部ツールで対応するしかない。
- 現状、翻訳完了→次の作業セルへの操作を行うと横にあるセルに移動する。しかも設定を変更できない。ゲーム翻訳者としては下に行って欲しい。ただこれについては機能追加のリクエストがあがっており、作者も乗り気であるため、そのうち改善されるであろう。
- 翻訳メモリや用語集から情報を引き出して挿入すると、原文が全部クリアされる。これは割とめんどくさい。クリアせず挿入してくれたら嬉しいのだけれど。と書いていて気づいたので今度リクエストしてみる。
- ショートカットがALT+1 、2、3などに設定されているため、人によってはEXCELのカスタムショートカットキーとかぶるかも。事実僕はかぶった。そして原文がクリアされる問題と重なって結構悲しい結果になった。
- 上の欠点などにより誤ってクリアしてしまった場合、セルのUndoがきかない。つまり「あ、まちがえて翻訳ほぼ終わっていたセルに用語集から用語を挿入してEnterしちゃった→翻訳消えて用語だけのまま翻訳確定→CTRL+Zしても帰ってこない僕の訳文」という悲しいことになる。これも今度リクエストしよう。するだけしよう、そうしよう。
大作ゲームともなれば、固有名詞に対応する訳語だけでも脂汗が出るほど多い。そういうとき、いちいちGrep検索したり(EXCEL検索なんて僕は絶対しませんよ！)、作業中ずっと脳みそに刻みこんでおくことに一体何の意味があるのよThis is 21st Centryですよ！と僕は叫ぶわけです。
一生懸命用語の対訳集を記憶したって品質は上がらないし、誰も得しない。それなら21世紀らしく楽に品質が上げられる方法を模索したい。今のところ、LYEの最適解はこれです。
まだ人に説明できるほど使い込めていないので、使い方の概要はもう少し慣れてから書こうと思います。
Gamebusiness.jp/インサイドにCEDECの記事を書かせていただきました
世間はTGS一色ですが、これ以上遅くならないうちに書いておきます。
何か超自然的な力が働いたとしか思えないのですが、あの Gamebusiness.jp/インサイド様のはからいでCEDECセッションのまとめ記事を書かせていただきました。
海外関係
私事ですが10月に引っ越します
体調も無事回復してきたので近々フリーランスのゲーム翻訳で御飯食べていくことに決めたのですが、諸々の事情で一旦東京を去り、実家のある長野県に引っ込むことにしました。戦略的撤退です。
当面の目標である「ゲームローカライズのインディペンデントコントラクター(プロジェクト単位でお仕事する個人事業者)」となるには、現在の技術だと東京に居ないと難しいので色々と落ち着いたら再上京することになると思いますし、あちらに住んでいてもセミナー等があれば東京には来たいなと思っているので、僕と遊んでくださる皆様にとって実質的に何か変わるかと言われれば別に…という感じではあるのですが。
というわけで今後とも宜しくお願いします。
イチから分かるソフトウェア向け CAT (翻訳支援) ツールの概要
今日はちょっと真面目に書きます。
「機械翻訳と翻訳支援ツールは何が違うか?」から始まり、「CAT ツールの構成と概要説明」、「ドキュメント用とソフトウェア用の違い」、「ソフトウェアを翻訳するときの長所と短所」、それから LYE の個人的な意見と続きます。LYE の意見では、「こいつを導入すれば御社大勝利! ではない」けれど「導入の必要性は時代がグイグイ高めてきているのでは?」ということなんかを書いています。
記述に間違いがありましたらメールまたは Twitter でご指摘いただけるとありがたいです。
それでは。
CAT ツールと機械翻訳ソフトの違い
機械翻訳ソフトとは、「原文を文法的に解析して機械的に訳出するソフトウェア」。翻訳に際して人間が一切干渉しなくてもよい。
要するに、エキサイト翻訳。
CAT ツールとは、主に翻訳メモリテクノロジを中心に据えた「翻訳者向け作業環境」のこと。主な機能にはつぎのようなものがある。
- 用語集に載っている用語が原文に含まれる場合に自動的に対訳ペアを表示する
- 過去に類似する原文を翻訳している場合に、その対訳ペアを表示する
- 原文にタグや変数 (
) や特定の記号 (\n) などが含まれている場合に、訳文にも完全な形で含まれているかチェックする
機械翻訳と違い、導入しても一文字たりとも機械的には翻訳されない (翻訳メモリの内容を再利用することはできる)。
ひどく乱暴な言い方をすれば、「プログラマにとっての「IDE」。本来の仕事を煩雑にしている要素を便利にしてくれるツール。用語の自動補完はないが、用語集にヒットした用語を訳文に挿入することなどはできる。
CAT ツールの主な構成
翻訳メモリ
- 原文と訳文のペアと、付随的情報 (作成日、作成者、更新日、オリジナルファイル名、IDやタグなどの文字列固有情報)を 1 レコードとしたデータベース。
A point clear!, A ポイント、クリア！, 2010/9/2, LYE, 2010/9/5,ingamestrings.resx, combat001,
- 翻訳を累積させていくことで、過去訳の再利用を可能にする。
B point clear!
翻訳時に、
”A point clear!, A ポイント、クリア！, 2010/9/2, LYE, 2010/9/5,ingamestrings.resx, combat001, ”
が表示され、差異である A と B の文字列が強調表示される。
- 社内のあらゆる翻訳物を一元的にまとめたものから、プロジェクトごと、製品ごと、製品バージョンごとまで、運用方法に応じてカバー範囲は変わる。
- ツール固有の形式を使用している場合が多いが、多くの場合は互換性の高い TMX フォーマットをサポートしているため、(日本語文字列の扱いに一部不具合などもあるが) ツール間で TM を移動させることも可能。
用語集ツール
- 原語:訳語、または原語:説明を最小単位とする。
原語:訳語の例: Pen:ペン
原語:説明の例: Pen:細長い形の、インクを筆記面に付着させることを目的とした器具
- カスタマイズが可能で、例えば形式を「原語:訳語:説明:ジャンル:例外的条件:メモ:更新日時」のようにすることもできる。
- 翻訳エディタでの作業中に自動的にルックアップさせたり、QA チェックのチェック条件として使ったりすることができる。
翻訳エディタ
- 実際に翻訳業務を行うためのエディタ。一般的に、原文と訳文が並んで表示される。
- 訳文のフィールドに翻訳文を入力していき、完了した段階で確定する。確定処理はソフトウェアによって異なる。
- 多くのツールでは、編集単位をセグメント/文節 (Segment) と呼ぶ。一般的には 1 文 = 1 セグメントだが、この範囲はカスタマイズ可能であることが多い。再利用性の高さと品質のバランスを考えると、技術文書などでは １ センテンス = 1 セグメントで運用する手法が最もよいとされるが、ゲームなどの場合は再利用性よりも品質を優先するため、1 パラグラフまたは 1 ID = 1 セグメントとすることが多い。
- 翻訳メモリ、用語集を読み込んだ状態で作業を行う。原文のセグメントにカーソルを合わせた瞬間に翻訳メモリに一致または類似するセグメントがないか検索され、ついで用語集に用語が登録されていないかが検索される。マッチが見つかった場合は各ペインに候補が表示される。
- 翻訳メモリに類似マッチがある場合には、差分がハイライト表示される。
翻訳メモリ管理ツール
- 翻訳メモリの検索、変更、プロパティ追加、形式変換などができる。
QA ツール
- エラー条件を定義した上で翻訳エディタ用ファイルに QA 処理を実行し、誤りや不統一を検出する。
- 文末の句点、連続するスペース、使用できない文字種、正規表現オプションなどを設定できる。
ドキュメント用 CAT ツールとソフトウェア用 CAT ツール
CAT ツールにも大きく分けてドキュメント向けとソフトウェア向けの 2 種類がある。利用者数からいけばドキュメント用の CAT ツールの方が圧倒的に多い。
ソフトウェアの GUI 翻訳ボリュームとマニュアル、ヘルプ、Web コンテンツ、その他の翻訳ボリュームを比べる、と考えればわかりやすいかもしれない。
利用者数が少ないという事実がありながらもソフトウェア向けのツールが開発、販売され続けている理由は、「ソフトウェア開発では避けられない傾向」と「ドキュメント向け CAT ツールのデザイン」の相性が悪いことが挙げられる。
主な理由は次の通り。
- 市場の要求によりソフトウェアの開発完了を待たずにローカライズが開始されることが多くなった
- 開発中のソフトウェアには頻繁に更新がかかる
- ドキュメント用 CAT ツールは「それ以降更新のかからないマテリアルの翻訳」に最適化されたデザインになっている (後述)
↓
- 「更新のかからないマテリアル用」ツールで「更新が頻繁にかかるマテリアル」を翻訳する利点は…ない！
主な違い
ドキュメント用 CAT ツールは「完成した文書を効率的に翻訳する」ことに特化したデザインになっている。一方、ソフトウェア用CATツールは「アップデートが頻繁にかかるファイル群を履歴や翻訳ステータスまで含めて一元的に管理しつつ翻訳する」ことを目的としたツールである。
本記事のテーマはゲームのローカライズであるので、両ツールの説明もゲームのローカライズに利用すると仮定して記していく。
ドキュメント用 CAT ツールの特徴
1 オリジナルファイル ＝ 1 作業ファイル
まず CAT ツールの翻訳エディタで作業するファイルには、2 言語分のテキストとステータスや更新日時などの関連情報を格納する必要があるため、オリジナルファイルから編集可能バイリンガルファイルに変換される。例えば SDL TRADOS で HTML ファイルを翻訳する場合、翻訳編集ソフト(TagEditor) で開くと TTX という拡張子の XML ファイルに変換される。このファイルを翻訳終了後に再変換するとターゲット言語のファイルが生成されるしくみになっている。
作成した作業ファイルはアップデート不可
だがドキュメント向け CAT ツールの場合、この変換後のファイル(以下、作業ファイル)が「固定」され、「アップデート不可」になる。
ここが上記で「ドキュメント用 CAT ツールは "それ以降更新のかからないマテリアルの翻訳" に最適化されている」と記した理由。
翻訳中にオリジナルファイルにアップデートがかかった場合、作業ファイルの原文を更新することができない。
つまり、20000行 のファイルのうち、1 行目の "Click A to Continue" を "Click B to Continue" にしたいだけでも、ファイル全体を作り直さなければならない。
(これ以降、便宜上作業中だったファイルを「旧作業ファイル」、作り直した新しいファイルを「最新作業ファイル」と呼ぶ)
アップデート発生時に変更箇所の反映が困難
この場合、翻訳作業が進行中であれば「旧作業ファイルの内容を最新作業ファイルに反映」させなければ、作業を続行できない。
このようなケースで実際に取られる手法は主に次の2つだ。しかしどちらも力技と言えるし、少なくともスマートな解決法ではない。
対応策:
アップデートされたオリジナルファイルから最新作業ファイルを作成し、翻訳メモリを活用して旧作業ファイル中の翻訳済セグメントを最新作業ファイルに移す
問題:
ひとつの原語セグメントに複数の訳語セグメントがある場合 (Play が「プレイ」と「再生」など) に適切な訳が翻訳メモリから適用されない。
現状、翻訳メモリは文脈を考慮して訳文を選択する機能が非常に限られているため、完全に翻訳したセグメントであっても、再チェックが必要になる。
また再チェックの内容も、「訳が正しいか間違っているか」ではなく「文脈に沿っているかどうか」になるため、単純に「原文と訳文が対応しているか」だけではチェック不十分となり、確認に要する時間もかかる上にケアレスミスも増える。
対応策:
新旧バージョンで Diff を出して、差分だけを挿入する/別途対応する
問題:
Diff を出す作業が (マクロなどで対応するにしても) 毎回発生する。
翻訳対象文字列を常時一元的には管理できなくなる。
Diff の処理でミスが発生すると発見しにくい。
ソフトウェア用 CAT ツールの特徴
すべての作業対象ファイルをデータベース化する
ソフトウェア用 CAT ツールでは、翻訳対象文字列を含むファイル群をディレクトリ構造ごとデータベース化する製品が一般的である。データベース化されたファイル群は 1 つに統合される。それ以降オリジナルファイルにアップデートがかかると、ディレクトリごと「再読み込み」させれば差分が自動的に取り込まれ、差分のステータスが「Added」や「Updated」のように変更される。この他、ほとんどの製品では文字列単位でチェックイン/アウト処理や編集ロックも可能である。
データベースのレコードに含まれる内容
データベースのレコードは一般的にが含まれる。この他、更新履歴を記録したり、制限文字数を定義したりできるツールもある。
- 「ファイル名および ID:原文:訳文:作成日時:作成者:更新日時:更新者:翻訳ステータス:備考欄」
多人数での作業にはクセがあり、コツがいる
文字列単位でのチェックイン/アウト処理や編集ロックといった機能は複数の翻訳者にアウトソースするために用意されたものであるが、ツールの売りである「一元的管理性」のため、エクセルよりも割り当て作業が煩雑になるという欠点もある (単純にデータベースをコピーして全員に送ってもあとで統合することができないツールもある。このようなツールの場合、ファイルや文字列単位でチェックアウトしてデータベースを「切り出し」、翻訳者に送る必要がある)。また、スケジュールがタイトな場合には五月雨納品が必要になるが、このような場合にも注意が必要になる。
翻訳後処理や更新作業が容易
データベース作成後は、いつでも生成機能を利用してローカライズされたリソースファイルを生成でき、エンジニアはそれを読み込むだけでビルドを開始できる。この処理は操作ひとつで行えるため、「翻訳ベンダから納品されたファイルを組み込めばそれ以上の処理は不要」という環境も作れる。この特徴を売りにしているツールは多い。
翻訳品質を一元的に管理できる
おそらくこれがもっとも有益な点のひとつだ。たとえば特定のキャラクターの設定が青年男性から中年男性に変更になった場合、セリフのインゲームテキストが複数のファイルに点在していても、ID 名に規則性があれば (character0034_xx)、フィルタ機能で character0034_ を含む文字列だけを表示すれば、語調を「一元的かつ視覚的に確認しながら」まとめて変更できる。このような処理はドキュメント用 CAT ツールや
EXCEL では困難であり、開発と同時進行のゲームローカリゼーションのように「コンテンツが生き物のように動く」プロジェクトでは非常に効果的である。
これで両ツールの特徴説明を終わる。最後に、感覚的な理解を促す意味で比喩を挙げてみたいと思う。
ツール比較を比喩で表す
ドキュメント用 CAT ツールはプリントアウトした紙と言える。
紙であるが故に、あとで付け足したり変更したりするにはプリントしなおしたり、別の紙を切り貼りしたりしなければならないが、1 枚ずつ切り離して別の人にサッと渡せるなど、取り回しが楽である。
ソフトウェア用 CAT ツールは (そのままではあるが) データベースと言える。すべてが一元的に管理でき、さまざまな処理を行え、情報の更新も容易だが、一元的であるが故に多人数で作業するには一定のルールに従う必要がある。
まとめ
これまで挙げてきた両ツールの特徴を見ていただけば容易に推測できる通り、全体で数千ワードしかない、EXCEL でも 1 ファイルにまとまるタイトルの翻訳であれば、おそらくソフトウェア用 CAT ツールを採用する意義はあまり高くない (もちろんパイロットケースとして採用するならば大いに意義がある)。
ソフトウェア用 CAT ツールの真価は、大規模なタイトルを開発と同時進行でローカライズするプロジェクトでこそ発揮される。
パッケージタイトルを複数言語にローカライズするような場合は、アップデートの容易さとフィルタ/QA 機能、そしてファイルハンドリングの用意さが効率化の大きな助けになることだろう。
ただし現状ではこれらのツールに習熟しているゲーム翻訳者は多くないことが想像できる。導入したとしてもすぐに劇的な生産性向上は期待できないことも事実だ。ツール自体の UI デザインが洗練されていない (失礼) こともあるが、フィルタや言語的 QA といった機能を完全に使いこなせるようになるには時間もかかるしサポートも必要になる。
参考;Alchemy CATALYST のフィルタ機能:
また今回は翻訳者が接する「翻訳支援ツール」の話題に限定したが、現在 IT ローカライズ業界では「ワークフロー管理システム」と翻訳支援ツール、および時には開発側のバージョン管理システムを統合するソリューションを (SaaS (Software as a Service) モデルなどで) 販売する企業が増えてきている。先日 Sega Of Europe がライセンス取得 (Develop)したことでニュースになった LocalizeDirect がまさにこのタイプだ。
どのツール、サービス、システムを選択すべきかは要件によって変わる。最初に行うべきことは、自社の要件を明確に洗い出すことだろう。
LYE の私見
今後市場のグローバル化が止まることはないだろうし、そのためゲームのローカライズにかけられる時間は短縮され続ける。これは結果的に、複数の翻訳者が並行して翻訳作業を行う必要性を上げる。そして並行して作業を進めれば、語調や用語の統一も難しくなる。これは既に IT 系ローカライズ企業がビジネスソフトウェアのローカライズで通った道だが、ゲーム業界も遅かれ早かれそうなることが予想できる。
またスクラムなどのアジャイル手法が今後さらに普及すれば、それだけ同時進行するローカライズの現場でも「作業対象ファイルのアップデート」を行う頻度が高まる。(念のため、改めて私見であることを強調しておくが) EXCEL では、たとえ様々なマクロを活用したとしてもこのようなアップデートに対応し続けることはかなり難しいはずだ。
まとめで触れたサービスやシステムは「本来の業務に集中する」助けになるものだと、LYE は強く感じている。翻訳環境の変更には翻訳業務を委託しているベンダーとの相談も必要になるし、またコストも掛かる。要件が何か? というシンプルな疑問も、ゲーム制作という「毎回違う生き物を生み出す」業務においては毎回変わるはずだ。
だからこそ、単純に導入しただけでは (最悪のケースでは) コストをかけたにもかかわらず、社内プログラマも翻訳ベンダーも使いたがらない、本当の要件があとから分かってきて迂回策が常態的に取られるようになる、何もかもが形骸化していく、などということになりかねない。
最初に手をつけるべきところは、「ローカリゼーションを見越した手順をまず定義」して「最初から開発すること」、そしてその上で「自社のローカライズ要件を洗い出すこと」なのかもしれない。
以上です。硬い文章なんか普段書かないのでちゃんと書けているかあやしいですが、今日のところはひとまずここまでとします。
これを書きながら頭を整理していった結果、「ローカリゼーションを見越した手順を定義して最初から開発すること」と「自社のローカライズ要件を洗い出すこと」がはっきりと自分の言葉になりました。これだけでも、書いてよかったです。
僕はエンジニアではないので (ここが非常に悔しい) 技術的なサポートまではできません。ただ、翻訳者の立場からでもよいから詳しい話を、ということであれば自分にできることなら喜んでします。興味のある方がいらっしゃいましたらご連絡ください。
日本語の感嘆表現/擬音と日英ローカリゼーション
"Gnhhh!" ... "Whhhhaaaah!" ... "Bah….ah...gahhhhhh"... "Hmmmf!"... "Ehiehhh" ... "Mhaemm!".. These grunts, sighs, squeals and miscellaneous other vocalizations compose roughly 1/4 of the dialogues in the early hours of Final Fantasy XIII.
On one hand, they're to be expected; Japan is known for its plethora of exclamations and onomatopoeiae. On the other - when translated literally - they make for a poor localization.
要約すると、
- FF XIII には英語話者からしたら没入感がそがれるくらい感嘆詞が多い
- 日本語はそういうのが多い言語として知られる
- 日本語の感嘆表現は英語よりも長いことが多いし、完全に対応する表現がない
- 多くの場合、英語でもそのまま置き換えられているが、そのせいでローカリゼーション品質が落ちる
- コアなファンはその変なところも味として受け入れているがカジュアルなファンはそこで冷める
- 文化の違いは尊重するべきものかもしれないが「プレイヤーにとって消化しやすいもの」とするには変わらなければいけない
そして Kotaku からの提案
- 可能なら、ローカライズ版ではいらない感嘆表現をカットしてしまう
- 意味不明になる感嘆表現はターゲット市場で通じるボディランゲージにしてしまう(「むわあ〜〜?」を「手を肩に置いて小さく"はあ？"」にするとか)
- 文脈のない感嘆表現を、ターゲット言語では文脈込みの表現にする*1 (車の衝突を見て「うをおおおあああああああああ!?」ならば、「Oh My God!?」とする)
- 変更の作業負荷? Lip-sync の自動化は既にけっこうポピュラー http://www.voice-o-matic.com/
記事の著者はビデオゲームデザインコンサルタント/Incubator Games のクリエイティブリード、Radek Koncewicz 氏。
おそらく大切なのは、「ターゲットがそれをどう捉えるのかをある程度まで把握した上でゲームを作り始める」ことなのでしょうね。
以前、僕の尊敬するローカライズ業界の先輩から「ローカリゼーションとはマーケティングである」という名言を聞きました。
これと「ローカリゼーションは開発開始時から始まっている」を組み合わせると、海外に向けた製品の品質をみすみす無駄に落とさせることがなくなるかもしれません。
皆様、お仕事、頑張ってください。
*1:私自身日英プロジェクトの経験はないので何も言えませんが、英日の場合でも「文脈のない感嘆表現を、ターゲット言語では文脈込みの表現にする」というのはテクニックとして使うように思います。
稲船さんインタビューなどの部分翻訳 3 点
Tumblr に流して Twitter でも呟きましたが、こちらにもまとめておきます。
下記 3 点は LYE が個人的に気になった部分だけを抜き出して翻訳したものです。他にも面白い情報が含まれていると思うので、特にご自身のお仕事に直接関係がある方などは是非原文を読んでみてください。
なお、稲船氏のインタビューは LYE が勝手に英語から日本語に翻訳したものですので、「稲船さんが話した日本語ではない」ことにご注意ください。
稲船さんインタビュー From EDGE Magazine
- 原典:Interview: Keiji Inafune
- URL:http://www.next-gen.biz/features/interview-keiji-inafune
海外デベロッパとのコラボレーションについて
<中略>
過去のプロジェクトの悪口を言いたくありませんが、成功しなかった過去のコラボレーションプロジェクトの場合、プロジェクトの初期段階で間違いを犯したと思います。開発に対するアプローチをどうやって管理すればよいか分からなかったからです。欧米モデルの開発を受け入れたほうがいいのか? それともこれまで培ってきたCapcom式を貫いたほうがいいのか?ということです。当時は初期段階において、あちらの開発会社から「欧米スタイルのゲームを作りたいから、うちの開発スタイルと方法論を使わせて欲しい」と言われまして、Capcomとしては海外デベロッパとのコラボレーションをした経験がまだまだ浅かったので、一歩引くことに同意して、あとは時々チェックするという方法を取ったんです。
しかしその結果、出来上がったゲームは「Capcomのゲーム」という感じがしなくなり、どのパブリッシャでも発売できるような感じのタイトルになってしまった。なので今回 Capcom が Blue Castle と一緒にやろうとしているのは、ギャップを超えて、真のコラボレーションを実現することだったんです。他のデベロッパと違い、Blue Castle のスタッフは Capcom のゲームを作りたい、Capcom の手法を使いたい、と言ってくれたんです。Capcom としてはDead Rising 2 を欧米で開発したかったので、両者ともにコラボレーションを求める気持ちが非常に強かった。これは完成したプロダクトにも反映されていて、日本的なデザイン要素を沢山盛り込みながらも、欧米スタジオの技能も取り入れることができていると思います。
<以下略>
CERO について
<中略>
日本のレーティング機関である CERO はゲーム中の暴力表現について非常に厳しいですよね。この点をクリアする上でどんなアプローチを取られますか?
かなりキツいです。CERO はゲーム内の要素を独立したものとして審査するんです。「あら、頭部欠損表現があるんですか? 血は出ますか?」と。でレーティングはその要素に基づいて付けられてしまう。ゲームの意図だとか、他の要素なんかは評価対象にしてもらえない。頭部欠損表現ありイコールZレーティングです。これが最大の問題ですね。CERO がゲーム全体を把握しながら、「このキャラクターをつき動かしている動機はなんですか?ゲームのテーマは?この暴力表現の背後にあるストーリーは?」と聞いてくれるようにならないと、レーティング機関の仕事には思えないです。
ゲーム全体を把握して評価するという点では、西洋諸国のほうがいい仕事をしてると思います。Capcom は以前 Shadow of Rome というゲームを出したんですが、頭部欠損表現があるにもかかわらずドイツでレーティングを取得できたんです。あちらの機関では、ゲームのテーマを見て、主人公は殺しを楽しんでいるわけではなく、愛する者を救うために戦っていること、そして多くの場合戦闘は回避できることを汲んでくれたんです。一方で CERO はモンスターハンターを「モンスターの尻尾を切り取れる」という理由で C (15 歳以上) とレーティングしています。 10〜12 歳の子供もモンスターハンターをプレイしますが、尻尾が切れることで悪影響が与えるなんて思いますか!? 私は審議会のプロセスがどうも理解できない。
<以下略>
この他、Dead Rising 2 の武器のアイデアは Blue Castle 社が出したものがたくさん入っているだとか、そういった細かなお話もありました。よかったら原文をチェックしてみてください。
Naughty Dog クリエイティブディレクター、同社のモーキャプについてちょっと語る From Develop
- 原典:Naughty Dog: Game acting methods miss the drama
- URL:http://www.develop-online.net/news/35534/Naughty-Dog-Game-acting-methods-miss-the-drama
<中略>
他のゲームデベロッパと違って、Naughty Dogではモーキャプステージ上で複数の役者さんに一緒に演技してもらいます。こうすることで、より演劇的、カメラ収録的な演技になるんです。ある意味、役者の原点に立ち返ってブラックボックスシアター(セットなどのない平らな床と黒い背景の舞台と椅子だけを並べた劇場、英語Wikipedia解説)で演じてもらうような感じです。
<以下略>
なお、このほかにも Uncharted 2 の未公開のアートやアイデアが満載の本が発売されている模様。
気になった方は読んでみてはいかがでしょう。Develop 誌には同書籍の抜粋もチェックできます!
ゲームメカニクスの深みを評価する - gamasutra 記事翻訳
この記事は LYE が下記記事を勝手に翻訳して公開しているものです。誤訳がある可能性がありますのでできたら原典も併せて読んでみてください。
- 原典: Evaluating Game Mechanics For Depth -- gamasutra
- URL:http://www.gamasutra.com/view/feature/5901/evaluating_game_mechanics_for_depth.php
- 著者 Mike Stout
[元 Insomniac 社デザイナー Mike Stout 氏が、「冗長さのチェック」などを含む、プレイメカニクスの深みを評価する上で役立つ有益な解説文を寄稿してくれた。本稿では Ratchet & Clank シリーズなどから例を示しながら、ゲームデザインを詳細に見ていく]
問題
ゲームの開発においては、書類の上では優れたデザインに見えても実際には期待したほど面白くならないということが多々あります。こういったケースでよく聞くフレーズが「浅い (Shallow)」や「単調 (flat)」などです。プレイテスター、パブリッシャ、同僚は「もっと多様性がないと」や「同じことの繰り返しだ」と評するかもしれません。
ゲームデザイナーならば、この類の苦言はよく聞くことでしょう。 じっさい私自身もこれまでに携わってきたゲームで毎回そういった問題に直面してきましたが、この問題を解決に導くアプローチは 3 種類あると考えています。
ひとつは、プレイヤーが「ゲームは全体的に多様性を欠いている」と感じている場合に、ゲームメカニクスを追加する方法。これは、ゲームの幅 (Breadth) を膨らませるものと考えるとよいでしょう。
- 注意すべきバズワード: ゲームには「長所がひとつしかない (one-trick pony)」、「同じことの繰り返し (repetitive)」、「もっと多様性を持たせるべき (need more variety)」。
- コンテンツの拡張 (訳注:ここでは、ゲームメカニクスの追加) で問題が解決できる場合、問題はゲーム全体に関するものである傾向が強い。ここでプレイヤーは、グローバルレベルで見て、ゲーム内でできることが足りないと感じています。
プレイヤーがあるゲームメカニクスを「単調 (flat)」で、「やりがいがない (unrewarding)」と感じる場合、プレイヤーに対するフィードバック (訳注:ここでは、ゲームからの反応) を改善する、報酬 (Reward) を増やす、エフェクトを改良する、サウンドやカメラワークをよりクールにする、個性を強めるなど、さまざまなものを付け加えることで、そのメカニクスの演出 (theatrics) を改良するという手があります。このような演出上のてこ入れをすると、苦言を呈したプレイヤーはかなりの確率で ― 根底にあるゲームプレイには一切変更を加えていないにもかかわらず ― 問題は解決された、と言うことが多いです。
- 注意すべきバズワード: 現状のゲームメカニクスは「退屈 (Boring)」、「同じことの繰り返し (repetitive)」、「純粋に楽しくない(just not fun)」。
- 演出の改良で問題が解決できる場合、問題はそのゲームメカニクスひとつだけれど、通常、その内容は曖昧で「感覚的 (touchy-feely)」です。
プレイヤーがあるゲームメカニクスを「いまいちプレイ意欲を掻き立てない」と感じていたり、「このメカニクスは最初は楽しいが、すぐに飽きる」と感じている場合、デザイナーはメカニクスに深みを持たせる必要があります。
- 注意すべきバズワード: 対象のゲームメカニクスは「浅すぎる (too shallow)」、「簡単すぎる (too easy)」、「単調 (flat)」。このような場合、プレイヤーは「最初は楽しかったがすぐに同じことの繰り返しになった/退屈になった」と言うことが多いです。
- こういったフィードバックを受けた場合には演出にてこ入れをすると良いですが、この方法はメカニクスの賞味期限を少し延ばすだけの効果しかない事には留意する必要があります。演出を強化しても効果が無い場合は、本腰を入れて、袖をまくり、そのゲームメカニクスに深みを与える作業を始めなければいけません。
ここまでに説明した問題について個別に記事を書くことも可能ですが、本稿では、おそらくもっともトリッキーな問題、すなわち「深み」を取り上げたいと思います。 本稿を通じて、「なぜゲームメカニクスに深みが足りないのか?」を発見するために私が使うツールについて解説できればと考えています。さらに、浅い (Shallow) ゲームメカニクスの手直しをする上で非常に役立つテクニックも紹介していきます。
はじめに: 用語の定義
詳細な議論を始める前に、ここで用いる用語のいくつかを定義しておきます。
- ゲームメカニクス (Game Mechanic):
本稿でゲームメカニクス (Game Mechanic)というとき、それは「ビデオゲームのゲームプレイを構成する主要なかたまり」を表します。名作 ゼルダの伝説 神々のトライフォース (The Legend of Zelda: A Link to the Past) から、いくつか例に出せば、「剣を用いて戦う」、「ブロックを押し動かす」「ブーメランを投げる」、「泳ぐ」、「ボタンを用いたパズルを解く」「危険を避ける」、「特定の武器を使う」などがゲームメカニクスにあたります。
- チャレンジ (Challenge):
チャレンジとは、「特定のゲームメカニクスを用いてプレイヤーのスキルを試す、ゲーム内シナリオ」のことを表します。例えば、『ゼルダ』シリーズのダンジョン内にある部屋、 『Ratchet & Clank』のレールスライド、『Halo』の会敵シーンなどがこれにあたります。
結局、「深み (depth)」とは何だ?
Dictionary.com では、depth (深み) は次のように定義されています: "The amount of knowledge, intelligence, wisdom, insight, feeling... evident either in some product of the mind, as a learned paper, argument, work of art, etc." (知識、知能、知恵、見識、意識の量 <中略> こころの産出したものや学術論文、議論、芸術作品などで明らかになるもの。)この定義でも明らかなように、深み (depth) とは極めて個人的な用語になりうるし、多数の人にとってそれぞれ異なる意味を持ちうる用語です。
私は、プレイヤーが、あるゲームメカニクスをマスターしたことを繰り返し披露するポイントが「深み (depth)」だと考えています。チャレンジとは、退屈し始めるほど長くてもダメなら、マスターしたメカニクスを存分に楽しめないほど短くてもいけません。
この意味での「深み」は、できるだけ多くのメカニクスに持たせたいものですが、それを獲得する方法はそうハッキリとはしていません。
私の経験上、ゲームメカニクスに深みを獲得させるには非常に重要な要素が 2 つあります。
- 明確な目的が必要: プレイヤーが、ゲームを進めるために何をすべきか理解した状態にする。混乱や邪魔が入り込むと ― 例えばゲームを進めるために様々な手法を手当たり次第に試さなければいけないような状況が生じると ― プレイヤーはメカニクスの深みが足りないのではないかと感じる。
- バラエティ豊かな、有意なスキル (Meaningful Skills) が必要: これがあれば、ゲームデザイナーは優れたチャレンジを作成でき、プレイヤーはそういったチャレンジを通じてスキルをマスターすることができる。
目標
チャレンジの開始時には、プレイヤーが目標を察することができるようにしておくべきです。その他、チャレンジの進捗情報を視覚化するのも有効な手でしょう。
明確な目標の提示は、ゲームメカニクスに深みを与える上での必須事項といえます。前述した通り、プレイヤーが取り組んでいるチャレンジの完了条件を理解できない場合には、意欲がそがれ、マスターしたゲームメカニクスを披露するかわりに、あてずっぽうに物を試すようになります。
有意なスキル
有意なスキルとは、チャレンジを開始から完了まで進める上で使う必要があるスキルすべてのことを指します。言い換えれば、(訳注:デザイナーの) 仕事は、プレイヤーがチャレンジの目標を把握した瞬間から始まるわけです。
ここで、有意なスキルについて改めて確認しておきましょう。「有意な」という単語は、この手法で非常に重要な意味を持ちますから。スキルがあまりに基本的に過ぎれば、ゲームメカニクスに深みを与える役目を果たさなくなります。そうなった場合スキルは、例えば買い物リストの項目にチェックマークをつけていくような、終わらせなければならない単純なタスクとなってしまうわけです。
基本的過ぎるスキルの古典的な例としては、「ポイント A から B へ移動する」というものがあります。 これほど根本的な移動操作をチャレンジにしてしまうと、プレイヤーにとっては「クリアするにはコントローラーのボタンを押し続けよう」と言われているのと同じになってしまうわけです。基礎的なものであっても、単純すぎて深みはないのです。
ここでよく考えてみて欲しいのは、「ポイント A から B へ移動する」というのはチャレンジの目標であって、目標を達成するために必要なスキルのことではない、ということです。
ほんの些細な区別に聞こえるかもしれませんが、実際、これは非常に重要な事です。ゲームメカニクスをデザインするとき、この切り分けができるようになれば、(いつもなら見過ごしていたであろう) 深みに関連する問題を認識できるようになります。
有意なスキル: 徳のお話
Ratchet & Clank 2 のジュニアデザイナー時代、私はゲーム中の 2 つ のレベル向けに「トラクタービーム」を使ったパズルを考える仕事を割り当てられたことがありました。トラクタービームは、特別なマークのついた巨大オブジェクトを自由に動かせるようにするゲームメカニクスで、本質的にはゼルダの伝説などのゲームにある古典的なブロックプッシュ型のチャレンジに、演出を加えて作り直したものです。
トレーニング向けのものはすぐに思いつきました。単純にブロックをポイント A からポイント B に移動させて、移動したブロックの上に飛び乗って脱出する、というものを作ればよかったからです。しかし問題はそこからです。高度なチャレンジが考えつかなかったのです。ここで私はすぐに行き詰まりました。 ブロックを別の場所に動かすというのは、スキルと呼ぶにはあまりにも基本的でした。トレーニング以降のチャレンジの難易度を「高めて」、徐々に難易度を上げながら多様なチャレンジを作ることができなかったのです。
つまるところ、当時の私はまだ、「有意なスキル」と「基本的すぎるスキル」の区別がついていなかったのです。また、明確に理解できる目標がどれほど重要かということも理解していませんでした。経験が足りなかった当時の私は、最終的にメカニクスに十分な深みがつくまで、フィーチャー (feature) を追加していくことにしました。今ウワァ…と言ったあなた、仲間ですね。 私自身も、これを書きながら私もウワーと言っています…。
最終的に私は、ブロックをあちこち動かすことは一旦忘れておき、ロボットを掴んで引きずり回せたらすごいんじゃないかというアイデアを思いつきました (今「なるほど、演出上のてこ入れ、ね」と思ったあなた、クッキーあげます)。そしてそこから、掴んだロボットをプレイヤーがボタンの上に落とすと、ドアが開くという仕組みを考えました。ただこのアイデアでは思ったほど深みが得られず、メカニクスは浅いままでした。
そうして私は、頑張ってフィーチャーを足していったわけです (ウウウ...)。
次に、(トラクタービームで動かせるアイテムとして) 爆弾とスリングショット (パチンコ) を追加して、ドアを爆破したり、爆弾を飛ばしたりできるようにしました。
さらに、ブロックを使ってレーザーを遮断できるようにし、うまく使うと通り抜けられるようにしました。
さらにさらに、特定のドアを爆破できる爆弾ロケットを内蔵したスペシャルブロックも追加しました。
そして最後に、ブロックをフロアの溝にはめこむ仕組みを追加しました。これは指定の順番にブロックを配置させるもので、複数のブロックを使わないと溝が埋まらないため、ブロック同士が邪魔になるという仕組みでした。
そしてフィーチャーの追加が終わるころには、私の名前は何人かのプログラマの「あいつだけは許さないリスト (Hate List)」に深く刻まれることとなりましたが、一方でトラクタービームのゲームメカニクスは急速に肥大化し、大きくなりすぎていました。プレイヤーが遊ぶには複雑になりすぎていたのです。プレイテストのチームからは「プレイヤーが何をしたらいいかわからない状態が続く」というフィードバックが返ってくるようになりました。最後には、プレイヤーが何をするべきなのか理解できるよう、全体の半分の時間をトラクタービームのトレーニングに充てる羽目になりました。
今振り返れば、あのメカニクスが深みを獲得できなかった理由は明白です。新しい目標ばかりを追加して、有意なスキルを追加できていなかったのです。
以下ではもう少し詳細に見ていきます。上の例を出したのは、目標と比べて有意なスキルがどれほど深みを与えるのかを強調したかったからです。
この経験から、私は貴重な教訓を学びました。それは「深みが足りないと感じるゲームメカニクスの多くは、目標ばかり多くて、有意なスキルが足りない」というものです。
ステートメントを作成する
もしあの時に戻れたら、トラクタービームのメカニクスを深めるため、今の私はどんな手を打つだろうか?今の私が最初に思い浮かべるのはセグメントのチャレンジごとに「アクティビティステートメント」を作成することです。
アクティビティステートメントとは、チャレンジと目標と、プレイヤーがチャレンジをクリアするためにマスターする有意なスキルの両方を、シンプルな文章で記したチャレンジの説明文のことです。
例えば、台をのぼるチャレンジのアクティビティステートメントは「(プレイヤーに) ゴールの台までジャンプしてのぼって欲しい」のようになります。このとき「ジャンプしてのぼる」が有意なスキル、「ゴールの台」が目標です。
より複雑なアクティビティステートメントとしては「(プレイヤーに) 垂直にダブルジャンプしてからグライダーにつかまり、ゴールの台までたどり着いて欲しい」や「(プレイヤーに) 噴き出す炎に当たらないタイミングでジャンプして欲しい」などが考えられるでしょう。
上記のアクティビティステートメントには、目標と有意なスキルの両方が混ざっています。 ではそのうち一方を削除してみるとどうなるでしょう?チャレンジに明確な目標がないと深みが出ない、というのは見てきました。しかし、浅いと感じられるゲームメカニクスには目標が多数あり、有意なスキルが少ない傾向があるのも本当です。
下記に、「昔の私」がデザインしたトラクタービームのチャレンジをアクティビティステートメントにしてまとめてみました。
- 「(プレイヤーに) ロボを初期位置から床のボタンがある場所まで移動させて欲しい」
- 「(プレイヤーに) 爆弾を初期位置から指定のドアの前まで移動させて欲しい」
- 「(プレイヤーに) ブロックを初期位置からレーザーがブロックされる位置まで移動させて欲しい」
- 「(プレイヤーに) 爆発ロケットブロックを床のボタンがある場所まで移動させて欲しい」
お気付きのとおり、上記ステートメントには目標はありますが、有意なスキルがひとつもありません。そして 4 つのステートメントの目標はすべて同じで、しかも内容は大して面白くないのです。
ステートメントの内容は基本的に「ポイント A からポイント B まで移動しろ」というものです。これまで見てきた通り、こんなに基本的なスキルではゲームメカニクスに深みは出ません。
昔の私がデザインしたあと 2 つのチャレンジは、多少の「深み」を与えていたようです。
- 「(プレイヤーに) 爆弾を初期位置からスリングショットまで移動させ、スリングショットを発射して敵を爆破して欲しい」
- 「(プレイヤーに) 溝に沿ってブロックをスライドさせて、指定の順になるよう並べて欲しい」
この 2 つのアクティビティステートメントにある「スリングショットを発射して敵を爆破する」や「指定の順になるよう並べる」は、他のスキルに比べてだいぶ有意なものだと言えるでしょう。
これらを踏まえた上で過去の私にアドバイスすると、次のようになります。
- 基本的すぎるスキルや目標の大部分を取り除く: 過去の私が作ったチャレンジの大半は、突き詰めれば「ドア近くにあるオブジェクトを拾ってドアを開けろ」と言っているようなもので、それが爆弾でも爆発ロケットでも同じです。冗長な部分は消し飛ばして、プレイヤーのほうを向いたシンプルさを追求しろよ! 昔の俺!今すぐやれッ!
- より深みのあるメカニクス 2 つを精査して、メカニクスひとつにつきチャレンジを 2 つ作る: 昔の私は、チャレンジごとにアクティビティステートメントを書くところからデザインを始めるべきです
- 新しいチャレンジをゲーム内で動くプロトタイプにする
- 新しいチャレンジをプレイテストする
- それでも全体的に浅い場合は、リストに "有意なスキル" (「目標」ではない点に要注意!) を追加して、ステップ 1 からやり直す
メモ: これまでに扱った例はパズル的なゲームプレイばかりでしたが、パズルを作るための話をしていあるわけではありません。この「考え方」からは、様々なタイプのゲームメカニクスを考える上で有益なアイデアが得られると思います。
例えば、銃を使った戦闘のメカニクスが「浅い」と感じるとします。その理由はもしかして「銃を使って敵を殺す」が有意なスキルにならないからではないでしょうか?実際、それでは「目標」です。 『Ratchet & Clank』において、銃を使った戦闘のアクティビティステートメントは「正しい武器または複数の武器の正しい組み合わせを選んで、可能な限り効率的に敵のグループを殺すこと」のようなものでした。
デザインのフェーズにおいてアクティビティステートメントを使うようにすると、有意なスキルを (およびそのベースとなるメカニクスも) 従来よりも確実に含められるので、ゲームデザイン全体に深みが増し、満足度も高くなります。
アクティビティステートメントを曖昧にしない
アクティビティステートメントは極めて有用なツールですが、使い方によっては面倒のもとにもなりえます。例えばアクティビティステートメントを曖昧にしてしまうと、すぐに問題が生じます。
これ以降では、『Portal』のゲーム内のほぼすべてのチャレンジに適用できるシンプルなアクティビティステートメントを例に見てみましょう。
- 「(プレイヤーに) ポータルガンを使って、ブロックをボタンの上に移動させて欲しい」
このシンプルなアクティビティステートメントに提示されたスキル (ポータルガンを使う) は有意なスキルになっていますが、このような曖昧なステートメントだと、幸運に恵まれない限り問題が生じることになります。
『Ratchet & Clank』シリーズにおけるクランクのゲームプレイは良例です。
クランクのチャレンジは Insomniac 社のデザイナー (私自身も含めて) にとっていつも悩みの種でした。デザイン中は深みのあるアクティビティになったはずだと思っていたアイデアが、いつもそうならなかったからです。
そういった場合、個性を足したり思い切ってシンプルにすることで対応しました (そう、演出の改良です!)。しかし満足いくまで深みを出すには、何度もやり直さなければなりませんでした。プレイヤーの皆さんには好評だったようですが、社内ではもっと良くできたと思っていました。
『Ratchet & Clank』シリーズの最初の 2 作では、ガジェボット (コロコロついてくるかわいい小型ロボ）に障害物エリアを通り抜けるよう命令を出す場面がありました。障害物エリアは複数種ありましたが、結局は全部同じような感じになってしまいました。エフェクトやかわいいアニメーションは追加したものの、やはり基本的にはかなり浅いものだったと思います。
アクティビティステートメント「(プレイヤーに) ガジェボットたちに障害物エリアを通り抜けるように命令を出して欲しい」は、結局のところ曖昧すぎました。このステートメントでは、メカニクスが深いかどうかを判断するための情報が足りなかったのです。
それでは時間を早送りして『Ratchet & Clank Future: A Crack in Time』を見てみましょう。この作品でクランクは、アクションを記録して、ホログラムに記録したアクションを再生させる能力を手に入れます。
こういう能力があると、非常に複雑なアクティビティステートメントを持ったチャレンジをデザインできます。たとえば、「(プレイヤーに) ドアを開けるボタンまで行く動作を記録して欲しい。その後、記録した動作を再生して、ホログラムがボタンを押してドアが開いたらドアを通り抜けて欲しい」のように。ここで「ボタンのところまで行ってドアを開けて欲しい」や「ドアを通り抜ける」というのは明確な目標に、「行動を記録する」、「記録した動作を再生する」という優れた有意なスキルになっています。
この例では、メカニクスは深みを増し、アクティビティステートメントの曖昧さも大幅に減っています。
演習: 深みを与えてみる
では、手元にゲームデザインがあって、すごく面白くなりそうなアクティビティステートメントがあるとしましょう。しかし、プロトタイプを作ってみた (あるいはそれ以上進めてみた) ら、どうもメカニクスが浅いように感じられます。次に何をすればいいでしょうか?
まずは出来ているものを評価してみましょう:
- 目標を特定し、全部挙げてみましょう
- 各目標について「この目標はリストにある他の目標と機能的には同じではないか?」と自問してみましょう。同じものがある場合は、本当に必要かどうか吟味してください。本当に、この目標を達成する方法をプレイヤーに教えたいですか?この問いに対する答えが「いいえ」ならば、対象の目標に取り消し線を引いてしまいましょう。
- 有意なスキルを特定し、全部挙げてみましょう
- 有意なスキルそれぞれについて、「これは本当に有意なスキルだろうか?」、「スキルが基本的すぎないか?」、「目標ではないか?」と自問してみましょう。
- 「この有意なスキルは、リストにある他の有意なスキルと機能的には同じではないか?」と自問してみましょう。もし同じであれば、取り消し線を弾いてしまいましょう。同じものがあるということは、「有意なスキル」の数を過大評価してしまっているということです。
これで、出来ているものの評価は一通り終わりました。さて、目標は多すぎないですか?有意なスキルが不足していませんか?この時点では、おそらく、そうなると思います。ここで、トラクタービームの例で「昔の私」に対して出したアドバイスをなぞってみましょう:
- 新たに有意なスキルをリストに 1 つ以上追加してみましょう
- 追加するときには、必ず上記の質問、「このスキルは本当に有意なものだろうか?」、 「基本的すぎないだろうか?」、「本当に目標だろうか?」を繰り返し自問しましょう。
- すべてのチャレンジを見直して、アクティビティステートメントを改良してみましょう。
- 新しいコンテンツのプロトタイプを作成してみましょう。
- プレイテストしてみましょう。問題は解決したでしょうか? 解決したら、これで OK です!
- 問題が解決しない場合は、手順 1 に戻ってやり直してみてください。
考慮すべき事項
本稿の最初に述べたとおり、「メカニクスに深みを持たせる」というのは常にやるべきことであるとは限りません。メカニクスに深みを持たせるには大量の作業が必要になります。その前に、以下の項目を自問してみてください。
- このメカニクスに深みを持たせたとき、対象ユーザーは楽しんでくれるだろうか?
- 低年齢層向けのゲームでは、浅めのゲームメカニクスをたくさん用意する傾向があります。その優れた例が『Lego Star Wars』でしょう。この点、同作は非常によくできています。
- 対象ユーザーは本当に深みを求めているだろうか?比較的カジュアル向けゲームでは、アクティビティの深みよりもバリエーションのほうが効果的です (フィットネスゲームや『WarioWare』などがこれにあたります)。
- 「チャーミングな」ゲームメカニクス
- メカニクスの最重要目的が「チャーミングさ」や「個性」を表現することである場合、深みや高度なチャレンジはプレイヤーにとっては過剰に凝ったものとなり、逆に邪魔になってしまう可能性があります。
- 上述した『Ratchet & Clank Future: A Crack in Time』のクランクのゲームプレイは、この事項の良例と言えます。
- 行動を記録するゲームプレイ要素は、ゲームレビューの評価では賛否両論となりました。
- またこのメカニクスを導入するため、プレイヤーは大量のトレーニングをこなしてヘルプメッセージを読まなければなりませんでした。ゲーム全体で見ればごく小さなボリュームしか占めないメカニクスだったことを考えると、あまり理想的とは言えません。
- クランクのセクションは、プレイヤーの目には「面白いサブゲーム」のように映ったかもしれませんが、新スキルの習得に長々と時間がかかることが避けられる要因にもなったかもしれません。
- 物語のゲームメカニクス
- 一部のゲームメカニクスは、プレイヤーに何かを「感じてもらう」ことや、物語を伝えることを目的としていることがあります。この場合、深みや高難易度は「感じて欲しい」ことを伝える上で邪魔になる場合があります。
- 『Indigo Prophecy』と『Heavy Rain』の 2 作は、全体を通じて物語の (Narrative) ゲームメカニクスをうまく扱っていると思います。
ひととおり終えて、メカニクスの「深み」が望むレベルに達したと判断したら、各メカニクスに明確な目標と有意なスキルのセットが備わっていることを再確認しましょう。上述の演習を活用しながら、基本的すぎるスキルと有意なスキルをしっかり見極めるようにすれば、ゲームメカニクスの評価とトラブルシューティング、深みの付与がうまくいく確率は高くなるでしょう。
おわりに
本稿では、ゲームメカニクスをブレークダウン (分解、Break down) していく具体的な方法を提唱してきました。 また目標と基本的過ぎるスキルではなく、有意なスキルに注目することの重要性を指摘してきました。
本稿で解説した手法は、私自身は要素のブレークダウン手法として非常に有益だと思っていますが、これが他の手法よりも「正しい」と主張する意図は一切なく、多数ある有効な手法の一つであると考えています。
フランスの数学者アンリ・ポアンカレ (Henri Poincare) 氏は著作『科学と方法』(Science and Method) で「幾何学とは真理ではなく便宜である(訳は LYE、超門外漢なのでちゃんと解釈できてる自信なし)」(Geometry is not true, it is advantageous.) と述べています。
これは、ゲームデザインの思考モデルについても当てはまります。どの手法も真理ではありません。便利であるだけです。私自身にとって、ここに提案したモデルはゲームメカニクスの深みを評価、予測、トラブルシュートする上で、非常に有用なものでした。同様の目的に活用するのであれば、きっとあなたのベストパートナーになってくれることと思います。
