设计游戏
在为 Decentraland 设计游戏时需要牢记的事项。
本文档介绍了在为 Decentraland 设计游戏时需要考虑的一些关键点。诸如其他场景的相邻关系以及 LAND 的分布式所有权等因素，使 Decentraland 成为一个独特的地方，要求你重新审视自己在以往游戏中可能形成的一些假设。
例如，你必须明白，与其他游戏平台不同，Decentraland 游戏并不是孤立存在的。你无法控制相邻场景中的内容，也无法控制某些细节，比如玩家的头像或他们可能从其他游戏中带入的物品。这为令人兴奋的可能性打开了大门，同时也要求你以不同的方式思考游戏机制。
目前主流游戏中最接近的例子是 Roblox，在那里，社区用户生成的内容可以成为他人探索、游玩和互动的聚会场所。与 Roblox 不同，你不是通过浏览一组互不相关的体验菜单来导航场景，而是通过在一个所有场景彼此相邻的地形中实际探索来移动。Decentraland 也使用区块链来管理土地、头像、资产等的所有权。
我们正在持续改进 SDK，因此以下某些限制可能会在未来更新中被移除。
场景边界
你的游戏必须完全位于 _LAND** 上，即你的场景所构建的土地上。** 对于小型场景，可以把它理解为足球这类游戏：尽管玩家能够走出球场，游戏规则仍会把相关互动限制在一个封闭空间内。玩家可以走出场景边界，但任何属于该场景的资产或实体都必须留在场景范围内。
走出你场景边界的玩家，只要场景仍在可见范围内，就会继续渲染它。如果他们走得太远，就会完全停止渲染。
你也可以设计一种游戏，分布在多个彼此不相连、玩家并不知晓的地块上，而对世界其余部分的探索成为玩法的一部分。这样的游戏会由多个彼此独立的 场景组成，并且这些场景可以通过服务器彼此共享数据。
如果你的游戏发布到 Decentraland World，那么你对玩家在场景边界之外看到的内容拥有更多控制权。World 周围通常会自动生成草地、树木和海洋景观，但如果 关闭此景观 会与你的游戏设定冲突，例如发生在开阔水域或太空中的游戏。
用户库存
目前还没有一种库存系统，能让玩家在场景之间移动时存放游戏物品。 目前可用的替代方案如下：
你可以在场景本身中存储库存信息，并将其与每个玩家的 Ethereum 地址关联（这可以用作持久化 ID）。这些信息只能从你的场景中读取。
你可以使用外部自定义存储，并将所有场景与之同步。这是一种更稳健的方案，能够处理更大规模的玩家数量。它还可以将此库存的访问扩展到你或其他人拥有的多个独立场景。
使用区块链中的代币来处理物品所有权。
当获得某个游戏物品时，它可以作为一个特殊代币存储在玩家的 Ethereum 钱包中。当持有该代币的玩家进入你的场景时，你的场景可以在游戏中赋予该玩家某些特性。
其他场景也可能以不同方式响应同一个代币，这会让不同游戏之间产生有趣的互动。
使用区块链存储库存物品的缺点是，所有交易对玩家都有成本，而且不是即时生效。有关区块链的更多内容，请参见下方的专门章节。
在未来版本中，玩家将拥有一个可随身携带的库存，其中包括链上和链下资产。
可携带体验
可携带体验是玩家在穿越元宇宙时随身带走的游戏玩法部分。它们不绑定到土地地块，有时绑定到代币，有时则由探索者触发。例如，玩家可以从你的场景中拿起一个雪球，走到另一个场景，再把雪球扔向另一位也在玩同一游戏的玩家。
智能穿戴物是一种可携带体验，它绑定到可穿戴代币，并在玩家穿上该服装时被激活。智能穿戴物可以赋予玩家新的能力，比如让他们飞行的喷气背包，或者在整个 genesis city 中随机放置可收集金币，从而在世界其他内容之上增加一层新的内容。
请记住，玩家在你的场景中时，可能正在使用别人的可携带体验。参见 用户数据 了解如何检查玩家当前已激活了哪些可携带体验。
游戏持久性
Decentraland 是一个持久化世界，你的场景可在任何时间被玩家访问。 你的场景没有启动阶段，也没有结束，因此你应当以一种允许随时进入或退出的玩家也能参与的方式来设计游戏机制。
你的场景可以有一个重置机制，将其恢复到初始状态，但你应谨慎避免打断已经在游玩的玩家。
同步场景状态
默认情况下，场景状态不会在玩家之间共享。 每个玩家都会运行自己本地的场景副本。这是构建场景的最简单方式，但并不适合社交体验。
在玩家之间共享状态的最简单方法，是使用 syncEntity 函数将实体标记为已同步。参见 无服务器多人游戏。采用这种方法时，状态变化不会存储在任何地方：如果当前没有玩家在场景附近加载它，那么下次加载时场景会重置为默认状态。
你也可以使用服务器来存储有关你场景的信息，并让所有玩家与之保持同步。 这样即使周围没有玩家，场景状态也能保持一致和持久，并且你可以验证变更，从而防止玩家作弊。推荐的方案是使用一个 多人服务器，它由 Decentraland 在你发布场景时为你托管和部署。你也可以托管 你自己的服务器，这样你就可以将某些信息，例如安全令牌，仅保留在服务器端，绝不向外暴露。
游戏时序
使用默认通信架构的游戏应当考虑到玩家之间可能存在延迟 ，因此不应依赖不同玩家动作之间的快速反应。我们推荐回合制游戏，或者主要基于玩家对环境交互的游戏。
对于玩家之间动作时序至关重要的游戏，例如第一人称射击游戏，你应该实现自己的服务器，作为你场景中所有玩家之间实时的权威真相来源。
场景中的玩家
在 Decentraland 中，玩家通过其 Ethereum 钱包地址来识别。 这个钱包被用作一个持久 ID，并且已经关联到玩家拥有的所有代币。
目前没有办法限制 Decentraland 中同一时间能有多少玩家存在。 不同于许多其他游戏，在这些游戏中，可能会有在独立服务器上托管的不同游戏会话；至少目前，所有玩家共享的 Decentraland 只有一个实例。
你需要记住，在任何给定时刻，可能会有多个玩家在你的场景中走动。其中一些可能只是路过，并不参与游戏。请确保游戏机制不会因此而轻易被破坏。
你场景的游戏循环不能直接影响玩家，场景会对玩家的动作采取响应式处理。如果玩家站在一个实体上，而该实体移动或旋转，玩家也会随之移动。这对于电梯、浮动平台等尤其有用。
作为场景的所有者，你不能强行将违规玩家推离或传送出你的场景。不过，你可以在信令服务器中将玩家列入黑名单。你也可以在场景代码中实现黑名单，并向黑名单中的玩家拒绝某些服务。
场景内容限制
请在构建场景时格外注意代码效率。 Decentraland 需要在网页浏览器和移动设备上运行，而且当玩家穿行于元宇宙时，会同时渲染多个场景。
你还应该尽量保持场景轻量。 与其他在线游戏不同，在那些游戏中相同的纹理和资产会在一个庞大的开放世界中被方便地重复使用，而在 Decentraland 中，每个场景都可能拥有自己完全不同的一套资产。随着玩家穿越多个场景，他们应该能够以合理的速度下载完整的场景内容，包括纹理、声音文件等。
因此，我们施加了一些限制，以防止对计算资源的过度使用。参见 场景限制 了解这些限制的具体内容。
访问场景
Decentraland 的地图经过设计，包含道路和公共广场， 这些确保了无论其他人如何建造，都能轻松到达地图的各个部分。那些不与任何道路或广场相邻的土地地块，存在被邻近场景围堵的风险，尽管我们预计大多数场景都可以步行进入，并且不会阻挡其他场景。
新玩家将在地图中心的 Genesis Plaza 开始他们的体验，在那里他们会被鼓励先完成一些教程活动，然后再去探索世界。
玩家也可以手动输入 Decentraland 地图中某个特定坐标的 URL，以在该位置生成。你也可以分享带有硬编码初始坐标的 URL 链接。
请记住，如果玩家从一个被围堵的位置，或者低于地形高度的位置开始，体验就不会愉快。为避免这种情况，你可以定义一组在你的场景中适合安全生成的特定位置。参见 场景元数据 了解详情。
玩家还可以使用地图以及热门地点和活动列表快速浏览世界。你的场景可以包含传送点，将玩家传送到世界的其他部分，参见 传送.
用户界面
玩家进入 Decentraland 时看到的默认覆盖式 UI 只有最基本的内容。 当玩家位于你的场景中时，你可以向该 UI 添加额外元素。请记住，Decentraland 的默认 UI 会显示在你场景中的任何内容之上，因此请设计你的 UI，使其不会与之重叠。
当玩家走出场景时，所有 UI 元素都会被移除，以免干扰其他场景。玩家的屏幕上还有一个按钮，可将场景中的所有 UI 元素切换关闭，这主要用于防止某些可能试图遮住玩家全部视野的场景出现滥用行为。
物理
请记住，SDK 并未为实体提供完整的物理引擎。你可以对玩家头像施加力和冲量，参见 玩家物理。对于实体之间的物理效果，例如碰撞或重力，你可以导入一个库，或者自己编写该行为。
控制器输入
你的游戏控制应限制在 SDK 支持的输入动作集合内：移动键、跳跃、点击、主按钮（E）和次按钮（F），以及编号动作按钮（1 到 4）。这些输入与物理按键是抽象分离的，因此它们也可以映射到移动应用的屏幕控制或其他设备上，不要假设每个人都有键盘。参见 指针按钮 获取完整列表，以及 移动端输入 了解针对移动玩家时应优先考虑什么。
所有这些输入都同时支持全局 button up 和 button down 事件，以及命中事件，让你可以识别某个实体是否位于玩家的瞄准范围内。
头像
玩家可以从一个庞大的可穿戴物目录中构建自己的头像，其中包括由社区创作者在 Decentraland Marketplace 上创建和销售的可穿戴物。你的场景可以读取玩家正在穿戴的内容并作出响应，参见 用户数据.
玩家之间的通信
玩家可以彼此聊天、进行语音聊天，并通过播放表情来传达肢体语言 ，例如跳舞、鼓掌或挥手，其中也包括由社区创作者出售的表情。
你的场景可以检测到玩家何时播放表情，也可以让玩家的头像播放动画。参见 玩家播放动画 和 头像动画.
游戏通知
目前没有跨场景通知系统。 任何需要在当前场景之外显示通知的游戏，都必须使用外部服务来实现。
使用区块链
在 Decentraland 中，区块链用于存储所有权信息。 如今，这主要指 LAND 所有权，但它也可以用于存储游戏物品、可穿戴物、特殊头像、表情，以及可确保某些游戏特权或进入游戏权限的代币的所有权。
区块链不用于存储游戏状态、玩家位置，或任何需要实时变化的内容。
LAND 和 MANA
玩家不需要拥有任何土地地块就可以参与元宇宙。 事实上，绝大多数玩家都不会拥有。玩家头像与他们拥有的 LAND 代币之间没有任何直接关联。
玩家进入 Decentraland 并不需要事先拥有 Ethereum 钱包或 MANA 代币。 如果你的玩法严重依赖于拥有代币，那么你会把大多数玩家排除在外。freemium 游戏模式可能是同时面向这两类用户群体的理想方式。
其他 NFT
你可以使用特殊的非同质化代币（NFT）来表示游戏物品、自定义头像或可穿戴物。 如果玩家拥有这些代币之一，你的场景可以以不同方式响应它。
阅读关于 NFT 是什么的内容，请见 这篇博客文章.
游戏内交易
你的场景可以支持区块链交易，让玩家购买或赚取代币。
区块链交易不会立即完成，它们需要验证时间，并且需要以太币成本，所需时间和成本都会因当前网络使用情况而异。
Decentraland 使用 Polygon 侧链来比 Ethereum 网络更快、更便宜地处理交易。这条侧链非常适合游戏内交易，因为变更可以更接近实时发生，而且成本非常低。对于需要更高安全性且可以承受更高费用和更长耗时的交易，仍然建议使用主 Ethereum 链。参见 第二层.
玩家必须始终在其 Ethereum 客户端上明确批准这些交易。例如在使用 Metamask 时，Metamask 会在每笔交易被处理前提示玩家接受该交易。
玩家也可以签署一个合约，自动批准来自特定地址或在某些约束条件内请求的所有交易，从而避免在批准交易时受到打断。
你也可以使用智能合约根据自定义条件来限制交易。例如，玩家可以对某场游戏的结果下注，而一旦结果已知，相应付款就会自动发生。
要在你的场景代码中实现区块链交互，你必须使用与 Ethereum 网络接口的外部库。SDK 的未来版本将提供一个自定义 API，以更简单的方式暴露这些功能。
最后更新于