threejs-gameplay-systems

Three.js ゲームプレイシステム

所有権を明確にし、レスポンシブな操作、決定論的な更新順序、プレイヤーの判断に影響を与える空間を備えた、プレイ可能なブラウザーゲームのループを作成または発展させます。

<this-skill-dir> とローカル参照は、実際に読み込まれたスキルファイルを基準に解決してください。ランナーが検出した代替候補を使う前に、そのファイルと同じ場所にある兄弟スキルを解決してください。

参照資料

ファイル	次の場合に読みます
references/game-feel.md	操作感、演出、インパクト、ヒットストップ、画面揺れを調整するとき、またはゲームプレイの完成度をうたうとき
references/genre-design.md	レベル、アリーナ、コース、ウェーブ、穴、パズル、遭遇、難易度曲線を設計するとき
references/physics-engine-selection.md	物理演算、衝突の多いゲームプレイ、乗り物、転がるボール、キャラクターコントローラー、センサー、動くプラットフォームを追加または変更するとき

ここから始める

python3 <this-skill-dir>/scripts/create_threejs_game.py ./my-game

assets/threejs-vite-game/ をコピーし、プロジェクト名を書き換えて、ゲーム専用のビジュアルテストとキャンバスインスペクターを用意します。--force を指定すると、空でないディレクトリにもコピーします。ひな形と競合するファイルは上書きし、それ以外のファイルはそのまま残します。

まず設計する

ゲームを幅広く作成するときや、設計を大幅に変更するときは、次の3つの短い成果物を作成するか、既存のものを更新してください。小規模なメカニクスの修正では、既存の設計を使い、無関係なシステムはそのまま維持します。

設計概要。 プレイヤーへの約束（1文で表すファンタジー） · 目指す感情 · 主な動詞 · 副次的な動詞 · プレイヤーが5～30秒ごとに繰り返す行動 · 1～5分で変化すること · 敗北、学習、再開の方法 · 報酬となるものとリスクを生むもの · 上達したプレイヤーが異なる方法で行うこと · 次の判断の伝え方 · 今回の対象範囲に含めないもの。

コアループの仕様。 プレイヤーは［プレッシャー］がリスクを生み出す中で、［目的］を達成するために［動詞］を実行する。成功すると［報酬］を得て、失敗すると［コスト／再挑戦］が発生する。 続いて、各節がコードで実現されていることを確認します。動詞が実際の入力に対応していること、目的がゲーム世界または HUD で見えること、最初にプレイできる1分間のうちにプレッシャーが存在すること、報酬が見た目だけでなく状態を変化させること、失敗によって何が起きたのか学べること、再開が次の挑戦を促すほど速いことを確認してください。

レベルまたは遭遇の計画。 空間の形式 · カメラで見える範囲と見えない範囲 · プレイヤーの開始地点、最初の判断、最初の脅威、最初の報酬 · 目印 · 20～60秒ごと、またはウェーブ／穴／ラップごとに難易度を上げる方法 · 立て直しの場面 · 危険を予告する方法 · モジュール化またはパラメーター化する要素。

「すてきなシーンを探索する」は設計概要ではありません。設計概要には、判断、プレッシャー、フィードバック、結果が必要です。

実装する

1. 既存の構成、スクリプト、依存関係、ループ、入力、カメラ、エンティティ、状態、UI、診断機能を確認します。
2. 所有権の境界は小さく保ちます。core、game、entities、systems、assets、ui、tests に分けます。
3. 入力、状態、エンティティ、衝突、フィードバック、HUD とオーディオフック、診断機能の順に、プレイ可能な単位で実装し、各段階でプレイできる状態を保ちます。 コンテンツを増やす前に、実際のヒーローとフィードバックを使い、想定するカメラのスケールで代表的な遭遇を1つ確立してください。敵、報酬、プロップの種類は、あらゆる場面で共通のアセット数を満たすためではなく、そのジャンルでの判断に役立つものであるべきです。
4. 操作感を調整します。移動、加速、カメラ追従と FOV、ヒットストップ、インパクトフィードバック、クールダウン、難易度、再開を調整します。
5. 頻繁に実行される処理での割り当てを抑え、更新順序を明示します。
6. ひな形のシード付き RNG を通じて、ゲームプレイのすべての乱数を生成し、決定論的なテストフックが引き続き機能するようにします。

複数の担当者で作業する場合は、個別モジュールを分担する前に、入力インテント、エンティティ／アセットのインターフェース、イベントを定義します。変更した動作とローカルでの確認内容を、ブラウザーでの統合テストを担当するリードに報告してください。ユーザーが要件を変更した場合は、完了した作業を最初からやり直すのではなく、既存の設計概要と未完了のタスクを更新します。

ゲームプレイコードはオーディオイベントを発行し、threejs-audio-generator が実際のアセットとランタイムのオーディオマトリクスを生成します。

スタック

TypeScript、Vite、Three.js モジュールを使用します。公式のコントロール、ローダー、ポストプロセッシングには three/addons/... を使用します。リアルタイムで定数を調整するには lil-gui を使用します。実行時の再生には Web Audio を使用します。物理エンジンの選択、タイムステップ、コライダー戦略は references/physics-engine-selection.md に従います。ゲームに実際のシミュレーションが必要な場合は、デフォルトで Rapier を使用します。

問題点

プレイ可能なループではなく静的なデモ · 先に構築したシーンへ後付けされたメカニクス · 実際の入力、プレッシャー、報酬、失敗と再挑戦を通じて一度も実証されないコアループ · 意思決定を形作るのではなく、ただ飾るだけのトラックやアリーナ · コンパイルはできても、どの入力でも発動できないメカニクス · カメラや操作が遅れる、または次の意思決定を見えなくすること · UI、オーディオ、VFX に反映されない状態変化 · 必要なメカニクスがまだないうちに作られた抽象化。

報告内容

動作と操作方法、大規模なビルドで作成した3つの設計成果物、アーキテクチャの選択と調整した値、変更したファイル、実際にプレイして気づいたことを報告してください。物理演算が対象に含まれる場合は、物理エンジン、タイムステップ、コライダー戦略を明記してください。