game-design

Compare original and translation side by side

🇺🇸

Original

English
🇨🇳

Translation

Chinese

Decentraland Game Design & Scene Optimization

Decentraland 游戏设计与场景优化

1. DCL Game Design Philosophy

1. DCL 游戏设计理念

Decentraland is a continuous, shared 3D world. Design around these constraints:
  • No startup screen: The scene is always live. Players walk in from adjacent parcels — there is no splash screen, no "press start." Your scene must be meaningful the instant a player arrives.
  • No forced endings: You cannot force a "game over" state. Players can leave at any time by walking away or teleporting. Design loops that accommodate drop-in / drop-out naturally.
  • Cannot remove players: There is no API to eject a player from a scene. You can teleport a player, but only within the existing scene. If you're teleporting outside the scene, you can only do it with their consent (they must accept the prompt). Design around misbehaving players with game mechanics, not eviction. If the scene has admin players, admins are able to ban other players from the scene manually.
  • Boundary awareness: Players standing outside your parcel can see into it. Your scene is always on display. Neighboring scenes are visible too — consider visual harmony.
  • Shared space: Multiple players are always potentially present. Even a "single-player" puzzle is witnessed by others. Embrace or account for this.
Decentraland 是一个持续运行且共享的 3D 世界。设计时需要围绕以下约束展开:
  • 无启动画面:场景始终处于在线状态。玩家会从相邻地块走进来——没有启动页,也没有“按开始”。你的场景必须在玩家到达的瞬间就具备明确意义。
  • 无法强制结束:不能强制进入“game over”状态。玩家随时可以走开或传送离开。应设计能够自然容纳玩家进入和退出的循环。
  • 不能移除玩家:没有 API 可以将玩家从场景中移除。你可以在现有场景内传送玩家,但如果要传送到场景之外,则必须征得玩家同意(他们必须接受提示)。应通过游戏机制而非驱逐来处理不当行为玩家。如果场景中有管理员玩家,管理员可以手动将其他玩家封禁在场景之外。
  • 边界感知:站在你的地块外的玩家也能看到地块内部。场景始终处于公开展示状态,邻近场景也同样可见——应考虑视觉协调。
  • 共享空间:场景中始终可能存在多名玩家。即使是“单人”解谜,也会被其他人围观。应接受这一设定或为其妥善设计。

2. Scene Limitation Formulas

2. 场景限制公式

Most limits scale with parcel count
n
(triangles, entities, bodies linear; materials, textures, height logarithmic). Key rule of thumb: 10,000 triangles and 200 entities per parcel.
For the full limits table across all parcel counts, see the optimize-scene skill.
大多数限制会随地块数量
n
缩放(三角形、实体和刚体呈线性增长;材质、纹理和高度呈对数增长)。关键经验法则是:每个地块 10,000 个三角形和 200 个实体。
有关所有地块数量对应的完整限制表,请参阅 optimize-scene skill。

3. Texture Requirements

3. 纹理要求

  • Dimensions must be power-of-two: 256, 512, 1024, 2048
  • Recommended sizes: 1024x1024 for scene objects, 512x512 for wearables
  • Use texture atlases to combine multiple small textures into one, reducing draw calls and material count
  • Prefer compressed formats (WebP) over raw PNG where possible
  • Share texture references across materials — do not duplicate texture files
  • 尺寸必须为 2 的幂:256、512、1024、2048
  • 推荐尺寸:场景对象使用 1024x1024,wearables 使用 512x512
  • 使用纹理图集将多个小纹理合并为一个,从而减少 draw call 和材质数量
  • 尽可能使用压缩格式(WebP),而不是原始 PNG
  • 在不同材质之间共享纹理引用——不要重复纹理文件

4. Asset Preloading

4. 资源预加载

Use the
AssetLoad
component to pre-load assets that aren't needed at scene startup so they display instantly when needed (e.g. things that appear later or on player interaction); don't use it for startup assets.
For the implementation pattern, see the optimize-scene skill.
使用
AssetLoad
组件预加载场景启动时不需要的资源,使其在需要时能够立即显示(例如之后出现或由玩家交互触发的对象);不要将其用于启动资源。
有关实现模式,请参阅 optimize-scene skill。

5. Performance Patterns

5. 性能模式

Object Pooling

对象池(Object Pooling)

Reuse entities instead of creating and destroying them:
typescript
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)
}
复用实体,而不是反复创建和销毁它们:
typescript
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 (Level of Detail)

LOD(Level of Detail)

Swap models or hide entities based on distance from the player:
typescript
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)
根据玩家与对象的距离切换模型或隐藏实体:
typescript
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)

Draw Call Reduction

减少 Draw Call

  • Merge meshes in Blender before export
  • Use texture atlases (one material for many objects)
  • Limit unique materials — reuse them across entities
  • Avoid transparency when possible (transparent objects cost extra draw calls)
  • 导出前在 Blender 中合并网格
  • 使用纹理图集(让多个对象共用一种材质)
  • 限制唯一材质的数量——在不同实体之间复用材质
  • 尽可能避免使用透明效果(透明对象会产生额外的 draw call)

System Optimization

系统优化

  • Do NOT run heavy logic every frame. Use timers:
    typescript
    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
    }
  • Minimize
    engine.getEntitiesWith()
    queries — cache results when entity sets are stable
  • Avoid allocating new objects (Vector3.create, arrays) inside systems that run every frame
  • 不要每帧都运行高开销逻辑。请使用 timer:
    typescript
    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()
    查询——当实体集合保持稳定时,应缓存查询结果
  • 避免在每帧运行的 system 中分配新对象(Vector3.create、数组)

Disable Unused Colliders

禁用未使用的碰撞体

Remove collision meshes from decorative objects that players never interact with. This reduces physics body count significantly.
从玩家永远不会交互的装饰对象中移除碰撞网格。这可以显著减少物理刚体数量。

Disable Landscape Terrain (Worlds)

禁用 Landscape Terrain(Worlds)

For single-scene Worlds, set
landscapeTerrain: false
in
scene.json
to remove the auto-generated grassland/trees/sea around the scene. Two payoffs: it frees rendering budget, and it lets you commit to a self-contained aesthetic (open water, space, void). Ignored in Genesis City. See the
create-scene
skill.
对于单场景 Worlds,请在
scene.json
中设置
landscapeTerrain: false
,以移除自动生成的草地、树木和海洋。这样做有两个好处:一是释放渲染预算,二是让你能够采用独立完整的美术风格(开放水面、太空、虚空)。Genesis City 中会忽略此设置。请参阅
create-scene
skill。

6. Input System Design

6. 输入系统设计

InputActionNotes
E keyPrimary action (
IA_PRIMARY
)
Main interaction
F keySecondary action (
IA_SECONDARY
)
Alternate interaction
Pointer click
IA_POINTER
Left mouse click / tap
Keys 1-4
IA_ACTION_3
through
IA_ACTION_6
Action bar slots
输入操作备注
E 键主操作(
IA_PRIMARY
)
主要交互
F 键次操作(
IA_SECONDARY
)
备用交互
指针点击
IA_POINTER
鼠标左键点击或触摸
1-4 键
IA_ACTION_3
至
IA_ACTION_6
动作栏槽位

Design Considerations

设计注意事项

  • Mouse wheel is not available as an input
  • Always design for both desktop and mobile. Mobile has no keyboard — rely on pointer and on-screen buttons
  • Set
    maxDistance
    on pointer events (8-10 meters typical) to prevent interactions from across the scene
  • Use
    hoverText
    to communicate what an interaction does before the player commits
  • 鼠标滚轮不可用作为输入方式
  • 始终为桌面端和移动端进行设计。移动端没有键盘,应依赖指针操作和屏幕按钮
  • 为指针事件设置
    maxDistance
    (通常为 8-10 米),防止玩家从场景远处进行交互
  • 使用
    hoverText
    在玩家执行操作前说明交互内容

7. State Management Patterns

7. 状态管理模式

Module-Level State (Simple Games)

模块级状态(简单游戏)

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

Component-Based State (Complex Games)

基于组件的状态(复杂游戏)

Use custom components as structured data containers:
typescript
import { engine, Schemas } from '@dcl/sdk/ecs'

const EnemyState = engine.defineComponent('EnemyState', {
  health: Schemas.Number,
  speed: Schemas.Number,
  target: Schemas.Entity
})
使用自定义组件作为结构化数据容器:
typescript
import { engine, Schemas } from '@dcl/sdk/ecs'

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

State Machines

状态机

Model game phases as explicit states with clear transitions:
typescript
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
  }
}
将游戏阶段建模为具有明确转换关系的独立状态:
typescript
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 Guidelines

8. UX/UI 指南

  • Keep UI minimal: The metaverse is about 3D presence, not 2D overlays. Avoid large HUDs that obscure the world.
  • Prefer spatial UI: Use
    TextShape
    on entities and 3D signs over screen-space UI whenever the information is tied to a place or object.
  • Clear affordances: Interactive objects should look interactive. Use glow effects, outlines, floating indicators, or subtle animations to signal "you can click this."
  • Sound feedback: Every significant player action should produce audio feedback. It confirms the action registered and adds polish.
  • Progressive disclosure: Do not dump all information at once. Reveal mechanics and story as the player engages. Start simple, layer complexity.
  • Immediate feedback: When a player interacts, respond within the same frame. Use tweens, sounds, or UI popups so the player never wonders "did that work?"
  • Accessibility: Use high-contrast text, readable font sizes (fontSize >= 16 for screen UI), and audio cues alongside visual ones.
  • 保持 UI 简洁:元宇宙的核心是 3D 临场感,而不是 2D 叠加层。避免使用遮挡世界的大型 HUD。
  • 优先使用空间 UI:当信息与某个地点或对象绑定时,应优先在实体上使用
    TextShape
    和 3D 标牌,而不是使用屏幕空间 UI。
  • 清晰的交互提示:可交互对象应该看起来具有可交互性。使用发光效果、轮廓、浮动指示器或细微动画来提示“你可以点击这个”。
  • 声音反馈:每项重要的玩家操作都应产生音频反馈。这既能确认操作已生效,也能提升体验品质。
  • 渐进式披露:不要一次性倾倒所有信息。随着玩家参与游戏,逐步揭示机制和故事。先从简单内容开始,再逐层增加复杂度。
  • 即时反馈:玩家进行交互时,应在同一帧内作出响应。使用 tween、声音或 UI 弹窗,避免玩家怀疑“是否生效了”。
  • 无障碍性:使用高对比度文本和易读的字号(屏幕 UI 的
    fontSize >= 16
    ),并在视觉提示之外提供音频提示。

9. MVP Planning

9. MVP 规划

Start with the Core Loop

从核心循环开始

Ask: What does the player DO? The answer should be a single sentence:
  • "The player explores rooms and finds hidden objects."
  • "The player races other players through an obstacle course."
  • "The player collects resources and builds structures."
提出问题:玩家会做什么? 答案应该是简短的一句话:
  • “玩家探索房间并寻找隐藏物品。”
  • “玩家与另一名玩家进行障碍赛竞速。”
  • “玩家收集资源并建造结构。”

Prototype Fast

快速制作原型

  • Build in 1-2 parcels first, even if the final scene will be larger
  • Use primitive shapes (boxes, spheres) as placeholders — do not wait for final art
  • Get the core loop working before adding any secondary features
  • 即使最终场景更大,也应先在 1-2 个地块中构建
  • 使用基础几何图形(方块、球体)作为占位对象,不要等待最终美术资源完成
  • 先让核心循环运行起来,再添加任何次要功能

Test Early

尽早测试

  • Deploy to a test world and walk through it yourself
  • Invite 2-3 real players and watch them (do not explain the game — see if it is self-explanatory)
  • Measure: Do players understand what to do within 30 seconds?
  • 部署到测试 World 中,并亲自完整体验
  • 邀请 2-3 名真实玩家进行测试并观察他们(不要解释游戏——看看它是否不言自明)
  • 衡量:玩家能否在 30 秒内理解该做什么?

Iterate on Fun

围绕乐趣迭代

  • Polish comes last. If the core loop is not fun with placeholder art, better art will not fix it
  • Cut features aggressively. A tight, small experience beats a sprawling, unfinished one
  • Replay value matters more than content volume in DCL (players return to scenes they enjoy)
  • 打磨应放在最后。如果使用占位美术时核心循环还不够有趣,更好的美术也无法解决问题
  • 大幅削减功能。紧凑而完整的体验优于庞大但未完成的作品
  • 在 DCL 中,重玩价值比内容数量更重要(玩家会回到自己喜欢的场景)

MVP Checklist

MVP 检查清单

  • Core loop defined: One sentence describing what the player does.
  • First action obvious: A new player knows what to do within 30 seconds.
  • Feedback present: Every interaction produces visible and/or audible feedback.
  • Win/progress condition clear: The player understands when they are succeeding.
  • Lose/fail condition fair: If there is failure, the player understands why and can retry quickly.
  • Replay value exists: There is a reason to play again (score improvement, new content, social competition).
  • Multiplayer compatible: Works correctly with 1 player and with 5+ simultaneous players.
  • Within scene limits: Triangle count, entity count, texture count, and file size all within budget for the target parcel count.
  • Performance acceptable: Maintains 30+ FPS during gameplay with target entity/triangle counts.
  • Mobile compatible: Core interactions work without a keyboard (pointer-only inputs). Detect platform with
    isMobile()
    from
    @dcl/sdk/platform
    to branch UI/controls. Note:
    borderRadius
    is unsupported on mobile UI; ParticleSystem and dynamic lights are not yet available on mobile.
Starting from scratch? See the create-scene skill first to scaffold the project before designing the game.
  • 已定义核心循环:用一句话描述玩家会做什么。
  • 首个操作清晰明了:新玩家在 30 秒内就知道该做什么。
  • 具备反馈:每次交互都会产生视觉和/或听觉反馈。
  • 胜利或进度条件明确:玩家明白自己何时正在取得进展或获胜。
  • 失败条件公平:如果存在失败,玩家应理解失败原因,并能快速重试。
  • 存在重玩价值:玩家有理由再次游玩(提升分数、新内容、社交竞争)。
  • 兼容多人模式:在 1 名玩家和 5 名以上玩家同时参与时都能正常运行。
  • 未超出场景限制:三角形数量、实体数量、纹理数量和文件大小均在目标地块数量的预算之内。
  • 性能可接受:在游戏中使用目标实体和三角形数量时,能够保持 30+ FPS。
  • 兼容移动端:核心交互无需键盘即可使用(仅使用指针输入)。使用
    @dcl/sdk/platform
    中的
    isMobile()
    检测平台,并据此分支 UI 和控制方式。注意:移动端 UI 不支持
    borderRadius
    ;移动端尚不支持 ParticleSystem 和动态灯光。
从零开始? 请先参阅 create-scene skill,在设计游戏前为项目搭建基础架构。

10. Game Loop Archetypes

10. 游戏循环原型

Exploration

探索

  • Core loop: Discover locations, find hidden items, unlock areas.
  • DCL fit: Excellent. The 3D world and spatial navigation are strengths.
  • Design tips: Use landmarks for wayfinding. Reward curiosity with hidden content. Use lighting and sound to guide attention.
  • 核心循环:发现地点、寻找隐藏物品、解锁区域。
  • DCL 适配度:极佳。3D 世界和空间导航是它的优势。
  • 设计建议:使用地标帮助玩家定位方向。用隐藏内容奖励好奇心。使用灯光和声音引导注意力。

Collection

收集

  • Core loop: Gather items, complete sets, earn rewards.
  • DCL fit: Strong. Combines well with exploration and daily engagement.
  • Design tips: Use entity pooling for collectibles. Scatter items spatially. Tie collections to visual progress (display cases, counters).
  • 核心循环:收集物品、完成套装、获得奖励。
  • DCL 适配度:强。能够很好地结合探索和日常参与。
  • 设计建议:为收集物使用实体池。在空间中分散布置物品。将收集进度与视觉进展关联起来(展示柜、计数器)。

Puzzle

解谜

  • Core loop: Solve spatial or logic challenges to progress.
  • DCL fit: Good. Spatial puzzles (move objects, find paths, activate sequences) work well.
  • Design tips: Provide clear feedback on progress. Avoid puzzles that require typing (input is limited). Use 3D interactions (click, proximity triggers) as puzzle inputs.
  • 核心循环:解决空间或逻辑挑战,以推进进度。
  • DCL 适配度:良好。空间解谜(移动对象、寻找路径、激活序列)效果很好。
  • 设计建议:提供清晰的进度反馈。避免需要输入文字的解谜(输入方式有限)。使用 3D 交互(点击、接近触发)作为解谜输入方式。

Social

社交

  • Core loop: Interact with other players, attend events, roleplay.
  • DCL fit: Excellent. This is the platform's native strength.
  • Design tips: Create gathering spaces (seating, stages, open areas). Provide conversation starters (interactive objects, games). Design for groups of 5-20.
  • 核心循环:与其他玩家互动、参加活动、进行角色扮演。
  • DCL 适配度:极佳。这是该平台的原生优势。
  • 设计建议:创建聚集空间(座位、舞台、开放区域)。提供话题引导元素(交互对象、小游戏)。面向 5-20 人的群体进行设计。

Competitive

竞技

  • Core loop: Race, fight, or outscore other players.
  • DCL fit: Moderate. Latency and input limitations constrain fast-paced action.
  • Design tips: Prefer turn-based or timing-based competition over twitch reflexes. Use server-authoritative state to prevent cheating. Keep rounds short (2-5 minutes).
  • Anti-cheat architecture: whenever scores or prizes are at stake, make the scene server-authoritative (see [[authoritative-server]]). Clients send intent messages only (e.g.
    claimPoint
    ) — never a score; the server validates (proximity to the objective, permissions) and is the only writer of game state. The official leaderboard test scene is a complete end-to-end template of this design: https://github.com/decentraland/sdk7-test-scenes/tree/main/scenes/90,-9-authoritative-server-leaderboard
  • 核心循环:竞速、战斗或获得比其他人更高的分数。
  • DCL 适配度:中等。延迟和输入限制会制约高速动作类玩法。
  • 设计建议:相比考验瞬时反应的玩法,更适合回合制或计时类竞技。使用 server-authoritative state 防止作弊。保持每轮较短(2-5 分钟)。
  • 反作弊架构:当分数或奖励受到 stakes 影响时,应让场景采用 server-authoritative 架构(参见 [[authoritative-server]])。客户端只能发送意图消息(例如
    claimPoint
    ),绝不能直接发送分数;服务器负责验证(与目标的距离、权限等),并且是游戏状态的唯一写入者。官方排行榜测试场景是这一设计的完整端到端模板:https://github.com/decentraland/sdk7-test-scenes/tree/main/scenes/90,-9-authoritative-server-leaderboard

11. Spatial Design

11. 空间设计

Landmarks

地标

  • Place a tall, visible landmark at the center or entrance of your scene. Players use it to orient themselves.
  • Every distinct area should have a unique visual identity (color, shape, lighting).
  • 在场景中心或入口放置高大、可见的地标,帮助玩家确定方位。
  • 每个独特区域都应具有鲜明的视觉身份(颜色、形状、灯光)。

Pathfinding

寻路

  • Guide players with visible paths (floor patterns, lighting, railings).
  • Avoid dead ends that require backtracking — use loops.
  • Place interactive elements along paths to maintain engagement during traversal.
  • 使用可见路径引导玩家(地面图案、灯光、栏杆)。
  • 避免需要原路返回的死路——应采用环形路径。
  • 沿路径布置交互元素,以保持玩家在移动过程中的参与感。

Sightlines

视线

  • Use open sightlines to draw players toward objectives.
  • Block sightlines strategically to create mystery and discovery.
  • Ensure the scene looks inviting from the parcel boundary (this is your "shop window").
  • 使用开阔的视线将玩家吸引至目标。
  • 有策略地阻挡视线,以营造神秘感和发现感。
  • 确保场景从地块边界看去依然具有吸引力(这是场景的“橱窗”)。

Parcel Transitions

地块过渡

  • If your scene spans multiple parcels, ensure smooth visual transitions.
  • Do not place critical interactive elements right at parcel boundaries (loading edge cases).
  • 如果场景跨越多个地块,应确保视觉过渡平滑。
  • 不要将关键交互元素放在地块边界附近(可能遇到加载边缘问题)。

Vertical Traversal with Gliding

利用滑翔进行垂直移动

  • While a player glides, continuous scene forces are 1.5× stronger and their upward component can lift the glider (the falling-speed cap only limits descent). This enables traversal mechanics like thermal updrafts, wind corridors, and floating-island hops. One-shot impulses (launch pads, knockback) are unaffected by gliding. See the
    player-physics
    skill ("Forces while gliding").
  • Use open space at parcel edges as buffer zones.
  • 玩家滑翔时,持续场景力会增强至 1.5 倍,其向上分量可以托起滑翔者(下落速度上限仅限制下降)。这支持热上升气流、风道和浮岛跳跃等移动机制。一次性冲量(发射台、击退)不受滑翔影响。请参阅
    player-physics
    skill(“滑翔时的作用力”)。
  • 在地块边缘留出开放空间作为缓冲区。

12. Engagement and Monetization

12. 参与度与变现

Engagement Patterns

参与模式

  • Daily rewards: Offer small rewards for daily visits. Track visits via external server — DCL has no built-in daily tracking. Display streak counters in-scene.
  • Progression systems: Levels or unlockable content tied to cumulative play. Store progress on a server or use NFT-based progression. Show progression visually (leaderboards, badges, evolving scene elements). For persistent leaderboards and per-player progress, the built-in Multiplayer Server's
    Storage
    persists across redeploys and server sleep, with a server-owned synced component all clients render — see [[authoritative-server]] for the full pattern and reference scene.
  • Achievements: Define clear milestones (first win, 100 collectibles, visited all rooms). Announce with sound and visual effects. Display achievement history in-scene (trophy room, wall of fame).
  • 每日奖励:为每日访问提供小额奖励。通过外部服务器追踪访问次数——DCL 没有内置的每日追踪功能。在场景中显示连续访问计数器。
  • 进度系统:提供与累计游戏时长或参与度关联的等级或可解锁内容。将进度存储在服务器上,或使用基于 NFT 的进度系统。以视觉方式展示进度(排行榜、徽章、不断变化的场景元素)。对于持久化排行榜和玩家个人进度,内置 Multiplayer Server 的
    Storage
    可以在重新部署和服务器休眠后继续保留数据,并通过由服务器拥有的同步组件呈现给所有客户端——完整模式请参阅 [[authoritative-server]] 及参考场景。
  • 成就:定义清晰的里程碑(首次获胜、收集 100 件物品、访问所有房间)。通过声音和视觉效果进行公告。在场景中展示成就记录(奖杯室、名人堂)。

Monetization Approaches

变现方式

  • In-scene purchases: Sell virtual items or abilities via MANA transactions. Use
    signedFetch
    for secure server-verified purchases. Always provide free gameplay alongside paid upgrades.
  • Wearable sales: Create and sell wearables that complement your scene's theme. Display wearables on mannequins in-scene as advertisements.
  • Entry fees/token gating: Charge MANA to enter a premium area, or require ownership of a specific NFT. Always have a free area that showcases what the paid area offers.
  • 场景内购买:通过 MANA transaction 销售虚拟物品或能力。使用
    signedFetch
    实现由服务器安全验证的购买。付费升级之外,始终应提供免费玩法。
  • Wearables 销售:创建并销售与场景主题相配的 wearables。在场景中使用 mannequin 展示 wearables,将其作为广告。
  • 入场费或 Token 限制:收取 MANA 以进入付费区域,或要求玩家拥有特定 NFT。始终提供一个免费区域,用来展示付费区域提供的内容。

Social Mechanics

社交机制

  • Cooperative tasks: Design objectives requiring multiple players (two switches pressed simultaneously, etc.). Reward cooperation with shared benefits.
  • Shared spaces: Create common areas where players naturally congregate. Add ambient interactive objects that encourage casual interaction.
  • Events: Design scenes that can host scheduled events (concerts, competitions). Include a stage area with good sightlines. Provide event host controls (start/stop game, reset scene, broadcast messages). Gate host/admin actions server-side with an admin allow-list checked against the server-verified sender ([[authoritative-server]] Pattern 4) — never trust a client-reported role.
  • 协作任务:设计需要多名玩家共同完成的目标(例如同时按下两个开关)。通过共享收益奖励合作。
  • 共享空间:创建玩家自然聚集的公共区域。加入环境交互对象,鼓励轻松互动。
  • 活动:设计可以承载定期活动的场景(音乐会、竞赛)。设置具有良好视线的舞台区域。提供活动主持控制(开始或停止游戏、重置场景、广播消息)。使用管理员 allow-list 在服务器端控制主持或管理员操作,并根据服务器验证的发送者检查 allow-list——绝不能信任客户端自行申报的角色。请参阅 [[authoritative-server]] 模式 4。

13. Tutorial and Onboarding

13. 教程与新手引导

In-World Signs

场景内标牌

  • Place
    TextShape
    entities with short instructions at key locations.
  • Use arrows, glowing outlines, or animated indicators to point to interactive objects.
  • Keep text under 10 words per sign.
  • 在关键位置放置包含简短说明的
    TextShape
    实体。
  • 使用箭头、发光轮廓或动画指示器指向交互对象。
  • 每块标牌的文字控制在 10 个词以内。

NPC Guides

NPC 引导

  • Use an animated NPC at the scene entrance to greet and instruct.
  • Deliver instructions through a dialog system (one message at a time, player advances).
  • NPC dialog should be skippable for returning players.
  • 在场景入口放置一个动画 NPC,用于迎接和指导玩家。
  • 通过对话系统传递说明(每次显示一条消息,由玩家推进)。
  • 对于回访玩家,NPC 对话应支持跳过。

Progressive Complexity

渐进式复杂度

  • Introduce one mechanic at a time. The first interaction should be obvious (a big, glowing button).
  • After the player succeeds at the simple task, introduce the next layer.
  • Gate advanced mechanics behind early accomplishments.
  • 每次只引入一种机制。第一次交互应一目了然(例如一个大型发光按钮)。
  • 玩家成功完成简单任务后,再引入下一层内容。
  • 将高级机制设置为需要先完成早期目标才能解锁。

Zero-Explanation Test

零说明测试

  • If a new player cannot figure out the first action within 30 seconds without any text or instructions, the design needs work.
  • Watch real players attempt your scene cold. Their confusion is your design feedback.
  • 如果新玩家在没有文字或说明的情况下,无法在 30 秒内判断出第一个操作,则设计需要改进。
  • 观察真实玩家首次进入场景时的表现。他们的困惑就是设计反馈。

14. Cross-References

14. 交叉引用

TopicSkillWhen to Use
Interactivity, input handling, raycastingadd-interactivityImplementing click handlers, triggers, input
Multiplayer sync, server communicationmultiplayer-syncNetworked game state, real-time sync
Server-authoritative games, leaderboards, anti-cheatauthoritative-serverCompetitive scoring, persistent progress, admin-gated host controls. The Gem Rush reference scene (
92,-9
) is a complete competitive game architecture with server-side proximity anti-cheat and checkpoint-only storage.
FPS-style / mouselook camera controlscamera-controlMouselook pattern:
PrimaryPointerInfo.screenDelta
+ VirtualCamera + PointerLock + InputModifier. Desktop only.
Audio-reactive visuals (music visualizers, beat detection)audio-analysis
AudioAnalysis
component on
AudioSource
or
VideoPlayer
(progressive only, not HLS). Drive geometry/lights/colors from
amplitude
and 8 frequency
bands
.
Screen UI, React-ECS, HUD elementsbuild-uiBuilding menus, scoreboards, dialogs
Mobile platform detectionadvanced-inputPlatform detection via
getPlatform()
/
isMobile()
from
@dcl/sdk/platform
to branch UI/controls for mobile.
Open Explorer UI panels from scenesscene-runtime
openExplorerUi()
restricted action to open map, backpack, settings, etc. from a user gesture. Useful for onboarding flows and UX shortcuts.
World deployment, storage budgetdeploy-worldsWorld storage budget (100 MB per NAME, 100 MB per LAND, 100 MB per 2k MANA; ENS = 36 MB fixed). Plan scene file sizes accordingly.
Performance optimization, entity/triangle budgetsoptimize-sceneDetailed optimization techniques. Creator Hub "Optimize Assets" preview option for testing with production-like asset bundles.
This skill focuses on the design decisions and optimization constraints that shape implementations. For detailed code patterns, see the referenced skills.
主题Skill使用场景
交互、输入处理、raycastingadd-interactivity实现点击处理器、触发器和输入
多人同步、服务器通信multiplayer-sync网络化游戏状态、实时同步
Server-authoritative 游戏、排行榜、反作弊authoritative-server竞技计分、持久化进度、管理员权限控制的主持功能。Gem Rush 参考场景(
92,-9
)是一套完整的竞技游戏架构,包含服务器端距离反作弊和仅保存检查点的存储模式。
FPS 风格或 mouselook 相机控制camera-controlMouselook 模式:
PrimaryPointerInfo.screenDelta
+ VirtualCamera + PointerLock + InputModifier。仅限桌面端。
音频响应式视觉效果(音乐可视化、节拍检测)audio-analysis在 AudioSource 或 VideoPlayer 上使用
AudioAnalysis
组件(仅支持 progressive,不支持 HLS)。根据
amplitude
和 8 个频段驱动几何体、灯光或颜色。
屏幕 UI、React-ECS、HUD 元素build-ui构建菜单、排行榜和对话框
移动平台检测advanced-input通过
@dcl/sdk/platform
中的
getPlatform()
或
isMobile()
检测平台,并据此分支 UI 和控制方式。
从场景中打开 Explorer UI 面板scene-runtime在用户手势中调用受限操作
openExplorerUi()
,打开地图、背包、设置等面板。适用于新手引导流程和 UX 快捷操作。
World 部署、存储预算deploy-worldsWorld 存储预算为每个 NAME 100 MB、每个 LAND 100 MB、每 2k MANA 100 MB;ENS 固定为 36 MB。应据此规划场景文件大小。
性能优化、实体和三角形预算optimize-scene详细的优化技术。使用 Creator Hub 的“Optimize Assets”预览选项,以接近生产环境的资源包进行测试。
本 skill 专注于塑造实现方案的设计决策和优化约束。有关详细代码模式,请参阅上述引用的 skills。