「Crusader Kings III」開発日記#171――リリース後のサポート

「Crusader Kings III」開発日記#171が公開されていましたので、その内容をご紹介。今回はリリース後のサポートについて。「Khans of the Steppe」リリース後の開発日記です。

前回：開発日記#167――もっとも偉大なるもの

開発日記#168はMod制作、開発日記#169はアート、開発日記#170はチェンジログと実績に関する内容となっており、当サイトでは記事にしていません。

開発日記

開発日記#171は、リリース後のサポートについて。

発売時の状況

4月28日に「Khans of the Steppe」と1.16「Chamfron」アップデートがリリースされ、最初の反応は技術的な観点からもプレイヤーの感情的な観点からもかなりよいものだったが、すぐにクラッシュ報告の急増に気づき、プレイヤーからのコメントもそれを裏付けた。QAチームはすぐに1.16の不安定性の2つの主要な原因を特定し、その両方に対処するホットフィックスをプッシュした。こうした修正でクラッシュ発生率は大幅に減少したが、依然として高いレベルのままであり、そうしたクラッシュの原因究明と解決に取り組んでいる。

安定性の問題から否定的なレビューが急増したが、「Khans of the Steppe」に対する反響の大勢は発売直後から非常に好意的だった。その後、レビューのスコアが下がり始めた。私たちのすべてのリリースでは事前に定めた間隔で内部報告を行う。0日後・1日後・7日後などだ。0日後・1日後のレポートは、最初は好意的なものだったが、週の終わりにはプレイヤーが我慢できなくなるほど時間のかかる未解決の問題があることが明らかになった。

その問題がなんなのかを解明するにはレビューそのものを基礎から分析する必要がある。まずSteamの否定的なレビューをスプレッドシートにまとめて翻訳し、主な不満がなにかに基づいて分類した（私たちが行うフィードバック分析はこれだけではないが、レビューについては説明しやすいので今回の開発日記の理想的な内容だ）。その後、どの不満が話題の中心になっているかを示すグラフを作成する。安定性への不満は既に対処されているか調査中なのでその次を確認すると、バランス調整となっている。このグラフでデザインチームとゲームディレクターに「プレイヤーはバランス調整がおかしいと思っている」と伝え、実際にフィードバックを調べて具体的な問題点を特定し、最初のリリース後のサポートアップデートでそれに対処できることになる。
「Khans of the Steppe」の次の展開として、私たちはプレイヤーのみなさんがこのDLCに懸念を持っていることを承知しており、リリース後のサポートに割り当てられた時間内でできる限り多くの懸念に対処するよう取り組んでいる。

プレイヤーからのフィードバック

インターネット上のコメントをどのように変更履歴に反映させているかを説明するため、まず私たちがサポートしているすべてのプラットフォームからどのようにフィードバックを収集し、解析しているかを説明する。

リリース前のフィードバック

「Khans of the Steppe」に対するプレイヤーからのフィードバックへの対応は「Chapter 4」発表前から始まっていた。2月のプレビュー開発日記は遊牧民に特化したDLCに対するプレイヤーの要望や期待を知るために通常のスケジュールよりもかなり前倒しで公開した。ここで得たフィードバックが、例えば遊牧民政府をステップでない地域にも拡大することなどにつながった。
さらにコミュニティからおよそ100人が参加する永続的なクローズドベータプログラムも運営しており、有名Mod開発者、歴史家、詳細かつ実用的なフィードバックを送ってきたコミュニティメンバー、コンテンツクリエーターなどがいる。このプログラムでは開発プロセスのできるだけ早い段階でコンテンツについてフィードバックを得る（「Khans of the Steppe」では1年ほど前から始まっている）。開発が進むにつれてフィードバックに応じて変更することが難しくなるため、このプログラムは私たちにとって不可欠だ。

開発バージョンが十分に進んで発表できるようになると、私たちは開発日記を始める。これは取り組んでいることをプレイヤーに伝え、コンテンツについてより幅広い意見や提案を得る機会をもたらす。YouTubeチャンネルで公開される動画視聴者も視聴者の視聴維持の統計から開発日記のどの節が興味を持たれているかを知ることができる。

最後に、リリース1か月前ほどから別のプレビューグループを運営し始めた。これは永続的なベータプログラムの期間限定バージョンで、参加者の選考基準も近い。ここでは基本的に門戸を開放し、運営上の安全性をある程度維持しつつ、管理できると思われるだけの人数を参加させる。Mod開発者の代表は、事前に彼らのModで互換パッチを作成できるように大幅に増加する。また、当社のインフルエンサーリレーションマネージャーが見つけたコンテンツクリエーターもこのプログラムに引き込む。あなたが考えているあのYouTuberもこのプログラムに参加している。ここでの目標はコンテンツが可能な限りプレイヤーの期待に沿うものであることをリリース前に確認することだ。

リリース後のフィードバック

メジャーアップデートの後にプレイヤーからのフィードバックを即座に収集するのは、テストをすり抜けた重大な問題に素早く対処し、リリース後のサポートで新コンテンツに関するプレイヤーの不快感に対処する上で非常に重要だ。こうしたフィードバックを私たちはフォーラム、Facebook、Steam、YouTube、Twitter、Reddit、Discord、QQ Guild、Bilibili、Tiebaなど、さまざまな場所から収集している。こうした情報収集を容易にするため、私たちはコミュニティアンバサダーを設けてプレイヤーと開発チームの架け橋としている。コミュニティアンバサダーの仕事はプレイヤーの感情やフィードバックの収集、議論のモニタリング、プレイヤーから報告される緊急の問題の特定などだ。リリース後に彼らは直ちに反応を探し始め、それを詳細なリリース後1日目のレポートにまとめる。たくさんの議論、提案、報告をよりわかりやすい形式にまとめ、コミュニティが最も緊急だと思うものを素早く特定する。こうして集められたフィードバックはリリース後サポート期間において開発チームが何を優先すべきかを決定するために使われる。

リリース後のサポート

私たちのスタジオはさまざまなチームに分かれており、それぞれ特定のアップデートや拡張に取り組んでいる。リリース後のサポートはメジャーアップデートを担当するチームが解散し、そのメンバーがスタジオ内の他のチームに異動するまでの、開発の最終段階だ。この段階の目的は未解決の問題に対処することで、バグ修正・バランス調整・フィードバックに基づくシステムの改善や変更などを行う。リリース後のサポート段階で実装できなかったアップデートや修正はRealm Maintenanceに回され、将来のアップデートに統合される。リリース後のサポート段階ではこれを支援する専門家を配置して品質保証の取り組みを強化する。こうした専門家は開発チームと緊密に連携してバグレポートを確認し、報告された問題を可能な限り多く調査、特定し、開発チームのメンバーに割り当てて対応する。

リリース後のサポート段階でもうひとつ重要なこととして、何らかの理由で初期リリースから「締め出された」問題を処理するという点がある。このようなことが起こり得る理由としてフィーチャーフリーズとlocフリーズがある。フィーチャーフリーズの間はDLCに新システムを追加できず、追加する必要があるものは次のアップデートを目標としなければならない。locフリーズは私たちがサポートしているすべての言語へのローカライズに時間がかかるため、新たなテキストが追加できないということであり、新たなテキストやテキストの更新は次のアップデートを目標とする。こうしたフリーズ期間はフィードバックへの対応が遅れることを意味するが、アップデートが意図された時期に実際にリリースされることを保証するのに役立つ。
上述の「次のアップデート」はリリース後のサポートの「ポイントリリース」となることがほとんどだ。リリース後のサポート期間には通常2つか3つのアップデートを行う期間が割り当てられており、フィーチャー/locフリーズ後に発生した問題やコミュニティから報告された問題に取り組むために必要になることを想定している。さらに、緊急アップデートを可能にするため、必要に応じてホットフィックスのための時間を割り当てている。
リリース後のサポート期間はフィードバックに対応するだけでなく、プレイヤーがゲームに期待していることを知って今後の開発の準備をするという意味でも重要な段階だ。

次のステップ

「Khans of the Steppe」以降に私たちが得たフィードバックとプレイヤーが望んでいるものは、第一にバランス調整がおかしいということと、より熱心なプレイヤーがゲームを難しくすることを望んでいるということだ。前者は既に1.16.1と1.16.2をリリースし、後者はハードとベリーハードの難易度を今週末に1.16.2.1でリリース予定だ。

私たちは難しさや挑戦がシステムの相互作用から有機的に生まれるものであってほしいと考えており、恣意的にAIを一律で強化したり、プレイヤーにペナルティを課すことは理想的な解決策ではないと考えている。しかしコミュニティは私たちが目標を達成できていないことを明確にしており、私たちは長期的にはそうした挑戦という目標を追求し続けるが、今すぐにゲームが難しくなることを望むプレイヤーのために新たな難易度を導入する。
恒常的にherdが減少するシステムもかなり求められているが、私たちはこれを実装するつもりはない。このシステムはそうしたことを念頭に置いて開発されておらず、不連続な減少を元にしている。herdの減衰はプレイヤーよりAI領主に与える影響が大きく、バランス調整や難易度に関する問題が複雑化する。「Khans of the Steppe」のリリース後のサポート期間がもうすぐ終わるため、核となる部分をそこまで作り直す時間もない。Realm Maintenanceで調整することはできるが、システムそのものを根本的に作り直す可能性は低い。
それ以外にまだ潰すべきバグがある。AIがpaizasを要求してくることは次のアップデートで大幅に減るはずだし、ステップ地域のマップモードも適切な色付けがされるはずだ。その後はMod制作者がModをアップデートでき、プレイヤーはアップデートが来ることを心配せずに長いキャンペーンを終えられるような比較的安定した期間がある。報告されるバグその他の問題には取り組むが、それは「Chapter IV」の次のDLC発売時に反映される。
以上は開発サイクル・リリース後のサポート・フィードバックのループの包括的な概要にはほど遠いが、こうしたことがどのように機能しているかがわかれば幸いだ。

来週は「All Under Heaven」の設計思想について。

次回：開発日記#172