ゲーム開発では、信頼はNDAやフラッシュなデッキで構築されていません。それは、クラッシュ週間、リリース前の混乱、リリース後の火災で構築されています。
SnoopGameでは、350以上のプロジェクトで信頼をストレステストしてきました。ソロ・インディー・デビューから、数百万人の出版社まで、私たちは一つのパターンを確認しました:品質保証が正しく行なわれたとき、それは見えなくなります - それが欠落しているためではなく、何も壊れないからです。
QA is easy to sell. It’s hard to scale.
ほとんどのスタジオはQAをコストセンターとして考え、必要悪である。
我々はこの10年を、これらの事柄のいかなるものでもないことを証明するために費やしてきた。
QAは関係です。そして、関係をスケーリングする - 単なるヘッドカウンターではない - は難しい部分です。
ソロデベロッパーには戦術的なサポートが必要です: 「ここに何が壊れたのか、そしてなぜか」
中規模のスタジオは、回帰フロー、明確なカバー、プラットフォーム特有のテストなどのシステムを望んでいます。
ある出版社は「12時間の通知で3つのタイムゾーンで10倍の容量で配信できますか。
それは、摩擦のないプロセス、騒音のないレポート、そしてバグを見つけてプレイヤーの経験に重要な理由を説明できるテスターを意味します。
Why scaling QA fails (and how we avoided it)
通常、QAがスケーリングを開始したときに最初に破るものは以下のとおりです。
- コンテキスト - テスターはゲームやジャンルを知らない。彼らはプレイヤーが1時間でヒットする場合のエッジを逃す。
- コミュニケーション - レポートは遅く、一般的、または無視されます。
- 新しいテスター = 新しい学習曲線 = 回帰穴
これを解決したのは、domain-specific pods: ゲームタイプ(FPS、パズル、サンドボックスなど)、プラットフォーム(コンソール、モバイル、PC)、スタジオスタイルによって訓練された小規模なチーム 彼らは水平にスケールするのではなく、階層的に。
それが信頼をスケーラブルにします。我々は盲目的にランプしない。我々は早めにランプします。
Deadlines don’t bend. We don’t pretend they do.
AAAのタイムラインは、チームが疲れているかどうでもいい。
彼らは、あなたの1日パッチにクラスバグが含まれているかどうかを気にします。
私たちの最も高額なプロジェクトの1つは、巨大なコミュニティと公共のロードマップを持つ戦術シューターでした。我々は打ち上げの3週間前に搭載されました - 内部のQAはマルチプレイヤーに触れていませんでした、14のゲームモードがあり、適切な回帰マトリックスはありませんでした。
48時間で1つ作りました。
3つのタイムゾーンで2交代。
そして21日間で80以上のビルドをテストしました。
我々はそれを失敗に近いと言い、その後クライアントと協力して持続可能なテストパイプラインを構築した。
Indie or enterprise, the trust equation is the same
あなたはあなたのゲーム、あなたのプレッシャー、あなたのプレイヤーベースを理解するQAパートナーが必要です。
SnoopGame を構築したのは、最大ではなく、圧力の下で最も信頼性の高いプレイヤーになるためです。一つのビルドであれ、3年間のロードマップであれ、私たちの仕事はシンプルです:プレイヤーがあなたが構築したものを体験することを確認してください。
