「Crusader Kings III」開発日記#92が公開されていましたので、その内容をご紹介。今回はバグ報告から修正までの過程について。バージョン1.5+「Royal Court」リリース後の開発日記です。
開発日記
開発日記#92は、バグ報告から修正までの過程について。
バグ報告フォーラム
- みなさんがゲームを起動して中世の王国を管理するよい数時間を過ごす決心をしたとき、その裏では問題なく記憶に残る体験ができるようにさまざまなことが起こっている。CK3のような複雑なゲームではこれはより重要なことで、機能が追加されるにつれて経済・AI・戦争・交流のバランスを注意深くとるようなことがますます複雑になる。すべては最新のアップデートで得られる体験が待つに値するものにするためだ。
- 私たちQAはうまくいくものといかないものを見極め、ゲームがプラットフォームに登場する前にあらゆる問題をチームに報告することを職務としているが、時には問題が隠されていて、発見するには多くの手順を経なければならないとしたら？ ここがみなさんに助けていただけるところだ。私たちは深刻で大きな問題をみなさんがその存在に気づく前に先回りして発見し、取り除いて、洗練された製品をお届けできる。
- それ以外のことについては規模の経済だ。さまざまなシステム・言語・体験・プレイスタイルについて、ゲームをどのように形づくるかという点で最大の助けになるのはみなさんだ。そのために私たちはバグ報告フォーラムを用意している。ここではみなさんの苦情・フィードバック・再現手順・イライラすることを吐き出してもらえる。
確認
- 貴重な時間を割いてプレイ上の問題を報告してもらうと、QAはフォーラムを調べて私たちのマシン上で再現し、その問題が深刻かどうかや、その問題を回避するアドバイスを提供できるかを確認する。
- チケットがみなさんの再現手順、説明、スクリーンショット、クラッシュログ、セーブデータによって内部で確認されると、私たちは社内のチームが理解できる言語、Jiraに翻訳する。プロジェクトチームが重要なこと、つまりより面白いものを作ることに集中できるように、プロジェクト全体のデータベースを評価し、古くなったチケットを取り除き、残っているチケットをすべて更新するのは通常QAの仕事だ。
- 「古くなった」とはどういうことか。例えばある問題が長い間隠れたシステムに残っていた場合、その問題は古くなる。私たちはバグを機能にしたりシステムを完全に変えたりして、もはやそれは問題ではなくなる。私たちも驚くほど長い間プレイヤーに拾われないバグもある。
Jira
- 私たちはJiraのチケットを効率的に使用するようチームに呼びかけている。「昨日話したことを修正せよ」というチケットが送られてきて、それ以外にはなにも書かれていない場合、既になにをやっていてこれからなにをやる必要があるのか、どのようにそこに戻って再テストするのかをどうして思い出せるだろう。そのようなチケットが意味するところを理解できる人は誰もいない。
- すべてのフィールドが適切に記入されていることはデータベースを効率的に使用するために最重要のことであり、みなさんや内部から報告が来る大量のバグを処理する際に私たちのチームの仕事をほんの少し楽にするために必要だ。
- すべてが整理され、全員が同じ考えを持っていれば、プロデューサーがいつどんな報告をするかスケジュールを立てやすくなる。
- フォーラムで賛成投票をすることは？ どのチケットが優先され、どんなことがあっても修正されなければならないものかを知らせてくれる強力なツールだ。これは先に修正されるべき重要なものはなにかに影響を与えることができる手段だ。
（アン）ラッキーなプログラマー/デザイナー
- バグの確認、Jiraへの登録、バージョンの割り当て、優先順位付けが完了すると、開発者はそのバグを選び出して修正できるようになる。これはバグの発生元に応じて、通常デザイナーかプログラマーのどちらかが担当する。バグの原因がゲームの他の部分にあることが判明した場合、バグが他の役割に再割り当てされることもある。
宗教騎士団の軍が解散するかどうかを制御するコード
- 次はどのようになぜその問題が起こるのかを調査する必要がある。例として、宗教騎士団が参戦要請を受けた際に自分たちの軍を召集して直後にそれを解散させてしまうという最近修正された問題を見てみよう。この問題は大聖戦において宗教騎士団が自分たちの軍を召集するようにした副作用だ。宗教騎士団が同盟勢力として参戦したときはいつでも（大聖戦の間はその基準を満たしている）、彼らは軍を召集するようになっていた。
宗教騎士団がキャラクターによって雇用され得るかをチェックするコード
- 私たちはなぜ宗教騎士団が軍を解散させるのかを調べることから始めた。軍を召集するということは戦う相手がいるはずだ。私たちはデバッグモードとソースコードで、個々の関数呼び出しの段階を踏んでなにが起こっているかを確認できる。関数をたどると、宗教騎士団が戦っている戦争は彼らにとって関係ないために軍が解散していることが判明した。彼らが参戦している戦争の敵を調べると、敵対する教派である者は誰もいなかった。また、彼らは宗教騎士団のグランドマスターに雇用されているために宗教騎士団自身が軍を召集しているのであって、他のキャラクターが雇用しているのではないこともわかった。
- 宗教騎士団は戦う相手側に敵対する教派の参加者がいない戦争では戦わない。宗教騎士団が無関係な敵に対して軍を召集したために解散したことがわかったので、私たちは彼らが軍を召集する方法を制御するロジックを調査しなければならない。
キャラクターが宗教騎士団が利用できるときのチェックを行うコード
- AIのコードを掘り下げるのはやめておくが、まとめると「宗教騎士団は軍が召集され得るときは軍を召集する」ということだ。そこで私たちは明らかに不可能なはずのときに宗教騎士団が軍を召集できるのはなぜかを調べる必要があり、上のような関数にたどり着いた。これはキャラクターが宗教騎士団が利用できるかどうかをチェックするコードだ。宗教騎士団が自身で参戦する場合、pCharacterは宗教騎士団の所有者であるグランドマスターとなる。
- グランドマスターが自分の宗教騎士団を利用できるのは理にかなっているが、さらにその下にそのキャラクターが関連する戦争に参加しているかをチェックしていることに注目してほしい。これは、先ほど軍を解散させたのと同じ関数だ。
宗教騎士団がキャラクターによって雇用され得るかをチェックするコード2
- 宗教騎士団がグランドマスターに雇用され得るかどうかをチェックする関数に戻ろう。簡略化のため、関係ない部分はすべて折り畳んでいる。それぞれの「if」セクションの中にはこの関数が失敗し、グランドマスターが自分の宗教騎士団を雇用できなくするものが含まれている。
- 関連部分を見ていこう。グランドマスターとして他の宗教騎士団を雇用することはないので、雇用制限には抵触しない（注：上の画像の最初のif文）。既に他の誰かに雇用されているわけでもないので、その部分はスキップする（注：2番目のif文）。グランドマスターはこの騎士団を所有しているので、3番目のif文も関係ない。最後に、自分の宗教騎士団を雇用する余裕がある（注：4番目のif文）。これはグランドマスターが宗教騎士団を雇用できることを意味する。
宗教騎士団の軍の召集を防ぐ解決
- ここで解決策が見つかった。自分の宗教騎士団を持っている場合はいつでもこれを利用できるが、そのために参加している戦争が関連性のあるものかどうかをまったく確認していない。そこで、私たちはこの問題について非常に単純な解決を行った。関連する戦争であるかどうかのチェックはその宗教騎士団のグランドマスターであるときのみスキップされ、グランドマスターの教派をチェックする必要はないということはわかっているため、宗教騎士団を雇用しようとする者が宗教騎士団の所有者である場合は彼らが関連する戦争に参加しているかどうかをチェックするようにした。
マージリクエスト
宗教騎士団が無関係な戦争で軍を召集するのを防ぐことについてのマージリクエストの概要
- 修正が作成されるとマージリクエストに入れられる。これはその修正が次のビルドに入れられる前のステップだ。マージされるまでに多くのステップがある。適切な分野のチームのメンバーが変更をレビューすることから始まる。これは修正によって発生し得る意図しない副作用を発見するための最初のステップだ。こうしたレビューの厳密さは、その修正が次のリリースに入る場合にはさらにいくつかのステップを経て大きく高まる。
問題修正のコミット
- マージリクエストにはテンプレートがあり、提出時に記入する必要がある。このプロセスは修正者とレビュワーの双方に修正の意図とそれを実際に特定のバージョンにコミットするかを見直す機会をもたらす。私たちは修正がどの程度危険なのか、その修正がどの程度意図しない効果をもたらすか、ゲーム全体のパフォーマンスにどのような影響を与えるのか、修正にパフォーマンスを落とすような計算の重いコードやスクリプトがあるかどうかなどを真剣に検討する。
- マージリクエストを管理する際に重要なのは以下の点だ。
- レビュワーは間違っていると証明されるまで正しい。
- ディシプリンリードは常に正しい。
- 修正をビルドに追加するには、一般にディシプリンリード・技術リード・もう一人のレビュワーの承認が必要だ。リリースが近づいたときには技術リードだけが実際にビルドに修正をマージできる。
- レビュワーはマージリクエストに対してフィードバックを行い、これにはなんらかの対処を行う必要がある。概要ではこの修正は全部で5つのコミットで終わっていることがわかるが、そのうちの1つだけが修正で、残りのコミットはレビュープロセスでのコメントやパイプラインと呼ばれる自動ビルド・テストシステムで発生した問題への対応だ。
マージリクエストのパイプライン
- パイプラインはレビュープロセスを進める間にコードの整合性と品質を検証し、ゲームをビルドし、テストする。マージリクエストを通すには、プログラマーから明確な許可がない限りは、こうしたことをすべて通らなければならない。また、次のリリースの場合はパイプラインもすべて合格しなければならない。例外はない。
QAの確認
- 修正がマージされたらQAチームに引き渡される。私たちはもう一度チケットを確認し、その修正がそこに記載された問題を解決しただけでなく、他に影響も及ぼしていないかを確認する。大きな修正はドミノのようなもので、ひとつ押せば他も倒れる。ずっと昔に作ったものがランダムに押されて、なにもないところに古い問題が突如として現れることもある。
- 時には同じチケットに何度も繰り返し取り組む理由がこれだ。時にはバグが長い間私たちのデータベースに残ることもある。私たちはリリース時にみなさんが言及する問題が依然として残っているのをわかっているし、私たちはすべて修正したいと思っているが、リリースのたびに新たなチケットが切られ、それに対処しなければならない。
アップデート
- 私たちの側ではバグを解決済みとして完了するが、バグを解決する際にもうひとつ重要なのがコミュニティのみなさんだ。QAチームがリリース前にほとんどの問題を発見するが、問題が再発することもある。これは説明の難しい無数の要因によって起こり得る。ハードウェアに起因する問題や私たちがテストできないような特殊な状況もある。こうした場合はみなさんに発見していただき、報告していただいている。詳細で具体的であるほどよい。コミュニティの誰もその問題を再び経験しなければ、解決済みのままとなる。
コメント