> 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/design-games.md).

# 设计游戏

为 Decentraland 设计游戏时需要注意的事项。

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

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

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

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

## 场景边界

**你的游戏必须完全位于 \_LAND**\_\*\* 之内，也就是你的场景所建立其上的区域。\*\* 对于小型场景，可以把它想成足球之类的游戏：即使玩家能够走出球场，游戏规则仍会把相关互动限制在一个封闭空间内。玩家可以走出场景边界，但任何属于该场景的资产或实体都必须留在场景内。

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

你也可以制作一款游戏，让它分布在多个彼此不相连、玩家并不知道其存在的地块上，而探索世界的其余部分会成为游戏玩法的一部分。这样的游戏将由多个独立的 *场景*组成，它们可以通过服务器彼此共享数据。

如果你的游戏发布到一个 [Decentraland World](https://github.com/decentraland/docs/tree/main/creator/worlds/about.md)，你就能更好地控制玩家在你的场景边界之外看到什么。World 通常会被自动生成的草地、树木和海洋景观所环绕，不过你可以 [禁用此景观](/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/lian-wang/serverless-multiplayer.md)。采用这种方式时，状态变化不会存储在任何地方：如果当前没有玩家在场景附近并加载它，那么下次加载时，场景将重置为默认状态。

**你也可以使用服务器来存储有关你场景的信息，并让所有玩家与之保持同步。** 这样即使附近没有玩家，场景状态也能保持一致且持久，并且你可以验证更改，从而防止玩家作弊。推荐的方案是使用 [多人服务器](/creator/content-creator-zh/chang-jing-sdk7/lian-wang/authoritative-servers.md)，它会作为你发布场景流程的一部分由 Decentraland 为你托管和部署。你也可以托管 [你自己的服务器](/creator/content-creator-zh/chang-jing-sdk7/lian-wang/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 时看到的默认覆盖式界面只有最基本的内容。** 当玩家在你的场景中时，你可以向该界面添加额外元素。请记住，Decentraland 的默认界面显示在你场景中的任何内容之上，因此设计界面时不要与之重叠。

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

## 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/mian-xiang-yi-dong-duan-gou-jian/kai-fa/input-on-mobile.md) ，了解面向移动端玩家时应优先选择什么。

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

## 头像

**玩家可以从一个庞大的可穿戴物品目录中打造自己的头像**，其中包括由 Decentraland Marketplace 上的社区创作者制作并出售的可穿戴物品。你的场景可以读取玩家正在穿戴的内容并作出响应，参见 [用户数据](/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/tou-xiang/avatar-animations.md).

## 游戏通知

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

## 使用区块链

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

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

### LAND 和 MANA

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

**玩家进入 Decentraland 前，也不需要事先拥有 Ethereum 钱包或 MANA 代币。** 如果你的玩法严重依赖于拥有代币，那么你会排除大多数玩家。免费增值（freemium）游戏模式可能是同时适配这两类用户群的理想方式。

### 其他 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 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/design-games.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.