game-design

Decentraland 游戏设计与场景优化

1. DCL 游戏设计理念

Decentraland 是一个持续运行、多人共享的 3D 世界。设计时应考虑以下限制：

• 没有启动画面：场景始终处于运行状态。玩家会从相邻地块步行进入，场景不会显示启动画面，也没有“按下开始”。玩家抵达的瞬间，场景就必须有意义。
• 没有强制结束：你无法强制进入“游戏结束”状态。玩家可以随时步行离开或传送离开。设计能够自然适应玩家随时加入或离开的循环。
• 无法移除玩家：没有可将玩家逐出场景的 API。你可以传送玩家，但只能在现有场景内传送。若要将玩家传送到场景之外，必须征得其同意（他们必须接受提示）。应通过游戏机制而非驱逐来应对行为不当的玩家。如果场景中有管理员玩家，管理员可以手动封禁其他玩家。
• 注意边界：站在地块外的玩家也能看到地块内的内容。你的场景始终处于展示状态。相邻场景也可见，因此应考虑视觉协调。
• 共享空间：随时可能有多名玩家同时在场。即使是“单人”谜题，也会被其他玩家看到。应善用或考虑这一点。

2. 场景限制公式

大多数限制会随地块数量 n 增长（三角形数量、实体和刚体为线性增长；材质和纹理为对数增长）。所有场景的高度上限均为 330 m；高于约 200 m 的内容可能出现多人同步问题。经验法则：每个地块 10,000 个三角形和 200 个实体。

如需查看所有地块数量对应的完整限制表，请参阅 optimize-scene 技能。

移动设备还有一套固定预算，不会随地块数量增长，其中两项限制的是设计，而不只是优化：每个场景最多 8 个光源（其中 2 个可投射阴影）和 8 个 VFX 发射器，这两项均为软性限制。更重要的是，每种移动设备图形配置只会点亮距离最近的少数几个光源——Very Low 配置下一个也不会点亮。因此，如果设计的可读性依赖于特定的灯、聚光灯或粒子效果，那么在低端手机上就会失效。应将照明和 VFX 作为点缀，并确保即使完全没有动态光源，场景仍然清晰可读。完整表格和运行时限制规则：optimize-scene → 移动设备场景限制。

3. 纹理要求

• 尺寸必须为 2 的幂：256、512、1024、2048
• 推荐尺寸：场景物体使用 1024x1024；可穿戴物品最大支持 1024x1024（每件最多 2 张纹理，正方形，72 ppi；皮肤是例外，支持 5 张纹理和 5k 个三角形）
• 使用纹理图集将多张小纹理合并为一张，从而减少绘制调用和材质数量
• 尽可能优先使用 WebP 等压缩格式，而非原始 PNG
• 在材质之间共享纹理引用，不要重复纹理文件

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 中合并网格
• 使用纹理图集（多个对象共用一种材质）
• 限制独有材质的数量——让实体复用材质
• 尽可能避免透明效果（透明对象会增加绘制调用）

系统优化

• 不要每帧都运行繁重逻辑。使用计时器：

  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、数组）

禁用未使用的碰撞体

从玩家永远不会互动的装饰对象中移除碰撞网格。这能显著减少物理体数量。

禁用地形（Worlds）

对于单场景 Worlds，在 scene.json 中设置 landscapeTerrain: false，以移除场景周围自动生成的草地、树木和海洋。这样有两项好处：释放渲染预算，并让你能够采用完整自洽的美学风格（开阔水域、太空、虚空）。在 Genesis City 中无效。参见 create-scene 技能。

6. 输入系统设计

输入	操作	备注
E 键	主要操作（IA_PRIMARY）	主要互动
F 键	次要操作（IA_SECONDARY）	备用互动
指针点击	IA_POINTER	鼠标左键点击 / 点按
按键 1-4	IA_ACTION_3 至 IA_ACTION_6	操作栏槽位

设计注意事项

• 无法将鼠标滚轮用作输入
• 始终同时面向桌面端和移动端进行设计。移动端没有键盘——依靠指针和屏幕按钮
• 为指针事件设置 maxDistance（通常为 8-10 米），以防玩家与场景另一端的对象互动。它衡量的是 avatar 距离（默认值为 10），而非摄像机距离，因此与玩家实际感受到的触及范围一致。将近距离互动保持在约 3m 以内：Explorer 的近距离宽相检测使用硬编码的 3m 球体，并会将更大的值限制在此范围内。参见 add-interactivity >“距离规则”。
• 使用 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 简洁：元宇宙注重 3D 临场感，而非 2D 覆盖层。避免使用遮挡世界的大型 HUD。
• 优先使用空间 UI：当信息与某个地点或对象相关时，优先在实体上使用 TextShape 和 3D 标牌，而非屏幕空间 UI。
• 提供明确的可操作提示：交互对象应看起来可供互动。使用发光效果、轮廓、悬浮指示器或轻微动画，提示“可以点击”。
• 提供声音反馈：每项重要的玩家操作都应产生音频反馈。它能确认操作已生效，并提升完成度。
• 渐进式呈现信息：不要一次性展示所有信息。随着玩家参与，逐步揭示机制和故事。从简单开始，再逐层增加复杂度。
• 开场绝不要出现大段文字：包含冗长段落的规则弹窗，或绘制在游戏内平面上的规则手册，都是已知的不良模式——玩家会跳过它们，之后便会困惑地进行游戏。参见第 13 节“规则：展示，而非讲述”。
• 将屏幕 UI 放在客户端界面之外：绝不要将 HUD 固定在左上角（小地图、聊天和移动端摇杆都在这里）。将其固定在右侧或中央，或使用可交互嵌入界面；确保移动端 HUD 避开右下角操作按钮，或者在全屏 UI 打开时隐藏这些按钮。规则和代码见 build-ui 技能。
• 即时反馈：玩家互动时，应在同一帧内响应。使用补间动画、声音或 UI 弹窗，让玩家无需疑惑“操作成功了吗？”
• 无障碍性：使用高对比度文本、易读的字号（屏幕 UI 的 fontSize >= 16），并在视觉提示之外辅以音频提示。

9. MVP 规划

从核心循环开始

问：“玩家要做什么？”答案应当只有一句话：

• “玩家探索房间并寻找隐藏物品。”
• “玩家在障碍赛道上与其他玩家竞速。”
• “玩家收集资源并建造结构。”

快速制作原型

• 先用 1-2 块地块搭建，即使最终场景会更大
• 使用基本形状（方块、球体）作为占位，不要等最终美术资源
• 先让核心循环运转起来，再添加任何次要功能

尽早测试，并让游戏测试契合当前阶段

• 部署到测试 World（绝不要部署到正在使用的 LAND 或主 World），然后亲自体验一遍。
• 邀请 2-3 位真实玩家并观察他们。不要解释游戏——如果你必须解释某件事，这就是设计反馈。
• 衡量：玩家能否在 30 秒内明白该做什么？

**该问的问题取决于游戏的完成程度。**对于垂直切片，问“玩得开心吗？”没有意义（游戏内容还不够，答案说明不了什么）；对于 V2，问“你明白该做什么了吗？”则是在用已经知道的问题浪费测试时间。

阶段	要了解什么	邀请谁
V0 垂直切片	核心机制是否易于理解和使用？玩家能否据此制定策略？	邀请几位已经了解 Decentraland 的玩家，这样客户端就不会造成干扰
V1 首个完整循环	玩家能否在无人协助的情况下推进？他们会在哪里卡住或失去兴趣？	邀请 Decentraland 玩家和新玩家
V2+	游戏带给玩家怎样的感受？他们会回来吗？他们会推荐给别人吗？	邀请新玩家，包括 Decentraland 以外的玩家

使用 RITE 迭代（测试 → 修复 → 测试）

快速迭代测试与评估：每轮邀请 3-5 位玩家，在两轮之间修复最明显的问题，再邀请新玩家进行下一轮测试。这比一次大型测试后留下长长的问题清单更有效。DCL 特有的做法：

• **在轮次之间修复问题，不要在测试期间修复。**在测试进行中重新部署会打断玩家的游戏，也会破坏归因——你将无法确定某条评论针对的是哪个构建版本。
• 各轮使用相同的问题，否则评分无法比较。可以添加问题，但不要改写正在追踪的问题。
• “明确”意味着：你亲眼看到问题发生，能说出玩家原本期待什么，也知道该如何修改。只有一位玩家反馈且原因不明 → 留到下一轮继续观察。
• 记录每一轮：构建版本、参与者、观察结果、所做的修改。
• 寻找测试者：在 Decentraland Discord 的 #playtesters 频道发布招募信息；在 Decentraland Events 发布活动，组织现场测试；或者在测试内容为首次体验时，邀请 Decentraland 以外的玩家。送上一份小小的谢礼（可以在客户端中右键点击玩家，赠送自己拥有的可穿戴物品或表情），能提高参与人数——请明确说明你想听到批评，而不是赞美。
• 做好反馈闭环：在同一讨论串中发布“你们提出了什么 / 我们学到了什么 / 我们做了哪些改动”的更新。看到反馈得到落实的测试者，会回来参加下一轮。

使用 Scene Feedback 模块在场景中收集反馈

sdk7-test-scenes/scenes/0,-1-scene-feedback 是一个即插即用的问卷模块：可在你选择的游戏过程中，提出带标签的 1-5 分评分题（可选填写评论），也可只收集文字回答；回复会以 CSV 格式保存到场景的 Storage，可从 Creator Hub 下载（Manage → World ⋮ → View Storage）。模块附带一个包含 20 个问题的题库，按 coreMechanic / coreLoop / social / motivation / world / technical 分组，另有 14 种评分量表、一个包含 113 个问题的灵感题库，以及 README 中的 Agent 安装提示词。

• 它需要权威多人游戏服务器（@dcl/sdk@auth-server、"authoritativeMultiplayer": true、在 requiredPermissions 中启用 USE_FETCH）——设置方法及其使用的 CSV 追加到 Storage 的模式，请参阅 [[authoritative-server]]。
• 设计原则：围绕试玩目标提出一到两个问题，并选择自然的停顿时机（如一轮结束后、购买后），不要在玩家行动过程中提问。问题会等到画面清晰后显示，并且每次进入时，每个触发条件只显示一次。
• 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 检查清单

• 核心循环明确：用一句话描述玩家要做什么。
• 清楚知道第一步该做什么：新玩家能在 30 秒内知道该做什么。
• 提供反馈：每次交互都会产生可见和／或可听的反馈。
• 胜利／进度条件清晰：玩家知道自己何时取得进展。
• 失败条件公平：如果会失败，玩家能明白原因，并可快速重试。
• 具备重玩价值：有再次游玩的理由（提升分数、解锁新内容、社交竞赛）。
• 兼容多人游戏：单人和 5 名以上玩家同时游玩时都能正常运行。
• 符合场景限制：三角形数量、实体数量、纹理数量和文件大小均符合目标地块数量的预算。
• 性能可接受：游戏过程中，在目标实体／三角形数量下保持 30+ FPS。
• 兼容移动设备：核心交互无需键盘即可使用（仅指针输入）。使用 TouchScreenControls（参见 advanced-input）自定义屏幕按钮，使用 UiInputBinding（参见 build-ui）创建自定义触控操作按钮。使用 @dcl/sdk/platform 中的 isMobile() 检测平台，以切换 UI／控制方式。现已支持：LightSource、ParticleSystem、avatar masks（v1.13.0）；音频功能对等、AudioEvent、AudioAnalysis、双指缩放（v1.14.0）；stopEmote、Tween MoveRotateScale、其他玩家的场景相对位置、首轮移动功能对等支持（v1.15.0）。完整列表：advanced-input → 移动设备注意事项。
• 机制不依赖移动设备无法实现的功能（截至 2026 年 10 月／移动端 v1.15.0 的缺陷——这些会限制设计，而不只是润色）：
  • TweenSequence 在移动设备上不会播放动画。 基于它实现的移动平台、升降机或巡逻障碍物都不会移动——如果它是跨越缺口的必经之路，玩家就无法在手机上完成场景。请改用系统驱动多段运动（animations-tweens）。
  • 厚度小于 1 cm 的碰撞体只能从上方触发碰撞，且隐形阻挡物可能完全无法阻挡。 切勿仅使用隐形碰撞体来围住游戏区域或设置坠落危险区域（player-physics）。
  • 除非场景包含经过优化的资源，否则 Draco 压缩的 GLB 会在加载失败时不显示任何错误——而移动设备预览没有此类资源，因此模型会不可见，且不会报错（add-3d-models）。
  • 尚未实现 AvatarNametag，因此玩家上方的角色／等级标牌在移动设备上不传达任何信息。切勿让它成为唯一的信息载体。
  • UiBackground 会平铺九宫格而非拉伸；Smart Items 尚未获官方支持。
• 符合移动端场景限制：光源 ≤ 8 个（其中投射阴影的 ≤ 2 个）、VFX 发射器 ≤ 8 个，并且在不启用任何场景光源的 Very Low 图形配置下，场景仍清晰可辨。参见 optimize-scene → 移动端场景限制。

从头开始？ 请先参阅 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 技能（“滑翔时的力”）。
• 在地块边缘处使用开阔空间作为缓冲区。

12. 参与度与变现

参与模式

• 每日奖励：为每日访问提供小额奖励。通过外部服务器追踪访问记录——DCL 没有内置的每日追踪功能。在场景中显示连续签到次数。
• 成长系统：将等级或可解锁内容与累计游戏进度挂钩。将进度存储在服务器上，或使用基于 NFT 的成长机制。通过排行榜、徽章、不断变化的场景元素等方式直观展示进度。对于持久化排行榜和每位玩家的进度，内置 Multiplayer Server 的 Storage 可以在重新部署和服务器休眠后保留数据，并通过服务器拥有的同步组件供所有客户端渲染——完整模式和参考场景参见 [[authoritative-server]]。
• 成就：设定明确的里程碑（首次获胜、收集 100 件物品、游览所有房间）。通过声音和视觉效果进行提示。在场景中展示成就历史（奖杯室、名人堂）。

变现方式

• 场景内购买：通过 MANA 交易出售虚拟物品或能力。使用 signedFetch 安全地验证服务器端购买。付费升级之外，始终提供免费玩法。
• 可穿戴设备销售：制作并销售与场景主题相配的可穿戴设备。在场景中将可穿戴设备展示于人体模型上作为广告。
• 入场费／代币门控：收取 MANA 以进入高级区域，或要求玩家拥有特定 NFT。始终提供免费区域，展示付费区域所提供的内容。

社交机制

• 协作任务：设计需要多名玩家共同完成的目标（例如同时按下两个开关）。通过共享奖励鼓励协作。
• 共享空间：创建玩家自然而然会聚集的公共区域。添加可互动的环境物件，鼓励玩家随意互动。
• 活动：设计可举办定期活动（音乐会、竞赛）的场景。设置视野良好的舞台区域。提供活动主持人控制项（开始／停止游戏、重置场景、广播消息）。在服务端通过根据服务端验证的发送者检查管理员允许列表来限制主持人／管理员操作（[[authoritative-server]] Pattern 4）——绝不信任客户端报告的角色。

13. 教程与引导

场景内标牌

• 在关键位置放置带有简短说明的 TextShape 实体。
• 使用箭头、发光轮廓或动画指示器指向可互动对象。
• 每个标牌的文字控制在 10 个词以内。

NPC 引导员

• 在场景入口使用动画 NPC 迎接玩家并提供指导。
• 通过对话系统传达说明（每次一条消息，由玩家逐条推进）。
• 返回玩家应能跳过 NPC 对话。

逐步增加复杂度

• 一次只引入一种机制。首次互动应一目了然（一个很大、会发光的按钮）。
• 玩家完成简单任务后，再引入下一层内容。
• 通过早期成就解锁高级机制。

规则：重在展示，而非讲解

生成的游戏中经常出现两种反模式。玩家往往会在首次互动前就因此流失。

• 规则弹窗。 用包含多段密集文字的介绍弹窗解释每种机制、计分规则和操作。玩家会直接关掉，不会阅读。改进方法：弹窗（如果有）只占一屏，包含 3–5 行文字，每行 ≤ 8 个词；最好只包括一行目标说明、一行操作说明和一张图片／示意图。其他内容都通过实际游玩来学习。
• 场景内规则手册。 把相同的段落放在场景中的风格化平面或牌子上。看起来像是精心设计的内容，但文字在场景中太小、太长，玩家不会停下来眯着眼读。改进方法：一个标牌只说一件事（≤ 10 个词，并使用较大的 fontSize）；每个要点单独使用一个标牌；其余内容融入关卡设计。

与其讲解，不如展示：

• 让第一个目标一目了然：将发光、带动画或超大的物体放在玩家开场时的视线范围内。脉动的轮廓比一句话更能教会玩家“点击我”。
• 先让玩家在安全环境中亲自尝试一次某种机制（教程关卡、练习目标），再开始正式游戏。
• 将 hoverText 用作互动实体的即时说明——它会在恰当的时机出现，无需玩家预先阅读。
• 用图片／示意图（uiBackground 纹理或场景内平面）说明空间或顺序规则；用“红宝石 = 1，蓝宝石 = 5”的图片代替一整段文字。
• 较长的内容通过 NPC 或对话逐条传达，允许跳过；也可以在相关时机显示类似 Timed Announcement 的提示。

将文字预算用作检查清单：介绍面板 ≤ 5 行；标牌 ≤ 10 个词；提示 ≤ 1 句话；如果某条规则需要更多文字，就重新设计机制，或通过视觉效果展示。

零讲解测试

• 如果新玩家在没有任何文字或说明的情况下，无法在 30 秒内弄清第一步该做什么，就说明设计还需要改进。
• 观察真实玩家首次进入场景时的游玩过程。他们感到困惑的地方，就是设计反馈。

14. 交叉引用

主题	技能	适用场景
跟随／追逐移动目标（追踪玩家的实体）	animations-tweens	使用 Tween.setMoveContinuous 实现平滑跟随；不要每帧重新创建 setMove 补间（会造成抖动）。参见 79,-4-tween-following-cube 测试场景。
交互、输入处理、射线检测	add-interactivity	实现点击处理器、触发器和输入
多人同步、服务器通信	multiplayer-sync	联网游戏状态、实时同步
在场景内收集游戏测试反馈	authoritative-server	场景反馈模块（0,-1-scene-feedback）需要 Multiplayer Server；答复会追加到场景 Storage 中不断滚动的 CSV 文件。若要将此技术用于自己的事件日志，请先参阅该技能中的 仅追加日志：Storage 中的滚动 CSV 分片 模式，了解轮转、转义和数据丢失规则。
由服务器权威控制的游戏、排行榜、反作弊	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。可用它暂停游戏循环、音频和高开销系统，避免玩家无法看到或与场景交互时仍继续运行。
移除实体会返回布尔值	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 目录提供一个仅需提示词即可使用的 “Trigger Area” Smart Item——设计者放置并调整不可见区域的大小，再向 AI 助手描述触发效果，即可快速制作区域机制原型，无需编写检测器。脚本作者：使用其 @event 进入／退出模式，而不是添加第二个 triggerAreaEventsSystem 回调（script-components）。
在关卡搭建阶段插入临时美术、音乐或视频素材	creator-hub-mcp	将文件从编辑器的 Local Assets 标签页拖到视口中，即可生成已指向该文件的对应目录 Smart Item（图像／环境音效／视频屏幕）——这是在确定布局前将真实媒体素材放入白盒场景的最快方式。参见 add-3d-models 和 audio-video。
向 Creator Hub AI 助手提供参考资料	creator-hub-mcp	每条提示词最多可附加 8 个附件（通过回形针、拖放或粘贴添加）。可附上情绪板、模型图或 .glb 文件，无需用文字描述——磁盘上的文件会以真实绝对路径传给 Agent，且没有大小限制。
此技能侧重于塑造实现方案的设计决策和优化约束。有关详细的代码模式，请参阅引用的技能。