game-design

Name: game-design
Author: decentraland

github.com/decentralandクリエイティブ・メディア4281 回インストール今日更新

リポジトリ

game-design について

Decentraland のゲーム設計とシーン最適化を案内するスキルで、共有ワールドの体験、性能予算、インタラクション、プレイテストを扱います。プラットフォームや端末の制約を踏まえた設計を支援します。

主な機能

01共有ワールドのゲーム設計原則
02シーンとモバイルの性能予算
03テクスチャとアセット事前読み込み
04エンティティ、描画、システムの最適化
05プロトタイプと反復テストの方法

活用シーン

01途中参加・退出できるゲームループの計画
02モバイル向けシーン予算の評価
03描画とシステム負荷の最適化
04段階的なプレイヤーテストの実施

インストール

コマンドをコピーしてターミナルで実行します。

$npx skills add https://github.com/decentraland/sdk-skills --skill game-design

インストール後、Claude Code で/game-designを入力して読み込まれたか確認します。

詳細

Decentraland のゲーム設計とシーン最適化

1. DCL のゲーム設計思想

Decentraland は途切れることのない共有 3D ワールドです。次の制約を考慮して設計してください。

スタート画面はありません：シーンは常に稼働しています。プレイヤーは隣接する区画から歩いて入ってきます。スプラッシュ画面も「スタートを押してください」もありません。プレイヤーが到着した瞬間から、シーンに意味があるようにしてください。
強制終了はありません：「ゲームオーバー」状態を強制することはできません。プレイヤーは歩いて離れたり、テレポートしたりして、いつでも退出できます。途中参加や途中退出に自然に対応できるループを設計してください。
プレイヤーを退出させることはできません：シーンからプレイヤーを追い出す API はありません。プレイヤーをテレポートさせることはできますが、移動先は現在のシーン内に限られます。シーンの外へテレポートさせる場合は、プレイヤーの同意が必要です（プレイヤーがプロンプトを承認する必要があります）。問題行動をとるプレイヤーには、追放ではなくゲームの仕組みで対処してください。シーンに管理者プレイヤーがいる場合、管理者は手動で他のプレイヤーをシーンから禁止できます。
境界を意識する：自分の区画の外に立っているプレイヤーからも、区画の中が見えます。シーンは常に表示されています。隣接するシーンも見えるため、視覚的な調和を考慮してください。
共有スペース：複数のプレイヤーが同時にいる可能性が常にあります。「シングルプレイヤー」パズルであっても、他のプレイヤーに見られます。その点を活かすか、考慮してください。

2. シーンの制限値の計算式

ほとんどの制限値は区画数 n に応じて増加します（トライアングル、エンティティ、ボディは線形、マテリアルとテクスチャは対数）。高さはすべてのシーンで一律 330 m です。約 200 m を超える高さのコンテンツでは、マルチプレイヤー同期に問題が生じる場合があります。目安となる基本ルールは、1 区画あたり 10,000 トライアングル、200 エンティティです。

区画数ごとの制限値をすべて確認するには、optimize-scene スキルを参照してください。

モバイルには、区画数に応じて増加しない、もう 1 つの固定予算があり、そのうち 2 つの項目は最適化だけでなく、設計にも制約を与えます。シーンあたりのライトソース 8 個（うち影を落とすものは 2 個）と、VFX エミッター 8 個です（いずれも緩やかな制限です）。さらに、各モバイルのグラフィックスプロファイルで照らされるのは、最も近い少数のソースだけです。Very Low では 0 個です。そのため、特定のランプ、スポットライト、パーティクルエフェクトが見えることを前提としたデザインは、低価格帯のスマートフォンでは機能しません。動的ライトがまったくない状態でも読み取れることを基本に、ライティングと VFX はアクセントとして予算を組んでください。全表と実行時のクランプルールについては、optimize-scene → モバイルのシーン制限を参照してください。

3. テクスチャの要件

寸法は 2 の累乗である必要があります：256、512、1024、2048
推奨サイズ：シーンのオブジェクトには 1024x1024。ウェアラブルは最大 1024x1024 まで使用できます（ウェアラブル 1 つにつきテクスチャは最大 2 枚、正方形、72 ppi。スキンは例外で、テクスチャ 5 枚、5k トライアングルです）。
テクスチャアトラスを使用して複数の小さなテクスチャを 1 つにまとめ、ドローコールとマテリアル数を削減してください。
可能であれば、未圧縮の PNG より圧縮形式（WebP）を優先してください。
複数のマテリアル間でテクスチャ参照を共有し、テクスチャファイルを重複させないでください。

4. アセットのプリロード

シーンの起動時には不要なアセットを必要なときにすぐ表示できるよう、AssetLoad コンポーネントを使って事前に読み込んでください（後から表示されるものや、プレイヤーの操作で表示されるものなど）。起動時に必要なアセットには使用しないでください。

実装パターンについては、optimize-scene スキルを参照してください。

最初の印象：イントロを読み込み画面に合わせる

シーンの起動時に行われる処理（イントロのシネマティック、ウェルカムサウンド、タイトル UI、オープニングのトゥイーンなど）は、Explorer の読み込み画面の背後で実行されるため、プレイヤーには見えません。読み込み画面が表示されている間、EngineInfo.sceneHidden は true で、画面がフェードアウトするフレームに false に切り替わります。この切り替わりが、「プレイヤーがシーンを見ている」ことを示す唯一の信頼できる合図です。タイマーやフレーム数ではなく、この値を条件にオープニングの演出を開始してください。実装パターンについては、scene-runtime スキルを参照してください。

5. パフォーマンスのパターン

オブジェクトプーリング

エンティティを作成して破棄する代わりに、再利用してください。

const pool: Entity[] = []

function getFromPool(): Entity {
  const existing = pool.pop()
  if (existing) return existing
  return engine.addEntity()
}

function returnToPool(entity: Entity) {
  Transform.getMutable(entity).position = Vector3.create(0, -100, 0)
  pool.push(entity)
}

LOD（詳細度）

プレイヤーからの距離に応じてモデルを切り替えるか、エンティティを非表示にしてください。

function lodSystem() {
  const playerPos = Transform.get(engine.PlayerEntity).position
  for (const [entity, transform] of engine.getEntitiesWith(Transform, GltfContainer)) {
    const distance = Vector3.distance(playerPos, transform.position)
    VisibilityComponent.createOrReplace(entity, { visible: distance <= 30 })
  }
}
engine.addSystem(lodSystem)

ドローコールの削減

エクスポート前に Blender でメッシュを結合します
テクスチャアトラスを使用します（多くのオブジェクトでマテリアルを1つにします）
固有のマテリアルを最小限に抑え、エンティティ間で再利用します
可能な限り透明度を避けます（透明なオブジェクトはドローコールが余分に発生します）

システムの最適化

毎フレーム、重い処理を実行しないでください。タイマーを使用します：

let timer = 0
function heavySystem(dt: number) {
  timer += dt
  if (timer < 0.5) return // Run every 500ms, not every frame
  timer = 0
  // ... expensive work here
}

engine.getEntitiesWith() のクエリを最小限に抑えます。エンティティの集合が安定している場合は、結果をキャッシュします
毎フレーム実行されるシステム内で、新しいオブジェクト（Vector3.create、配列）を割り当てないでください

使用していないコライダーを無効にする

プレイヤーが決して操作しない装飾オブジェクトから、衝突メッシュを取り除きます。これにより、物理ボディの数を大幅に減らせます。

ランドスケープの地形を無効にする（ワールド）

単一シーンのワールドでは、scene.json で landscapeTerrain: false を設定し、シーンの周囲に自動生成される草原、木、海を取り除きます。2つの利点があります。レンダリングの予算に余裕ができ、独自の美的表現（水面、宇宙、虚無など）を一貫して実現できます。Genesis City では無視されます。create-scene スキルを参照してください。

6. 入力システムの設計

入力	アクション	備考
E キー	プライマリアクション（`IA_PRIMARY`）	主なインタラクション
F キー	セカンダリアクション（`IA_SECONDARY`）	別のインタラクション
ポインタークリック	`IA_POINTER`	左クリック／タップ
キー 1-4	`IA_ACTION_3` から `IA_ACTION_6`	アクションバーのスロット

設計上の考慮事項

マウスホイールは入力として使用できません
必ずデスクトップとモバイルの両方を想定して設計します。モバイルにはキーボードがないため、ポインターと画面上のボタンを使用します
シーンの反対側からのインタラクションを防ぐため、ポインターイベントに maxDistance を設定します（一般的には 8〜10 メートル）。これはカメラからの距離ではなく、アバターからの距離（デフォルトは 10）なので、プレイヤーが感じる到達距離と一致します。近接インタラクションは約 3m 以内に収めます。エクスプローラーの近接範囲の広域判定は、値が大きくても上限が適用される、ハードコードされた半径 3m の球体です。add-interactivity の「Distance rules」を参照してください。
プレイヤーが操作する前に、インタラクションの内容が伝わるよう hoverText を使用します

7. 状態管理のパターン

モジュールレベルの状態（シンプルなゲーム）

// game-state.ts
export let score = 0
export let gamePhase: 'waiting' | 'playing' | 'ended' = 'waiting'
export function addScore(points: number) { score += points }

コンポーネントベースの状態（複雑なゲーム）

カスタムコンポーネントを構造化データのコンテナとして使用します：

import { engine, Schemas } from '@dcl/sdk/ecs'

const EnemyState = engine.defineComponent('EnemyState', {
  health: Schemas.Number,
  speed: Schemas.Number,
  target: Schemas.Entity
})

ステートマシン

ゲームのフェーズを、明確な遷移を持つ明示的な状態としてモデル化します：

type GameState = 'lobby' | 'countdown' | 'active' | 'cooldown'
let currentState: GameState = 'lobby'

function gameStateSystem(dt: number) {
  switch (currentState) {
    case 'lobby': handleLobby(dt); break
    case 'countdown': handleCountdown(dt); break
    case 'active': handleActive(dt); break
    case 'cooldown': handleCooldown(dt); break
  }
}

8. UX/UI ガイドライン

UI は最小限にする：メタバースの魅力は 2D オーバーレイではなく、3D 空間での存在感です。世界を覆い隠す大きな HUD は避けます。
空間 UI を優先する：情報が場所やオブジェクトに関連する場合は、画面空間の UI よりも、エンティティ上の TextShape や 3D 看板を使用します。
分かりやすい操作の手がかり：インタラクティブなオブジェクトは、見た目から操作できると分かるようにします。グロー効果、アウトライン、浮遊インジケーター、さりげないアニメーションを使って、「クリックできます」と伝えます。
サウンドによるフィードバック：プレイヤーの重要なアクションには、音声によるフィードバックを加えます。アクションが登録されたことを確認でき、仕上がりも良くなります。
段階的な情報開示：一度にすべての情報を提示しないでください。プレイヤーの行動に応じて、メカニクスやストーリーを明らかにします。シンプルに始め、徐々に複雑さを加えます。
最初に長文を表示しない：長い段落のルールポップアップや、ゲーム内の平面に描かれたルールブックは、よくある悪いパターンです。プレイヤーは読み飛ばし、混乱したままプレイしてしまいます。セクション 13「Rules: show, don't tell」を参照してください。
クライアントが重ならない場所に画面 UI を配置する：HUD を左上隅（ミニマップ、チャット、モバイルのジョイスティックが表示される場所）に固定しないでください。右側か中央に固定するか、インタラクト可能なインセットを使います。モバイル HUD は右下のアクションボタンに重ならないようにし、全画面 UI を開いている間はそれらのボタンを非表示にします。ルールとコードについては build-ui スキルを参照してください。
即時のフィードバック：プレイヤーが操作したら、同じフレーム内に反応を返します。トゥイーン、音、UI ポップアップを使い、「操作は効いたのか」とプレイヤーに迷わせないようにします。
アクセシビリティ：コントラストの高いテキスト、読みやすいフォントサイズ（画面 UI では fontSize >= 16）、視覚的な合図と併用する音声の合図を使用します。

9. MVP の計画

コアループから始める

**プレイヤーは何をするのか？**と問いかけます。答えは1文にまとめます。

「プレイヤーは部屋を探索し、隠されたアイテムを見つけます。」
「プレイヤーは障害物コースでほかのプレイヤーと競走します。」
「プレイヤーはリソースを集め、建造物を建てます。」

すばやくプロトタイプを作る

最終的なシーンがもっと大きくなる予定でも、まずは1～2区画で作ります
最終アートを待たず、仮置き用にプリミティブな形状（ボックスや球体）を使います
2次的な機能を追加する前に、コアループを動作させます

早い段階でテストする — そして進捗に合わせてプレイテストを行う

テスト用のWorldにデプロイし（稼働中のLANDやメインのWorldにはデプロイしないでください）、自分で歩き回って確認します。
実際のプレイヤーを2～3人招待し、プレイ中の様子を観察します。ゲームについて説明してはいけません — 何かを説明する必要があるなら、それが設計に関するフィードバックです。
次の点を測ります。プレイヤーは30秒以内に何をすべきか理解できますか？

尋ねるべき質問は、ゲームの完成度によって異なります。 バーティカルスライスについて「楽しかったですか？」と尋ねても、何もわかりません（答えに意味を持たせるには、まだゲームが十分にできていないためです）。V2について「何をすべきか理解できましたか？」と尋ねるのは、すでにわかっていることにセッションを費やすことになります。

段階	確認すること	招待する人
V0 バーティカルスライス	コアメカニクスは理解しやすく、使いやすいですか？プレイヤーはそれを踏まえた戦略を立てられますか？	クライアントの操作に妨げられないよう、すでにDecentralandを知っているプレイヤーを数人
V1 最初の完全なループ	プレイヤーは助けなしで進行できますか？どこで行き詰まったり、興味を失ったりしますか？	Decentralandのプレイヤーと、あなたのゲームを初めてプレイする人の両方
V2+	ゲームはプレイヤーにどのような感情をもたらしますか？またプレイしに戻ってきますか？人に勧めたいと思いますか？	Decentralandの外から来る人も含む、新しいプレイヤー

RITEで反復する（テスト → 修正 → テスト）

Rapid Iterative Testing and Evaluation（迅速な反復テストと評価）では、各ラウンドに3～5人のプレイヤーを参加させ、ラウンドの合間に最も明確な問題を修正し、新しいプレイヤーで次のラウンドを行います。問題点を長々と列挙する大規模なプレイテストを1回行うより効果的です。DCLならではの注意点は次のとおりです。

ラウンドの途中ではなく、ラウンドの合間に修正します。 セッション中に再デプロイすると、プレイヤーのゲームが中断され、フィードバックの帰属がわからなくなります。コメントがどのビルドを指しているのか、判断できなくなります。
ラウンドを通じて同じ質問を使います。そうしないと、評価を比較できません。質問を追加するのは構いませんが、追跡している質問の表現は変えないでください。
「明確」と言える条件は次のとおりです。実際に起きたことを見ており、プレイヤーが代わりに何を期待していたのかを説明でき、何を変更すべきかわかっています。プレイヤーが1人だけで、原因が不明な場合は、次のラウンドに持ち越します。
各ラウンドを記録します。ビルド、参加者、観察したこと、変更したことを記録します。
テスターを見つける方法：Decentraland Discordの#playtestersチャンネル、ライブセッション向けのDecentraland Eventsでのイベント、またはテスト対象が初回プレイ時の体験であればDecentralandの外から参加する人を探します。ささやかなお礼（所有しているウェアラブルやエモートを、プレイヤーを右クリックしてクライアント内でギフトとして贈れます）が参加者を増やします。称賛ではなく、率直な意見を求めていると明確に伝えましょう。
フィードバックに応えます：同じスレッドに「皆さんの声／わかったこと／変更したこと」の更新を投稿します。自分のフィードバックが反映されたとわかったテスターは、次のラウンドにも参加してくれます。

Scene Feedback モジュールでシーン内のフィードバックを収集する

sdk7-test-scenes/scenes/0,-1-scene-feedback は、そのまま導入できるアンケートモジュールです。ゲームプレイ中に任意のタイミングで、ラベル付きの1〜5評価と任意のコメント、またはテキストのみの回答を尋ねます。回答はシーンの Storage に CSV として保存され、Creator Hub からダウンロードできます（Manage → World ⋮ → View Storage）。coreMechanic / coreLoop / social / motivation / world / technical に分類された20問の質問バンク、14種類の評価尺度、アイデアの参考にできる113問の質問バンク、README に記載されたエージェントのインストール用プロンプトが付属しています。

権威型マルチプレイヤーサーバーが必要です（@dcl/sdk@auth-server、"authoritativeMultiplayer": true、requiredPermissions 内の USE_FETCH）。セットアップ方法と、このモジュールが使用する CSV を Storage に追記するパターンについては、[[authoritative-server]] を参照してください。
設計ルール：プレイテストの目的に沿った質問を1つか2つ、自然に一息つけるタイミング（ラウンド終了後、購入後など）で尋ねてください。プレイ中には尋ねないでください。質問は画面がクリアになるまで待機し、訪問ごとにトリガー1つにつき1回だけ表示されます。
API は名前空間です（import { feedback } from './scene-feedback'）：最初の feedback.ask() の前に同意を得る feedback.intro()、ゲーム内のトリガーで質問する feedback.ask()、プレイヤーがボタン、キオスク、トリガーエリアから開くフォームを表示する feedback.leaveFeedback() があります。
リポジトリ：https://github.com/decentraland/sdk7-test-scenes/tree/main/scenes/0,-1-scene-feedback

不在の間にもプレイヤーが送信できるフィードバックを集めるには、最初のローカルテストの後に scene-feedback を導入してください。フィードバックを収集する場合は、クリエイターが質問を追加します。

楽しさを追求して改善する

仕上げは最後です。コアとなるゲームループが仮のアートでも楽しくなければ、アートを改善しても解決しません
機能は思い切って削りましょう。広大で未完成な体験よりも、コンパクトで洗練された体験のほうが優れています
DCL ではコンテンツの量よりリプレイ性が重要です（プレイヤーは気に入ったシーンに戻ってきます）

MVP チェックリスト

ゼロから始めますか？ ゲームを設計する前に、まず create-scene スキルを参照してプロジェクトのひな形を作成してください。

10. ゲームループのアーキタイプ

探索

コアとなるループ：場所を見つけ、隠されたアイテムを探し、エリアをアンロックします。
DCL との相性：非常に良好です。3D の世界と空間内の移動は強みです。
設計のヒント：ランドマークを使って道案内をします。隠しコンテンツで好奇心に報います。ライティングと音で注意を導きます。

収集

コアとなるループ：アイテムを集め、セットを完成させ、報酬を獲得します。
DCL との相性：良好です。探索や日々のエンゲージメントとの相性も良好です。
設計のヒント：収集アイテムにはエンティティプーリングを使います。アイテムを空間内に散らします。コレクションを視覚的な進行状況（展示ケース、カウンターなど）に結び付けます。

パズル

コアとなるループ：空間的または論理的な課題を解いて進行します。
DCL との相性：良好です。空間パズル（オブジェクトを動かす、道を見つける、順番に起動するなど）はうまく機能します。
設計のヒント：進行状況が明確に伝わるようにします。入力手段には制限があるため、入力を必要とするパズルは避けます。パズルの入力には3D インタラクション（クリック、近接トリガー）を使います。

ソーシャル

コアループ：ほかのプレイヤーと交流し、イベントに参加し、ロールプレイを楽しみます。
DCL との相性：非常に優れています。これはプラットフォーム本来の強みです。
設計のヒント：人が集まる場所（座席、ステージ、広場）を作ります。会話のきっかけ（インタラクティブなオブジェクト、ゲーム）を用意します。5～20 人のグループ向けに設計します。

対戦

コアループ：ほかのプレイヤーとレース、戦闘、またはスコア競争をします。
DCL との相性：普通です。レイテンシーと入力の制約により、テンポの速いアクションには限界があります。
設計のヒント：素早い反射神経が求められるものより、ターン制またはタイミング重視の対戦を選びます。不正行為を防ぐには、サーバー権威型の状態管理を使用します。ラウンドは短く（2～5 分）します。
チート対策アーキテクチャ：スコアや賞品が関わる場合は、シーンをサーバー権威型にします（[[authoritative-server]] を参照）。クライアントが送信するのは意図メッセージのみ（例：claimPoint）であり、スコアは送信しません。サーバーが（目標地点への近さ、権限などを）検証し、ゲーム状態を書き込めるのはサーバーだけです。公式リーダーボードのテストシーンは、この設計をエンドツーエンドで示す完全なテンプレートです：https://github.com/decentraland/sdk7-test-scenes/tree/main/scenes/90,-9-authoritative-server-leaderboard

11. 空間設計

ランドマーク

シーンの中央または入口に、背が高く目立つランドマークを配置します。プレイヤーはこれを目印に自分の位置を把握します。
それぞれのエリアに、色、形、照明などで独自の視覚的特徴を持たせます。

経路探索

床の模様、照明、手すりなど、目に見える経路を使ってプレイヤーを誘導します。
引き返しが必要な行き止まりを避け、ループ状の経路を使います。
移動中の関心を保てるよう、経路沿いにインタラクティブな要素を配置します。

見通し

見通しのよい空間を使い、プレイヤーを目標へ誘導します。
見通しを意図的に遮り、謎や発見の楽しみを生み出します。
区画の境界から見たときにも、シーンが魅力的に見えるようにします（ここが「ショーウィンドウ」です）。

区画間の移行

シーンが複数の区画にまたがる場合は、視覚的に滑らかに移行できるようにします。
読み込み時の境界条件の問題を避けるため、重要なインタラクティブ要素を区画の境界に配置しないでください。

滑空による垂直移動

プレイヤーが滑空している間は、シーン内の継続的な力が 1.5 倍強くなり、上向きの成分によって滑空中のプレイヤーを上昇させることができます（落下速度の上限が制限するのは下降のみです）。これにより、サーマル上昇気流、風の通り道、浮遊島間の跳躍などの移動メカニクスを実現できます。一度だけ発生する衝撃（ジャンプパッド、ノックバック）は、滑空の影響を受けません。player-physics スキルの「Forces while gliding」を参照してください。
区画の端には、バッファーゾーンとして開けた空間を確保します。

12. エンゲージメントと収益化

エンゲージメントのパターン

デイリー報酬：毎日の訪問に対して少額の報酬を提供します。DCL にはデイリー訪問の追跡機能が組み込まれていないため、外部サーバーで訪問を追跡します。シーン内に連続訪問日数のカウンターを表示します。
プログレッションシステム：累計プレイに応じたレベルやアンロック可能なコンテンツを用意します。進行状況はサーバーに保存するか、NFT ベースのプログレッションを使用します。リーダーボード、バッジ、変化するシーン要素などで、進行状況を視覚的に表示します。永続的なリーダーボードやプレイヤーごとの進行状況には、組み込みの Multiplayer Server の Storage がデプロイし直した後やサーバーのスリープ後もデータを保持し、サーバーが所有する同期コンポーネントをすべてのクライアントが描画します。全体のパターンと参考シーンについては、[[authoritative-server]] を参照してください。
実績：明確な達成目標（初勝利、コレクティブル 100 個、すべての部屋を訪問など）を定義します。サウンドや視覚効果で達成を知らせます。実績の履歴をシーン内（トロフィールーム、殿堂など）に表示します。

収益化の方法

シーン内購入：MANA トランザクションを通じて、バーチャルアイテムや能力を販売します。安全にサーバーで購入を検証するには、signedFetch を使用します。有料アップグレードと並行して、無料でプレイできる内容も必ず用意します。
ウェアラブルの販売：シーンのテーマに合ったウェアラブルを作成して販売します。広告として、シーン内のマネキンにウェアラブルを展示します。
入場料／トークンによるアクセス制限：プレミアムエリアへの入場に MANA を課金するか、特定の NFT の所有を条件にします。有料エリアで提供する内容を紹介できる無料エリアも必ず用意します。

ソーシャルメカニクス

協力タスク：複数のプレイヤーが必要な目標を設計します（2つのスイッチを同時に押すなど）。協力に対して、全員が受けられる報酬を用意します。
共有スペース：プレイヤーが自然に集まる共有エリアを作成します。気軽な交流を促す、周囲のインタラクティブなオブジェクトを追加します。
イベント：スケジュールされたイベント（コンサート、競技会など）を開催できるシーンを設計します。見通しのよいステージエリアを設けます。イベント主催者用の操作機能（ゲームの開始／停止、シーンのリセット、メッセージの配信）を用意します。[[authoritative-server]] Pattern 4に従い、サーバーで検証された送信者と照合する管理者許可リストを使って、主催者／管理者の操作をサーバー側で制限します。クライアントが申告した役割を決して信用しないでください。

13. チュートリアルとオンボーディング

ゲーム内の看板

重要な場所に、短い説明を記したTextShapeエンティティを配置します。
矢印、光る輪郭、アニメーション表示でインタラクティブなオブジェクトを示します。
看板1枚あたりのテキストは10語未満にします。

NPCガイド

シーンの入口にアニメーション付きNPCを配置し、プレイヤーを迎えて案内します。
ダイアログシステムを使って、一度に1つずつメッセージを表示します（プレイヤーが操作して次に進みます）。
NPCのダイアログは、再訪したプレイヤーがスキップできるようにします。

段階的な複雑さ

メカニクスは一度に1つずつ導入します。最初の操作は、光る大きなボタンなど、すぐに分かるものにします。
プレイヤーが簡単なタスクを成功させた後で、次の要素を導入します。
高度なメカニクスは、序盤の目標を達成してから利用できるようにします。

ルール：説明するのではなく、見せる

生成されたゲームでは、次の2つのアンチパターンが頻繁に見られます。どちらも、最初のインタラクションが始まる前にプレイヤーを離脱させてしまいます。

ルールのポップアップ。 すべてのメカニクス、スコアリングルール、操作方法を詳しく説明する、複数の段落からなる導入モーダルです。プレイヤーは読まずに閉じてしまいます。対策：ポップアップを表示する場合でも、1画面に収め、3～5行、各行8語以下にします。理想的には、目標を示す1行、操作方法を示す1行、画像または図を1つだけにします。それ以外は、プレイを通じて学べるようにします。
ゲーム内のルールブック。 同じ段落を、シーン内の装飾された板やボードに掲載するパターンです。デザインの一部には見えますが、文字が小さすぎて長いためゲーム内では読みにくく、プレイヤーは立ち止まって目を凝らしてくれません。対策：看板1枚につき内容は1つだけ（10語以下、大きなfontSize）。アイデアごとに看板を分け、残りはレベルデザインに反映します。

説明するのではなく、見せましょう。

最初のターゲットを一目で分かるようにします。プレイヤーが開始時に見る範囲に、光るオブジェクト、アニメーション付きのオブジェクト、または大きなオブジェクトを配置します。点滅する輪郭のほうが、「クリックしてください」という文よりも効果的に操作を伝えられます。
チュートリアル用のゲートや練習用ターゲットなどを使い、プレイヤーが本番開始前に安全に一度だけメカニクスを体験できるようにします。
インタラクティブなエンティティのhoverTextを、その場に応じた説明として使います。関連するタイミングで表示されるため、事前に読む必要がありません。
空間や順序のルールには、画像や図を使います（uiBackgroundテクスチャまたはゲーム内の板など）。「赤い宝石＝1、青い宝石＝5」という画像があれば、段落で説明する必要はありません。
長めの説明は、NPCやダイアログで一度に1メッセージずつ、スキップ可能な形で提示するか、必要なタイミングでTimed Announcement形式のヒントとして表示します。

チェックリストとしてのテキスト量の目安：導入パネルは5行以下、看板は10語以下、ヒントは1文以下とします。ルールの説明にそれ以上必要な場合は、メカニクスを再設計するか、視覚的に示してください。

説明なしテスト

新しいプレイヤーがテキストや説明なしで30秒以内に最初の行動を理解できない場合、デザインを見直す必要があります。
初見の状態で、実際のプレイヤーがシーンを試す様子を観察します。プレイヤーの戸惑いを、デザイン改善の手がかりにします。

14. 相互参照

トピック	スキル	使用するタイミング
動くターゲットを追跡する（プレイヤーを追跡するエンティティ）	animations-tweens	滑らかに追従させるには `Tween.setMoveContinuous` を使用します。フレームごとに `setMove` トゥイーンを作り直すのは避けてください（ジッターの原因になります）。`79,-4-tween-following-cube` のテストシーンを参照してください。
インタラクティブ機能、入力処理、レイキャスト	add-interactivity	クリックハンドラー、トリガー、入力を実装する場合
マルチプレイヤー同期、サーバー通信	multiplayer-sync	ネットワーク対応のゲーム状態、リアルタイム同期
シーン内でプレイテストのフィードバックを収集する	authoritative-server	Scene Feedback モジュール（`0,-1-scene-feedback`）には Multiplayer Server が必要です。回答はシーンの `Storage` 内にある、順次追記される CSV に追加されます。この手法をご自身のイベントログに再利用する前に、このスキルの Append-only logs: rolling CSV parts in Storage パターンで、ローテーション、エスケープ、データ損失に関するルールを確認してください。
サーバー権威型ゲーム、リーダーボード、チート対策	authoritative-server	競争型のスコアリング、進行状況の永続化、管理者限定のホスト操作に使用します。Gem Rush のリファレンスシーン（`92,-9`）は、サーバー側の近接チート対策とチェックポイント時のみのストレージを備えた、競争型ゲームアーキテクチャの完全な例です。
FPS スタイル／マウスルックのカメラ操作	camera-control	マウスルックのパターン：`PrimaryPointerInfo.screenDelta` + VirtualCamera + PointerLock + InputModifier。デスクトップのみです。
観戦／オブザーバー／ディレクターカメラ	camera-control	観戦モードのパターン：フリーカメラまたはプレイヤー追従カメラ、WASD/E/F/1/2 操作、区画境界による制限、プレイヤー一覧。観戦モードを利用できるユーザーを制限するには、管理者チェック（authoritative-server）と組み合わせてください。
オーディオリアクティブなビジュアル（ミュージックビジュアライザー、ビート検出）	audio-analysis	`AudioSource` または `VideoPlayer` に `AudioAnalysis` コンポーネントを設定します（段階的ストリーミングのみ。HLS は対象外です）。`amplitude` と 8 つの周波数 `bands` に応じて、ジオメトリ、ライト、色を変化させます。
画面 UI、React-ECS、HUD 要素	build-ui	メニュー、スコアボード、ダイアログを作成する場合。`UiInputBinding` プロパティを使うと、InputActions を UI 要素にバインドできます（モバイル向けの画面上ボタンに使用します）。
モバイルのタッチ操作	advanced-input	`TouchScreenControls` コンポーネントを使用して、画面上ボタンの表示／非表示、メインアクションの設定、ジョイスティック／クロスヘアの非表示を行います。`@dcl/sdk/platform` の `getPlatform()`／`isMobile()` でプラットフォームを判定します。
シーンから Explorer UI パネルを開く	scene-runtime	ユーザー操作をきっかけとして、制限付きアクション `openExplorerUi()` でマップ、バックパック、設定などを開きます。オンボーディングのフローや UX のショートカットに便利です。
デプロイのタイミングと公開後のトラブルシューティング	deploy-scene	アセットバンドルの変換には約 15 分かかります（30～60 分を見込んでください）。ライブイベントの 2 時間以上前に公開してください。`/detectabs` でワールド内から変換状況を確認できます。監視用の変換状況 URL もあります。
ローカルでのアセットバンドルのプレビュー	optimize-scene	「Compress Assets」（Creator Hub Play Options > Desktop Client）または `--asset-bundles` CLI フラグを使うと、本番用のアセットバンドル変換をローカルで再現できます。公開前にテクスチャ／モデルの問題を検出できます。
シーンが非表示の間、ゲームプレイを一時停止する	scene-runtime	シーンをフルスクリーンの Explorer UI（マップ、バックパック、ロード画面）が覆っている場合、`EngineInfo.getOrNull(engine.RootEntity)?.sceneHidden` は `true` になります。プレイヤーがシーンを見たり操作したりできない間、ゲームループ、オーディオ、負荷の高いシステムが動作しないように、一時停止に使用します。
エンティティの削除は boolean を返す	scene-runtime	`engine.removeEntity(entity)` は `boolean` を返すようになりました。レンダラーが予約した（アバターの）エンティティの場合は `false` を返し、コンポーネントはそのまま残ります。ゲームループでエンティティをデスポーンする際は、エンティティの削除に失敗しても気づかないことがないよう、戻り値を確認してください。
ワールドのデプロイ、ストレージ容量	deploy-worlds	ワールドのストレージ容量（NAME あたり 100 MB、LAND あたり 100 MB、2k MANA あたり 100 MB。ENS は固定で 36 MB）を考慮してください。それに応じてシーンのファイルサイズを計画します。
パフォーマンスの最適化、エンティティ／三角形の上限	optimize-scene	詳細な最適化手法、ローカルでのアセットバンドルのプレビュー、gltf の再利用と結合のベンチマークを確認できます。
ゾーン駆動型のゲームプレイ（チェックポイント、アリーナ、待ち伏せ部屋、安全地帯）	add-interactivity	`TriggerArea` + `triggerAreaEventsSystem` を使用します。Creator Hub でシーンを開くと、`utils` カタログに、プロンプトで操作できる Smart Item 「Trigger Area」が 1 つあります。デザイナーは見えないボリュームを配置してサイズを変更し、AI アシスタントに反応を説明するだけで、検出器を書かずにゾーンの仕組みを試作できます。スクリプト作成者は、2 つ目の `triggerAreaEventsSystem` コールバックではなく、`@event` の enter／exit パターンを使用してください（script-components）。
ブロックアウト中に仮のアート、音楽、動画を追加する	creator-hub-mcp	エディターの Local Assets タブからビューポートにファイルをドラッグすると、それに対応するカタログの Smart Item（画像／環境音／動画画面）が、そのファイルを参照する状態で配置されます。レイアウトを決める前にグレーボックスへ実際のメディアを取り込む最速の方法です。add-3d-models と audio-video を参照してください。
Creator Hub の AI アシスタントに参考資料を渡す	creator-hub-mcp	コンポーザーでは、1 つのプロンプトにつき最大 8 個の添付ファイルを追加できます（クリップアイコン、ドラッグ＆ドロップ、貼り付けに対応）。ムードボード、モックアップ、または `.glb` を添付すれば、説明する代わりに資料を見せられます。ディスク上のファイルはサイズ制限なしで、実際の絶対パスとしてエージェントに渡されます。
このスキルでは、実装を形作る設計上の判断と最適化の制約に焦点を当てます。詳しいコードパターンについては、参照先のスキルをご覧ください。

Markdown 対応

ログインしてコメント

基本情報

作者: decentraland
リポジトリ: decentraland/sdk-skills
カテゴリ: クリエイティブ・メディア
インストール数: 281
GitHub スター: 4

問題を報告