Commentsこんにちは、架け橋ゲームズ矢澤です。ご無沙汰しています、お陰様で架け橋ゲームズはそれなりに忙しくやっております。どちらも翻訳は完了して現在テスティング中なので、そう遠くない未来にお披露目できるのではないかと!それからまだ名前は出せませんが、2タイトルのローカライズに携わらせていただきました。これも発表OKになったら報告させていただきます。こんなにたくさんのインディーゲームに携わることができ、矢澤はいち翻訳者として本当に幸せな時間を過ごしておりますよ...。本日は、特にウチが携わったタイトル固有の話ではないですがインディーゲームのローカライズを開始する前に見つかる、一般的な問題について説明してみたいと思います。働いていたけど独立した人から、学校を卒業して/在学中にゲーム開発を始めた人までそのバックグラウンドは実に様々です。(もちろん、独立後にコーディングを学んだりしている人が大多数ですが)。非プログラマの人が担当することも結構な割合で多くなっているのです。商業ゲーム開発に取り組んだことのある人でも、ローカライズに深く取り組んだ人はかなり稀です。このような事情があり、従来までのパッケージタイトル向けローカライズ手法は「時に」インディーゲームのローカライズで機能しないことがあります。これはある種、ゲーム開発の民主化の副作用とも言えるでしょう。同様のことが起きていると考えられます。ローカライズにおける課題となるのは具体的にどんなコトなのでしょう?今後はこの件について3回にわたり展開していきたいと思います。お題は、「テキストのハードディング」、「日本語フォント」、「文字列のエンコード方式」。第一回は、テキストのハードコーディングについてです。ハードコーディング昨今のパッケージ向けタイトルでは、ローカライズ対象テキストはプログラム的なコードから分離されて「一箇所に抜き出されて」おり、少し乱暴に言えばそのファイルを差し替えるだけでローカライズがほぼ完了します。プログラムの変更が必要になることもありますし、フォントの問題もありますし、音声やグラフィックの扱いはさらに複雑ですが、ものすごく乱暴に言うとそんなカンジです。「抜き出したファイル」は言い難いので、以後はコレをリソースファイルと呼びますね。仕組みになっているわけです。これを「テキストがハードコーディングされてる」と言います。ハードコーディングとはざっくり言うと「決め打ち」のことで、例えばローカライズの例で言えば「テキストは自国語版のみ」と決め打ちされた状態であると言えます。紛れ込んでいるわけです。手動で置換するなんて手間がかかります。ちなみに「ハードコーディングを避ける」というのは一般的なソフトウェア開発でもかなり徹底されていて、こないだ非ゲームプログラマをしている友人と話をしていたら「テキストのハードコーディングとか、ガンジーが助走つけて殴るレベル」と言っていました。(なぜなら、後でタイヘンな目に遭うのが自分なので)。分かったけど、ハードコーディングの何がダメなの?それでも「まあ一回我慢して突っ込めばいいじゃない?」と思った紳士淑女の皆様のために、この項ではコイツが引き起こす弊害について説明してみましょう。ゲーム本体の更新管理がクソめんどくさくなるまずコレ。同期管理するぜ!という宣言と同義であります。オリジナル版のゲームに変更を加えたい場合、まったく同じ内容をローカライズ版にも反映させなければいけないワケです。「やっべローカライズ版のコードに一個修正反映させ忘れたー>死亡」というワケです。誰もこんな事したくありません。リソースファイルに切り分けておくということは「ゲームのマスターデータ」と「ローカライズのマスターデータ」を分離しておくということです。これ超大事だしテストに出ます。無駄なヒューマンエラーのせいで作業量が倍増する翻訳者が一回目で完ぺきな翻訳を上げたとしても、テキストがハードコーディングされた環境ではデベロッパー側でゲームに入れ込む際にミスが生じることがあります。(俺が納品したデータでは全部正しいのに何が起きている!?)、入れ込み担当したプログラマも全然クリエイティブじゃない仕事で嫌になるしで誰も幸せになりません。何をするにも複数人が関与し、おまけに時間がかかるゲームの言語テストでは「実機で見てみると、ここは直したほうが品質良くなるな」みたいに、実機チェックして初めて見つかるアラというのがどうしても見つかります。こんな時、リソースファイルがきちんと切りだされた環境なら翻訳者が修正してデベロッパーは差しこむだけで済みますが、ハードコーディングされていると毎回毎回デベロッパーが修正反映させなければなりません。