game-dev-combat-skill-polish

ゲーム開発：戦闘スキルの磨き込み

スキルは、発動（術者の体）、効果（投げるもの、持ち上げるもの、または切り開くもの）、結果（対象の反応と、その場に残すもの）で構成されます。この3つすべてを磨き込み、制作に関わっていない人に実際の映像を見てもらって評価します。

評価基準は2つあります。ユーザーがどちらを指しているのか確認してください。

基準	問い	評価項目	典型的な目標
読みやすさ	それ自体だと分かる表現になっていますか？攻撃が届くタイミングと場所で、結果が伝わりますか？ポーズに個性がありますか？	references/rubric-readability.md（認識しやすさ、タイミング、体、効果、反応）	すべてのスキルで6以上
アート	ディテールと質感、光、動きと軌跡、インパクト、アートディレクション、明示されたリファレンスとの比較	references/rubric-art.md（Diablo IVのパラディンのスキルを文章で説明）	スキルごとに7以上

読みやすさが7でアートが3のスキルもありえます。評価基準を明示せずにスコアだけを引用してはいけません。

1. 作業内容を明確にする

• 対象スキル：すべて（調査）か、指定されたスキル（作り直し）か。複数の作業を同時に進める場合は、スレッドごとにスキルを1つにします。
• 評価基準とリファレンスを確認します。ユーザーがリファレンス画像を提示した場合は、評価者が開けるようプロジェクトに保存します。そうでない場合は、評価基準に文章で記載します。
• 設計を始める前に、プロジェクトのリファレンス（存在する場合はreferences/<project>.md）を確認します。各スキルのコードの場所、ハーネスの設定、これまでのスコアカード、ほかのスレッドですでに分かったことが記載されています。
• 作業に入る前にgit fetchを実行し、ほかのスレッドでの変更を確認します。複数のスキルのスレッドが同じ効果やアニメーションのファイルを編集することがあります。

2. 実際の映像を撮影する

• メインブランチから独立した、自分専用のgit worktreeで作業します。空いているポートで起動し、比較用の「変更前」として、クリーンなメインworktreeを別のポートで起動します。
• 停止してフレーム単位で進めるクロックを使い、ヘッドレスで撮影します。ゲーム内クロックを止め、1フレームごとに0.05秒進め、レンダリングされたフレームを待ってから撮影します。これならマシンの負荷が高くても、フレーム間隔を均等にできます。（scripts/film.mjs。スキルごとのセットアップは scripts/scenarios.example.mjsのようなシナリオファイルで行います。）ゲームには、このためのレビュー専用フックが必要です。状態をセットアップし、コマンドを発行し、カメラを向け、クロックを停止・進行できるようにします（契約はfilm.mjsの先頭に記載されています。HOOK、PAGE、READY、SETTINGS_KEY、CHROMEは環境から設定します）。
• キャスター、ターゲット、ヒーローオブジェクト、着弾地点が切り抜き範囲内に収まり、HUDに隠れないように、各発動の撮影条件をセットアップします（frame、span、points）。パネルの背後に隠れたものは「点」の評価になります。
• 発動ごとにコンタクトシート（scripts/strips.py、余波も残すためN=16、TAIL=3）と、重要なフレームのクローズアップ（scripts/close.py）を作成します。評価者には両方が必要です。コンタクトシートでタイミングを、クローズアップでアートを確認できます。
• 測定できるものは測定します。敵が動くフレームと攻撃が届くフレームの比較（フレームごとのアクションと時間を記録するmeta.json）、発動中のドローコールと三角形の数（scripts/perf.mjs）、ダウンロードサイズを記録します。
• 撮影中に、配信中のソースファイルを編集してはいけません。撮影の途中で開発サーバーが再読み込みされます。

3. 2人ずつでブラインド評価する

• 1回の評価につき、汎用のサブエージェントを新たに2つ起動します。評価基準、リストファイル、画像パスを渡し、ほかのファイルは開かないよう伝えます。コード、過去のスコア、キーを見せてはいけません。scripts/judge-set.pyでコンタクトシートを中立的なIDに匿名化し、リストとキーを書き出します。2つのプロンプトはtemplates/judge-prompt.mdにあります。
• JSON形式で、各項目のスコア、合計点、最大の問題点、スコアを最も引き上げる変更を1つ回答してもらいます。すべての回答をjudges/に保存します。
• 2人のうち低い方のスコアを採用します。切り上げてはいけません。自分で撮影した映像を自分で評価してはいけません。
• 評価者間のばらつきは、およそ±0.5～1です。7点を確実な評価と判断する前に、同じ画像を再評価するか、セットにキャリブレーション用のコンタクトシート（旧バージョン）を混ぜます。運よく高評価になった1回だけでは合格になりません。
• 評価者の「次にやること」が作業リストになります。2人が同じ項目を挙げたら、まずそれに取り組みます。

4. ラウンドごとに改善する

最も多く減点されている基準を修正します。以下は以前にスコアを伸ばした項目です。

タイミングと読みやすさ

• 結果はビートに合わせて反映される必要があります。対象が反応する、押し戻される、または状態を付与されるのは、打撃、ミサイル、波が到着したときであり、クリック時ではありません。ユニットを毎フレーム、ルール上の位置に描画するシーンレイヤーを確認してください。打撃より先に押し戻されたように表示されることがあります（このスキルが作られたプロジェクトで、最初に見つかった最大の修正点です）。
• 別のスキルのスケジュール（持続時間と接触のタイミング）を借りるスキルには、独自の動作を持たせられません。独自のスケジュールとキー付きの動きを用意してください。ひざまずいてから立ち上がる、集めてから投げる、お辞儀をしてから迎える、といった動きです。そのうえで、古いスケジュール名に基づいて分岐している箇所をすべて更新してください。
• 波やミサイルの移動時間を考慮し、到着してから命中させます。
• 弧を描く範囲への攻撃は、まとめて発射するのではなく、計測した刃の軌道に沿って段階的に命中させます。
• 対象のリアクションも演出の半分を担います。のけぞり、ひるみ、朦朧、ノックバックなどが必要です。状態ラベルだけではスコアは伸びません。

アート

• 主役となるオブジェクトのモデリングが上限を決めます。 スクリプトで生成したプリミティブや手作業で作ったメッシュは、「単調な角柱」「おもちゃ」の評価となり、5.5～6.5あたりで頭打ちになります。コンセプトアート（gpt_image_2_5）を描き起こし、image-to-3D（Higgsfield image_to_3d、Meshy、テクスチャ付き＋PBR、約12k三角形）でテクスチャ付きモデルにしたところ、2つのスキルが7を超えました。主役となる要素がない場合、スキルは6前後で頭打ちになりがちです（モデル要素のない風のスキルは、20ラウンド後も6で止まりました）。
• 主役が小さなワールドプロップの場合は、プロップを見分けやすくし、その周囲に描画したウィスプで効果を表現します（モデリングした「力の手」は、戦術カメラからは読み取れませんでした）。
• 黒地に描画したテクスチャを加算合成する手法（クレーター、三日月、リボン、衝撃波リング、渦）は、プロシージャルなリングや軌跡より効果的です。出荷前にスキルのカラーパレットに合わせてグラデーションマップを適用してください（赤い対象マーカーの隣に溶岩の赤があると、見た目が不自然です）。
• リボンと軌跡：経路に対してカメラ向きにし、描画する経路に合わせて幅を広げ、幅方向には柔らかくし、フレームごとではなく動き自体に沿ってサンプリングします。細く均一な線は「レーザー」や「デバッグ線」に見え、幅の広い一枚の帯は「平らなカード」に見えます。
• 金属には反射対象が必要です。 戦術シーンには環境マップがないことがよくあります。モデルごとに小さな全天球の空を用意し、タイトなフレネルリムを加えてください。幅広のリムや暖色の色味は、金色をクリーム色や銅色に見せてしまいます。
• ライト：オブジェクト上、または本体のそばの術者側に、約1メートル離して配置します。本体の内部に置いたライトは何も照らしません。飛翔物の下にできるライトのプールは「切り離された円盤」に見え、明るすぎると対象が白飛びします。
• 衝撃：小さく熱い中心部、飛び散って落下する破片、低く暗い粉じん、冷えるか消えていく地面の跡、そして強いリアクションを表現します。対象を隠す大きな白い円盤は必ず減点されます。

審査で常に減点されるもの：既存の見た目の流用（別スキルのリング、閃光、ポーズ）、平坦なクリーム色や白の仮置きフラッシュ、均一な放射状の筋、対象の上に伸びる光の柱や光槍、地面をクリーム色に明るくする加算合成の粉じんリング、引き伸ばされた白い火花（「白いダッシュ」）、長く残る軌跡（「レーザー」「稲妻」）、電気的に見えるひび割れのデカール、HUDの下に隠れるもの。

改善を続ける間も、フレーム予算、初回シーンのダウンロード予算（新しいアセットは、それを使える戦闘が始まってからのみ読み込みます）、読みやすさのスコア、テスト、他のスキルの見た目といった制約を守ってください。WIPは各ラウンドでローカルにコミットしておけば、再起動してもコストはかかりません。

5. 停止し、確定して、リリースする

• 下位の評価者で基準を満たし（再評価でも同じ結果になった）か、スキルが数ラウンドにわたって頭打ちになった時点で停止します。そのうえで、何が必要か（通常はモデル化されたヒーロー要素）を明確に伝えます。
• 評価者が採点したバージョンをリリースします。評価されていない微調整版はリリースしません。
• スキル独自のスケジュール、モデル、またはレシピを固定するテストを追加します。
• スコアカードを作成します。各ラウンドの表（変更内容、両方のスコア、採用したかどうか）、スコアに影響した要素、残っている課題、コスト、ビフォー／アフターのシート（scripts/beforeafter.py）を記載します。
• プロジェクトのリリース手順（workflow-ship-change）に従って、開始時、重要な場面、結果の3枚の画像と、計測したサイズを添えて、独立したバージョンとしてリリースします。
• スコアに影響した要素と新たな注意点をプロジェクトのメモリに反映し、次のスキルがさらに先の状態から始められるようにします。

レポート

各スキルについて、名前付きの評価基準で結果を最初に示します。「Summon Hammer 4 → 7（アート、ブラインド評価者2名、低い方のスコアを採用）」。次にラウンドごとの表、評価方法と使用した映像、評価者の言葉で示した未解決の課題、コスト、インラインで添付したビフォー／アフター画像を記載します。キャプチャには、デバイスでのテストではなく、ヘッドレスブラウザーでのキャプチャと明記してください。