エフェクトを安定動作させる『自動チェック』への取り組み

エフェクトを安定動作させる 『自動チェック』への取り組み エフェクトを安定動作させる『自動チェック』の取り組みについてお話させていただきます。 ©CAPCOM 1

アジェンダ • 導入経緯 • 自動チェックフローについて • 画像比較による差分チェックについて • 導入結果 本日のアジェンダです。 • 自動チェックの導入経緯 2 • 自動チェックフローについて • 自動チェックの１つである「画像比較による差分チェックについて」お話させていただいたあと、チェックを導入した結果につい て共有させていただきたいと思います。 ©CAPCOM 2

導入経緯 まずは導入経緯についてです。 3 ©CAPCOM 3

新機能実装・リファクタリング時に 誤って不具合が入ってしまうことがある 何か新しい機能を実装した際やリファクタリングを行った際に誤って不具合が入ってしまうことがあるかと思います。 4 ©CAPCOM 4

自動チェックの導入経緯 バグ 混入 バグ 混入 対応 コスト 中 大きく挙動が変わる不具合は 比較的気づきやすく 早めに報告がくる 対応 コスト 大 少しだけ挙動が変わる不具合は ほとんど気づかれず 時間が経ってから報告がくる 画像は極端な例ですが、 エフェクトの向きが９０度回転したなど大きく挙動が変わるような不具合は早めに報告されやすく対応コストは少しかかってしまう 5 ものの素早く対処できます。 しかし左右が反転したといった少しだけ見た目が変わるような不具合や使用頻度の少ない機能に不具合が入ってしまった場合ほとん ど気づかれず、後々「挙動が変わった」「挙動がおかしい」といった報告がタイトル側から上がってきます。 時間がたってから報告があると昔のエンジンでの動作やコードを確認するといった対応や既に作成されたアセットの挙動を壊さない ように処理を分けたりなどの対応をしなければならず、開発効率が低下してしまう原因になっていました。 ©CAPCOM 5

自動チェックの導入経緯 該当のエフェクトをチェックすれば防げるが… エフェクトには多種多様な機能があるため １つ１つエフェクトを人の手でチェックするの はコストが高く現実的ではない 実装時に自動で動作チェックを行い、 安定性の向上とコストの削減を目指す これらの問題は影響のあるエフェクトを実装時に確認することで防ぐことができますが、エフェクトには多種多様な機能があるため、 影響範囲が広いと大量のエフェクトを１つ１つ人の手で確認する必要があります。 これはコストがかなり高く現実的ではありませんし、見落としてしまう可能性も高いです。 6 そこで実装したタイミングに「挙動が変わっていないか」「挙動に問題ないか」のチェックを自動的に行うことで、安定性の向上と 人の手によるチェックや後々発生する対応コストの削減を目指し、自動チェックを導入することにしました。 ©CAPCOM 6

自動チェックフロー 次に自動チェックの１つ「画像比較による差分チェック」のチェックフローについて紹介させていただきます。 7 ©CAPCOM 7

自動チェックフロー commit & push まず何かしらの実装を行い、commitとpushを行ったとします。 8 ©CAPCOM 8

自動チェックフロー commit & push commit & push CIを実行 [GitLab] Merge Request [GitLab] master にマージ [GitLab] Merge Request Pipeline(CI) をルールに則り実行 pushされたことを検知しCIを動作させます。 RE ENGINEの開発ではGitLabとマージリクエストによるマージを採用しており、チェック担当者がマージリクエストの内容を確認 9 し、問題なければmasterにマージするといった開発フローをとっています。 マージリクエストでは、マージリクエストパイプラインという機能でCIを実行させることができ、エフェクト専用の変更であれば チェックを行うといったルールを決め、実行させています。 ©CAPCOM 9

自動チェックフロー commit & push commit & push CIを実行 [GitLab] Merge Request ビルドして エンジンを 起動 [GitLab] master にマージ [GitLab] Merge Request Pipeline(CI) をルールに則り実行 CI内では、変更が入ったブランチをcheckoutした後、ビルドしてエンジンを起動させ、 10 ©CAPCOM 10

自動チェックフロー 対象となるエフェクトがすべて再生 されるまで繰り返す commit & push commit & push CIを実行 [GitLab] Merge Request ビルドして エンジンを 起動 エフェクト を再生 [GitLab] master にマージ 数フレーム ごとに画面 キャプチャ 正解画像と 比較し違い をチェック 正解画像を 作成する CIを実行 [GitLab] Merge Request Pipeline(CI) をルールに則り実行 エンジン内では「エフェクトを再生」「フレームごとに画面のキャプチャ」「事前に用意した正解画像と比較しチェックする」とい うフローをチェック対象のエフェクトがすべて再生されるまで繰り返します。 11 正解画像は別途CIを動かし作成していますが詳細については後述します。 ©CAPCOM 11

自動チェックフロー 対象となるエフェクトがすべて再生 されるまで繰り返す commit & push commit & push CIを実行 [GitLab] Merge Request ビルドして エンジンを 起動 [GitLab] master にマージ [GitLab] Merge Request Pipeline(CI) をルールに則り実行 エフェクト を再生 数フレーム ごとに画面 キャプチャ 新規にチェック追加可能 ＋ エンジン内で処理しているため 細かい制御が可能 正解画像と 比較し違い をチェック 正解画像を 作成する CIを実行 この囲われている箇所ですが変更可能になっており、後でチェックを追加することが可能です。 各チェック処理はエンジン内に組み込んでいるので、エフェクトを再生し、１フレームずつ進めるといった細かい制御ができ、多彩 12 なチェックを可能としています。 ©CAPCOM 12

自動チェックフロー 対象となるエフェクトがすべて再生 されるまで繰り返す commit & push commit & push CIを実行 [GitLab] Merge Request ビルドして エンジンを 起動 [GitLab] master にマージ [GitLab] Merge Request Pipeline(CI) をルールに則り実行 エフェクト を再生 数フレーム ごとに画面 キャプチャ 新規にチェック追加可能 ＋ エンジン内で処理しているため 細かい制御が可能 正解画像と 比較し違い をチェック クラッシュ やチェック に失敗した らエラー 正解画像を 作成する CIを実行 このチェック中にクラッシュが発生したり、１つでも違いがあればエラーとし、マージリクエストをエラー状態にすることで問題の ある変更が入ることを防いでいます。 13 これが「画像比較による差分チェック」のフローになります。 ©CAPCOM 13

画像比較による 差分チェックについて 次に「画像比較による差分チェック」そのものについてお話させていただきます。 まず実際にこのチェックを利用して、どのような差分が検出できるかをご紹介したいと思います。 14 ©CAPCOM 14

画像比較による差分チェックについて 正解 機能 追加後 正解画像としての画像、機能追加を行った際の画像がこちらです。 パッと見た感じは同じように見えますが、よくよく見比べてみないとわからない程度のずれがあります。 実際には動いていたり、乱数によってランダム性があるため人の手でチェックした場合は絶対に気づきません。 15 この２つの画像を差分チェックに通すと… ©CAPCOM 15

画像比較による差分チェックについて 人では気づけない挙動の変化にも気付くことができる 正解 差が検知され エラーになる 機能 追加後 差分がこのように検知され、エラーとして扱われます。 この画像は実際に開発で検出されたもので、コード整理の際に必要なコードを消したことによって挙動が変わり差分チェックに引っ 16 かかっていました。 このような人が気づかないような差でも状況によってはエフェクトの見た目が大幅に変わってしまうため、このチェックにより意図 せず処理を変えてしまったなどを未然に防いでいます。 ©CAPCOM 16

画像比較による差分チェックについて 実現するために必要だったもの 1.再現可能な 仕組み 2.正解画像の用意 3.画像比較処理 4.チェック用 アセット ここから差分チェックを実現するために必要だった４つのことについて１つずつ紹介していきます。 17 ©CAPCOM 17

画像比較による差分チェックについて 1 再現可能な仕組み 正解画像と一致させるために何度再生しても挙動や画面をキャプチャしたときの画 像を同じにする必要がある フレームレート の固定 パーティクルの 乱数固定 フレーム単位で の再生制御 何度やっても同じ挙動、 同じキャプチャ画像を実現 １つ目…「再現可能な仕組み」についてです。 正解画像と合わせるためには、エフェクトの挙動を何度再生しても同じにし、画面をキャプチャしたときの画像を同じにする必要が 18 あります。 そこで「フレームレートの固定」「パーティクルの乱数固定」を行うことでランダム性をなくし、「フレーム単位でエフェクトの再 生を制御」することでキャプチャタイミングを数フレームごとに設けることができ、毎回同じ見た目、同じキャプチャ画像を実現し ています。 ©CAPCOM 18

画像比較による差分チェックについて 1 再現可能な仕組み 一番問題になったのが「GPUParticle」 ・Interlocked等によってズレが生じる ・チェックのために処理を変えるわけにはいかない 挙動のチェックが 目的 パフォーマンスは度外視可能 1Particle/1Dispatchにすることで挙動に かかわる処理を変えずにチェック可能 この仕組みを作るにあたって、かなり大変だったのが、「GPUParticle」です。 パーティクルの更新が並列で動作してしまうため、Interlockedなどが利用されていると生成されるパーティクルがずれてしまい、そ 19 のままではうまくいきませんでした。 加えて、チェックのために処理を変えると正常なチェックにならないため変更することもできません。 このチェックでは「挙動に差がでないかチェックすること」が目的なのでパフォーマンスの問題は無視することが可能です。 そのため1Particle/1Dispatchにすることで何度再生しても同じ挙動かつ挙動にかかわる処理を変えることなくチェックできるように なっています。 ©CAPCOM 19

画像比較による差分チェックについて 2 正解画像の用意 ・毎日深夜にCIを実行させ自動生成 ・チェック用の処理を流用し、挙動をあわせ 数フレームごとにキャプチャしサーバーへ 正解画像は 意図した挙動時の 画像にする 画像の生成が必要なものだけアップロード 他の要因による見た目の変化を防止し、 昔の挙動・見た目をずっと担保可能 ２つ目…「正解画像の用意」についてです。 毎日深夜にCIを実行させ、チェック時と同じ「乱数やフレームレートの固定」やフレーム単位でエフェクトの再生を制御し、数フ 20 レームごとにキャプチャして正解画像を作成していきます。 作った正解画像はサーバーなどCIを実行するPC等からアクセスできる位置にアップロードしています。 正解画像は意図した挙動になったときの画像にする必要があるため、全アセットの画像を再生成せず、画像がない場合やアセットに 更新があった場合のみ生成しアップロードしています。 これにより他の要因によって見た目が変わり、正解画像が意図しないものになることを防止し、昔の挙動や見た目をずっと担保でき ます。 ©CAPCOM 20

画像比較による差分チェックについて 3 画像比較処理 一番の問題「キャプチャした画像は完全には一致しない」 ・完全一致によるチェックは不可 ・類似率によるチェックはエフェクト毎に調整や設定が難しい 正常に検知でき、 調整もしやすい方法 OpenCVによるエッジ検出でのチェック ・縮小化・ブラーしてからエッジ検出 ・指定サイズ以上のエッジがあればエラーに ３つ目…「画像比較処理」についてです。 ここで一番の問題となったのが「キャプチャした画像は完全には一致しない」ということです。 毎回同じ挙動になるようにしていますが、数Pixel程度のずれは必ず発生します。 21 そのため完全一致によるチェックは使えず、類似率によるチェックだとエフェクトごとに画像の占有率が異なるため、どこまで許容 していいか調整がしづらく使えませんでした。 そこで正常に検知でき、ある程度調整が可能な方法として、OpenCVによるエッジ検出を利用したチェックを採用しました。 誤差を減らすためブラーや縮小化してからエッジ検出を行い、指定サイズ以上のエッジがあればエラーとする・・・といった単純な ものですが実際に誤検知されたことはありませんし、細かい挙動の差も検知できています。 ©CAPCOM 21

画像比較による差分チェックについて 4 チェック用のアセット 問題その１「タイトルアセットは膨大かつチェックに向かない作り」 ・チェックに時間がかかるためpushする度に実行できない ・極小パーティクルやゲーム内の要素に紐づいたエフェクトは 正常にチェックできない 短時間かつ効果的に チェックする方法 チェック専用のアセットを作成 しかし、これにも問題がある 最後の４つ目…「チェック用のアセット」についてです。 タイトルのアセットを利用するとチェックするアセットが膨大になってしまうかつ、チェックに長時間かかってしまうため、pushす 22 る度に実行するわけにはいきません。 さらにタイトルのアセットにはチェックに向かないものがあったりもします。 そこで、短時間かつ効果的にチェックする方法として、チェック専用のアセットを作ることにしました。 …が、これにも問題がありました。 ©CAPCOM 22

画像比較による差分チェックについて 4 チェック用のアセット 問題その２「チェック専用のアセットを作るのは大変」 ・多種多様な機能があるためアセットを作成するコストが高い ・案件は山積みなのでまとまった時間をとるのも難しい 低コストでアセット を増やす方法 実装時に使ったアセットの再利用 修正確認用、新機能確認用のアセットを利用 しチェック範囲を徐々に拡大していく 単純にチェック専用のアセットを作るのはコストが高いということです。 多種多様な機能をカバーするアセットを作成するためにはまとまった時間が必要です。 23 そこで、低コストでアセットを増やす方法として「修正確認用のアセット」「新機能確認用のアセット」などを利用していくことに しました。 同じ不具合を防止できたり、新機能は不具合が起きやすいためチェックとしてとても有用です。 さらに確認用のアセットは様々な機能を併せて作られることが多いため、チェック範囲を広げることもできます。 現在も徐々に数を増やし、現在は約２００アセット（約数百パターン）を網羅しており、約１５分程度ですべてをチェックしていま す。 以上が画像比較による差分チェックについての紹介でした。 ©CAPCOM 23

その他の自動チェック 画像比較による差分チェック以外にも 様々なチェックを導入 ・ アセットを開いて正常に保存ができるか ・ エフェクトが利用するシェーダが正常にコンバートできるか ・ エフェクトアセットが正常にプレビューできるか 画像比較による差分チェックを主に紹介させていただきましたが他にも 安定性向上やチェックコストを削減できる様々なチェックを用意しています。 24 ©CAPCOM 24

自動チェックを導入した結果 これらの自動チェックを導入してどうなったのか…というところですが、 25 ©CAPCOM 25

自動チェックを導入した結果 人の手にかかるコストは減った ０ 簡単な動作チェック 約30分 分に まず人の手にかかるコストは削減できました。 簡単な動作チェックを人の手で行うと、ビルドしてエンジンを起動しチェックが完了するまで約３０分ほど必要でしたが、自動 26 チェックに任せられる範囲の場合、これが“０分”となり、開発効率向上に貢献しています。 事前に不具合が検知されることで、チェック担当者によるチェック回数も減らすことができ、チェック担当者の負担軽減にもつな がっています。 ©CAPCOM 26

自動チェックを導入した結果 報告された不具合の修正数は減少 不具合修正数（１年間） 導入前 242 導入後 212 自動チェックで マージ前に防いだ 不具合数 47 次にタイトル側から報告された不具合の修正数ですが、これも減少しました。 自動チェックを導入してから１年間でクラッシュや挙動の差異等を「４７件」検知しマージ前に防ぎました。 27 その結果、不具合の修正対応数は約１０％減少し、サポートコストや対応コストの削減につながっています。 ただまだ不具合数が多いので、今後は様々な機能を網羅できるタイトルアセットを利用したチェックやアセットも自動生成しチェッ クする・・・といったものも実装予定で、より不具合報告や修正数を減らし、機能実装や研究に時間を使えるようにしたいと考えて おります。 ©CAPCOM 27

自動チェックを導入した結果 リファクタリングに取り組みやすい １年間でリファクタリングを行った回数 導入後 導入前 75 38 自動チェックの導入はコスト削減だけではなく、リファクタリングに取り組みやすくなるというメリットも生まれました。 影響範囲が読みづらく手が出しづらい大規模なリファクタリングも「自動チェックによって幅広い機能をカバーしてくれるから大丈 28 夫」といった安心感をエンジン開発者へ与えることができ、リファクタリングへの意欲向上や行動に繋がっています。 実際に自動チェック導入前と導入後の１年間を比較してみると、リファクタリングを行った数は大小合わせて倍となり、エンジンを より良いものにする助けも担っています。 これらが自動チェックを導入した結果になります。 この情報が何かの参考になれば幸いです。 ©CAPCOM 28

以上となります。 ご清聴ありがとうございました。 29 ©CAPCOM 29