threejs-game-generator-skill

Three.js ゲームジェネレーター

ゲームの概要や未完成の Three.js シーンを、小規模で完成度の高いブラウザーゲームに仕上げます。まず満足感のあるプレイ可能なループを作り、独自の方向性を打ち出し、ユーザーの既存スタックを活用して、実際のブラウザーで動作を確認します。

動作モードを選ぶ

• 新規ゲーム： リクエストに合った、保守しやすい最小限のプロジェクトを作成します。既存のスタックがない場合は、Three.js と Vite を標準で使用します。
• 既存ゲーム： パッケージマネージャー、アーキテクチャ、ルート、アセット、操作方法、動作中のシステムを維持します。リクエストされた結果に必要な部分だけを変更します。
• シーンからゲームへ： 役に立つシーンは維持しつつ、明確な目標、プレイヤーのアクション、フィードバック、失敗またはクリア、リスタート、進行要素を追加します。
• 磨き込み： 変更する前に、現在のビルドのプロファイルを取り、実際にプレイします。フィードバック、カメラ、操作方法、テンポ、パフォーマンス、状態遷移の順に問題を修正します。

ユーザーから明示的に依頼されない限り、公開、アセットの購入、有料サービスの呼び出し、外部システムの変更は行いません。

ゲームの仕様を定める

概要が曖昧な場合は不足している要素を推測しますが、プロトタイプを大規模な製品へと勝手に拡張しないでください。

実装前に、簡潔な仕様を作成します。

1. ゲームの魅力： プレイヤーにどのような体験をしてもらうか。
2. コアループ： 繰り返し行うアクション、それに対する反応、報酬、段階的な難化。
3. 勝利、敗北、またはクリア： プレイがどのように終了し、プレイヤーがどうやって再開するか。
4. カメラと操作方法： 視点、移動モデル、入力デバイス、タッチ操作。
5. ビジュアルのコンセプト： メカニクスに結びついた、ひと目でわかるアートディレクション。
6. スコープ： コアループを成立させる最小限のコンテンツと、後回しにする機能の明示。

既存のタイトルが指定された場合は、抽象度の高いインタラクションのアイデアのみを取り入れます。キャラクター、環境、レイアウト、UI、名称、音声、アートはオリジナルで制作してください。

参考資料を必要に応じて読む

• ゲームループ、レンダラー、操作方法、カメラ、衝突判定、読み込み、永続化、オブジェクトのライフサイクル、パフォーマンスを設定または変更する場合は、engine-patterns.md を読んでください。
• ライティング、マテリアル、プロシージャルジオメトリ、アセットのスタイル、雰囲気、UI の表現、影、品質レベルを選ぶ場合は、visuals.md を読んでください。
• ゲームに音楽、フィードバック音、空間オーディオ、ユーザージェスチャーによる有効化、ミキシングが必要な場合は、audio-recipes.md を読んでください。
• 概要に、実現可能なメカニクスの組み合わせ、カメラと操作方法の対応、コンテンツの予算、ジャンル特有のリスク確認が必要な場合は、genres.md を読んでください。

デフォルトでは、すべての参考資料を読み込まないでください。

ワークフロー

1. ワークスペースを調査する

以下を特定します。

• パッケージマネージャー、スクリプト、エントリーポイント、Three.js のバージョン、アドオン、ビルドツール。
• 現在のシーングラフ、レンダラー、カメラ、入力、状態管理、物理演算、アセット、UI、オーディオ。
• 本番ビルドのコマンドと既存のテスト。
• 保持すべきローカルの変更。

可能な場合は現在のプロジェクトを実行します。編集前に、画面上で確認できる問題とブラウザーコンソールのエラーを記録します。好みのひな形を使うためだけに、正常に動作しているプロジェクトを置き換えないでください。

2. 垂直スライスで検証する

内容を広げる前に、最小限の完全なループを作ります。

• 操作可能なプレイヤー、または主要なインタラクションを 1 つ。
• 目標を 1 つ、意味のある障害物を 1 つ。
• 成功、ダメージ、収集、進行を示す視覚的なフィードバック。
• 開始、プレイ中、一時停止、クリア／失敗、リスタートの各状態。
• 意図したゲームの手触りを伝える、30～180 秒のプレイセッション。

スケール、移動、カメラ、テンポが機能するまでは、グレーボックスのジオメトリを使います。完成までプレイできるループのない美しいシーンは、ゲームではありません。

3. 安定した基盤を構築する

engine-patterns.md のプロジェクトパターンを使用してください。次の不変条件を守ってください。

• レンダラーは1つ、権威あるアニメーションループも1つにします。
• フレームレートに依存しない移動と上限を設けたデルタ値を使用するか、決定性が重要な場合は固定シミュレーションステップを使用します。
• ブール値をあちこちに散在させず、明示的なゲーム状態を使用します。
• キーボード、ポインター、ゲームパッド、タッチでゲームロジックを共有できるよう、入力をアクションとしてサンプリングします。
• ワールド単位と座標の規則を最初に決め、一貫して使用します。
• デバイスピクセル比に上限を設け、レンダラーとカメラを更新するリサイズ処理を実装します。
• ジオメトリとマテリアルを再利用し、GPU リソースを意図的に破棄します。
• 3D 配置が不可欠でない限り、読みやすいメニュー、設定、HUD には HTML UI を使用します。
• アセットの読み込み状況と失敗状態を表示します。
• クライアントコードにシークレットを含めません。

物理エンジンを追加するのは、そのメカニクスで剛体シミュレーションが本当に必要な場合に限ります。アーケードゲームの移動では、単純な球、ボックス、カプセル、レイキャスト、空間分割で十分な場合は、それらを使用します。

4. 操作感を実装する

入力、移動、カメラ、フィードバックをまとめて調整します。

• 操作は即座に反応し、フレームレートが低くても高くても予測可能である必要があります。
• カメラ追従では、プレイヤーの変換値をそのまま使わず、ダンピングと上限を設けた先読みを使用します。
• 衝突では、何も起こらずにただ止まるのではなく、分かりやすい結果を生み出します。
• アクションには、ジャンルに応じた予備動作、衝撃、回復動作が必要です。
• 画面の揺れ、ヒットストップ、パーティクル、軌跡、ポストプロセッシングは控えめにし、モーション軽減や低品質設定では確実に無効化できるようにします。
• タッチターゲットと仮想コントロールは、実際のビューポートに収まり、重要なプレイ領域を覆わないようにします。

コアループが楽しくなってから、追加システムを実装します。

5. 世界観を統一する

visuals.md を読んでください。少数のカラーパレット、ライティングモデル、形状の特徴、マテリアルの系統、雰囲気を定めます。詳細度の高い無関係なアセットを混ぜるより、複雑さを抑えた統一感のある世界を優先します。

カラー用テクスチャには正しい色空間を使用し、負荷の高いシャドウには上限を設け、フレームごとのメモリー割り当てを避けます。ゲームプレイの分かりやすさを損なう前に、ピクセル比やエフェクトを減らします。外部アセットはすべて、クレジットとライセンスを記載してください。

6. 音声と永続化を適切な範囲で追加する

音声を扱う場合は、audio-recipes.md を読んでください。音声はユーザー操作の後にのみ開始し、ミュートと音量のコントロールを用意します。また、音がなくても重要なフィードバックが理解できるようにします。

設定、ベストスコア、アンロック済みのレベル、チェックポイントなど、有用な状態だけを永続化します。保存データにはバージョンを付け、値がない場合や無効な場合にも安全に復旧できるようにします。

7. 実際にゲームを検証する

まず本番用ビルドを実行し、すべてのエラーを修正します。その後、ブラウザーでビルド版または開発版をテストします。

次の点を確認してください。

• 開始 → プレイ → 一時停止／再開 → 勝利／敗北 → 再開が、ページを再読み込みせずに動作する。
• タッチ操作を約束している場合はそれも含め、ドキュメントに記載されたすべての操作が機能する。
• リサイズ、画面の向きの変更、バックグラウンドへの移行、フォーカスの喪失によって状態が壊れない。
• ブラウザーのコンソールに未処理のエラーや不足しているアセットがない。
• UI が読みやすく、キーボードからも操作できる。
• 音声の有効化とミュートの動作が正しい。
• 保存データが再読み込み後も保持され、無効な保存データがクラッシュを引き起こさない。
• 最も負荷の高いシーンでも、対象デバイスのクラスで応答性が保たれる。
• モーション軽減モードと低品質モードでは、重要なフィードバックを隠さず、負荷の高いエフェクトが取り除かれる。

少なくとも1回は最初から最後までプレイしてください。ビルドの自動テストが成功しただけでは不十分です。

品質基準

• 初めて見る人でも、ソースコードを読まずに目的と操作方法を理解できます。
• 最初の意味のある操作にすぐたどり着けます。
• シーンや技術デモにとどまらず、ゲームの一連の進行と再開の流れが完成しています。
• カメラ、移動、衝突、フィードバックが1つのシステムとして機能しています。
• アートディレクションに独自性があり、一目で認識できます。
• プレイ不能になる前に、パフォーマンスが段階的に低下します。
• プロジェクトが十分に理解しやすく、拡張できます。

避けること

• 著作権で保護されたキャラクター、レベル、UI、音楽、またはブランド素材を再現すること。
• 必要性を確認する前に、大規模なエンジンや物理演算スタックを導入すること。
• レンダリング、入力、状態、UI、オーディオ、すべてのエンティティを1つのファイルにまとめること。
• 移動をフレーム数に直接依存させること。
• ホットループ内でベクター、マテリアル、ジオメトリ、またはローダーを割り当てること。
• パーティクル、ライト、シャドウキャスター、またはデバイスのピクセル比を無制限にすること。
• 解除手段のないポインターロックや、デスクトップ向けの代替操作がないタッチ操作を使うこと。
• 読み込みの失敗、WebGL の非対応、または認証情報の不足を空白のキャンバスのままにして隠すこと。
• 未完成のゲームメカニクスを、作り込まれたタイトル画面で取り繕うこと。

引き継ぎ

まず、ゲームの実行方法を説明してください。続けて、以下を報告してください。

• 実装したコアループと操作方法。
• ビルドおよびプレイテストのコマンドと結果。
• アセットの出典とライセンス。
• ブラウザーおよびデバイスの制限事項。
• 意図的にスコープ外とした、後回しの機能。