アートディレクションと承認ゲート は何をしますか?
ユーザーが見た目を決定します。あなたはユーザーが決定を下しやすいようにします。ここにあるすべてのルールは、却下されたアートのラウンドから生まれました。
1. 1つのターゲットフレーム
アセットが作られる前に、ユーザーはルックの基準となる1つのゲームプレイフレーム(実際のものか生成されたもの)を選びます。それは、きれいなコンセプトショットではなく、実際のUIが表示された実際のカメラでの実際のプレイを示しています。そのフレームに何が含まれているか(マテリアル、ライト、UIレイアウト)を書き留め、すべてのゲートとアセットをそれと比較して判断します。
- 実際のゲームカメラを使用します。テキストのみのカメラ説明は失敗しました。アングルが一致する必要がある場合は、実際のスクリーンショットを添付してください。
- 方向性の変更はターゲットフレームを置き換え、同じ日に文書化されます。
2. レイヤーとゲート
アートはレイヤーで構築され、各レイヤーはユーザーがテストして承認するゲートで終了します。ユーザーが現在のゲートを承認する前に、次のレイヤーを絶対に開始しないでください。 ユーザーはレイヤーを並べ替えることができます。ユーザーの順序に従ってください。
- ユーザーは、モデリングされる前にすべてのコンセプト画像を承認します。 既存のレンダリングも含みます。コンセプトはラベル付きのコンタクトシートとして表示し、選択内容と修正指示を記録します。
- アートは見た目のみを変更します。 モデルは物の見た目を置き換えるものであり、そのコリジョンやフットプリントを決して変更しません。モデルがないものはプレースホルダーにフォールバックするため、ゲームは常に動作し、テストは移動しません。
- ゲートレポートには以下が含まれます: 毎回同じ固定カメラ位置からのスクリーンショット(ターゲットフレームのビューに一致するものを含む)、テストのグリーンステータス、固定された忙しいシーンのフレームタイム、すべての新しいアセットのシート、使用されたクレジット、最終チェック(カメラがクリップしない、何も詰まっていない、ログがクリーン)。承認された各ゲートでコミットしてタグを付けます。
- ショットを判断する前に、リビルドが実際に行われたことを確認します(ログ、タイムスタンプ)。あるスクリプトがかつて別のスクリプトのアセットを静かに上書きしたことがあります。
3. 視認性
プレイヤーは、ゲームプレイカメラから1秒以内に、それが何であるかを認識できなければなりません。
- 特徴的なシルエットと識別用プロップをプロンプトに記述します。汎用的な形状は「すべて同じ」として却下されます。
- バリアントは同じものとして認識されます。 アップグレードやレベルアップは、同じデザインの目に見える変化であり、新しいデザインではありません。
- マテリアルは、そのコストや高度さを示します。 ゲーム用に書かれたテーブルで表現します。
- 単一アセットのプロンプトは、アセット単体を無地の薄い灰色の背景に置いた状態で終了します。これにより、ゲーム側が設定を提供します。
4. 実世界スケール
すべてが実寸であり、それを証明するチェックが存在します。あるゲームでは、車が建物と同じ大きさになってからこの重要性に気づきました。最初のアセットの前に、ゲーム内の種類ごとのサイズテーブルを作成し、最初のアートレイヤーに自動スケールチェックを追加します。それは0を報告しなければなりません。スケールはアートまたはデータテーブルで修正し、インスタンスごとではなく、モデルを引き伸ばして合わせることは絶対にしないでください。
5. 機能するプロンプト
- 長くて具体的に: 実際のカメラでの実際のゲームプレイ、UI、すべての要素のマテリアル、時間帯。このユーザーは詳細を読みます。曖昧なプロンプトは汎用的な結果をもたらします。
- 見た目を説明し、ゲーム名は決して挙げないでください。 ゲーム名を挙げると、その設定が引き寄せられてしまいます。
- リファレンス内のプレースホルダーはコピーされます。 各プレースホルダーが何になるべきかを言及してください。
- 2つのリファレンスがある場合、完成度の高い方がカメラを支配します。レイアウトを維持するには、自分のスクリーンショットのみを添付し、見た目を言葉で説明してください。スタイルを固定するには、承認されたフレームを2番目の画像として添付してください。
- 画像数を指定した1つのプロンプト。「4つのバリエーションを作成」とは決して書かないでください(コラージュになります)。
- UIプロンプト:固定された仕様(目標、フォーマット、ワイヤーフレームとしてのレイアウトを言葉で、タイプ、色とマテリアルを16進数で、正確なコピー、ネガティブ)、最初にアートディレクション、バリアントごとに1つの変数。バリエーションは承認されたスタイルの上に行われ、新しいスタイルではありません。
6. 既に却下されたルック
ゲームごとにテーブルを維持します:何が却下されたか、ユーザーの言葉。ルックが却下された日に1行追加し、二度とそれを提案しないでください。このユーザーが全般的に却下したもの:自分たちのスクリーンショットのAI再ペイント、衝突する混在アートソース(生成アートの横にあるスキャン)、コード描画の「グレイボックス」UI、リファレンスゲームの文字通りのコピー。
7. 評価ルーブリック(1〜10、ターゲットフレームと比較)
ゲートショットと新しいアセットをゲーム自身の照明下で評価します。
| スコア | 意味 |
|---|---|
| 9-10 | ターゲットフレームに収まる可能性がある;瞬時に読み取れる |
| 7-8 | 正しいルック、小さな欠陥;バッチ内で修正 |
| 5-6 | アイデアは正しいが実行が間違っている;ゲート前にやり直し |
| 3-4 | 汎用的またはスタイル外れ;新しいコンセプトが必要 |
| 1-2 | 壊れている:浮いている、埋まっている、テクスチャがない、スケールが間違っている |
7未満のものは「完成」としてユーザーに渡さないでください。完成と呼ぶ前にクロップとズームを行ってください。7未満の欠陥はすべてチケット化します。
関連スキル
studio-operating-model, tripo-studio, ue-scripted-runs, ue-test-gate, character-and-animation