「Stellaris」開発日記#217――CustodiansのフィードバックとQ&Aのまとめ

「Stellaris」の開発日記#217が公開されていましたので、その内容をご紹介。今回はフィードバックとQ&Aのまとめについて。3.1?「レム」リリース前の開発日記です。

前回：開発日記#216――レムアップデートにおけるnecroidsの変更

開発日記

開発日記#217は、フィードバックとQ&Aのまとめについて。

• 「Custodian」イニシアティブの発表以来、Custodianチームに取り組んでほしいことについて多くの投稿があったし、私たちには取り組みたいことやゲーム内で改善できると感じていることについて大きな計画がある。コミュニティチームはコミュニティがCustodianチームに取り組んでほしいことや、我々が積極的に取り組んでいることに関するフィードバックを収集している。
• こうしたことについて私たちは何度も繰り返してきたが、私たちが考え出した多くのアイディアはいわば「車輪の再発明」を含んでいた。つまりフィードバックの閲覧や議論の管理のために第二の（時には第三の）プラットフォームを追加し、そこからフィードバックを収集し、検討/実装のために内部のトラッキングシステムにロードするというものだった。
• 最終的に、私たちはフィードバックを2つのカテゴリーに分けることにした。すなわち「募集型フィードバック」と「コミュニティフィードバック」だ。

募集型フィードバック

• Custodianチームのフィードバックのアイディアを考えている間に、私たちはフォーラムで試験的なフィードバックスレッドを立てた。これが非常にうまくいったため、こうしたフィードバックスレッドを続けることにした。こうしたスレッドはパラド社員のみが投稿できる「フィードバック」サブフォーラムに移動するが、すべてのフォーラムユーザーが返信できる。こうした方向づけされたフィードバックスレッドはこれまでのものと同じ一般的なフォーマットに従う。
• 私たちはフォーラムの管理者とともにオプションを検討している。例えば応答することでどの返信がもっとも人気であるかを測定したり、これをフィードバック収集の追加指標として使用するなどだ。
• 私たちが使用するタイムフレームを指摘しておくのは重要だろう。ゲーム開発は長いプロセスであり、開発者がコンテンツを書く→コンテンツがQAを通過する→コンテンツがゲームのライブビルドにプッシュされる、というほど単純であることは稀だ。ほとんどの場合で特定の機能の開発に数か月かかり、機能のフレームワークが文書で作成されてからゲームのコードが書かれる。
• 最初の設計段階はコミュニティからのフィードバックを集めるのに最適な時期だ。というのは、その機能に関する作業がまだ行われていないためだ。これは開発にとってはいいことだが、タイムフレームに対するコミュニティの期待を緩和することが重要で、一般的には1～2パッチサイクル先のパッチに対するフィードバックを収集している。
• レムアップデートを例にとると、現時点でレムのデザインは完了しており、レムの次のアップデートのデザインも順調に進んでいる（ネタバレになるが、レムよりも小規模になる予定だ。レムはリードタイムが非常に長く、今後のほとんどのCustodianパッチよりも範囲が広い）。
• 今後数か月の間に、冬のアップデートの後にリリースされるパッチに関するさまざまな話題を調査するため、フィードバックスレッドを投稿するかもしれない。重要なこととして、ある話題に関するフィードバックスレッドを私たちが投稿するときに、提案された変更が実現しない可能性がある。これは遠い将来に実現する計画のものに対するフィードバックを集めることにもつながる。

コミュニティの提案

• 何十もの異なるスレッドからフィードバックを収集するのは、コミュニティがなにを好む/好まないかを示す指標がないために時間がかかり、容赦なくコミュニティやQAの時間を食い潰してミームを作ったりゲームをテストしたりする余裕がなくなってしまう。これは私たちが「車輪の再発明」に至ったもうひとつの状況であり、結局は多くの提案に対してフォーラムの既存のフレームワークを使うより大変な作業をしていた。
• 私たちはコミュニティからのフィードバックを収集したいと思っているが、x票の賛成があったからある機能が実装されるとコミュニティが期待するような状況にしたいとは思っていない。提案が実装されるかどうか、いつ実装されるか決めるには多くの要素がある。
• 今後の予定として、こうしたコミュニティフィードバックには既存の提案フォーラムを利用し、パッチサイクルの終わりにコミュニティチームがCustodianチームに対してそのパッチサイクルの間にもっとも賛成票を集めた提案はなんだったかを報告し、その時点で投票をリセットするようにする。
• このレポートに掲載されたものがゲームに反映されるという保証はない。繰り返すが、タイムフレームについて述べることと期待を緩和することは重要だ。次のパッチのデザインの範囲はコードが書かれるずっと前に決定されており、提案は「おまけ」として組み込まれるかもしれない。
• 提案フォーラムに提案を追加する際には、提案する変更の範囲とCustodiansチームが行う作業の範囲、彼らに割り当てられた作業時間を念頭に置くことが重要だ。アーティスト・プログラマー・コンテンツデザイナーを含む大規模な変更は、例えば「UIにxボタンを追加する」というような小さな変更より考慮される可能性が下がる。しかし、上で述べたように提案がゲームに採用されることを保証するものではないが、私たちはみなさんの提案に目を通しているし、コミュニティの提案が高く評価されていることはお知らせしたい。

Q&Aのまとめ

• 今週水曜日にStellaris Discordで開発者とのQ&Aセッションを開催し、質問を受け付けていた1時間で185の質問が寄せられ、その40%程度に回答した。以下はその完全なまとめだ。（注：本記事では、私が気になったものを抜粋してご紹介します）

Q：Stellarisの中核的な問題は「技術ラッシュ」だけど、技術が経済（特定の材料が必要）や建造物（社会学・物理学・工学それぞれのみを研究する特殊な研究所）やその他の手段（征服した惑星が研究ボーナスをもたらしたり、技術を盗んだり）に依存するようにしたりはしないの？

A：今のところ技術に必要な資源を増やす予定はない。乱数生成によるものは特にそうだ。しかし、技術ラッシュを現在ほど厳しくないものにするために対応策をいくつか考えている。しかし現時点で約束できることはない。

Q：海賊について見直しはしないの？

A：まだ具体的な話はないが、議論していることはある。

Q：フリゲートのような新たな艦種を追加する予定はある？

A：その可能性は非常に低い。というのは、既存の艦船セットすべてに追加する必要があり、非常に時間とコストがかかるためだ。

Q：開発チームが「基準」としている難易度はなに？　例えばトレイラーでは開発チームはどの難易度に設定されていると考えてるの？　あと推奨する難易度は？

A：少尉（Ensign）。プレイヤーにもAIにもボーナスがない。設定に関してはゲームを起動したときのデフォルト設定がそれだ。

Q：諜報は基礎はいいけど物足りない感じがする。諜報作戦（Operations）の数を増やす予定はある？

A：次にやることを決める際にはさまざまな種類のコンテンツがあることを考慮するが、諜報は今後のアップデートで考慮されるもののひとつだ。

Q：管理許容量がなくなったら官僚もなくなるの？

A：実験的なバージョンでは統合力（Unity）を生成する職になっている。文化人（Culture Workers）はなくなり、PriestsやManagersは官僚の代替となる。

Q：国内政治を拡張する予定は？

A：具体的にはないが、派閥が最近あまり愛されていないことは認識している。今後の展開を見守りたい。

Q：最近話題になったこと（管理許容量・統合力・伝統）以外で未開発と感じるのはどこ？

A：帝国内の原始種族や中立機構（enclaves）などの「小さな文明」は比較的未開発だが大きなポテンシャルがあると思う。

Q：開発チームは小さく強力な帝国と大きな帝国は同じくらい強力であるべきだと思ってる？　それとも積極的なプレイは消極的な戦略より利益が大きくあるべきだと思う？

A：小さく強力な帝国と大きな帝国のバランスをとるのは地雷原のようなものだ。Stellarisは拡大するために資源が必要なゲームなので、より多くの資源のある領域を得るのは常に優位性がある。しかし、私たちは消極的なプレイスタイルも実現可能にする方法を模索している。

• この夏の開発日記は今回が最後で、再開は8月の最初の数週間の予定だ。

次回：開発日記#218――Plantoidsのゲームプレイ