Hearts of Iron IV 開発者日記 第108回目を紹介。
今回HoI4のプロジェクトマネージャーがパラド社の開発プロセスについて説明しているのですが･･･。
[記事内の画像はパラドフォーラムより引用]
Hearts of Iron IV 開発者日記 2017年8月30日分 (第108回) 当社の開発プロセス
今回はProject Leadの視点からの開発者日記。
今日の開発者日記の目的は、開発プロセスを少し洞察することです。
なぜ私たちはいくつかのバグを修正し、他のものを残し、次の拡張になるものを決定し、そしてもっとという流れになっているかについて。
混雑したバーを想像してほしい
今、一人の勤勉なバーテンダーであり、一度にすべての顧客が注文を叫んでいると想像してください。
バーテンダーが群衆の集まった騒音内でどれくらいの単語を聞き取れると思いますか？
あなたは彼が正しいことができると思いますか？
あなたが「NO」と答えたら、おそらく真実に近いでしょう。
私の仕事は、もし私がそのバーで働いていたら、動作するキューシステムを編成することです。
物事を動かし、できるだけ早く人々が望むものを得るようにする。
Paradoxのプロジェクトリーダーとして、ゲームプレイヤーが自分の望むものを手に入れるよう取り計らう事は私の仕事です。
可能な限り短い時間内で、ゲームに最高の価値をもたらします。
チームと私がこの要求を実現させる方法に関して超凝縮されたバージョンがあるのです。
設計プロセス
まずチーム内でデザイナーはプレイヤーのことを話します。デザイナーはチームが何をすべきかを決める者です。
何が幸せをもたらすのか…対処する必要があるゲームの弱点…すべての良いもののバランスの取れた組み合わせはどれか。
これらが “設計文書”に収集されます。
この文書では、新しい拡張機能に対応する新しい機能(フィックス)ごとのビジョンについて説明します。
それはチームのための作業仕様、または作業のコストとなります。
新機能、修正、拡張をどうやって決めるのか
設計者は、例えば次のような設計文書の内容に基づいて決定します。
- 機能は拡張の全体的なテーマに適合しているか？
(空軍や海軍などのテーマで作業することが望ましいバグ修正など) - 有料の機能と無料の機能をうまく組み合わせて使えるか？
(難しいことをどのように実装し、ゲームのバランスに与える影響が大きいかどうかによって決まる) - プレーヤーの行動に関するデータ。
(そのデータが分析され、新しい機能や修正が行われる) - 私たちには、改善の余地のあるデータベースがある。
- 我々はバグはもちろん優先順位を付けて処理する。
- 私たちはまた、このフォーラムを中心に、そして(ある程度は)他のHOIコミュニティを綿密に監視する。両方のフォーラムの投稿からバグや提案されたインスピレーションを受ける。
どのバグを修正するかを選ぶ
バグ、改善アイデア、機能提案などの大きなデータベースがあります。
多くのバグ修正はこのデータベースのエントリの同じ基本システムに関連しています。
システムでオーバーホールを行うとバグが一掃されます。
これらは私たちが優先順位をつけているものです。
バグは、多くの場合、報告されることによって、私たちのレーダーで捉えられます。
バグは私たちのデータベースに転送され。そして、それを分析して調査を始めます。
問題の発生頻度を知る必要があります。どのように深刻で、どのくらい迅速に修正するかに関わることです。
より頻繁または深刻なバグは、それがすぐに修正されるように取り計らいます。
バグが深刻で頻発するならば、修正するのが速い。ではまだ修正されていないバグは･･･、なぜ我々はそれを修正していないのでしょうか？
単にそれを私たちのスケジュールに適合させることができなかったからです。
開発プロセスを仕事の1日と考えてほしい
昼食前に聞いた深刻な事柄は、確実に日が終わる前に修正されます。
その後、あなたは他の何かに、より低い優先度でしばらく働くかもしれません。
次の大きな問題が現れるまで。
しかしあなたが家に帰る前に、あなたはそれをすべて終わらせる事はできない。また作業を翌日まで待たなければならない。
だから、貴重な時間を無駄にしないために、あなたは取り組むべき何かを絞り込みます。
これが開発サイクルの仕組みです。
拡張を出荷する前に、何かを始めて固定したり改良したりすることができないことがあります。
(この例は後に優先度の高い項目が残っている場合に、優先度の低いものがどのように処理されるかを示唆しています。)
難しい判断の呼び出し
他のバグや提案がもっと議論の対象になります。
あるグループの人々が喜んで跳躍するようなことをすることは、別のグループの人達が真剣に怒る事かもしれません。私たちはそのバランスを維持しなければなりません。
大きな時間を奪う人
AIを改善するような要求の中には、急いではいけない永続的な仕事であることは言うまでもありません。
エリアが仕事を必要とするのは明らかです。いくつかのことは卵を孵化するようなものです。それには時間がかかります。ユーザーがどれだけ問題を投げかけても気にしてはいけない。
破壊と評価のプロセス
チームはデザインを考えデザイン・ドキュメントが完成したら、それをコーダー、コンテンツデザイナー、アート、UXデザイン、サウンドなどの作業に振り分けます。
私たちは一緒に座って各タスクを「見積もり」します。完全な機能を開発するまでどれくらいの時間がかかるかを私たちに伝えます。
締め切りとリリース日はどのように決定されるか
Paradoxには、1年に何個の拡張/ DLCをリリースすべきかという計画があります。
HOI4のリリース日は、
- 計画に基づいて
- リリースの希望販売価格にどれくらい迅速に到達できるか。
- マーケティングチームが選択した特定の日付に調整。
に応じて決定されます。
(この件については、来週の開発者日記で詳しく説明)
締め切り内に拡張設計を行うことは可能か
すべての機能が推定された後。私たちがやりたいことが期限内に可能かどうかは分かります。人々を私たちの自由に処分する。
YES:賞賛
NO:デザイナーの夢と希望が押しつぶされる
私たちは時間通りに仕上げるために何かを切り離す必要があります。
これに関しては私たちが議論し合意したものです。
私は静かに背中を撫でて、ティッシュを手渡す。
何を切り離すのか
何かをカットするとき、私は考慮する必要があります、例えば：
- 機能実装の望ましさと優先度。
- どのような人が利用できるか？
- どのくらい、何を、それぞれの人が作業できるか。
- ブロックされていない、またはブロックしている間、他の誰か。
- 他の機能に何が関係しているか
(きれいに切り離せるほど独立したものがあるか)
時には、この複雑なパズルを敷設し、優先順位の高い作品を一緒に合わせようとすると、壁にジェロを釘付けしようとするよりもやっかいです。
物事は常に滑り、絶えず変化する。これは開発作業の本質と性質です。
最後に
パラドックスとHOI4が闘っている問題は、すべてのあらゆるITプロジェクトで発生するのと同じ問題です。
それはひどく複雑な作業です。
だから、問題とリスクはよく知られていて、ある程度予測して計画することができますが、問題は問題として依然と残っています。
来週は、ブランドマネージャーが開発日記を書く予定です。
以上
感想
うーん。
正直な感想をいうと、これわざわざ開発者日記で説明する必要があるのかなぁ･･･という気がしました。
会社組織は当然として、個人事業主でも無意識下でこういう意思決定プロセスを経て仕事をしているわけなので、わざわざ開発者日記で書かなくても至極当たり前のことじゃないでしょうか？(´･_･`)
今回は休憩回みたいな感じでしたね。
HoI4 開発者日記 第108回 2017年8月30日分は以上となります。
