前置き
こんにちはヾ(＠⌒ー⌒＠)ノ
癒し系魔法エンジニアとして前回の記事担当の@mix3から紹介されました@p_chinです('Θ' )
普段はPOCKET FOOTBALLERというゲームの新機能開発などをやっておりますフロントエンジニアです。( 'Θ' )
今回はこちらの開発中に作成したローカライズのシステム周りの一部について書いていこうと思います( 'Θ')
本投稿はTech KAYAC Advent Calendar 2015の12/19の内容になります。
目次
開発の経緯
このポケフトというアプリは大前提として、初回リリース時から世界公開を目標にしていたプロジェクトでしたので、ワンバイナリで多言語表示に対応したゲームを作成する必要がありました。
まぁ他にも過去のつらい経験の反省を生かしてワンバイナリでローカライズ出来る様にした...という経緯も個人的にはありますので過去のローカライズ事例については、昨年のAdventCalenderで触れているので良かったらどうぞ。
ローカライズシステムの簡単な概要
初回起動時に標準言語を決定する処理フロー
標準言語はモバイル端末のOS設定から決めます。
- アプリ起動
- 対応言語リストをサーバーから取得
- ここまでにユーザーへ伝える情報(エラーなど)は、とりあえず英語で表示
- 初回起動端末ならばOSの言語設定が対応言語リストに含まれてれば表示言語をそれに自動決定
- OS設定の言語が未対応ならば、とりあえず英語を表示する
基本機能
- 起動後→AssetBundle読み込みまでの翻訳はアプリに組み込まれてる
- その他の翻訳はTextAssetとしてAssetBundleから配信されている
- 翻訳テキストはkey&value形式で管理されていて、keyから現在の言語の文字列を取得する
- (NGUIの標準のローカライズ機能を使用)
ローカライズ補助ツールについて
翻訳テキストの管理
ポケフトではNGUI3.0.6f7を使用していたので、言語毎に {language}.txt を用意して、それをNGUIのLocalizationコンポーネントに参照させて翻訳処理を行っていました。
過去にローカライズしたプロジェクトではエンジニアが温もり溢れる手動編集でja.txtとen.txtの翻訳を編集していたのですが、ポケフトは初回リリース時に対応する言語が当初は5ヶ国語あったので手動でエンジニアがメンテナンスするのは辛そうです。
なので、GoogleSpreadsheetで翻訳を管理して、そこから各言語の翻訳txtを出力するシステムを弊社技術基盤チームの@sumipanに作成していただいた感じです。
ちなみに現在は専用のgithubのissueからsetup {unity_project_repositry_branch_name}と入力するだけで翻訳の出力が完了するというよしなシステムになって稼働中です。
github-scriptというgemを使って可能にしてる様です。
Sceneにハードコードされたtextを検知するテスト
.unityや.prefabなどのComponentの情報がシリアライズされてるファイルの中に文字列がハードコードされていた場合にはgithubのpull-requestのテストが失敗するという仕組みです。
NGUIのUIlabelというゲーム内のラベルを制御する為のComponentがあるのですが、そちらのmTextというシリアライズされたフィールドに何かしらの文字が入っていた場合にpull-requestのテストを失敗状態にします。
※ちなみにmTextとはUnity上では以下の様に表示されてる値のことです。
こちらの仕組みもissueを書いたら@sumipanに作って頂けたので技術基盤チームは素晴らしいと思いました。
この仕組みが必要になった経緯
Sceneのセットアップ処理の中でExceptionが起きてしまった場合に製品版のアプリにハードコードされた文字が不本意にユーザーに見えてしまう可能性があるのが危険だと思っていたのが理由です。
たとえば『うんこ』とハードコードされたままリリースしてしまい、Sceneのセットアップ時にこのtextを設定する前の処理で例外が発生して画面が見えてしまった場合には大問題ですよね。
また、多言語化を想定したゲームだったので、英語の言語設定してるユーザーがいきなり日本語を見てしまった時には不快になると思ったのも理由の一つです。
画面作成ルール
ゲーム画面のローカライズをするにあたって、開発を効率化する為にプロジェクト発足時に幾つかのルールを決めました。
デザイン上のルール
基本的に画像にラベリングする(ローカライズする必要のある文字を書く)のをデザイナーに避けてもらっていました。
理由
ラベリングすると、その画像の翻訳管理をしなければいけなくなるからです。
その為、デザイナーから強い要望が無い限りは、ゲーム内に埋め込まれてるフォントの文字列をゲーム内に表示する方針にして貰っていました。
過去のプロジェクトをローカライズした時に、ラベリングされた画像が多かったので翻訳のコストが高かった経験も生かしての判断でした。
テキストが描画範囲を超えた場合のルール
以下の画像の通りです。(デザイナーが画像でルールを定義してくださってたので抜粋してみました)
画面に表示する文字列をmTextにハードコードしない
先ほどSceneにハードコードされたtextを検知するテストの項目で説明した通りです。
参考資料
文字列管理などの思想が個人的には結構良いと思っててローカライズシステムを設計する時の参考になります。
（僕はシステム作り切った後で見ましたが。。）
終わりに
さて、一部のみの紹介になってしまいましたが如何でしたでしょうか？
githubに挙げられるコードは用意出来なかったのですが、今後ゲームのローカライズする方のお役に立てれば幸いです。 :pray:
さて、明日は谷脇さん(@mackee_w)による『人体と電気』についてのエントリーになります！
楽しみですね[-o-]
→ 
