> For the complete documentation index, see [llms.txt](https://docs.decentraland.org/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.decentraland.org/creator/content-creator-zh/chang-jing-sdk7/ti-yan-she-ji/ux-ui-guide.md).

# UX 与 UI 指南

构建让玩家愿意停留并回访的场景的技巧与实践！

我们认为至关重要的是，Decentraland 的内容创作者应能自由且充分地发挥创造力。这对于 Decentraland 成为一个值得探索、并能带来回报的地方至关重要。不过，也要记住，Decentraland 中的场景会被各种各样的用户访问，我们希望这些场景对所有人都可访问。因此，我们不能忽视建立统一设计标准的必要性——这是一份指南，能够确保玩家无论身处哪个场景，都能获得同样直观且愉快的体验。

在本文档中，我们分享 Decentraland 的设计价值观，旨在推广我们认为用于设计界面和玩家体验的最佳实践。我们希望这些标准能作为构建和/或改进构成元宇宙的场景的起点。

## 设计价值观

Decentraland 中的所有场景都应在设计时牢记这些价值观：

* **热情欢迎**：让玩家感到受到热情欢迎。
* **用户友好**：UI 易于且有趣地使用——你应该避免重复造轮子。
* **易于学习**：玩家会觉得 UI 熟悉且直观。整个场景中应一致地使用各种模式。
* **提供引导**：场景提供帮助。文字、动效、声音和图形会引导并提示玩家朝正确方向前进。
* **有响应性**：对玩家输入有清晰的动作-反应反馈。
* **极简**：少即是多。玩家可以把注意力集中在重要的事情上。
* **有趣**：场景充分利用了让 Decentraland 独特且值得一游的元素。
* **有目的性**：玩家有充分的理由再次回来。
* **令人愉悦**：玩家享受事物的外观、声音和触感。

## 用户体验

### 从哪里开始？

你的场景目标是什么？是提供一个可供欣赏和探索的美丽景观？是一个博物馆？是单人游戏？竞技游戏？还是遵循线性叙事流程？

在设计过程的每一步，都要清楚地了解这一目标；它应该指导你的所有决策，而这些决策都会深刻影响访客的体验。

对于遵循线性流程的场景，其中每一步都依赖前一步，我们建议用墙体围住场景，并建立一个或多个固定入口，以避免玩家误以错误顺序进入内容。顺便说一下，入口点也是展示欢迎信息并解释玩家在场景中的目标的绝佳位置。

<figure><img src="https://2460066822-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FoPnXBby9S6MrsW83Y9qZ%2Fuploads%2Fgit-blob-97ebd53471da877dec44f02a12a433af644d458a%2Fux-instructions.png?alt=media" alt="In-world banner" width="800"><figcaption><p>场景内说明</p></figcaption></figure>

如果玩家在你的场景中的体验并非线性，但你仍需要提供一些基本说明以确保他们充分享受体验，你可以用弹窗展示说明。无论玩家从哪个方向进入，都可以在他们一进入时就在屏幕上显示弹窗，从而确保玩家始终知道基本要点。

<figure><img src="https://2460066822-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FoPnXBby9S6MrsW83Y9qZ%2Fuploads%2Fgit-blob-8a74df26bf66f63d5d103d0c9ee5a4cd8323ddd1%2Fux-banner.png?alt=media" alt="Pop-up banner" width="800"><figcaption><p>弹窗说明</p></figcaption></figure>

{% hint style="warning" %}
**📔 注意**：确保弹窗不会过于打扰，并且点击任意位置即可轻松关闭。
{% endhint %}

欢迎信息应向玩家传达以下内容：

* 场景标题
* 欢迎玩家
* 玩家的最终目标与动机
* 说明/下一步
* *（可选）* 控制方式。若你的场景使用全局按钮事件，这通常很有用。否则，物品本身会在鼠标悬停时提示如何使用它们。

### 动机

你大概会希望访客不断回到你的场景，想想你可以用什么方式激励他们这样做！问问自己：“什么会让玩家想再次回到我的场景，或者愿意把它推荐给朋友？”

例如，你可以向他们发起挑战，给他们一些需要完成的目标，而且难度要足以让他们多次尝试。你也可以组织具有竞争性的多人活动，这同样是社交的绝佳机会。让你的场景成为一个动态的地方，让玩家觉得自己喜欢待在这里！

### 反馈与声音

声音扮演着双重关键角色，不要错过使用它！一方面，声音对于营造沉浸感至关重要；很多没有声音就不会显得真实的东西，都需要声音陪伴。声音的另一个关键作用是为玩家操作提供反馈。如果你只依赖视觉提示，就无法确定玩家是否正看向正确方向来看到其操作效果。通过使用声音，你可以确保他们意识到某件事已经发生。如果你将视觉和声音提示结合使用，那么听到声音会促使玩家四处寻找视觉提示，以防他们没有看到。

请记住，有些玩家可能关闭了声音。如果你把声音作为提供场景说明或游戏机制关键内容的方式，请尽量同时提供某种视觉提示，以指向同一个方向。例如，你可以在 UI 底部显示文字来配合这些声音，就像电影字幕一样。

## 用户界面

本节旨在帮助你通过场景设计构建叙事，将玩家的注意力引导到最重要的元素上。善用此处描述的工具，可以让他们的体验更加沉浸，也更容易成功。

我们无法过分强调颜色、图标、动效和比例在传达正确信息方面的价值：场景中的一切都在传递意义，请记住这一点。

### 布局

在将 UI 放置到与默认 Decentraland UI 元素重叠的屏幕区域时要小心。在桌面客户端中，默认的 Decentraland UI（侧边栏、小地图、聊天等）被设计为仅占据屏幕左侧 25% 的区域（图中红色高亮部分）。其余屏幕空间是一个安全区域，内容创作者可以自由使用。

<figure><img src="https://2460066822-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FoPnXBby9S6MrsW83Y9qZ%2Fuploads%2Fgit-blob-dd66dfc723550792844114dde7e60be4127d5d64%2FUI-Zones.png?alt=media" alt="Screen regions used by UI" width="800"><figcaption></figcaption></figure>

在屏幕左侧 25% 的区域放置 UI 元素没有限制，但请记住，explorer 会持续对其设计进行修改和改进。如今在该区域中未被遮挡的任何空间，未来版本中都可能被覆盖。

{% hint style="info" %}
**📱 移动端安全区域**：该 [移动客户端](/creator/content-creator-zh/mian-xiang-yi-dong-duan-gou-jian/yi-dong-ke-hu-duan/overview.md) 会在画布的一部分上绘制自己的控制项： **左侧** （聊天、搜索、个人资料、摇杆、表情动作）、 **右上角** （个人资料和相机控制）、以及 **右下角** （动作和交互按钮）。不要手动测量这些区域：请在客户端报告的区域内渲染，使用 `screenInset: 'interactable'`。把关键 UI 保持在屏幕中央或正上方，并遵循 [移动端安全区域](/creator/content-creator-zh/mian-xiang-yi-dong-duan-gou-jian/kai-fa/safe-area.md)。使用 [`isMobile()`](/creator/content-creator-zh/mian-xiang-yi-dong-duan-gou-jian/kai-fa/detect-platform.md) ，以便在桌面端与移动端限制不一致时切换布局。
{% endhint %}

{% hint style="warning" %}
**📔 注意**：来自场景和智能穿戴设备的 UI 元素总是出现在默认 Decentraland UI 之后的一层。
{% endhint %}

#### 永远不要把你的 UI 锚定到左上角

最常见的布局错误是把面板固定在左上角，或者把它放在一个覆盖整个屏幕的根节点原点位置。那个角落，以及整条左边缘，正是 explorer 绘制自己的小地图和聊天区域的地方，而在移动端则是虚拟摇杆。放在那里的场景 UI 仍然会渲染，但客户端自己的 UI 会盖在它上面，因此最终被遮住，而且按钮往往无法点击。布局引擎不会就此向你发出任何警告。

请改用以下方式之一：

* **锚定到右侧，或将元素居中。** 对于分数、计时器或小面板，请设置 `positionType: 'absolute'` 和 `position: { top: 40, right: 40 }`，或者使用 `justifyContent: 'center'` 在根节点上将其居中。
* **让 explorer 告诉你哪里是安全的。** 设置 [`screenInset: 'interactable'`](/creator/content-creator-zh/chang-jing-sdk7/2d-ui/onscreen-ui.md#screen-inset-area) 在渲染器上。然后你的 UI 会被放置在 explorer 为场景 UI 预留的矩形中，而该区域已经排除了小地图、聊天和左侧控制项。

```ts
ReactEcsRenderer.setUiRenderer(uiComponent, { screenInset: 'interactable' })
```

在移动端，右下角的动作按钮会故意绘制在该区域上方，此处的点击会传给客户端按钮，而不是你的场景。请将交互元素放在右下角之外，或者，如果你的 UI 本来就要接管整个屏幕，在它打开时隐藏触控控制：

```ts
import { TouchScreenControls } from '@dcl/sdk/ecs'

// 当全屏面板打开时，玩家不需要跳跃或按 E
TouchScreenControls.hideAll()
TouchScreenControls.hideJoystick()

// 面板关闭时恢复它们
TouchScreenControls.showAll()
TouchScreenControls.showJoystick()
```

这些辅助方法在桌面端不会产生任何作用，因此你可以无条件调用它们。参见 [屏幕控制](/creator/content-creator-zh/chang-jing-sdk7/jiao-hu-xing/touch-screen-controls.md).

始终把网格牢记在心，并在对 UI 进行空间组织时将其作为主要标准。如果你正在制作需要 HUD 的场景，可以先把所有消耗品放在一起（例如货币、食物、生命值），另一侧则放置工具或武器等可储备物品。尽量保持网格尺寸和内边距的一致性。让每个玩家操作的反馈都清晰明确。

### 颜色

选择一个配色方案很重要，因为这能赋予你的场景独特的身份，同时也能传达元素之间的关系与层级。

在组合配色方案时，先选择一个主色，并可选地再加一个辅助色。然后你需要决定该配色相对于主色是采用类似色、互补色还是三色配色等。

<figure><img src="https://2460066822-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FoPnXBby9S6MrsW83Y9qZ%2Fuploads%2Fgit-blob-90a514428232e163d5b6012aa8ab57371da92782%2Fux-color-wheel2.png?alt=media" alt="Chromatic color palette" width="300"><figcaption><p>有彩色配色方案</p></figcaption></figure>

<figure><img src="https://2460066822-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FoPnXBby9S6MrsW83Y9qZ%2Fuploads%2Fgit-blob-a557422ba97313b5ac752e934e90f55206640145%2Fux-color-wheel.png?alt=media" alt="Strategies for combining colors properly" width="300"><figcaption><p>正确组合颜色的策略</p></figcaption></figure>

{% hint style="info" %}
**💡 提示**：我们推荐的免费配色生成器： [Coolors](https://coolors.co), [Adobe Color CC](https://color.adobe.com/), [Colour Lovers](http://www.colourlovers.com), [Color Hunt](http://www.colorhunt.co), [Color by Hailpixel](http://color.hailpixel.com), [Colour Code](http://colourco.de), [Sip](https://sipapp.io/), [Paletton 的 Color Scheme Designer](http://paletton.com), [Cohesive Colors](http://javierbyte.github.io/cohesive-colors), [Colr](http://www.colr.org)
{% endhint %}

主色应当是 UI 组件中使用最频繁的颜色。如果你的配色没有辅助色，你可以将主色与黑色或白色组合来突出元素。辅助色并非必须，但它有助于强调并区分你的场景 UI 元素。辅助色最适合用于高亮、选择控件（滑块和开关）、链接和标题。

记住，每种颜色都有其独特的表现特质，要善于利用它们通过颜色传达信息。例如，红色通常与负面含义相关，而绿色通常与正面含义相关。

<figure><img src="https://2460066822-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FoPnXBby9S6MrsW83Y9qZ%2Fuploads%2Fgit-blob-39fa7214733c589571654b3b05067edae03d2353%2Fux-switches.png?alt=media" alt="Colored switches" width="300"><figcaption><p>错误地使用颜色会令人困惑</p></figcaption></figure>

你也可以策略性地使用颜色来表示状态变化，例如通过改变某个元素的颜色来表示它是激活还是未激活。

{% hint style="warning" %}
**📔 注意**：状态传达 UI 元素的状态。元素的状态应保持一定的连续性，但它们必须具有清晰的可供性，并且能与其他状态以及周围布局轻松区分。
{% endhint %}

<figure><img src="https://2460066822-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FoPnXBby9S6MrsW83Y9qZ%2Fuploads%2Fgit-blob-ccb8ecfe2c2b624018c96ecb9317c494c44dbeb9%2Fux-active-button.png?alt=media" alt="Active inactive button" width="300"><figcaption><p>用于按钮状态的颜色</p></figcaption></figure>

警告！当选择将叠加显示的颜色时，要特别注意确保它们一起使用时仍然清晰可读。这里有一条基本规则：一起显示的元素颜色之间应始终保持足够的对比度。请注意，有些玩家可能是在不理想的光照条件下看屏幕，这会增加阅读难度。

<figure><img src="https://2460066822-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FoPnXBby9S6MrsW83Y9qZ%2Fuploads%2Fgit-blob-febc1a60718f42d58120c40515664253cf09a363%2Fux-icons.png?alt=media" alt="Icon contrast" width="300"><figcaption><p>这两个图标都可以区分，但第一个对比度更好。它更易读，也更省力去理解。</p></figcaption></figure>

### 排版层级

尽量为标题、副标题和正文定义至少 3 个字号层级。注意颜色和字体大小的使用。所有字体大小都应为 12 px 或更大。

如果你要放置显示在图像上方（或世界之上）的文本，你肯定需要反复测试其可读性。在这种情况下，我们建议你在文本和图像之间的层中添加一块有颜色的纯色区域，这样可以确保文本保持可读。

<figure><img src="https://2460066822-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FoPnXBby9S6MrsW83Y9qZ%2Fuploads%2Fgit-blob-9a277a4a94c7904455781552939bac4bf90c0403%2Fux-text-over-images.png?alt=media" alt="Text over images" width="300"><figcaption><p>优先保证可读性</p></figcaption></figure>

### 图标

图标能综合信息，通过图像帮助你识别操作。与使用文字标注事物相比，它们是极其强大的工具，能够快速传达可理解的输入，从而减少玩家需要投入的注意力和时间。将图标与文字结合展示也很有用，因为这有助于消除歧义。

<figure><img src="https://2460066822-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FoPnXBby9S6MrsW83Y9qZ%2Fuploads%2Fgit-blob-cdcdf8db8cd023d3550881b30f3ab56dc818ac9d%2Fux-icons2.png?alt=media" alt="Icon examples" width="300"><figcaption><p>将图标作为一种通用语言</p></figcaption></figure>

### 运动

在需要时，用动效提供反馈并引导方向。动效有助于玩家集中注意力，并在 UI 变化时维持连续性。

<figure><img src="https://2460066822-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FoPnXBby9S6MrsW83Y9qZ%2Fuploads%2Fgit-blob-0a13840d235b318e369b3dc11ea4272633b8c0b4%2Fux-glow.png?alt=media" alt="Adding glow" width="300"><figcaption><p>使用粒子、缩放或渐隐边距让内容更醒目</p></figcaption></figure>

### 文案与内容结构

UI 文本可以让界面更易用，也能让玩家更有信心地操作。始终尽可能让 UI 文本简洁。玩家是来玩的，不是来读长篇文字的。任何看起来太长的文本，大多数玩家都不会读。

用欢迎信息迎接玩家，并告诉他们场景的目标。先明确他们在场景中的目标，然后说明实现目标所需的操作。接着你可以在需要时逐步揭示信息，这样玩家在体验一开始就不会感到不知所措。与图形资源一样，尽量在 UI 功能和叙事中使用一致的措辞。

#### 展示，而不是讲述

以下两种模式会让玩家在首次交互前流失：

* **规则弹窗**：一个包含多段密集段落的介绍面板，覆盖所有机制、计分规则和控制方式。玩家会直接关闭而不阅读。
* **场景内规则手册**：场景中的标牌或公告板上写着同样的段落。它看起来像设计的一部分，但场景内文字太小、太长，无法阅读，而玩家也不会站着不动去眯眼看它。

把介绍面板控制在一个无需滚动的屏幕内：3 到 5 行短句，理想情况下，一行写目标，一行写控制方式，再加一张图片。标牌应该只说一件事，不超过 10 个词，使用较大的字号，并且一个想法对应一块标牌。

然后把其余内容改为展示，而不是书写：

* 让第一个目标一目了然。把一个发光、会动或夸张放大的物体放在玩家最初视线中。脉冲式描边比一句话更能教会玩家“点击我”。
* 在正式游戏开始前，先让玩家在练习区安全地操作一次机制。
* 使用 `hoverText` 在交互实体上作为即时说明。它会在恰当相关时出现，前置阅读成本为零。参见 [悬停反馈](/creator/content-creator-zh/chang-jing-sdk7/jiao-hu-xing/an-niu-shi-jian/register-callback.md#hover-feedback).
* 对于空间或顺序规则，使用图示。“红宝石 = 1，蓝宝石 = 5”的图示可以替代一整段文字。
* 任何更长的内容都应一次只通过一条消息传达，可借助 NPC 或玩家可以跳过的对话。

如果一条规则需要比这更多的文字，那就重新设计机制，或者把它可视化。

### 物体交互

确保玩家能分辨哪些物体可交互，哪些不可交互。在实体上注册按钮事件时，SDK 默认会显示悬停反馈：实体边缘高亮，并在光标旁显示提示，说明应使用哪种输入，还可以自定义文字来描述交互效果。我们强烈建议使用它，这会让你的场景感觉更自然，也更易用。参见 [悬停反馈](/creator/content-creator-zh/chang-jing-sdk7/jiao-hu-xing/an-niu-shi-jian/register-callback.md#hover-feedback).

### 第三人称摄像机

玩家可以随时按下 ‘V’ 键，在第一人称和第三人称摄像机之间切换。设计你的场景时，应确保交互在这两种模式下都能舒适地进行：例如，小的点击目标在第三人称下更难命中。你的场景可以读取玩家当前的摄像机模式，或者在某个区域强制使用特定模式，参见 [摄像机](/creator/content-creator-zh/chang-jing-sdk7/3d-nei-rong-ji-chu/camera.md).


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation by asking a question.

Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters:

```
GET https://docs.decentraland.org/creator/content-creator-zh/chang-jing-sdk7/ti-yan-she-ji/ux-ui-guide.md?ask=<question>&goal=<user_goal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.