国内タイトルを海外向けに開発運用した経験を振り返る

本記事は[Craft Egg Advent Calendar 2021](https://qiita.com/advent-calendar/2021/craftegg)の12/8の記事です。
12/6の記事は@Tomy_0331さんの[【ツール】Toggle Trackを使ってみて](https://qiita.com/Tomy_0331/private/73bf19bc6574bb871498)
でした。

# はじめに

株式会社Craft EggでUnityクライアントエンジニアをしている中垣です。
私は今年の半ばくらいまで同グループ他社の国内向けに運用されているスマートフォン向けタイトルの海外展開バージョンの開発運用のプロジェクトに参画していたので、その時の経験で特に印象深いものについて書き留めておこうと思います。

※当時の開発環境はUnity 2019.4.9.f1を使用しています。

# どんな体制で開発していたか

発足時は大元の国内版タイトルから切り出した数名の少人数プロジェクトとして始動、その後元のプロジェクトの１セクションとして合流し開発をするといった流れでした。
その中で私の担当はクライアントに関わる作業全般を一名で対応しておりました。

また、このプロジェクトは国内版海外版ともに運営元が同一となることを考えて
海外版を国内版と同一のリポジトリ/ブランチで開発、ビルドは国内海外で別といった構成となりました。

運営元が別だとすると国内版のブランチを海外版のブランチに取り込んで運用すれば良いのですが、
それだと運用を続けていく中で国内版を取り込む工数が一生発生してしまうため、それなら同一ブランチで開発した方が国内版に影響が出ないように最初に開発してしまえばそれで済む！といった考えからの方針でした。
ちなみに、海外版の売り上げ目標が国内版と同等クラスだからプロジェクトとして同列に扱う、という精神的な理由も絡んでの選択でした。

ただこれもお互いに影響がないように開発する、という工数が発生するため必ずしもこちらがベターではないと言えると思います。実際に当初は別のプロジェクトの扱いで国内側は特に海外側への影響をほとんど考えていない状態での開発となっていたため、私の工数も殆どここに費やされたといっても過言ではありません。


# どんな対応をしたか

大きく、

- 言語のローカライズに関わる開発
- 海外の法律に関わる開発
- 海外ユーザをターゲットにした新規機能開発

と、ローカライズといえど単に言語の選択だけできるようにしたわけではありませんでした。
次はそれぞれの学びや苦労した点を振り返ります。

# 言語のローカライズに関わる開発

こちらはおそらく「海外向けにローカライズする」となった場合にパッと思いつく対応であるかと思われますが、
ゲーム内文字と音声が設定した言語になる対応です。
実際にやってみてまずよく発生した問題は日本語に比べて英語の一単語が長すぎるので改行が発生しUIが崩れるといった事象が頻発しました。↓(例
![スクリーンショット 2021-12-01 10.57.22.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2301970/cb475bf9-4ad1-69cb-1fab-f0b6b49b5af8.png)
これに対しチームでの対応方針は

- 再翻訳
- いい翻訳がなかったら、テキストボックスをギリギリまで広げる
- ボックスの大きさ変更では解決しない場合、デザインに変更を加える

の順序での対応となりました。
デザイン変更の優先度が低いのは国内版への影響が発生するためです。
同一のデータを触ることになるため、既に運用しているタイトルのUIを触るリスクがあるのでできるだけ回避していました。
再翻訳自体は短縮形を用いたり別の短い単語に置き換えるといったもので、意外にも一定の効果はありました。
(character->unitなど)

また多言語対応についてまわるフォントの問題への対応もありました。
特にこのタイトルではUIやシナリオなどのゲームパートによって使用するフォントが異なっておりそのフォントが必要になる状態で、フォントそれぞれの微妙な大きさの違いによるUI崩れが頻発しました。
通貨単位はフォントファイルのみでカバー出来ず以下のような処理でOSのシステムフォントを呼び出して表示する対応となっていました。

            // OSのフォントをfallbackFontに登録
            string[] fontPaths = UnityEngine.Font.GetPathsToOSFonts();
            UnityEngine.Font osFont;
            int length = fontPaths.Length;

            // 以下の処理ではOSのフォントを全て登録するため
            // 必要なフォントのみを検索し登録する方がよりメモリ負荷がかからない
            for (int i = 0; i < length; i ++)
            {
                osFont = new UnityEngine.Font(fontPaths[i]);
                var fontAsset = TMP_FontAsset.CreateFontAsset(osFont);
                font.fallbackFontAssetTable.Add(fontAsset);
            }

# 海外の法律に関わる開発

国内タイトルについて例えば資金決済法に基づいた表示をする必要があるように、海外にもアプリゲーム中に対応の義務がある法律・規則が存在します。
代表的なものが[GDPR](https://www.hitachi-solutions.co.jp/hibun/sp/column/leakage/03.html)で、ATTによる確認に加えて再度トラッキングへの同意を求める対応などを施しました。
また逆に日本の法律に基づいた表示に関しては日本で展開しないバージョンのため画面から取り除く対応をしています。

# 海外ユーザをターゲットにした開発

これらは言語ローカライズ以外の地域に沿った対応になります。
具体的な内容としては広告タップによるリワードにてアイテムを入手できる仕組みを実装しました。
ユーザは多いが課金ユーザ/課金額が極端に少ない国があったとして、課金してもらわないと売り上げがサーバ費用を上回ってしまい赤字になるリスクがありますが、ユーザ数の増加が見込めるのは魅力的といった状況がある場合に対してすることで単純な課金以外から収益を発生させることができリスクを回避できる、といった考慮からの実装です。
他にも日本では法律上実装不可なコンプガチャなどの仕組みを取り入れたりなども可能となりますが、課金施策が本国版より多くなることへの批判や広告が出ることによる世界観の崩壊などには注意が必要です。

この辺りの戦略については、[AppAnnie](https://www.appannie.com/jp/)の有料プランにてグローバル展開しているタイトルの各国での実績を参考にして立てていました。

また、ゲームアカウントをFacebookのような海外でユーザ数が多いSNSと紐付ける機能の対応なども行なっています。
Appleの規約で外部SNS連携を行う際はAppleアカウントとも連携できる必要があるため注意が必要です。

# その他開発中に経験したこと

- 読めない言語の表記バグは気づかない

例えばハングルなどは読めない人間には図形にしか見えないので簡単な表記間違いでもなかなか気づけないです。ネイティブの方のLQAは必須だと感じました。

- 同じ機種のスマートフォンでも国によって仕様が異なる場合がある

特定端末で発生する不具合などの対応で海外仕様版の端末を手に入れる必要が出てくる場合があります。

- Unityプロジェクトで一つのブランチで二つのアプリを生成しようとするとAndroidManifestの扱いが大変

URLスキームを同一にできないなどの問題が出てくるので、プリビルド時にAndroidManifestを直接書き換える仕組みを導入しました。


# まとめ

実際のプロジェクトの話なので具体的な例を挙げることができなかったりしましたが、海外向けの運用も内部でやることを見据えて開発する経験は貴重なものだったので書ける範囲で書き留めてみました。
海外展開を考えている方々に少しでも参考になる情報があれば幸いです。
ここまで読んで頂き、ありがとうございました。

Craft Egg Advent Calendar 2021 明日は@aluminum1981さんの記事になります！