こんにちは、「Caliburn」です、時間が開いてしまいましたが、月刊「Kenshi」のコミュニティアップデートをお届します。月刊アップデートとしては在宅勤務が始まってから2回目となりますが、5月は新たなスタッフ数人が加わったこともあり、彼らを迎え入れるために多くの時間を費やしました。今回のアップデートでは、まず継続している公式版のローカリゼーションについてや、最近開催されたバーチャル・イベントへの参加、「Kenshi 2」の世界観の表現法や大規模なサンドボックスを開発するに当たっての技術的な考察などをお知らせします。
「Kenshi」のローカリゼーション
以前より「Kenshi」の各国語版についてのお知らせは何度かさせて頂いていますが、ローカリゼーションするとはどういうことなのかということについてはお伝えしていなかったと思います。現在でも主な２言語の再リリースの準備が進められている中、今月のアップデートでは翻訳とローカリゼーションの違いについてお話したいと思います。
外国映画やアニメのファンの方で、字幕や吹替などで話を追っていく際に、訳としては正しくても、その意味合いに少々疑問を持たれたことはないでしょうか。私達は無意識にその文化特有の諺や婉曲表現を使って語る傾向がありますが、それが他の言語に訳された場合に本来の意味からずれてしまう場合があります。20代半ばの方であれば、ポケモンのアニメに出て来る「ジャムドーナツ」を覚えている方もいらっしゃるのではないでしょうか？
でも、実はおにぎりだったジャムドーナツ。欧米の視聴者にはおにぎりが何か分からないだろうという発想のもと、ドーナツという訳になっていますが、文化的な要素を考慮に入れても、この訳はサンドイッチか饅頭、ペーストリーに近い意味合いを持ってるはずです。たとえ見た目は大きく違っていても、それがアッシュとの冒険のためにブロックがわざわざ作って持ってきてくれたお弁当という意味でのおにぎりだったからです。それを理解した上で、では最も適切な訳が何なのか考えるのが、ローカリゼーションの第一歩です。
日本語の訳に関していうと、今までの「Kenshi」日本語版の翻訳はなるべく正しく翻訳する事に重点が置かれており、直訳に近いものでした。ですが、今回進めているのは意訳のローカリゼーションで、特に今まで日本のプレーヤーの方々の間で違和感を覚えられていたダイアログの修正を中心に行われています。例えば、「Kenshi」のダイアログには数多くのアイロニーが含まれていますが、直訳されると逆の意味を持ってしまうため、ダイアログの選択をする際に悩まれていた方も多かったのではないでしょうか。また、直訳でも理解はできるけれども、話の流れ的にもっと分かりやすい言い回しがあればそれを変更したり（例：「ブーツをくらえ」を「蹴りとばせ」に変更）、英語の諺で「フライパンから出て、火に入る」を同様の意味の日本語の諺、「飛んで火に入る夏の虫」に置き換え、会話の途中で突然「フライパン」が意味もなく出て来ることがないようにする、等の作業を進めています。結果、ほぼ全ての翻訳の見直しをすることとなり、当初予定していたよりも長い時間がかかっています。
韓国語のローカリゼーションに関しては、先日大きなアップデートを行いました。前回とは異なるチームで見直しを行い、クオリティチェックにはファンのJeffrey Jeoungさんに参加して頂きました。これにより、言葉の壁を乗り越え、翻訳のクオリティを確認する事ができたと思っています。
「Kenshi」x Indie Live Expo
パンデミックがまだ収束していない今、ゲーム開発者参加のライブイベントが次々に中止され、本来ならば大規模ゲームイベントが開催されている時期なのに、そのことを忘れてしまいそうな日々が続いています。
そんな中、昨年PLAYISMのお声掛けで上海にて参加したライブイベントに続き、Lo-Fi Gamesとしては初めてとなるデジタルイベント、Indie Live Expo 2020 に参加いたしました。
このイベントは日本のリューズオフィス共催で、英語、日本語、中国語にて「ゲームを通じた友情や熱狂が、今こそ必要である」という信念のもと開催されました。
イベントの内容としては「未発表タイトルの最新情報に加え、注目タイトルの最新情報や、未体験ユーザーにはマストプレイなインディゲームの名作情報や、番組独自のセレクションによるレコメンドタイトルの紹介」が行われ、加えて、ZUN（『東方プロジェクト』）、トビー・フォックス（『UNDERTALE』『DELTARUNE』）、SWERY（The Good Life/株式会社White Owls）、新納一哉（TYPE-MOON studio BB）などのインディゲームに縁の深いクリエーターの方からのメッセージが発信されました。
「Kenshi」のDiscordのコミュニティでは有名な話ですが、私（Caliburn）はエヴァンゲリオンのファンであるため、『シン・エヴァンゲリオン劇場版』公開を前に、このゲームをテーマにしたミニゲームコンテストが現在開催されていることも追記しておきます。
イベントのアーカイブはこちら：YouTube (日本語)/Twitch/Bilibili (中国語）
ホームページはこちら：Indie Live Expo website
コミュニケーションしてるだけ
現実の世界と同様「Kenshi 2」も大きな世界の中で繰り広げられていきます。ゲームの売りになるようなマップサイズの詳細はまだ秘密のようですが、「Kenshi」よりも大きなサイズになることは間違いないようです。そこで今回はその世界にどうやって息を吹き込んでいくのか、そしてそれを可能にするため必要な技術は何なのかという2点の質問に答えてもらいました。まずはナタリーに「つぶやきや聞こえて来る会話」の魔術について聞いてみました。
「こんにちは！この数か月間、私は『Kenshi』の世界の様々な歴史や文化などをどのようにして垣間見せていくかという事を考え続けてきました。サンドボックスのゲームでは、開発者は通常のRPGのようにプレイヤーが何を聞き、目にし、NPCがどのような行動を取るのかということをコントロールする事は出来ません。ですから『Kenshi』の世界に息を吹き込み、プレイヤーにその世界に入り込んでもらいながら、必要な情報をしっかりと伝える方法を考えねばならないのです。
数か月前、ワールドマップ上での大まかな勢力図を描いているというお話をしましたが、今は各都市の中で繰り広げられている小さな争いごとに焦点を絞って考察しています。私が主に行っているのは、自分の中で『人参』と呼んでいるものの計画です。『人参』とは、プレイヤーに探索したいと思わせる目的や秘密を差します。『人参』を設定したら、その後、ゲーム内のアイテムの詳細や様々な会話、ビジュアルに訴える何か等を通してそれらの情報をどのようにして伝えていくかをリストアップします。『Kenshi』ではRPGによくみられるクエストのシステムは使われないため、プレイヤーには間接的に、そこはかとなく情報を伝え、頭のどこかに残るように情報を植え付け、自分から行動を起こしてもらえるようにする必要があります。
そのように『少しづつ』提供される情報の中にダイアログの『バークス』と呼ばれるものがあります。『バークス』とは、NPCが何かに反応する、または何となく呟く短いダイアログの事を言います。そのように何となく呟く内容が世界に息を吹き込み、ゴールや伝承を伝え、プレイヤーをこの世界に引き込む重要な要素となります。ですが…それらを邪魔にならない程度に興味深く散りばめていくには、どうしようもないほどたくさんのバークスを書く必要があるのです。時には頭が一杯になってしまうこともありますが、都市の中で市民が呟いたり噂話をしていたりする様子を描くのは、私の最も好む過程でもあります。
私がどのようなプロセスを使ってそのような『バークス』に取り組んでいるか、Gamasutraに掘り下げたブログ記事を書いていますので、そちらを読むか、私のツイッターをフォローしてください。」
美しい世界
もう既にご存知だと思いますが、「Kenshi 2」はUnreal Engine 4（UE4)にて開発されているため、古くからあるOgreで実装されていた要素が大きく変わることになります。そのUE4での技術的な開発状況を、テクニカルアーティストのビクターに聞いてみました。
まずは酷評され続けている要素からお聞きします。「Kenshi」ではよく「ロード中」と表示され、一時的にゲームが止まってしまいますが、UE4ではこのような事がなくなり、大きなマップをきちんと処理できるのでしょうか？
「UE4にはワールド・コンポジションという世界を細かなセルに分割し、カメラが近づくと自動的にそれらをロードする機能があります。その機能はシンクロしないため、データのロード作業をゲームを止まらせることなく裏で動かすことができます。ですから建物等をバラバラにしてセル化し、それらをロードしていない状態にしておき、必要な時にだけ自動的にロードさせる事が出来るのです。ワールド・コンポジションはUE4エンジンのランドスケープ機能と合わせて動かすこともできます。
ただ残念なことにランドスケープ機能は『Kenshi 2』ほどの巨大な世界に使われるようには作られていません。ですから、ワールド・コンポジションを使用する傍ら、他社のランドスケープ・システムを使えないか現在調査を進めています。『Kenshi 2」』の世界は~1000km2の『Kenshi』よりもさらに大きくなる予定のため、それに対応させる必要があります。」
それはとても大きいですね。そのように大きなスケールはあまり聞いたことがありません。これは担当されていないことかもしれませんが、ワールド・コンポジションを使えば、空に向かって走っていくようなことはなくなりますか？
「できればそれは避けたいですが、それは経路探索の問題です。今のところ、まだ『Kenshi 2』の経路探索については決定されていませんが、恐らくリキャスト（UE4のストック・ナビメッシュで、既に検証され信頼性が高いと言われている）を使うことになるのではないかと思われます。まだ断言できる段階ではありませんが、大きな青い空にむかってキャラクターが走り去る事はなくなるでしょう。
UE4とリキャストは非常にフレキシブルに大量のナビメッシュを生成することができるので、理論的にはまったく問題なく『Kenshi 2』の世界に対応できるはずです。いずれにせよ、『Kenshi』で見られるようなおかしな経路はほとんどなくなると思います。」
先ほど、セル化した世界を表示したりアンロードしたりする機能の話をされていましたが、大きな建造物についてはどうでしょう。Unrealフェストにて、デベロッパーがオブジェクトや建物の何通りかのタイプを作った後、エリアの境界線を設定すれば、あとはエンジンが都市そのものをつくったり、それを修正したりすることができるようになるという発表があったようですが、『Kenshi 2』ではそのような機能は使われるのでしょうか？
「シティ・スポーナーなどを使う事はできますが、『Kenshi 2』の特殊な世界と詳細な設定を考えると、汎用的なシステムに頼ることはできないと思います。もしそのようなツールを使うとしたら、自分達で開発する事になるでしょう。そういった汎用的なシステムを使い、機能に頼り過ぎてしまうと、何もかも同じに見えてしまうという問題が出てくるからです。
アーティストが丁寧に描く建物や鍋などの小物をいちいち正しい位置に置いていくことで、その物体の本来の存在する意義が出てきます。モジュラー化して使いまわせるものは使いまわしますが、『Kenshi 2』のユニークで独特な世界観を保つためにも、使い過ぎないように注意する必要があります。」
自然のバイオームについてはどうでしょう？
「少なくとも単純な草などの自然環境を表現するのに自動化は適しています。勿論、草一本一本をいちいち置いて行くこともできますが、それは悪夢としか言いようがありません。ですから、レベル・デザイナーによって定められた位置に草を置き、あとは自動化するようにしています。
自然を表現するに当たり、我々のワークフローに簡単に取り入れられるツールが他にもあります。例えば、UE4には一体化されたスプレッド・ツリーという機能があるのですが、それで枝葉などの「種族」を作ると、その種族の形態の異なる木を大量に生成できます。いちいち枝葉のモデルを作る退屈な作業を軽減できるので重宝しています。」
見栄えが良くなることにより処理するデータも増えますが、それがパフォーマンスに与える影響はどうでしょう？
「まず、『Kenshi』ではLOD（ディテールのレベルを流動的に変えること）を使っていなかったため、最大限に拡大されたディテールのメッシュを常に逼迫させるかたちで表示していました。『Kenshi 2』ではLODを多用し、UE4の（ほぼ）自動化されたLOD生成システムを使っています。つまり、拡大されたディテールには細かなメッシュを表示し、ズームアウトされたディテールには粗いメッシュで表示するのです。これはアーティストが特に何かする必要なく設定する事ができます。」
基本的なソフトウェアの最適化についてのお話は一旦終了します。では、ハードウェアについてはどうでしょう ‐「Kenshi」はシングル・スレッドで動くことで有名なOGREの古いバージョンで動いていましたが、UE4で動く「Kenshi 2」ではそれはどう変わるのでしょうか？
「それは大きく変わります。『Kenshi』の開発が始まったばかりの頃は、マルチ・スレッドのCPUは珍しく、コアも現在のように速くはありませんでした。当時はIntelの i3/i5/i7のリリース・スキームさえなかったのです。ゲーム開発する際は、なるべく多くの人にプレイしてもらえるように開発する必要があります。ですから、当時はシングル・スレッド以上の技術で開発する理由はなく、あえて非常に複雑なコードで開発時間を割く理由もありませんでした。
でも、それから状況は大きく変わりました。平均的なユーザーでも4つのCPUコアでプレイできる環境にいます。Unrealエンジンはデフォルトで個別のコアにてレンダーをスレッドするように作られています。『Kenshi 2』ではそのロジックのほとんど全てを、さらに増え、速くなったスレッドで動かしているため、マルチスレッドで得られるものは非常に大きいです。もう一つ大きく変わった事として、十年ほど前までCPUで処理されていたレンダリングが、今ではGPUで処理されるようになったことが挙げられます。これにより、ボトルネックとなっていた各フレームでの数百千回の計算が、迅速に行えるようになりました。GPUの処理能力はこの10年余りでとてつもなく上がりましたので、それを最大限に生かしたいと思っています。」
何もかも素晴らしいですが、それら全てがきちんと動くかどのようにして判断できるのでしょうか？
「ほとんどの場合、開発の『感』のようなものから、何をすべきで、何をすべきでないか判断しています。想定されたプロフィール分析とワイヤーフレームを提示されれば、大抵の場合はどこに問題が発生するか分かります。それがどういう問題なのかは、もっと掘り下げてみないと分かりませんが、出来る事の選択肢と、選択した後に起こりうる結果は感じ取れるのです。
開発の初期の段階では、大まかなアイデアをパフォーマンスの限界やきつい制約なしで進めてみます。それらがきちんと動いていることを確認出来た時点で、今度はその設定が合理的か、フレーム時間を短縮する方法がないかを考えます。パフォーマンスに大きな問題が出て来た時点で様々な分析をすることになります。大抵の場合、最低のスペックでもそこそこのパフォーマンスを出すための基準値があり、それに達しない場合は、どの部分に負荷がかかっているのかをたくさんの数値から洗い出し、そこから問題点を絞っていきます。そして、最も問題のある部分からまず色々と大胆に削っていきます。最適化は基本的にはサイクルになっていて、何度も繰り返されます。また、そのような問題が積みあがると、負荷も多くなる一方なので、ともかく基準値に達するまで、色々と削りまくっていきます。そして、またそのサイクルが繰り返されるのです。」
最後に、Epicが最近になってUnreal 5 (UE5) を発表し、UE4から問題なく移行できそうだという話だったので、その対応をスタジオ内で話されていたようですが、特に「Kenshi 2」に使えそうな機能はありますか？
「テクニカルアーティストとしては、UE5の可能性は素晴らしいものだと思っています。もしEpicが既に謳っているような光の調整や幾何学的要素が加わるのであれば、開発が根本的に変わるかもしれません。
とはいえ、現段階でそれらの機能がどの程度導入されるのかは分かっていないため、それに頼るわけにはいきません。届いている資料を見る限り、移行するのは簡単そうであり、その点は恐らく問題ないだろうと想定できますが、今ある情報を鵜呑みにしたままUE4からUE5に移行するわけにはいきません。それらの新機能はアート関連のワークフローには多大な影響を与えるものではありますが、ユーザーには関係なく、また既に作業が進んでいる工程でもあるからです。また、現時点で理想的ではあっても何も詳細が分からないワークフローで作業を進めるわけにもいかず、またUE5のリリースを指を咥えて待ち続けているわけにもいきませんので、このまま何も変更せずに開発を続け、UE5がリリースされた後でまた考えようという事になりました。
例えばもしも『Kenshi 3』が開発されるようなことになれば…UE5を使うことで、アートのパイプライン関連のワークフローが根本的に変更され、大幅に時間を短縮する事ができるのではないかと考えられます。ただし、それは机上の空論ですので、あまり期待しないでいてください。」
今回のブログはとても長いものになりましたので、皆さまからのご意見や質問などをお待ちしています。また、近々クリエータ―向けのコンテストなどのお知らせをツイッターやニコニコ動画のブログより発信する予定です。もしこの月刊アップデート(英語）をメールにてお読みになりたい場合はこちらからご登録ください。
では、また
サム（Caliburn)ヒルズ
