この記事は前段の記事となります。
具体的な解決策は次の記事から。
次の記事
背景:ローカライズって面倒だよね
現代のインディーゲームのパブリッシュにおいて、ローカライズは必須となってきていますよね。
開発者としては、ローカライズがない前提の開発であれば、テキストを直接インスペクターに書き込んだりスクリプトに直書きしたいところです。ただし、そんなハードコーディングしたゲームをパブリッシャーさんや翻訳者さんに持ち込んだら、おそらく苦い顔をされることでしょう。
これまで完成させたゲームの場合
さて、僕がUnityで作ったゲーム(以下)ではどうしていたかといいますと、基本的には独自に実装していました。
1. アンリアルライフの場合
こちらはアドベンチャーゲーム。9ヶ国語に対応しています。テキストは10万字ぐらい。
2019年ぐらい?当時主流だったエクセルインポーターを使用していました。
xlsxで管理していました。
▼たしかこれ
2.ghostpia シーズンワンの場合
こちらはノベルゲーム。4ヶ国語に対応しています。
NuGetから必要なパッケージを取り込んで、Google APIを直接たたいて作りました。
▼近そうな記事
Unity Localizationの便利さ
近年は毎度まいど独自に実装していたり、アセットを購入す必要もなくなってきてますね。
Unityが公式にローカライズ用のパッケージを用意してくれているからです。
みなさんも一度は導入を検討したことがあるかもしれませんが、実際の使いやすさはどうでしょうか。以下はいち開発者の所感となります。
Unity Localizationの実用性
ローカライズの基本的な実装のほとんどを担ってくれているのが本当にありがたいです。
良い点を挙げたらきりがないですが、
- ロケーションのアレコレを全部やってくれてる
- CSV、SpreadSheetとのシート連携が容易
- Smart機能で変数や単位の表現拡張もできる
- 標準パッケージなので安心。技術を共有しやすい
- etc...
といった感じでしょうか。
1.CSV、SpreadSheetとのシート連携が容易
翻訳者さんとは基本的にSpreadSheetでやり取りしたいので、割と必須です。
シートからエディタへのPullだけでなく、エディタからシートへのPushもできます。
2.ロケーションのアレコレを全部やってくれてる
言語の切り替えも容易です。
3.Smart機能で変数や単位の表現拡張もできる
日本では「1日、2日、3日」と表現するが英語では「first day, second, day third day」になるなど
4.標準パッケージなので安心。技術を共有しやすい
リリースしてからの言語追加を別のエンジニアさんに任せることも多いはず。
そんな夢のようなパッケージですが、実用性は…?と聞かれるとあと一歩…!と思うところがあります。ありがたいことに機能がめっちゃ多いので、小さいプロジェクト等では機能過多かも…?と思うことも多いんじゃないでしょうか。
Unity Localizationの思うところ…
Unity Localizationを導入してみてしばらく使ってみたところ、心理的障壁になっているなと感じる部分がいくつかありました。
- StringTableCollection
- 設定や設計思想をとらえるのが少し難しい
⇒これはしょうがない - ①いつでもすぐにPullしたい(Pushはいいかな)
- ②いつでもすぐにスプレッドシートを開きたい
- 設定や設計思想をとらえるのが少し難しい
- LocalizedString
- ③Smartのチェックがめんどくさい
- ④ドロワーが重い
- ⑤(コード上)変数のセットがめんどくさい
- できたらいいな~という点
- シートに話者情報やコマンドを書き込める列を作りたい
シンプルに 機能過多な部分 があり、ちょっと使用感のカロリーが高めです。インディーゲーム製作に限る部分もありますが、やはりスムーズに使用するにはエディター上での手数が重要になってきます。
ということで、時間があるときにそれぞれの解決法について、書いていこうと思います。
次の記事