アナタのもう一つの物語

ロマフェリの開発日誌#5:ゲーム内に翻訳を実施

今回の開発日記では前回のロマフェリ開発日誌#4で始まったローカライズについての話の続きをしたいと思います。今回のテーマは私たちがどのようにして翻訳を行っているのか、という技術面についてお話してみようと

続きを読む

ロマフェリの開発日誌#4: ローカライゼーションの基本

今回の開発日記ではロマフェリの主な特徴のひとつであるローカライゼーションを取り上げたいと思います。ゲーム開発業界のグローバル化、デジタルで出版することも一般的になってきていて、(できるだけ多くの)様々

続きを読む

ロマフェリの開発日誌#3: UIとUXのより良い理解へ

ロマフェリの開発日誌も第3回となりましたが、このような開発の思考や失敗から学んだことについての記事が少しでも皆さまの興味を引くことができるものになっていればと思います。今回は、これまでの開発の中で試行

続きを読む

今回の開発日記では前回のロマフェリ開発日誌#4で始まったローカライズについての話の続きをしたいと思います。今回のテーマは私たちがどのようにして翻訳を行っているのか、という技術面についてお話してみようと思います。特に、翻訳システムの仕組みについて、そしてどのようなハードルに直面し、現在も直面している問題とは何なのか?等の質問を答えてみたいと思います。

Ren’pyの翻訳フレームワーク

基本的な翻訳を済ませたあと、どうやってゲームにその作ったものを実装していますか?ゲームによって違いますが、翻訳ファイルのフォーマットを決めるために翻訳フレームワークをまず決定しないといけないので、多くの場合はそこから始めていると思います。

ロマフェリの場合は、Ren’pyというビジュアルノベル用の特化したオープンソースのエンジンをゲームエンジンとして利用しています。Ren’pyはマルチリンガルに対応したエンジンとしては長い歴史を持っているのでもちろん組み込み翻訳フレームワークが備わっています。

このしっかりした、わかりやすいシステムは、自分の考えたアイデアをゲームにしたいけどプログラミングに詳しくないというRen’pyのターゲットユーザーにはぴったり合います。ですので、Ren’pyは翻訳が簡単にできるように目的言語のフォルダーに元の言語のファイルのコピーを作成する仕組みを用いています。それで翻訳者がスクリプトファイルに直接働いて、自分の言語でスムーズに流れるように微調整できます。

そういった方法で翻訳を行う場合はシンプルで簡単であり、もうスクリプトが変わらない完成しているゲームの翻訳には適しています。ですが、残念ながら私たちのゲームでのニーズはもっと複雑なものです。私たちの翻訳フィロソフィー、途中から言語変更を可能にすること、長時間の早期アクセスで定期的にアップデートすることには不向きです。そのうえ、数人のライターと翻訳者と協力しているため、Ren’pyの翻訳フレームワークより協力に基づいているシステムを使った方が理にかなっています。

適したツールをさがして

従って、自分たちで翻訳システムを作ることを考えざるを得ませんでした。でも、それを始める前にどの機能が必要かについて考える必要がありました。そうして検討することにより、よく使われる翻訳ツールを調べてどれが一番ニーズに合っているかを探すことができます。

翻訳ファイルのフォーマット

スクリプトファイルで翻訳文を保管するRen’pyの翻訳する方法がうまくいかないとわかったため、別のフォーマットを見つける必要がありました。運よく、テキストとコードを別々に行う方法について広く知られているローカライゼーション方法が存在していました:gettextがその方法です。本質的にいうと、人間に可読な形式である翻訳ファイル(POファイル)をコンパクトなゲームエンジンに可読な形式であるファイル(MOファイル)に変換するプログラムです。WEBサイトやソフトウェアのローカリゼーションならびに、多言語対応ドキュメンテーションによく使われているシステムなので、私たちのゲームとも相性がいいと期待しました。

翻訳された文章の保管

次に解決する問題はどうやって翻訳された文章を保管するかです。ライターと翻訳家にとって扱いやすく、ゲームに求められるどんなフォーマットにも変更ができて、管理とバックアップが簡単なものが必要でした。

最初は翻訳家にとって使いやすいと思われ、一般的にも多く使われているエクセルファイルを試してみました。ゲームのプレビュー版を完成させる分には足りましたが、複数人のライターと翻訳家がいるため、ファイル管理がとても大変でした。

すでにデジタル翻訳はスタンダードですし、gettextでエクセルファイルをPOとMOファイルに変更しているため、最初は直接POファイルへ書き込む作業の代替案として考えました。エクセルやワードみたいな複雑なフォーマットではなく簡単なテキストファイルなので、それでファイル管理の問題が解決できます。ただし直接POファイルで作業するのは手軽にできるものではないので、多くの翻訳家はもっと使いやすいインターフェースを提供する別のプログラムを使います。

二つ目に考えた代替案は独自にWEB上のツールを作ることでした。自分で作ることにより、ほしい機能もすべて実装でき、自分のニーズにも合わせられます。それに加えて、出来上がったツールのクオリティが高ければ販売できる可能性もあります。でも、正直に言うと翻訳ツールとゲームを同時に開発できる人材がいないので、(とりあえず)その提案を断念しました。

結局、すでにあったWeblateというWEB上のツールを使ってみることにしました。ライターと翻訳家にとって使いやすく、しっかりしたバックアップとバージョン管理システムがあって、gettextにも対応しているので、今のところはうまくいっています。ただし、欠点ももちろんあります。特に、定期的なメンテナンスが必要なのと、直接ゲームに入れられるMOファイルをWEBからダウンロードする方法がないという、簡単に解決できない2点の問題があります。後者に対しては素早くゲーム内テストができるように最新のPOファイルを引き出してMOファイルをビルドするための小さなスクリプトを作りましたが、それを設置するのが大変、そして決まった環境でしか使えないので、業務受託者には使えません。将来的にライターと翻訳家が直接WEBツールから正しいファイルをダウンロードできるようにアドオンを作成する予定がありますが、しばらくはやりくりして処理せざるを得ません。

翻訳IDを使用

フレームワークに対して必要となることを探り出すための最後の問題は、ゲーム側でどの文章をどこで使うのかを指定するためのIDを管理する方法を決めることでした。ほとんどの翻訳フレームワークは基本的に元の言語の文章をIDとして割り当て、一致しているIDを持っている翻訳文を表示します。たとえば、元の文章が「おはようございます!」とすると、英語の「Good morning!」とうい文章のIDも「おはようございます!」になります。

私たちがその方法を利用しようとすると、当然、3点の大きな問題が出てきます:1)一つの原言語がない、2)ほとんどの文章が長い段落、3)テキストがよく編集やアップデートされてIDもどんどん変わってしまう。それで、他のゲームでも見かけたやり方を私たちの解決法にしました:翻訳IDをユニークなストリングにします。上の「おはようございます!」の例では、「元の文章」を「MORNING_GREETING」などにしたら、それが英語と日本語(と未来に翻訳するすべての言語)のIDになります。このやり方にすることでスタッフが母語で文章を作成することが可能になり、テキストの編集も簡単に必要な分だけ行うことができます。

複雑な問題とでくわして

決まったフレームワークの中でCodeNekoがほしい機能を備えた翻訳システムを作ることに成功しました。そうして、やっぱり、使いだしてからすぐに問題が出始めました。Ren’pyのロールバックとヒストリーログはゲームの途中で言語を変更した場合に対応しておらず、ふりがなを表示するためのルビテキストがUI要素のレイアウトを壊してしまって、言語による文章の長さの違いが対話の流れにちょっかいを出す……などなど。

ある問題(たとえば、ロールバックやヒストリーログ)は単純に良い解決法が存在しないものです。でも、他の問題は解決法があるので、早期アクセス中に実装する予定があります。

様々なレイアウトを対応

ロマフェリ開発日誌#3で話した通り、言語によって言葉の長さが大きく変わって、そして表示されている文字数がレイアウトに大きな影響を与えます。テキストからアイコンに切り替えることである程度問題を避けられるところがありますが、どうしてもテキストが一番というところがあります。他にも考えるべきことが1点あります:読みやすさは言語と文化に影響を受けることです。例えば、映画のポスターを見ると、国によって全然違うスタイルとテキストがあります。そこまで激しく変える必要がないとも言えますが、言語によって一番よい文字のサイズ、行の空き具合、カーニングなどが違うのが現実です。国によっての違いを見ると、日本などの文化ではテキストや絵が込み合った「にぎやかな」レイアウトを好みますが、その一方で北アメリカなどの他の文化ではそれが悪いデザインと判断される場合もあります。ゲームのレイアウトはどの言語でも読みやすいものになっていることが理想ですが、実際にはどうしても不可能な場合もあります。ロマフェリの場合はルビテキスト(ふりがなを漢字の上に置く方法)の表示でこの問題が明確になります。

ルビテキストの表示例
ふりがなを置くための必要なスペースはレイアウトを崩してしまいます

日本語ではすでに行の間が英語より広いのに、ふりがなが読めるようにするためにはさらに空けないといけません。増えたスペースへも対応できるように頑張りますが、フォントサイズと行の高さを調整するだけでは足りない場合が出てきます。

この場合には(同じような対応が必要となる言語が出てきた場合にも)、ルビテキストのために特別なレイアウトを作らないといけなくなります。現在では、私たちのシステムでは対応しているレイアウトの変更はその中のスタイル要素だけなので、レイアウト自体は変えられません。ロマフェリが1.0のリリースになる前に言語ごとのレイアウト対応を翻訳システムに追加していかなければなりません。

自然な対話の流れを保つ

もう一つ、文章が多いゲームによくある問題に私たちも出くわすと予想しています:言語によって対話の流れが変わってしまうことです。私たちの場合は翻訳に適するために台詞を編集することができるから今はまだこの問題が出ていませんが、完成したゲームに翻訳言語を追加するとテキストボックスが少なすぎる、または多すぎるところが出るでしょう。

これは一つのウィンドウで表示できるテキストに制限があるからです。言語とフォーマットで制限の文字数が変わってきますが、一定の場所に入る可読なテキスト量は限られています。では、ちゃんと翻訳するのに表示しないといけないテキストが利用可能な場所より大きいとどうなりますか?ある台詞が二つのウィンドウで表示しているのに翻訳したらウィンドウ一つで足りる場合は?

今まででは翻訳家が想像力を生かして(たまには笑ってしまうような)解決法を考えなければなりませんでしたが、今ではもうバイトと画面のスペースが高価だったコンピュータの暗黒時代ではありません。よって、もちろんある程度の柔軟性を備えないといけません。残念ながら、今まで試した解決法ではまだ成功していませんが、早期アクセス中には良いやり方を見つけて発売後にはよりたくさんの言語に翻訳対応した準備ができる自信があります!

実際に直面して私たちも学んだことなのですが、ローカライゼーションがこんなに複雑なことだなんて意外と思われるかもしれませんね!他のブログより技術的な内容でしたが、面白いと思っていただける内容になっていたら幸いです。またいつかローカライゼーションについて書くと思いますが、今回はこれまでにしたいと思います!

今回の開発日記ではロマフェリの主な特徴のひとつであるローカライゼーションを取り上げたいと思います。ゲーム開発業界のグローバル化、デジタルで出版することも一般的になってきていて、(できるだけ多くの)様々な言語にゲームを翻訳するのが当たり前になってきました。バイリンガルな会社として、ゲームを発売する際に英語版と日本語版が必要不可欠です。

ですが、「ローカライゼーション」という話題は一つのブログでまとめるには大きすぎます―毎回テーマに沿って長い文章を書いてしまっているブログですが、それでもあまりにも大きすぎたので……なので、基本から始めるために翻訳に対する考え方、方針、こだわりなどの「翻訳フィロソフィ」と世界中で発売するつもりのゲームを作る際に気を付ける文化の問題について今回のテーマにしました。

私たちの翻訳フィロソフィ

ローカライゼーションを始める前にまず私たちはどんな翻訳フィロソフィにするのかを決めることにしました。翻訳は化学よりも美術に近いもので、翻訳家ごとに自分のスタイルもあり、「良い」翻訳とはどんなものなのかの様々な意見もあります。会社別に見ても翻訳へのアプローチが全く違っています:一人の翻訳家にまるごと任せる会社もあれば、(たくさんの翻訳家と協力して)スタイルガイド、小辞典、厳しいルールを設けている会社もあります。

多くのメディアで使われている翻訳フィロソフィでは、目的の言語の文化に合わせるために文章のニュアンスや意味も大きく変えても構わないとされているようです。逆に、ファンや有志によって翻訳されたメディアは逆に元の文章に従いすぎて読者にとって読みにくい印象を与えるものもたくさんあります。

私たちの考え方はその真ん中にあります。理想はもちろん元の文章を正確に訳して目的言語で自然な文章を作ることです。意外と難しい目標ですが、元の文章に誠実であることが大切だと考えています。

ほとんどのゲームはモノリンガルの開発者が母語で開発して、完成したあとに他の言語に翻訳されます。オリジナルの開発者は目的言語がわからないので、翻訳家を信じて良い翻訳ができると期待するしかありません。各言語版が完全に別売な場合はプレイヤーにとって比較対象がないのでそれでもよかったのですが、最近は設定画面で言語の選択をする方法が一般的になっていて(新しい言語も追加コンテンツとしてダウンロード可能)、それで「良い」翻訳と判断される標準が厳しくなってきています。

私たちはバイリンガルなチームなので、その取り得を最大限に活かしています。英語も日本語もネイティブスピーカーがいて、ゲーム開発を導くことができており、バイリンガルなシナリオライターが一かモノリンガルなライターと翻訳家と協力の架け橋となっています。これにより、他とは違う珍しいことができるようになりました:二か国語で同時にゲームを作ることです。

間違いなく、一か国語でゲームを作ってから翻訳した方が速くて費用対効果が高いです。でも、それでは、翻訳しているときに何か違うと感じたらどうすればいいのでしょう?特に英語と日本語みたいにあまりにも違う二か国語では、翻訳は難しい表現などがあって、もう出来上がったゲームを翻訳している場合には元の文章を翻訳しやすいものに変えられないというのが当然です。そうなってしまったら、あるもので頑張るしかなくて、結局は意味を大きく変えてでも目的言語で理解可能な文章にすることになります。

二か国語でゲームを作ることには独特の問題はありますが、どちらの言語の文章も編集できる柔軟性があります。実はブログも似たようなやり方で書いています。スタッフが母語で書いて、翻訳家に翻訳してもらって、バイリンガルなライターが両言語バージョンをチェックして、ネイティブスピーカーの耳に自然に響くために必要な編集をします。

この考え方はマルチリンガルなプレイヤーにはいくつかの言語で楽しんでいただけるゲームであるロマフェリの目標と相性が良いです。ゲームをある言語で遊びたい、言語の勉強に役立てたい、翻訳でニュアンスが変わってしまうという心配をしないで母語で遊びたい、というプレイヤーがいます。そのためのハイクオリティの翻訳を提供するために努力をしています。

文化の問題を意識する

はっきりした翻訳フィロソフィの他に、違う文化がどう作品を受け取るかについての理解が必要です。それを意識することで、スートリーや画像を大きく変更しないで世界中の誰でもが遊べるゲームが作れていくと考えています。

違う視点からものをみる

国ごとに違う歴史、文化、できごとの見方があります。一つの国の人にのっては取るに足らないものでも、違う国の人にのっては末永く社会を大きくかわるものでさえありえます。

一つの例はカプコンから発売されている、バイオハザード5で起きた問題です。日本の開発者がアメリカ合衆国の奴隷や人種差別に関する歴史を十分に考えないまま、白人系アメリカ人がアフリカへ行って(主に黒人の)ゾンビを殺すというスートリーやビジュアルのゲームから、どういった印象を受けるのかを広い視点で想定できていませんでした。他によく耳にするローカライゼーションと文化の問題はドイツのナチスの符号とテーマを縛る法律です。ドイツの社会はナチスによって深い傷を負ったのでその符号やテーマを表現するメディアに対しては厳しい姿勢をとっています。

ロマフェリはファンタジーの世界を舞台にしているので実際の歴史の出来事でトラブルが起こしにくいですが、実際の歴史に似せた場面は色々な国の人にどう映るかを意識しなければなりません。そして他国のメディアに関する法律を意識する責任があります。例えば、同性愛のカップルを表現した内容を含むために、反LGBT法律を持つロシアでは18禁のレーティングになるかもしれません。

文化の勘違い

大きな歴史と文化のコンテキスト以外にも小さなミスコミュニケーションもたくさん起こりえます。ボディーランゲージから符号の使用までが、国、地方、世代で意味が違うことがあります。

ジェスチャーなどがイメージしやすい問題でしょうか……これは、国によって大きく意味が違っていることがあり、肯定的なつもりのジェスチャーが見た人によっては否定的として受け取られることがあります。

OKジェスチャー
良い意味と悪い意味を持つジェスチャー

たとえば、キャラクターに手でOKのジェスチャーをさせたとしましょう。私たちなら上のジェスチャーをしますが、それで想定していない意味が伝わる可能性があります。日本では、このジェスチャーを見る向きによっては「お金」という意味になる場合もあります。フランスでは、Oの形がゼロ、つまり「価値がない」という意味として伝わることがあります。地中海の国では下品な意味を持ちます。世界規模化で「OK」の意味も広く知られるようになってるので、意味を明確にするコンテキストも入れたら多分正しく伝わると思うので、ゲームに利用しても大丈夫でしょうが、勘違いされることもあると開発者は意識を持っておいた方が良いと考えています。

他に気を付けないといけないところはアイコンです。ロマフェリ開発日記#3で触れた通り、アイコンがマルチリンガルなゲームにとっては強い道具となりますが、思っていたものと全く違う意味が伝わってしまう可能性があります。

お寺記号が載せてある地図イメージ
仏教のお寺を表すこの符号は人によってショックを与えます

日本でもその問題に直面しています。それはまんじです。仏教を含むたくさんの宗教で古くから神聖な符号として使われてきた歴史がありますから、日本の地図記号ではお寺を指す記号として使用されています。残念なことに、ナチスがその符号を勝手に利用したために、海外、特に西洋諸国ではナチスと反ユダヤ主義のシンボルになってしまいました。日本の開発者がそのことを意識せずにゲーム内でその符号を使えば、翻訳するときに問題になります。過去の例を挙げると、コナミから発売されていた「がんばれゴエモン」シリーズでは、日本向けではまんじのマークを使用していますが、翻訳したものは☆に差し替えていたり、任天堂から発売されていたポケモンカードシリーズのとあるカードの絵柄の一部にまんじが描かれていたことにより、ユダヤ人コミュニティに非難されるということもありました。

もちろん、開発者には必ずすべての文化違いに対する過失を予想することは不可能です―特に私たちみたいな小規模の開発会社には。でも、ローカライズする予定の地方の文化と歴史の基本など、少しでも意識をしていれば大きな問題を避けることができるはずです。そして、問題があると言われたときには、悪気がなかったから、と問題として取り上げなかったり、悪気はなかったとはいえ、謝罪のみで責任を逃れていると思われる行動に出るよりも、しっかりと問題となった元への意見を聞き、解決策を考えていく方が良いと感じています。少なくとも、私たちはそういった姿勢で開発を続けていく予定です。

今回の開発日記はこれで終わりです! ロマフェリのゲーム本編から少し離れた大きなテーマでしたが面白く読んでいただけたら幸いです。次回もローカライゼーションのやり方について紹介しますので今回で興味を持たれた方は、ぜひまた読んでください!

ロマフェリの開発日誌も第3回となりましたが、このような開発の思考や失敗から学んだことについての記事が少しでも皆さまの興味を引くことができるものになっていればと思います。今回は、これまでの開発の中で試行錯誤を経て大きく変えることとなったUI/UXと、その開発プロセスの重要性をテーマにし、考えてみました。

紙上にしたデザインを上手くゲームに落とし込めるとは限らない

旧マイ・ルーム画面の仕様書
旧マイ・ルーム画面の仕様書

私たちがゲーム開発を始めた当初は、過去に別のゲーム会社で働いていたスタッフたちが経験を元に開発フローを考えていたために、まずプランナーが機能仕様書やレイアウト仕様書を作成し、それを元にデザイナーが細かく完成度の高いイメージを作成するという流れで進めていました。ここまでは特に問題が無さそうに思えます。私たちもそう感じていました。これは、開発日誌#1でも触れた通り、より規模の大きいゲーム会社で働いていたからこそできたことだったのですが、まだこの時はそのことに気付いていませんでした。この段階で作成したイメージは綺麗で完成形に近いものだったのですが、それぞれを作成するのに長い時間をかけていました。その影響もあってか、作成された綺麗なイメージをそのままゲームに入れて必要に応じて微調整するだけでゲームのデザインが完成すると考え、イメージをゲームで利用できるUI資源に変換する長いプロセスに着手することにしたのですが……ここで様々な問題に直面することとなりました。

旧スケジュール画面
旧スケジュール画面の学習項目は最大3文字表示

最大の問題となったのは、表示する文字数でした。私たちが開発するゲームは、多言語対応を大前提としています。しかし、デザインを作成する時点では、日本語の表示しか考慮していなかったのです。日本語では文字数の少ない単語でも英語では当然ながら文字数が増大してしまい、デザインされたレイアウトに収まらない状態になってしまいました。また、仕様書やデザインの状態では使いやすいと思っていたレイアウトにも無駄な操作などが見つかり、実際にゲームへ反映して動かしてみると使いにくいと感じるところも多くありました。

これらの問題を解決するためにはレイアウトを変更する必要があるとわかりましたが、デザイナーの作成したイメージは本当に丁寧に細かく作り込まれていたので、簡単に修正できるものではなく、結果としてとりあえずゲームで利用できるためだけの修正に沢山の時間を費やすことになりました。1つだけのレイアウトに集中せず代替のパターンを用意していたら、この問題はここまで大きなものにはならなかったと、今となってはそう思えますが……長い時間をかけて苦労した結果、そのような開発プロセスは開発スケジュール全体にとって大変な痛手であると学びました。

柔軟なアプローチに挑戦

今後このような修正に本来必要ない時間を使わず、効率的で円滑に進められる方法を考えて、UI開発のプロセスを見直すことにしました。まず、私たちが反省したのは、企画とコンセプトの段階でした。上記の通り、予想した通りに動作しなかった(結果、修正が必要になった)仕様書と完璧に作りこんでしまった「コンセプト」のデザインを作成するのにかなりの時間をかけていました。

プランナーたちが学校や前の会社で学んでいたことにもかかわらず、仕様書はゲームの機能を概念化するのに役に立たず、そしてゲームで実現した時に出てくる問題点を予測することも仕様書の段階ではできていませんでした。その時にチームに入っていたデザイナーはゲームで表示するレイアウトのイメージをそのまま作成する方が簡単で早いと考えており、その通りに開発を進めていたのですが、本当に少しだけ修正したい時なども、それが困難となっていました。ワイヤーフレームや簡易的なコンセプト・レイアウトを行わなかった結果、今の開発速度の倍くらいの時間がかかっていました。さらに、もう既に綺麗に完成されているデザインは、大きな変更をしたくてもそれが難しく、最初から考え直した方が良いようなものでも、レイアウトを修正し続けてしまっており、完成に辿り着くのが困難になっていました。

設定画面のワイヤーフレーム
設定画面のワイヤーフレーム

そこで、プロセスを合理化するために細かい仕様書とレイアウトのイメージを処分して、ミーティング、レイアウト参考例の調査、単純化したワイヤーフレームの作成をこれまでのプロセスの代わりに行うことにしました。その結果、ある画面に対してかなり時間をかけていたにも拘らず、一から作り直すことになるという問題を防ぐことができました。ワイヤーフレームを利用することで簡単にいくつかのパターンを実施し、良いものがあるのか、どこをどのように変更すれば良いものになるのかなどを検討できるようになりました。シンプルでフラットなデザインにすると、UIに含まれる要素の配置や大きさの調整など、レイアウトの変更が非常に簡単になります。

日付のインタフェース用のデザイン・パターン
日付のインタフェース用のデザイン・パターン

上記に書かれている方法論を利用することで早めにいくつかのデザイン・パターンを作成し、大きな修正と小さな修正の両方を何時間、早い時は何分程度で実施できるようになりました。コンセプトのイメージをチームでリビューすることにより一人のプランナーが自分で仕様書を作成している時では気づけない問題点を見つけやすくなりました。出来上がるゲーム画面は前のように磨かれた感じではないかもしれませんが、より簡単に微調整できて色々変更していける柔軟性が出てきました。

より良いユーザーエクスペリエンスを作成

柔軟性のないデザイン・プロセスというハードルをクリアしたため、次は実際にUIに何の問題があるのか、それはどのようにユーザーエクスペリエンス(UX)を悪くしたのかを把握する段階に進むことができました。良いUI/UXの基礎は使いやすさであり、それはクリック数からわかりやすさまで様々な要素が含まれています。要素の範囲が結構幅広いため、さらに3つのカテゴリーに分けてみました:鮮明性、ユーザビリティ・アクセシビリティ(使いやすさ)、「エンゲージャビリティ(ハマる要素)」……この3つです。

旧ステータス画面
旧UIでは文字に頼りすぎたせいで可読性が下がりました

鮮明性を発見

旧デザインをゲームに入れてから鮮明性が低い(つまり、ゲームをプレイしている時にユーザーが何をすればいいのか、何を見ればいいのかなどが明確になっていないことがある)という問題点に早めに気づきました。限られていた文字数を元に、その文字数だけが入るようにデザインが作られていたので、英語版ではこういった問題が更に明確になっていきました。英語のUIでは日本語よりも多くなりやすい文字数に対応するためにフォントのサイズをなるべく小さくしたり、1行の方が伝わりやすいものを仕方なく2行にするなど、結構無理やりな対応をする必要がありました。その結果、UI全般のわかりやすさやナビゲートしやすさが低くなっていました。

学習項目選択画面
アイコンとツールチップの表示

そこで、認知性を向上させるために、多くの文字になっている要素をアイコン化しました。それによってスペースに余裕ができ(レイアウトの自由度が高くなったおかげで様々な視覚的階層を試せるようになった)、そして(アイコンはどんな言語でも変わらないため)マルチ言語によりうまく対応できるUIにもなりました。UI要素の説明文もツールチップに移動することができたので、文字数でレイアウトに影響を及ぼさずにユーザーが要素の使い方を理解しやすいように作り変えることができました。

ユーザビリティ・アクセシビリティを向上

旧メニューナビゲーション
旧メニューのナビゲーションはゲーム状態によってレイアウトが変わっていました

ユーザーフレンドリーのインタフェースを作成する基本としてユーザビリティとアクセシビリティはもちろん大事ですが、綺麗でユニークなデザインを作ろうと意識してしまうとそれらを簡単に見落とすことになってしまいます。旧デザイナーはイラスト作成の経験が深かったものの、レイアウトのデザイン経験があまりなくて、それが元のデザインのプロセスが失敗した一つの理由となっていました。プランナーも経験が豊富なUIデザイナーと一緒に働くことに慣れていて、仕様書内の説明文と一つだけのイメージ図からゲームの雰囲気に相応しいレイアウトが作成できると思っていました。しかし、まだ良いUIに対して勉強中だったデザイナーは当然ながら参考例のイメージ画像をテンプレートとして利用してUIをデザインしていきます。いくつかの出来上がった画面に対して上記のような問題が起こった結果、UI要素がゲーム状態によって位置が変わってしまうなどの問題が出てきました。

仕様書を利用しているトップダウンアプローチからミーティングと頻繁なリビューをする共同アプローチに切り替えたおかげでUIのユーザビリティとアクセシビリティをもっと最適化できるようになりました。かくして、様々なレイアウトのパターンへの挑戦、ボタンなどのUI要素の適切な配置やサイズの検討、プレイ中に必要な操作が無駄に多くないかの確認などができ、デザインのユーザーフレンドリー性をより簡単に企画し、テストもできるようになりました。コントローラー対応や他のプラットフォームにポートを対応するための工夫などの微調整や改善点を将来的に行う計画も立てています。もちろん、まだ先のことでもあるので、長い時間をかけてこれからもこのようなUIの改善をしていく予定です。

エンゲージャビリティで興味を引く

最後はUI/UXがユーザーをエンゲージして楽しい体験をさせる力である「エンゲージャビリティ」というものです。残念ながら、これはまだ深く対応できないところです。「エンゲージャビリティ」はある程度ロマフェリのインタフェースの鮮明性とユーザビリティ・アクセシビリティを改善することで少しずつ感じられるようになるかもしれませんが、一番重要なのは磨かれた資源になります。UIがゲームの楽しさを高める一つの大きな方法としてゲームプレイに必要な機能部分がゲームの世界に溶け込み、それでプレイした時の没入感をより感じられるようになります。正直に言うと、私たちが利用している現在の仮の資源ではそれができません。現在の状態で、要点なUIの使いやすさに満足できるようになったら、UIデザイナーに依頼して出来上がったコンセプト・アートを磨かれた画像に入れ替えるようにしていく予定です。ですので、私たちが良いUIを作成している間はもう少し皆さんに待っていていただければ助かります。

では、今回の開発日誌は以上にしたいと思います。次回も面白く読んでもらえるようなものを作成する予定ですので、また読んでいただければ嬉しいです!