> 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/she-ji-ti-yan/design-games.md).

# 设计游戏

为 Decentraland 设计游戏时你需要牢记的事项。

本文概述了在为 Decentraland 设计游戏时需要考虑的一些关键点。诸如其他场景的邻接关系以及 LAND 的分布式所有权等因素，使 Decentraland 成为一个独特的地方，也要求你重新审视以往游戏中的一些假设。

例如，你必须明白，与其他游戏平台不同，Decentraland 游戏并不是孤立存在的。你无法控制相邻场景中的内容，也无法控制某些细节，比如玩家的头像或他们可能从其他游戏中带入的物品。这为令人兴奋的可能性打开了大门，也要求你用不同的方式思考游戏机制。

目前主流游戏中最接近的例子是 Roblox，在那里，社区中由用户生成的内容可以成为他人探索、游玩和互动的聚集地。与 Roblox 不同的是，你并不是通过浏览一堆彼此无关的体验菜单来导航场景，而是通过实际探索一个所有场景彼此相邻的地形来进行。Decentraland 也利用区块链来管理土地、头像、资产等的所有权。

我们正在持续改进 SDK，因此下面的一些限制可能会在未来更新中被移除。

## 场景边界

**你的游戏必须完全适配其所构建于其上的 \_LAND**\_\*\*。对于小型场景，可以把它想象成足球这类游戏，游戏规则会把相关交互限制在一个封闭空间内，尽管玩家可以走出球场。玩家可以走出场景边界，但任何属于场景的资源或实体都必须留在场景内。

走出你场景的玩家，只要还在可见范围内，仍会继续渲染该场景。如果他们走得太远，便会完全停止渲染。

你也可以构建一种游戏，它分布在多个彼此断开、玩家并不知道的土地区块上，而探索世界的其余部分也会成为游戏玩法的一部分。这样的游戏会由多个独立的 *场景*组成，这些场景可以通过服务器彼此共享数据。

如果你的游戏发布到一个 [Decentraland 世界](https://github.com/decentraland/docs/tree/main/creator/worlds/about.md)，你就能更好地控制玩家在你场景边界之外看到的内容。世界通常会被自动生成的草地、树木和海洋景观所包围，但如果 [禁用这种景观](/creator/content-creator-zh/chang-jing-sdk7/xiang-mu-lei-xing/scene-metadata.md#landscape-terrain) ，例如你的游戏背景与之冲突时，比如发生在开阔水域或太空中的游戏。

### 用户库存

**目前还没有库存系统供玩家在场景之间移动时存放游戏物品。** 目前可用的替代方案如下：

* 你可以将库存信息存储在场景本身中，并将其关联到每位玩家的 Ethereum 地址（这可以作为持久 ID）。这些信息只能在你的场景中读取。
* 你可以使用外部自定义存储，并将所有场景同步到其中。这是一个更稳健的解决方案，可以应对更大量的玩家。它还可以把这个库存的访问扩展到你或他人拥有的多个独立场景。
* 使用区块链中的代币来处理物品所有权。

当获得某个游戏物品时，它可以作为一种特殊代币存储在玩家的 Ethereum 钱包中。当持有该代币的玩家走进你的场景时，你的场景可以在游戏中赋予该玩家某些特性。

其他场景也可能以不同方式对同一个代币作出响应，这会让游戏之间产生有趣的联动。

使用区块链存储库存物品的缺点是，所有交易对玩家来说都有成本，而且不会立刻完成。关于区块链的更多内容请参见下方专门章节。

在未来版本中，玩家将拥有一个随身携带、可在各处使用的库存，其中既包括链上资产，也包括链下资产。

### 可携带体验

{% hint style="info" %}
**💡 提示**：参见 [可携带体验](/creator/content-creator-zh/chang-jing-sdk7/xiang-mu-lei-xing/portable-experiences.md) 和 [智能穿戴](/creator/content-creator-zh/chang-jing-sdk7/xiang-mu-lei-xing/smart-wearables.md) 了解如何创建这些内容。
{% endhint %}

可携带体验是玩家在穿越元宇宙时随身带走的游戏内容。这些内容不绑定于土地区块，有时会绑定于代币，或者有时由探索者自行触发。例如，玩家可以从你的场景中拿起一个雪球，走到另一个场景，然后把雪球扔向另一个也在玩同一游戏的玩家。

智能穿戴是一种可携带体验，它绑定到可穿戴代币上，当玩家穿上该服饰时便会激活。智能穿戴可以赋予玩家新的能力，比如让他们飞行的喷气背包，或者在世界其他部分之上增加一个新的内容层，比如在整个 Genesis City 中随机放置可收集的金币。

请记住，玩家在你的场景中时，可能正在使用别人的可携带体验。参见 [用户数据](/creator/content-creator-zh/chang-jing-sdk7/jiao-hu-xing/user-data.md#get-portable-experiences) ，了解如何检查玩家当前已激活了哪些可携带体验。

## 游戏持久性

**Decentraland 是一个持久世界，你的场景可在任何时间被玩家访问。** 你的场景没有启动阶段和结束阶段，因此你应以一种能让任何时刻进出场的玩家都能参与的方式来设计游戏机制。

你的场景可以有一个重置机制，将其恢复到初始状态，但你应小心不要打断已经在玩的玩家的游戏。

### 同步场景状态

**默认情况下，场景状态不会在玩家之间共享。** 每位玩家都运行自己本地的场景副本。这是构建场景最简单的方法，但对于社交体验来说并不理想。

在玩家之间共享状态最简单的方法，是使用 `syncEntity` 函数中来确保场景加载完成后再执行。参见 [无服务器多人游戏](/creator/content-creator-zh/chang-jing-sdk7/wang-luo/serverless-multiplayer.md)将实体标记为同步。采用这种方法时，状态更改不会存储在任何地方：如果当前没有玩家在场景附近加载它，那么下次加载时场景将重置为默认状态。

**你也可以使用服务器来存储关于你场景的信息，并让所有玩家与其保持同步。** 即使周围没有玩家，这也能保持场景状态一致且持久，并让你验证变更，从而防止玩家作弊。推荐使用 [多人服务器](/creator/content-creator-zh/chang-jing-sdk7/wang-luo/authoritative-servers.md)，它由 Decentraland 在你发布场景时为你托管并部署。你也可以托管 [自己的服务器](/creator/content-creator-zh/chang-jing-sdk7/wang-luo/third-party-servers.md)，这样你就可以把某些信息，比如安全令牌，仅保留在服务器上，而不会在外部暴露。

### 游戏时序

**使用默认通信架构的游戏应考虑到玩家之间可能会有延迟，** 并且不应依赖不同玩家行为之间的快速反应。我们建议采用回合制游戏，或主要基于玩家对环境交互的游戏。

对于玩家之间动作时序至关重要的游戏，例如第一人称射击游戏，你应该实现自己的服务器，作为你场景中所有玩家之间实时的权威事实来源。

## 场景中的玩家

**在 Decentraland 中，玩家通过其 Ethereum 钱包地址来识别。** 该钱包被用作一个持久 ID，并且已经与玩家拥有的所有代币关联。

**目前无法限制 Decentraland 中同一时间可存在的玩家数量。** 与许多其他游戏不同，在那些游戏中可能由不同服务器托管不同的游戏会话，而在这里，至少目前，所有玩家共享的 Decentraland 只有一个实例。

你需要记住，随时可能有多个玩家在你的场景中走动。其中一些人可能只是路过，并不参与游戏。确保游戏机制不会因此被轻易破坏。

**你场景的游戏循环不能直接影响玩家**，场景对玩家的动作采用的是响应式方式。如果玩家站在某个实体上，而该实体移动或旋转，玩家也会随该实体移动。这对于电梯、悬浮平台等特别有用。

作为场景所有者，你不能强行把违规玩家推出或传送出你的场景。不过，你可以在信令服务器中将玩家列入黑名单。你也可以在场景代码中实现黑名单，并对黑名单玩家拒绝某些服务。

## 场景内容限制

**请务必在构建场景时格外注意代码效率。** Decentraland 需要在网页浏览器和移动设备上运行，玩家在穿越元宇宙时会同时渲染多个场景。

**你也应尽量保持场景轻量。** 与其他在线游戏不同，在那些游戏中，相同的纹理和资源会在一个大型开放世界中方便地重复出现，而在 Decentraland 中，每个场景都可能拥有一整套完全不同的资源。随着玩家穿越多个场景，他们应能够以合理速度下载整个场景内容，包括纹理、音频文件等。

因此，我们设置了一些限制，以防止对计算资源的过度使用。有关这些限制的详情请参见 [场景限制](/creator/content-creator-zh/chang-jing-sdk7/you-hua/scene-limitations.md) 。

## 场景访问

**Decentraland 的地图经过设计，包含道路和公共广场，** 无论其他人如何建造，这些都能确保地图各部分易于到达。那些不与任何道路或广场相邻的土地区块有可能被邻近场景围挡，不过我们预计大多数场景都可以步行到达，并且不会阻挡其他场景。

新玩家将从地图中心的 Genesis Plaza 开始体验，在那里他们会被鼓励先完成一些教程活动，然后再去探索世界。

玩家也可以手动输入 Decentraland 地图中某个特定坐标的 URL，以在该位置生成。你也可以分享带有硬编码初始坐标的 URL 链接。

请记住，如果玩家从一个被围挡的地点，或者低于地形高度的位置开始体验，这不会是愉快的经历。为了避免这种情况，你可以在场景中定义一组可安全生成的特定位置。参见 [场景元数据](/creator/content-creator-zh/chang-jing-sdk7/xiang-mu-lei-xing/scene-metadata.md) 了解详情。

玩家也可以通过地图以及热门地点和活动列表快速导航世界。你的场景可以包含将玩家传送到世界其他部分的传送门，参见 [传送](/creator/content-creator-zh/chang-jing-sdk7/jiao-hu-xing/external-links.md#teleports).

## 用户界面

**玩家进入 Decentraland 时看到的默认覆盖式 UI 只有最基本的内容。** 当玩家在你的场景中时，你可以为该 UI 添加额外元素。请记住，Decentraland 的默认 UI 显示在你场景的任何内容之上，因此设计你的 UI 时不要与其重叠。

当玩家走出场景时，所有 UI 元素都会被移除，以免干扰其他场景。玩家屏幕上也有一个按钮，可以切换关闭场景中的所有 UI 元素，这主要用于防止某些场景通过覆盖玩家整个视野而产生滥用行为。

## Physics

请记住，SDK 并未为实体提供完整的物理引擎。你可以对玩家的头像施加力和冲量，参见 [玩家物理](/creator/content-creator-zh/chang-jing-sdk7/jiao-hu-xing/player-physics.md)。对于实体之间的物理效果，如碰撞或重力，你可以导入一个库，或者自行编写行为代码。

## 控制器输入

**你的游戏控制应仅限于 SDK 支持的一组输入操作**：移动键、跳跃、点选、主按钮（E）和次按钮（F），以及编号动作按钮（1 到 4）。这些输入与物理按键是抽象分离的，因此也可以映射到移动应用的屏幕控制或其他设备，不要假设每个人都有键盘。完整列表请参见 [指针按钮](/creator/content-creator-zh/chang-jing-sdk7/jiao-hu-xing/an-niu-shi-jian/click-events.md#pointer-buttons) ，而 [移动端输入](/creator/content-creator-zh/wei-yi-dong-duan-gou-jian/kai-fa/input-on-mobile.md) 则说明了面向移动端玩家时应优先使用什么。

所有这些输入都同时支持全局 *按钮抬起* 和 *按钮按下* 事件，以及命中事件，让你识别某个实体是否在玩家的瞄准范围内。

## 头像

**玩家可以从大量可穿戴物品目录中构建自己的头像**，其中包括由社区创作者在 Decentraland 市场中创建并出售的可穿戴物品。你的场景可以读取玩家穿着的内容并对此作出反应，参见 [用户数据](/creator/content-creator-zh/chang-jing-sdk7/jiao-hu-xing/user-data.md#get-player-data).

## 玩家之间的通信

**玩家可以彼此聊天、进行语音聊天，并通过播放表情动作来传达肢体语言** ，例如跳舞、鼓掌或挥手，包括由社区创作者出售的表情动作。

你的场景可以检测玩家何时播放表情动作，也可以让玩家的头像播放动画。参见 [玩家播放动画](/creator/content-creator-zh/chang-jing-sdk7/jiao-hu-xing/event-listeners.md#player-plays-animation) 和 [触发表情动作](/creator/content-creator-zh/chang-jing-sdk7/jiao-hu-xing/player-avatar.md).

## 游戏通知

**目前还没有跨场景通知系统。** 任何需要在当前场景之外显示通知的游戏，都必须使用外部服务来实现。

## 使用区块链

**在 Decentraland 中，区块链用于存储所有权信息。** 如今这主要指 LAND 所有权，但它也可用于游戏物品、可穿戴物品、特殊头像、表情动作以及代币的所有权，这些都可以确保某些游戏特权或进入游戏的权限。

区块链不会用于存储游戏状态、玩家位置或任何需要实时变化的内容。

### LAND 和 MANA

**玩家不需要拥有任何土地区块就能参与元宇宙。** 事实上，绝大多数玩家都不会拥有。玩家头像和他们拥有的 LAND 代币之间没有任何直接联系。

**玩家进入 Decentraland 不需要事先拥有 Ethereum 钱包或 MANA 代币。** 如果你的玩法过度依赖代币所有权，你会把大多数玩家排除在外。免费增值游戏模式可能是同时适配这两类用户群体的理想方式。

### 其他 NFT

**你可以使用特殊的非同质化代币（NFT）来表示游戏物品、自定义头像或可穿戴物品。** 如果玩家拥有这些代币之一，你的场景可以以不同方式对其作出响应。

阅读关于 NFT 是什么的内容，请参见 [这篇博客文章](https://decentraland.org/blog/technology/what-are-nfts/).

### 游戏内交易

**你的场景可以支持玩家通过区块链交易来购买或赚取代币。**

区块链交易不会立即完成，它们需要验证时间，并且会产生 Ether 成本，所需时间和成本都会根据当前网络使用情况而变化。

Decentraland 使用 Polygon 侧链来比 Ethereum 网络更快、更便宜地处理交易。该侧链非常适合游戏内交易，因为变更可以更接近实时发生，而且成本非常低。对于需要更高安全性且能够承担更高费用和更长时间的交易，仍然建议使用主 Ethereum 链。参见 [第二层](/creator/content-creator-zh/chang-jing-sdk7/qu-kuai-lian/second-layer.md).

玩家必须始终在其 Ethereum 客户端中明确批准这些交易。例如在使用 Metamask 时，Metamask 会在处理每笔交易前提示玩家接受。

玩家也可以签署一个合约，自动批准来自特定地址或在某些约束条件下请求的所有交易，从而避免为批准交易而中断。

你也可以使用智能合约，根据自定义条件来约束交易。例如，玩家可以就游戏结果下注，而一旦结果确定，对应的付款就会自动发生。

要在你场景的代码中实现区块链交互，你必须使用与 Ethereum 网络交互的外部库。SDK 的未来版本将提供一个自定义 API，以更简单的方式暴露这些功能。


---

# 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 dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter:

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

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal.

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.