クオリティエンジニアってどんな仕事?―ゲームの開発もQAも横断して自動化するプロジェクト専任エンジニア誕生の軌跡―

お久しぶりです。セガの阪上です。前回の記事「QAエンジニアってどんな仕事?~ゲーム開発におけるテストの世界~」を寄稿してから6年が経ちました。今回は、前回の記事以降に発表した講演内容を振り返りつつ、前回紹介したQAエンジニアという職種から、クオリティエンジニアに役割を再定義した経緯について紹介します。

また、今年のCEDEC2024の講演『「龍が如く」も「スーパーモンキーボール」も自動化!クオリティエンジニアリングチームによるマルチゲームエンジン対応で進化した「龍が如くスタジオ」のテスト自動化環境について』は楽しんでいただけたでしょうか?

マルチゲームエンジン対応となったテスト自動化環境について、説明しきれなかった内容も補足しますので、最後まで楽しんで読んでいただけたら幸いです。

目次

「QAエンジニア」から「クオリティエンジニア」になった経緯

まず、今回のタイトルにもあるクオリティエンジニアの説明から始めます。ゲーム業界では、他のソフトウェア業界と同様に、開発環境やQA(Quality Assurance/品質保証)環境の自動化を推進していく潮流があり、その中で、主に開発環境を自動化するビルドエンジニアと、主にQA環境を自動化するQAエンジニアに細分化が進んでいました。しかしながら、開発とQAは密接に関わっており、別々の担当者がそれぞれの視点で自動化することは、それぞれの担当範囲の間に立ちはだかる課題を解決する上での障壁となり、必ずしもプロジェクト全体の効率化につながらないということが分かってきました。そこで、開発・QAの環境の自動化・効率化を横断して行うために、クオリティエンジニアという職種を新たに定義することにしました。クオリティエンジニアの具体的な業務内容をまとめると、下記になります。

  1. アセットやパッケージのビルドの自動化
  2. QAの自動化・効率化 
  3. 開発・QA・LQA(ローカライズQA)を含めた拠点間のデータデリバリーの自動化
  4. プロジェクトのワークフローに適合したチケット管理システムの構築・運用、チケット処理フローの自動化 

1と2は分業でも対応ができますが、3と4については、分業だとなかなか対応ができず、そもそも問題に気付けないということにもなりかねません。次項からは、このクオリティエンジニア誕生までの軌跡を、前回のブログ投稿時(2018年8月)をスタート地点として、過去の講演を振り返りながら、ビルドとQAの両方の視点を合わせないとできないプロジェクト全体の自動化・効率化の事例として、先ほど挙げた業務内容の3と4を中心に紹介していきます。

(2018年~)開発・QAにおける自動化ワークフローの確立と、クオリティエンジニアの育成

当時QAエンジニアを名乗っていた私は、前回の記事以降に発売となった「JUDGE EYES:死神の遺言」「龍が如く7 光と闇の行方」のプロジェクトを通して、今までの自動化技術の集大成として、自動化ワークフローの確立に取り掛かりました。その結果生まれたのが「全自動バグ取りシステム」です。
このシステムを構築することで、パッケージ作成などのビルドの自動化だけではなく、ゲームでは難しいとされてきたテスト自動化の手法についても確立することができました。
「全自動バグ取りシステム」の詳細は、CEDEC2020の講演資料をご覧ください。

そして、この自動化ワークフローを支えるために、テスト自動化チームを結成しました。これは、クオリティエンジニアによって実装されたテスト自動化フレームワークを使いこなして、自動テストの作成・運用を行うチームです。専任のクオリティエンジニア以外に、新人などの若手のプログラマーも参加します。「龍が如くスタジオ」では、2017年ごろから、新人研修の一環(※)として、テスト自動化チームに入って、自動テストの作成や、デバッグの手法を学びます。これらの経験は、その後の自身で実装したゲームの自動テストを自ら作成するなど、ゲーム開発に生かされますし、クオリティエンジニアの育成にもつながる取り組みになります。(※新人研修では、もちろんゲーム制作についても学びます)

この若手育成の取り組みやテスト自動化フレームワークの詳細については、下記の講演資料・講演動画で詳しく説明しています。

この取り組みが功を奏して、クオリティエンジニアも徐々に増えていきました。次項からは、私一人では成し遂げられなかったことばかりですので、一人称も「私」から「私たち」に変更します。(やったね!)

(2020年~)マルチプラットフォーム・多言語対応による多拠点の自動化・効率化

「LOST JUDGMENT:裁かれざる記憶」の開発のころから、マルチプラットフォームで世界同時発売を前提としたプロジェクトが増えてきました。これは、各プラットフォームで動かせるようにして、各言語に翻訳をすればよいというものではありません。ここでは、これらの対応における問題点を開発環境やテストに絞った上で、私たちがどのように解決したかを説明します。

マルチプラットフォーム対応においては、主にアセットビルドやパッケージの作成が各プラットフォーム分必要になってくるという点が挙げられます。単に Jenkins などのCIツール上に接続するPCを増やして並列実行させればよいだけではないかと思う方もいると思いますが、それらがエラーになった時などのメンテナンスコストはプラットフォームの数に比例して増えていきますし、最近の大規模タイトルだと、1プラットフォーム当たりのパッケージのサイズが50GBから100GB程度に拡大し、さらにこのパッケージを高速に配布しなければならないため、そのデリバリー時間(アップロード、ダウンロード、インストール、動作確認を含めた時間)についても、意識して対応する必要があります。また、多言語対応については、開発・QA・翻訳・LQAを行うメンバーの拠点が国をまたいでいることが多く、時差や言語の壁により、拠点間のコミュニケーションに時間やコストがかかることも問題になります。そして、特定のプラットフォームや言語の不具合も同時に増えていきます。

私たちは、この複数の問題を自動化のアイデアで解決することにしました。まず、マルチプラットフォームのパッケージの作成と提出(アップロード)を自動化しましたが、これだけでは足りませんでした。なぜかというと、プラットフォームが増えて、対応言語も増えた結果、それぞれの環境での動作確認を開発側でカバーすることができず、特定のプラットフォームや特定の言語でだけ、ゲームの起動すらできない、という不具合が頻発しました。初めは手動で行っていましたが、複数名が動作確認に時間を取られることになるため、自動化することにしました。そこで導入したのが、全プラットフォームで実施する言語切り替えテストの自動化です。最新のパッケージが作成されると、各プラットフォームの開発機に自動でインストールして、ゲームを起動し、すべての言語に切り替えて正常に動作するかを確認します。それと同時に、各プラットフォームで可能な限りの言語に切り替えて、メインストーリーをクリアする自動テストも動かすことで、日々更新されるパッケージの動作確認を自動化することができました。ここまでがCEDEC2022での講演内容になります。

これですべて解決・・・と言いたいところだったのですが、実際にはここまでやっても足りないことがありました。

残っていた問題は、拠点間の時差を含めたデリバリー時間の肥大化です。手動テストを行っているQAチームが、パッケージの数とサイズの肥大化により、手動でダウンロードしてインストールを行うのにとても時間がかかっているという相談を受けました。詳しく調査してみたところ、開発側が想定しているよりも時間がかかっていることがわかりました。これは、古いパッケージでテストが行われるため、すでに最新パッケージで修正しているバグの報告が届くことになり、開発チームにも悪影響があります。

さらに詳しく調査したところ、自動化ワークフローにも問題がありました。自動テストは、当たり前ですが自動で実行され、自動で結果も集計されるのですが、その結果をテスト自動化チーム側で分析してパッケージの安定性を各拠点(開発・QA・翻訳・LQA)に連絡するという作業は手動でした。これは時間にすると2時間程度でしたが、手動テストの部隊を2時間待たせることになりますし、翻訳やLQAを行う海外拠点だと、時差の関係で、タイミングが悪いと結果の伝達に丸1日かかるなど、テスト自動化チームがボトルネックになっていました。図にまとめると下記のようなワークフロー上の問題がありました。

問題点を整理すると、まず、デリバリーの自動化は、アップロードだけでなく、ダウンロードやインストールにも注視する必要があるということです。わかってしまえば当たり前のことですが、開発チームとしては、パッケージをリリースすればOKという認識になりがちですし、QAチーム側も仕方ないものとして、なかなか開発チームに相談できないケースが多いのではないかと思います。クオリティエンジニアが普段から開発チームとQAチームを横断して自動化・効率化を行っているのは、こういった拠点間・チーム間の課題を見つけるためでもあります。これは、自動テストに協力しているQA部門のメンバーがすでに使っていたパッケージの自動ダウンロード・インストールツールをQA拠点全体に展開してもらうことで解決できました。

1つ目の問題点が解決したので、もう1つのテスト結果の伝達によりテスト自動化チームがボトルネックになっている問題に取り掛かりました。これは、プロジェクトの自動化・効率化が目的のチームなのに、とても皮肉なことですね。しかし、私たちは悲観することなく、この問題の原因調査を行いました。
そもそもなぜテスト自動化チームが自動テストの結果を分析して、それを各拠点に伝える作業をしていて、時間もかかっていたのでしょうか?原因は2点ありました。

1つ目は、自動テストのカバー範囲が拡大した結果、テスト結果が膨大になって、可視化したグラフを一通り確認するだけでも時間がかかっていることが分かりました。これは、可視化を整理することで解決できそうです。

2つ目は、各拠点で安定しているパッケージとみなす条件が異なり、常にその条件が変化するという点です。開発チームは致命的ですぐ修正すべき不具合が何かという情報を必要としていますが、これは自動化ワークフローによって自動で集計されるため、時間をそれほど要しません。しかし、QA・LQAのチームは手動でその日にテストしようとしているテストケースが最新のパッケージで動作するか、バグがあるにしても、最低限起動するかどうかなどの情報を必要としており、常にテストケースの実施範囲は変化するため、日々の自動テストの結果の細かい箇所を調査して伝える必要がありました。完全にすべてが安定したパッケージを毎日作成できれば良いのですが、開発中はどうしても新規に実装することで新しい不具合が出てしまうため、どこが安定していて、どこに致命的な不具合があるかを見極めて伝達する必要があります。極端な例ですが、QAの場合、ボス敵のテストに集中している時は、ザコ敵と戦えないような致命的な不具合があっても、その日のテスト作業に影響は出ません。また、LQAの場合は、フランス語のテストに集中している時は、必ずしも全言語で安定している必要はありません。このように、テスト自動化チーム側で各拠点の進捗を把握して、その上で必要な自動テストの結果をまとめて伝えていたので、時間がかかっていたわけです。

私たちは、この2つの問題を解決するために、自動テストの結果の伝達方法についても自動化しました。それが下記の図になります。

まず、可視化の一番重要なものを1ページにまとめたサマリーを作って、簡単に最新パッケージの安定性を確認できるようにしました。そのうえで、個々の拠点が必要としている分析結果を別のページにまとめて、その確認方法も各拠点に説明して、最新パッケージを使ってテストするかどうかを拠点ごとに各自で判断してもらうことにしました。さらに、夜間のQA環境を利用して、開発チームだけでなく、手動のQAチームにも自動テスト実行に協力してもらうことにしました。自動テストを実行する過程で最新のパッケージが自動でインストールされていますので、手動のQAチームのメンバーは、始業して自動テストの結果を確認したら、すぐに最新のパッケージに切り替えて手動テストを実施することができるようになりました。これらの自動化とワークフローの変更により、最大7時間程度かかっていたのが、11分に大幅に短縮することができました。

また、前項で誕生したテスト自動化チームは、このタイミングでQA部門のメンバーが加入することになりました。開発とQAが協力したテスト自動化チームを結成することで、QA部門側からも、開発の中を含めたプロジェクト全体を横断する視点が生まれました。これは、QAテスターの新しいキャリアパスを生むことにつながりました。QAテスターだったメンバーが、テスト自動化エンジニアになり、さらにクオリティエンジニアに成長して、開発側の環境もサポートするようになったケースが実際に生まれています。今後は、QA部門での新しいキャリアの選択肢となっていくことに期待しています。

(2022年~)マルチゲームエンジンに対応した自動化とクオリティエンジニアリングチームの誕生

前項で述べた事例のように、プロジェクト全体を横断して自動化・効率化する重要性の高まりに合わせて、クオリティエンジニアの需要も増えていきました。
今までの若手育成の取り組みにより、クオリティエンジニアを各プロジェクトに1名ずつアサインできるようになってきていたため、まさに満を持したタイミングになりますが、各クオリティエンジニアは、日々の業務を行えるスキルを身に着けているものの、そのスキルレベルにはばらつきがあり、異なるゲームエンジンの情報や、お互いの技術・知見を共有する場が必要でした。また、適切なワークバランスの確保のため、バックアップ体制も整えておく必要がありました。そこで、クオリティエンジニアについても、自動テストの作成・運用を行うテスト自動化チームのように、チームを結成することにしました。クオリティエンジニアリングチームの誕生です。
出来たばかりのクオリティエンジニアリングチームには、マルチゲームエンジンに対応した自動化環境の整備という新たな課題がありました。内製エンジンのドラゴンエンジン以外に、Unreal Engine、Unityのテスト自動化環境を用意したのが、下記のCEDEC2024の講演資料になります。ドラゴンエンジンのテスト自動化のフレームワークを各ゲームエンジンに適した形で移植することで、共通のテスト自動化のフレームワークとして実装・運用し、それぞれのゲームエンジンを使用したタイトルで、開発スピードやゲームの品質の向上に貢献することができました。

ここでは、講演で詳細に説明しきれなかった点を補足したいと思います。各ゲームエンジンの開発では、チケット管理システムの運用にも影響がありました。チケット管理システムでは、バグやタスクを管理していますが、そのステータスの遷移であるチケットのワークフローは、各プロジェクトのワークフローに沿ったものが必要です。ゲームエンジンの特性はこのプロジェクトのワークフローに影響があるため、チケット管理システムにも影響が出てくることになります。ドラゴンエンジンには、アセットやパッケージのビルド後にチケットを自動遷移する「コンバート予約」という仕組みがあるのですが、この自動遷移するステータスを見直す必要がありました。

コンバート予約の詳細:『「龍が如く」の高速デバッグ術~そびえ立つバグの山を踏破するための弾丸ワークフロー~』(73P-78P)

ドラゴンエンジンの場合は、各アセットを中間データで管理しており、この中間データをコンバートすることでゲームのパッケージに反映される仕組みです。このコンバートにより、共通の中間データから各プラットフォームに最適なデータに変換する作業が自動化されるだけでなく、アセット単体のバリデーションテストを行うことで、データのバグの混入を未然に防ぐというメリットもあります。しかし、自分が作成・修正したアセットが、いつゲームに反映されるかを知る方法が複雑で、バグの場合は特に報告者がどのパッケージで修正を確認すればいいのか迷ってしまう状態になります。この問題を解決するために導入したのがコンバート予約という仕組みです。ドラゴンエンジンでは、「コンバート待ち」「パッケージ更新待ち」というステータスを用意して、各コンバートやパッケージのビルドが完了すると、チケットのステータスを、最新パッケージで修正確認が可能な「確認待ち」のステータスに自動遷移します。このタイミングで、修正が反映されたタイミングが分かるのと同時に、どのビルド番号のパッケージに反映されたかを確認することができるため、手戻りや待ち時間を削減することができます。

これがUnreal EngineやUnityの場合は、アセットをコミットすることで、直接Editor上に反映され、即時確認ができるという点で異なっていました。さらにUnreal Engineでは、プログラム(C++)の修正を加えた場合にEditor用のDLLを更新する必要があります。大枠のチケットワークフローは統一しつつ、これらのゲームエンジンの違いに寄り添ったのが下記の図です。

Unreal Engineでは「DLL更新待ち」というステータスを追加して、Editorへの反映も通知できるようにしました。そのうえで、ゲームエンジンごとにステータスの意味の定義を見直して、UnityやUnreal Engineでは、「パッケージ更新待ち」の時点で「Editor上で修正を確認可能」という意味に再定義しました。この柔軟な取り組みによって、基本的なチケットワークフローを統一しつつ、それぞれのゲームエンジンに最適かつ最速なチケットワークフローを構築することができました。
また、ここまで説明してきたテスト自動化の様々な取り組みは、クオリティエンジニアの頑張りだけではなく、開発チームの協力も欠かせません。例えば、プログラマーに積極的にアサーションを組み込んでもらうことで、適切なタイミングでエラーを検知することが可能になります。プロジェクトのメンバーに自動化の仕組みを理解してもらい、最大限活用してもらうことで初めて成果を出すことができるのです。
私たちは、様々な自動化の環境を実装・導入・運用するだけでなく、それらを普及させることも活動内容の一つです。そのためには、プロジェクトにアサインされて、より深くプロジェクトの状況を把握する必要があります。これもプロジェクトに1名ずつクオリティエンジニアが必要な理由の一つになります。

クオリティエンジニアのモチベーションの源泉には何があるのか?

ここまで読み進めていただいた方の中には、なぜここまでやるのか、どこからそのモチベーションが生まれてくるのか、疑問に思われる方もいらっしゃるかもしれません。私たちクオリティエンジニアは、ゲームを開発する人、ゲームをテストする人、ゲームをローカライズする人、それぞれと同様に、そして彼らと共にゲームを作っているという認識で取り組んでいます。より面白く、より高品質なゲームを、より早くユーザーの方たちに届けたいという思いも同じです。ただ、その目的を達成するための手段や役割が異なるだけなのです。
私たちクオリティエンジニアは、開発者を最大限リスペクトして、彼らがゲームを面白くすることだけに集中できる環境作りを目指しています。自動化・効率化を行う際は、ルールを極力増やさずに、自動化・効率化したワークフローを自然に受け入れてもらえるように気をつけながら、「ゲームを面白くすること以外は、私たちが全部自動化するんだ!」という気概で取り組んでいます。

クオリティエンジニアの新たな挑戦

最後に、再び一人称を阪上のみの「私」に戻します。このような経緯で、クオリティエンジニアとクオリティエンジニアリングチームが誕生したわけですが、これはあくまで「龍が如くスタジオ」の中だけの話でした。この取り組みは、高品質なゲームをより早くユーザーに届けることに一丸となる「龍が如くスタジオ」の組織文化があったからこそ生まれたと言えますが、 同様の体制を構築することは、どのチーム・スタジオ・会社でも実現できるのではないかと私は考えました。そこで、私個人は、セガのグループ内のすべてのゲームプロジェクトを自動化・効率化するため、グループ全体の技術サポートを行う部署に異動することにしました。まだ始めたばかりの取り組みですが、共通化や汎用化を進めつつも、各プロジェクトに寄り添った形で自動化・効率化を進めるという基本な考え方は同じです。この新たなチャレンジの成果の発表は、またの機会を楽しみにしていてもらえればと思います。

しかしながら、セガのグループ全体の自動化・効率化となると、圧倒的に人手が足りません。ここまで読んでいただいた方の中には、クオリティエンジニアに興味を持っていただけた方もいるのではないかと思います。セガのグループ内の様々なゲームプロジェクトを自動化・効率化するクオリティエンジニアは絶賛募集中ですので、ぜひご検討ください。

https://hrmos.co/pages/sega/jobs/174

また、このような自動化・効率化が行われている「龍が如くスタジオ」の環境で働いてみたいという方も募集していますので、こちらもよろしくお願いします。

https://hrmos.co/pages/sega/jobs/1714868213340426255

CEDEC 2024 セガサミーグループによるセッション紹介!

暑い日々が続きますが、ゲーム開発者にとっても熱いゲーム業界最大級のカンファレンス「CEDEC2024」が今年も近づいてまいりました。
例年同様に横浜で開催される今回のCEDEC、セガサミーグループ社員も多数登壇します!

cedec.cesa.or.jp

会期:2024年8月21日(水)~8月23日(金)

今回のSEGA Techblogでは、各セッションとその登壇者の紹介に加え、ここでしか見られない当日資料を抜粋してチラ見せ!(一部公募のみ)  ブログ本文は、株式会社セガ 第3事業部の麓から紹介させていただきます。

(紹介する順番は講演日時順です。)

  • 自分達のプロダクトを自分達でユーザーに届ける。メリットしかなかったマーケティングのインハウス化
    • セッション内容
    • 講演者
  • 「龍が如く」も「スーパーモンキーボール」も自動化!クオリティエンジニアリングチームによるマルチゲームエンジン対応で進化した「龍が如くスタジオ」のテスト自動化環境について
    • セッション内容
    • 講演者
    • スナップショット
  • 仮想ファイルシステムを導入して開発環境のストレージ課題を解消する!
    • セッション内容
    • 講演者
    • スナップショット
  • PCリリースでグローバル展開!PC対応における技術課題と開発サポート体制構築
    • セッション内容
    • 講演者
    • スナップショット
  • Mayaウィザードが徹底討論!Mayaのあれってどっちがいいの?
    • セッション内容
    • 講演者
  • ワーキングペアレントの働き方と悩み/上司・経営者の立場での悩み:ラウンドテーブル2024【現地のみ開催】
    • セッション内容
    • 講演者
    • スナップショット
  • ゲーム開発過去資料の保存の最前線を語ろう!
    • セッション内容
    • 講演者
  • ペルソナ3 リロードでの自動プレイの実装と運用
    • セッション内容
    • 講演者
    • スナップショット

自分達のプロダクトを自分達でユーザーに届ける。メリットしかなかったマーケティングのインハウス化

セッション内容

本セッションではセガのデジタルマーケティングチームとアプリボットが取り組んでいる、
スマホゲームマーケのインハウス化に関してご説明いたします。

デジタルマーケティングをインハウス化することには、
コストカットや運用のスピードUPなどの様々なメリットがあります。
一方でインハウス化を実現するにはマーケの最新トレンドの獲得やクリエイティブ制作の工数などいくつかの課題をクリアしなければいけません。

セガが実際にインハウス化を進めるにあたり、どのような課題がありそれをどう乗り越えたのか、
またインハウス化を進めるにあたりアプリボットがどのようなサポートをしたのかをご紹介いたします。

講演者

株式会社セガ
ジャパンアジアパブリッシング事業本部 マーケティング本部 データソリューション部 アドストラテジーチーム
チームリーダー
李 惠媛 ほか

第6会場 8月21日(水) 13:40 〜 14:40 レギュラーセッション(60分)

cedec.cesa.or.jp

続きを読む

『PSO2ニュージェネシス』における雪原の跡付け表現について

1.はじめに

株式会社セガ 第3事業部 第3オンライン研究開発プログラム1部の釘田と申します。
連日の寒さも徐々に明け、春の訪れを感じる頃合いです。
今年の冬は何度か弊社オフィスのある大崎でも雪が降りました。

私はこれまで雪のあまり降らない地域で過ごしてきたこともあり、
雪が積もるとつい童心に帰り、雪の上を歩きたくなります。

この雪の上で跡が付く様子ですが、ゲームではどのように表現されているでしょうか?
今回の記事では『ファンタシースターオンライン2 ニュージェネシス』における
雪原の跡付け表現について紹介したいと思います。

2.目次

3.前置き

記事内の画像は開発時のゲーム画面となります。
実際にリリースされているゲーム画面とは異なる場合もありますので、あらかじめご了承ください。
また、以降『ファンタシースターオンライン2ニュージェネシス』のことを『NGS』と表記します。

4.フィールドでの雪原の跡付け表現

まず、『NGS』における雪と氷のフィールドである「クヴァリス」での雪原の跡付け表現について説明します。
「クヴァリス」では一部の雪原において、キャラクターが歩いた場所に足跡が残ります。

4.1.キャラクターの足跡表現

足跡を雪原に残すにはどうすればいいでしょうか?

まずは実際に現実世界で雪がどのようにしてへこむかについて考えてみましょう。
冒頭の写真のような雪が積もった道を思い浮かべてみてください。

雪は柔らかいため、足を踏み入れると雪が積もっていた高さから踏み込んだ深さまでへこみ、足跡として残ります。

『NGS』では、地面の高さを雪の厚みの分だけ上昇させ、キャラクターが歩いた場所をへこませています。
これは以下のような処理で実現できそうです。

  1. 地形とキャラクターに対する深度撮影
  2. 軌跡テクスチャの作成
  3. 雪面の変形

それでは実際の処理について見ていきましょう。

4.1.1.地形とキャラクターに対する深度撮影

キャラクターの足によってどの位置でどの程度の深さまでへこませるかを決めるために、
カメラを地面の下から上方向に向けて地形とキャラクターに対して深度撮影を行います。

4.1.2.軌跡テクスチャの作成

次に、跡を付ける深さの情報が格納された軌跡テクスチャを作成します。
雪がへこむのは以下の図のように、キャラクターの足が地面と雪面の間にあるときです。

条件式で表すと以下のようになります。

地面の高さ < キャラクターの高さ < 雪面の高さ

ここでは説明のため、キャラクターの足の位置を「キャラクターの高さ」と表現します。

先ほどの深度撮影の結果を用いて
「キャラクターの高さ」はキャラクター深度から、「地面の高さ」は地形深度から求まります。
また、「雪面の高さ」は「地面の高さ」と「雪の厚み」を合わせた値です。
「雪の厚み」は内部的に設定されたパラメータで、場所によって厚みが異なります。

「雪をへこませる割合」は雪がへこんでいない状態を0.0、すべてへこんでいる状態を1.0として、
以下のように計算します。

雪をへこませる割合 = (地面の高さ + 雪の厚み - キャラクターの高さ) /  雪の厚み

シェーダーで計算された値は軌跡テクスチャへと書き込まれます。

地形深度を用いているため、傾斜のある地形などでもへこませることができます。

4.1.2.1.軌跡テクスチャのフィルタ処理

次に作成した軌跡テクスチャに対して、より自然なへこみ跡を表現するため、フィルタ処理をかけています。
ここで冒頭の写真を再度見てみましょう。

足跡と雪の縁の部分に着目してみると、足跡側ではへこみが緩やかに広がっています。
また、雪側では踏まれて押し出された雪によって盛り上がっていることがわかります。

これらを表現するために、フィルタ処理では平滑化を行い、へこみを緩やかにしたうえで、
へこみ部分の縁の高さを調整し隆起させています。

以下は実際のゲーム内でのフィルタ処理の有無の比較画像になります。

フィルタ処理をかけることで、全体的に滑らかな跡になり、縁部分での雪の盛り上がりも表現できています。

また、軌跡テクスチャにはプレイヤーキャラクターを中心として80m四方の範囲内の跡が記録されており、
プレイヤーキャラクターからの距離に応じて徐々に足跡が消えていく表現についてもフィルタ処理で行っています。

4.1.3.雪面の変形

最後は雪面の描画時に、作成した軌跡テクスチャの情報を元に雪面を変形させます。
雪面の変形にはテッセレーション処理を用います。

テッセレーション処理では地形モデルのポリゴンを分割し、分割されたポリゴンの頂点の位置を変更します。
頂点位置の変更の際に軌跡テクスチャを参照することで、跡付けを行う部分をへこませます。

下記がテッセレーション処理の有無の比較画像になります。

テッセレーションなし(左)とテッセレーションあり(右)の比較

ちなみに、テッセレーションに対応していない場合でも、軌跡テクスチャを用いた法線の調整やAOにより陰影をつけることで疑似的に表現しています。

5.ハウジングコンテンツでの雪原の跡付け表現

ここまではフィールドにおける雪原の跡付け表現について説明しました。

ここからは、『NGS』のハウジングコンテンツである、「クリエイティブスペース」の雪山風マップ
「クヴァリステーマ」における雪原の跡付け表現について説明します。

「クリエイティブスペース」内ではフィールドと同様のキャラクターによる雪への跡付けだけでなく、
プレイヤーが設置可能なオブジェクトである「ビルドパーツ」による跡付けにも対応しています。

5.1.オブジェクトよる跡付け表現

基本的な処理の流れについてはフィールドでの跡付けと同様です。

今回はオブジェクトによる跡付けを行うため、追加でオブジェクトに対する深度撮影を行い、
軌跡テクスチャ作成時にオブジェクトの高さも考慮します。

処理の流れは以下の通りです。

  1. オブジェクトに対する深度撮影
  2. 地形とキャラクターに対する深度撮影
  3. オブジェクトの深度を考慮した軌跡テクスチャの作成
  4. 雪面の変形

以降の説明では、1. と 3. について紹介します。

5.1.1.オブジェクトに対する深度撮影

まずは 「1. オブジェクトに対する深度撮影」についての説明です。

オブジェクトを設置する際にカメラを地面の下から上方向に向け、
オブジェクトの表面と背面の深度を撮影します。
描画結果は二枚のキャッシュテクスチャに格納されます。
表面と背面の両方で深度を描画する理由については後述します。

「クリエイティブスペース」ではオブジェクトの設置だけでなく、地形の高さも編集することができます。
オブジェクトに対する深度撮影の際には地形の編集が可能な、高さ100m、256m四方の範囲が収まるように
キャッシュテクスチャへ深度が書き込まれます。

これによって「クリエイティブスペース」内にいる間は、オブジェクトの跡が付いた場所から離れても跡が残ります。

また、オブジェクトに対する深度撮影はオブジェクト設置時に一度だけ行うことで、
深度撮影による負荷を抑えています。

5.1.2.オブジェクトの深度を考慮した軌跡テクスチャの作成

次に「3. オブジェクトの深度を考慮した軌跡テクスチャの作成」について説明します。

オブジェクト深度の使い方について、
まずはキャラクターの場合と同じように深度テクスチャを一つだけ使う場合を考えてみましょう。

次のようなオブジェクトを設置します。

雪がへこむのは、オブジェクトの底面が地面と雪面の間にあるときです。

条件式で表すと以下のようになります。

地面の高さ < オブジェクト底面の高さ < 雪面の高さ

ここでオブジェクト底面の位置を、説明のため「オブジェクト底面の高さ」と表現します。
「オブジェクト底面の高さ」はカメラを地面の下から上方向に向け、
オブジェクトに対して深度撮影した、オブジェクトの表面の深度から求まります。

「雪をへこませる割合」についてもキャラクターの場合と同様に計算します。

ここまではキャラクターの場合と同様に、オブジェクト表面のみの深度撮影で問題なさそうです。

では次のケースを見ていきましょう。

「クリエイティブスペース」ではプレイヤーが自由にオブジェクトを設置でき、
地形の高さも編集できるため、オブジェクトが地形に埋まる場合があります。
以下のようにオブジェクトを地形に埋めた状態で配置する場合はどうでしょうか?

地形に埋まった状態で設置した場合、オブジェクトの底面が地面よりも低くなってしまい、
埋まった箇所で跡が付きません。

そこで、地面の高さよりも低い位置にオブジェクト底面が来た場合は、
「雪をへこませる割合」を1.0とし、雪をすべてへこませます。

この場合は以下のように地形に埋まった箇所でも跡を付けることができます。

しかし、上記の改善を加えた場合でも別の問題が二つ起きてしまいます。
次で詳しく見ていきましょう。

5.1.2.1.オブジェクトの深度撮影が表面のみの場合に起きる問題

まず一つ目はオブジェクトが完全に地中に埋まってしまった場合です。

この場合だと「オブジェクト底面の高さ」だけではオブジェクトが完全に埋まったかの判定が取れず、
以下のように不自然に跡が付いてしまいます。

二つ目の問題はオブジェクトを回転させたときに起きます。
先ほどのオブジェクトを次のように回転させ、一部地中に埋まった状態で設置する場合を考えてみましょう。

この場合も完全に埋まった場合と同様に、地中に埋まって隠れってしまった部分で不自然に跡が付いてしまいます。

これらの問題に対応するために、オブジェクトに関しては表面と裏面の両面で深度を描画しています。
表面と裏面の深度の使い方について、先ほど回転させて設置した場合を例に見ていきます。

まず、オブジェクトの上面が地面よりも上にくる領域に着目します。

条件としては以下のようになります。

地面の高さ < オブジェクト上面の高さ

ここでも底面と同様に、オブジェクト上面の位置を、説明のため「オブジェクト上面の高さ」と表現します。
「オブジェクト上面の高さ」はカメラを地面の下から上方向に向け、オブジェクトに対して深度撮影した、
オブジェクトの背面の深度から求まります。

次に、「オブジェクト底面の高さ」を用いて雪をへこませる部分を決めます。

上図の①のように、オブジェクト底面が地面と雪面の間にくる場合は、先ほどの説明の通り、
キャラクターでの跡付けと同様の方法で「雪をへこませる割合」を計算します。

また、上図の②のようにオブジェクトの底面が地面よりも下にくる場合は、
「雪をへこませる割合」を1.0とし、雪をすべてへこませます。

これにより、オブジェクトが完全に地中に埋まってしまう場合や、
一部だけ埋まってしまう場合に対しても自然な跡付けを行うことができます。

最終的に二枚のキャッシュテクスチャに保存されたオブジェクト深度、キャラクター深度、
地形深度を用いて軌跡を描き、キャラクターの跡付けの際と同様のフィルタ処理を経て、
「クリエイティブスペース」での軌跡テクスチャができます。

6.まとめ

今回『NGS』における雪原表現について、フィールドとハウジングコンテンツにおける事例を紹介しました。

フィールドではキャラクターの足跡による跡付け、
ハウジングコンテンツでは自由な配置を踏まえたオブジェクトによる跡付けについて説明させていただきました。

現実世界は目を引く景色、心を動かす風景、興味深い光学現象であふれています。
それらを注意深く観察し、ゲームに落とし込むことでさらに感動を与える表現が生まれると思っています。

今回紹介した手法は目新しいものではありませんが、何かの参考になりましたら幸いです。

7.最後に

セガでは一緒に働く仲間を募集しています。
共に感動体験を色々な人に提供できるようなゲームとそのグラフィックス表現を作りませんか?
もしご興味を持たれましたら下記のサイトにアクセスをお願いいたします。

採用サイト

SIEM on Amazon OpenSearch Serviceによるセキュリティログの可視化について

はじめに

株式会社セガ ゲームコンテンツ&サービス事業本部技術本部開発IT支援部の長谷川と申します。今回はセキュリティログの活用法の一例としてSIEMを用いた可視化方法を紹介します。

目次

背景

昨今セキュリティ対策不足によるデータの抽出やサービス操作される被害が発生しており、ログからユーザの行動を抽出し、可視化するまでを一括管理できるものが求められていました。さまざまなサービスの中でSIEM on Amazon OpenSearch Serviceにてログ情報からユーザの行動を可視化・検索により原因を改善するができるため、利用し始めました。 セキュリティログをgrepやAthena利用して調査を行ってきましたが、可視化を行うまでは進んでおらず全体的なセキュリティを確認するまで相当な時間がかかっていました。上記のサービスを利用することで、原因特定までの時間が軽減されました。

Opensearch(Elasticsearch)とは

  • 大容量データを処理することを想定した全文検索エンジン
  • 複数のノードにデータ分散して保存する分散設計
  • システムログの可視化・検知やユーザへのレコメンドや分析など多種多様な範囲で利用可能

SIEMとは

  • SIEM は Security Information and Event Management の略で、セキュリティ機器、ネットワーク機器、その他のあらゆる機器のデータを収集及び一元管理をして、相関分析によって脅威検出とインシデントレスポンスをサポートするためのソリューションです。Amazon OpenSearch Service は、OpenSearch と OpenSearch Dashboards を大規模かつ簡単でコスト効率の良い方法を使用してデプロイ、保護、実行する完全マネージド型サービスです。Amazon OpenSearch Service の環境に SIEM として必要な機能を実装したのが SIEM on Amazon ES です。

github.com

Cognitoとは

大きくユーザプールとIDプールに分けて認証・認可を行うシステムです

ユーザプールとは

  • ユーザの作成、管理及び認証を行うユーザディレクトリです
  • アプリからの多数の承認フローが利用可能です
  • サインイン後に発行されるトークンを用いて、認証されたサービスへアクセスを行います

IDプールとは

  • ユーザプールにて認証されたユーザがどのリソースへのアクセスに対してユーザの権限を管理します
  • 未承認のユーザに対して、一時的なリソースへのアクセス権を付与することができます
  • ユーザのアクセス権をルールベースおよびアクセスベースでの制御が可能です

アーキテクチャ

設定方法

※今回はセキュリティ面を考慮しまして、VPC内でOpenSearchを構築いたします

  1. SIEMの設定方法は下記より構築しています SIEM構築
  2. ECS on Fargate,SecretsManager,Cognito,ELB,Route53サービスの作成します
    1. terraformにより作成(作成方法については割愛します)
  3. Cognito設定を一部抜粋して紹介します
    1. ユーザプールの作成

      1. 該当のユーザプールのサインインエクスペリエンス欄より、多機能認証を必須設定する
      2. アプリケーション総合よりアプリケーションクライアントの作成をします
        1. 認証フローについては該当の項目を選択します

          Note If you don't specify a value for ExplicitAuthFlows, your user client supports ALLOW_REFRESH_TOKEN_AUTH, ALLOW_USER_SRP_AUTH, and ALLOW_CUSTOM_AUTH. docs.aws.amazon.com

        2. コールバックURL,サインアウトURLを記入します
    2. IDプールを作成します

      1. ユーザアクセス欄より認証されたユーザに対するロールを作成します
  4. nginxプロキシによるCognitio認証設定します
    1. https://repost.aws/ja/knowledge-center/opensearch-outside-vpc-nginx
    2. セキュリティの観点より環境情報などをSecretsManagerより値を取得し、nginxに取得した環境変数を渡します ※下記はタスク定義の設定を抜粋して記載しています
{
    "containerDefinitions": [
    { ------ 中略 ------
        "secrets": [
            {
                "name": "opensearch_domain",
                "valueFrom": <secretsmanager_arn>:<opensearch_domain_key>::
            },
            {
                "name": "cognito_domain",
                "valueFrom": <secretsmanager_arn>:<cognito_domain_key>::
            }
        ]
    }
}

Cognitoによるログイン

  • SIEMのURLにアクセスすることでCognito認証によるログインを行います
  • MFA設定されている場合は次にTOTPよりコードを入力します

セキュリティログの可視化

  • Discover画面にて特定のインデックスで取り込んだログを表示が可能になります

    • フィルターやSearch欄でクエリで絞り込むことで特定ログ・項目の絞り込みが可能になります
  • DashBoardにおいても特定フィルター、特定アカウント、特定ACLの絞り込みにより必要なデータの可視化が可能になります


    クロスアカウントのCloudTrailログの可視化


WAFログの可視化

補足

※今回はアカウント間のデータを一括収集を行い、データの可視化を行う例となっております。

  • 特定の条件(特定のIP、国、UAからDDosアタック)が発生した場合にOpensearchのアラート通知を送るなどでシステム改善の気づきを与えます
  • セキュリティログに限らずアクセスログも収集しているため、Athenaに頼らずに検索や可視化までが一括して可能になるため汎用的な調査が可能になります
  • アクセスログ(CloudFront,ELB,WAF,VPCFlowログなど)の可視化により不要に開放しているセキュリティグループやパスを改善する手がかりを得られ、システム改善にも貢献します
  • 他のメンバーにも確認しやすいDashBoardになっているため、インフラ面の改善に限らずアプリケーション側の改善やBotなどの防ぐべき対象を可視化することができます

まとめ

  • セキュリティログの一元管理および可視化としてSIEMを利用しました
  • 一括管理することで、情報が整理されて必要な条件下でのセキュリティの対策を包括的に行うことが可能になります
  • S3のトリガー経由でログの取り込みが行われるため、同一アカウント・クロスアカウントに限らず様々なサービスログを取り込むことも可能になります

※まずは、セキュリティに不安がある方や様々なサービスを用いて通知疲れになっている方はSIEMを用いて一元管理して可視化してみると効率的な監視の手がかりがつかめると思います。

セガで働くことにご興味を持たれましたら下記サイトにアクセスお願いします。 www.sega.co.jp (C)SEGA

参考

『PSO2 ニュージェネシス』におけるトゥーン表示対応について

1.はじめに

株式会社セガ 技術本部 技術統括室 ソフトシステムセクションの西濱 高志と申します。 今回の記事では『ファンタシースターオンライン2 ニュージェネシス』におけるトゥーン表示対応について紹介いたします。

2.目次

3.前置き

記事内の画像は開発時のゲーム画面となります。実際にリリースされているゲーム画面とは異なるところもありますので、あらかじめご了承下さい。

また、表記として『ファンタシースターオンライン2 ニュージェネシス』のことを『NGS』、『ファンタシースターオンライン2』のことを『PSO2』と呼称することにします。

トゥーンレンダリングに関する最新技術の話はありませんが、何かしら参考になれば幸いです。

4.トゥーンレンダリングとは?

トゥーンレンダリングとは、コンピュータグラフィックスにおいてアニメ風、広くは漫画やイラスト風の作画でレンダリングする手法のことを言います。 セルシェーディングとも呼ばれ、ゲームの表現において個人、企業問わず採用する例が増えています。

トゥーンレンダリングを実現する上で、重要な要素となるのが「陰影のマルチトーン化」と「アウトライン表現」の2点になります。

4.1.陰影のマルチトーン化

トゥーンレンダリングにおける陰影は、物理的な計算を解いて表現するフォトリアルな陰影とは違い、デザイナー(アーティスト)が指定、調整した色で陰影も表現されることが多いです。

一般的な実装としては色の段階を設定したテクスチャ(ランプテクスチャ)を用意し、陰影の表現に使用する形が多いです。

しかし陰影を段階的にする都合上、人間の顔など複雑な凹凸がある物体では陰影が綺麗にならないことが多いです。 このため、トゥーンレンダリングでは物体の法線を調整して陰影を綺麗にし、アニメのような表現に近づけるといった工夫がされています。

この記事では、このようなトゥーンレンダリングにおける陰影の段階化を「陰影のマルチトーン化」と呼称することにします。

4.2.アウトライン表現

イラストやアニメにおける、「線画」を表現するため、アウトラインの表示もトゥーンレンダリングでは重要な要素になります。

実装方法としては、「背面法」と「輪郭線の抽出」の二つがあります。 「背面法」とは対象のモデルについて頂点を法線方向に拡大して裏面を描画した後、通常の描画を上塗りすることでアウトラインを表現する手法になります。1

「輪郭線の抽出」とは、レンダリング途中で生成した深度情報等をもとにフィルタ処理をすることで輪郭線の抽出を行い、アウトラインを描画する手法になります。 下記図は、出力された画像に対してSobelフィルタを用いてアウトラインを描画する例になります。

それぞれ特徴があり、まとめると下記のようになります。

手法 クォリティ 処理負荷 モデルデータの改良
背面法 描画する物体が多くなるほど高くなる 必要
輪郭線の抽出 描画する物体に関わらずほぼ一定 不要

このため、プレイヤー等、描画する物体が少ない場合はクォリティが高い「背面法」、背景や小物など描画する物体が多い場合は処理負荷を抑えられる「輪郭線の抽出」と使い分けをすることが、最近のゲームでは多いです。

5.『NGS』におけるトゥーン表示対応について

『NGS』では、元々トゥーンレンダリングを想定してモデルデータを作成していません。 このため、いくつか異なるアプローチで実装する必要がありました。 ここでは具体的にどのような実装をしたのかについて紹介いたします。

5.1.『NGS』のレンダリングシステムについて

『NGS』では、不透明の描画について「ディファードレンダリング」を行い、半透明、カットイン画面で「フォワードレンダリング」を行うという実装になっています。 通常のレンダリングパスを図にしたものが下記になります。

また、描画したGBufferの内容が下記になります。

前述したように、モデルデータがトゥーン表示用のものではないので必要な情報を適宜GBuffer等から取得して、活用していくことで実装しました。 最終的なトゥーン表示におけるレンダリングパスが下記になります。

5.2.拡散反射光(陰影)のマルチトーン表現

最初に拡散反射光(陰影)のマルチトーン表現について説明します。 前述したように、拡散反射光(陰影)のマルチトーン表現を行う際はランプテクスチャを用意して、陰影付けを行うのが一般的です。

しかし、『NGS』の既存のモデルデータにランプテクスチャを追加するのは難しく、GBufferにモデル毎のランプテクスチャの値を入れるための容量もありません。 なので、一律のパラメータを用意し、計算で陰影付けを行いました。

具体的なパラメータは下記になります。

struct ToonDiffuseParameter
{
    float brightness;     //!< 陰影の明るさ
    float subsurface;     //!< どの程度表面下散乱の色(血の色)を使用するか
    float threshold;      //!< どの段階から暗くするか
    float gradation;      //!< どの程度陰影をくっきりさせるか
}

ToonDiffuseParameter m_diffuse_bright; //!< 明るい部分のパラメータ
ToonDiffuseParameter m_diffuse_middle; //!< 中間部分のパラメータ
ToonDiffuseParameter m_diffuse_dark;   //!< 暗い部分のパラメータ

これらのパラメータを用いて、陰影を3段階に分けています。

『NGS』の拡散反射光は「Lambert BRDF」を使用しています。 このため、トゥーンレンダリングにおいてもモデルの法線とライトの内積値を元に、陰影を3段階に分けて陰影付けに使用しています。 実際にパラメータを調整すると下記のように陰影の調整ができます。

また、GBufferにどのシェーダを使用しているかの情報(ShaderID)を格納しているため、陰影をつけている物体の判別ができます。 これを用いて『NGS』では「毛髪用のパラメータ」と、「それ以外のパラメータ」の二つを用意して別々で調整ができるようにしています。2

5.3.鏡面反射光(スぺキュラ)のマルチトーン表現

次にスぺキュラのマルチトーン表現について説明します。 トゥーンレンダリングのスぺキュラ表現では、ワンポイントで表現することが多いかと思います。 実装方法としては、「スペキュラ自体をテクスチャに描きこむ」、或いは「スぺキュラマスクを用意して指定した箇所のみスペキュラを描く」等があります。

しかし、『NGS』ではゲーム中に登場するNPCの「グレン」のように、顔の色がほぼ黒色のキャラクターを作ることができます。 このようなキャラクターは前述した、「拡散反射光(陰影)のマルチトーン化」をしても陰影ができず、真っ黒になってしまうといったことが発生しました。

このため、『NGS』でも「陰影のマルチトーン化」と同様に「スぺキュラのマルチトーン化」を行うことで、黒色のキャラクターでもアニメ調のような陰影が見えるように実装を行いました。 下記が調整するパラメータになります。

struct ToonSpecularParameter
{
    float brightness;     //!< スペキュラの明るさ
    float exponent;       //!< スペキュラの広がり
    float gradation;      //!< どの程度くっきりさせるか
}

ToonSpecularParameter m_specular_bright; //!< 明るい部分のパラメータ
ToonSpecularParameter m_specular_middle; //!< 中間色のパラメータ
ToonSpecularParameter m_specular_dark;   //!< 暗い部分のパラメータ

基本的には「拡散反射光(陰影)のマルチトーン化」とほぼ同じような処理でスぺキュラを3段階に分けて描画しています。

実際にパラメータを調整すると下記のような表示になります。

特にパラメータの調整では黒色のキャラクターでも真っ黒な顔にならないようにしつつ、キャスト(ロボット)等の金属の光沢がカッコよく表現できるように調整しました。

また、スペキュラのマルチトーン化は「肌」、「毛髪」、「その他」で別のパラメータを調整しています。

5.4.アウトライン表現

次に、「アウトライン表現」について説明します。 前述したように、トゥーンレンダリングのアウトライン表現では「背面法」と「輪郭線の抽出」の二つが手法としてあります。 『NGS』では、下記のような制約があり「背面法」を採用することができませんでした。

  • モデルについて、片面しかないモデルやハードエッジを使用しているモデルがあり、法線方向に拡大した時にアウトラインがひび割れてしまう等、不自然な描画になってしまうことがある。
  • 多数のプレイヤー、NPCをトゥーン表示にする必要があり、「背面法」では処理負荷が高くなってしまう。
  • 半透明のアウトラインについて対応することが難しい。

このため、「輪郭線の抽出」を用いてアウトライン表現を実装しました。

5.4.3.輪郭線の抽出

『NGS』ではGBufferのうち「深度」、「法線」、「マテリアル」情報を用いて輪郭線の抽出を行いました。 処理としては、近傍の値と比較して一定以上の差異がある場合、アウトラインを描画するという内容になります。

また、ShaderIDを用いて、「顔と毛髪以外は法線によるアウトラインを使用する」、「毛髪のみ、マテリアルによるアウトラインを使用する」と、カテゴリ毎に分けて使用することで、アウトラインを描画するようにしました。 下記が、それぞれの情報を用いて輪郭線の抽出を行った結果になります。

パラメータとしては、アウトラインの太さや色を調整できるようにしました。 特にアウトラインの色については、近傍の色を元に明度と彩度の調整をすることで色トレスができるようにしています。 また、これらのパラメータは「肌」、「毛髪」、「その他」で調整ができるように実装しています。

struct ToonOutlineParameter
{
    float brightness;   // 明度
    float saturation;   // 彩度
}

ToonOutlineParameter skin_outline_param;    // 肌のアウトライン
ToonOutlineParameter hair_outline_param;    // 毛髪のアウトライン
ToonOutlineParameter other_outline_param;   // その他のアウトライン
float outline_weight;                       // アウトラインの太さ

6.トゥーン用の顔データの作成について

ここまでの処理で、プログラム上の処理が一通り完了しました。 しかし、既存のモデルではやはり顔の陰影が綺麗になりにくいといった問題が発生しました。

これに対処するには、顔モデルの法線を調整する等、データに対して調整を行う必要があります。 『NGS』では、トゥーン表示用に法線等を調整したモデルを新たに用意し、トゥーン表示に切り替えた際に顔モデルを切り替えることで対処するようにしました。3

元々、『PSO2』から『NGS』にアップデートする際、顔のデータは『PSO2』で体のデータは『NGS』といったように、顔と体で別のデータを切り替えることができるシステムとデータを作っていました。 このため顔の切り替え処理については実装をスムーズに行うことができました。

詳細な情報については、CEDEC2022の資料「『PSO2 ニュージェネシス』 長期運営タイトルにおける、大規模バージョンアップの開発事例の紹介」を参照してください。4

トゥーン用の顔データの作成では主に「法線の調整」、「目の陰影を追加」、「ラフネス値の調整」をデザイナー(アーティスト)の方に行っていただきました。 行った調整について簡単にご紹介させていただきます。

6.1 法線の調整について

顔の法線については、モデルの頂点法線について下記のような調整を行っています。

  • 頬の陰影が綺麗になるように調整
  • 口元や、鼻の陰影がくっきりでるように調整

下図が通常時との比較になります。

6.2 ラフネス値の調整について

一部の顔モデルについては、頬、鼻先、唇にスペキュラが出やすくするためにラフネスの調整をしています。 下記が通常時との比較になります。

6.3 目の影について

イラストの表現では、目に対してまぶたの影をつけることで立体感を表現することがあります。 『NGS』のトゥーン表示でも同様に目に影をつけることでイラスト特有の立体感のある目を表現しています。

7.その他の対応

以上がおおまかな、対応内容になります。 しかし、後付けの処理であるため様々な問題が発生しました。 ここでは、発生した問題や対処した方法について紹介したいと思います。

7.1.カットイン画面のトゥーン表示対応

『NGS』では、キャラクターの顔が小さいウインドウに表示される「カットイン描画」と呼ばれるものがあります。この機能は主に、チャット画面やショップでのプレビュー画面で使用されます。

このカットイン画面は、全てフォワードレンダリングで描画しています。 既存の処理ではGBufferの情報を出力しない設計になっていたので、新しくGBufferの情報を一部追加で出力するように改良する必要がありました。 最終的には下記のように、フォワードレンダリングの結果だけでなく法線、マテリアル情報も出力するように変更しました。

後は、前述した処理と同様に「陰影のマルチトーン化」や「アウトラインの表示」を行っています。 下記がトゥーン表示時における、カットイン描画のパスになります。

7.2.半透明のアウトライン

『PSO2』では半透明を使用しているものが多くあります。例として、プレイヤーが身に着けられるアクセサリーである「フォトンマフラー」は、不透明と半透明の組み合わせで作られています。5

このデータでアウトラインを表示した場合、不透明部分だけ考慮されるため、半透明部分で不自然なアウトラインが描画される問題が発生しました。

この問題に対処するため、新しく半透明部分を表すアルファマスク作成し、半透明部分にアウトラインが描画されない対応を行いました。 下図が対応後の結果になります。

8.調整するパラメータについて

内部で調整できるパラメータの合計は最終的に60個になりました。 実装当初、用意したパラメータは固定値とする予定でした。

しかし、『NGS』では人間、キャスト(ロボット)、或いはその枠を超えた様々なキャラクターを作成することができます。

システムの都合で個別にパラメータを設定することが難しいですがそれでも調整できる方が良いと判断し、上記のパラメータをシンプルな形で調整できるようにしました。

製品では「影の濃度」と「輪郭の強調」の二つのパラメータを調整することで、見た目が変わるようにしています。

9.まとめ

これらの対応を行うことで事前にトゥーンレンダリングを想定していなくとも、ある程度のクォリティでキャラクターのトゥーン化を行うことができました。

リリース前はプレイヤーの皆様に受け入れてもらえるか不安でしたが、「キャラクタークリエイトの幅が広がった」、「過去のコスチュームの見た目がよくなり使用する機会が増えた」といった好意的な意見があり、実装してよかったと感じました。

10.最後に

汎用ゲームエンジンが流行りつつありますが、自社でゲームエンジンを開発することで、どういった処理が最適なのかを基礎から学び、ひいては独自の実装で特徴ある表現を可能にすることができます。特に今回のような「ゲームの表現を途中で変えるような大きな変更対応」は自社のゲームエンジンでしか実現ができないものだと思います。自社でゲームエンジンを「使う」だけでなく、「作る」ことができる環境。 セガで働くことにご興味を持たれましたら下記サイトにアクセスお願いします。

(C) SEGA www.sega.co.jp


  1. 描画負荷としては裏面を後で描画する方が良いですが、わかりやすさのために上記の記載になっています。
  2. キャラクターの肌について、肌ではないけど肌と陰影を合わせたいアクセサリーがあり、パラメータを分けることはしませんでした。
  3. トゥーン用に用意してあるのは、『NGS』で新しく作成した顔モデルのみになります。
  4. https://cedil.cesa.or.jp/cedil_sessions/view/2614
  5. 『PSO2』における、髪型も半透明と不透明の組み合わせで作られています。
Powered by はてなブログ