> 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/mvp-guidelines.md).

# MVP 指南

使用 SDK 制作你的第一个 MVP 场景或体验的推荐指南

本文档的目的是帮助你了解在 Decentraland 中构建场景的首批迭代过程。我们将其称为最小可行产品（MVP）。

**在为你的场景创建最小可行产品（MVP）时，你需要考虑两个重点领域：**

1. 项目的基本用户体验和功能。
2. 创建一个基础“流水线”，或团队工作流程和内容管理系统，用于构建你的体验并对其进行迭代改进。

MVP 不应试图展示每一种可能体验的所有可能结果。相反，MVP 应该是你使用 Decentraland 的 SDK 所能做出的、对你的体验的最佳第一印象。

重要的是要考虑你自身的局限、你打算如何向用户提供内容，以及用户的期望。以这种方式推进你的 MVP 需要三个不同的视角：

1. 作为开发者或制作人，我如何向我的用户/玩家交付一种体验？
2. 作为用户或玩家，我对这种体验有什么期望？
3. 作为贡献者或利益相关者，我如何为流水线或体验做出贡献？

重要的是要将这种方法与传统的敏捷开发区分开来，因为为了实现你的设计目标，你可能不得不使用并非最优的方法。

你必须结合用户的期望来审视自己的目标，以决定某个版本更侧重于玩家、流水线和内容贡献者，还是两者兼顾但程度都不高。

在规划每个版本时，至关重要的是你要根据这三个视角有意识且有目的地设定优先级。

你可以预期你的开发待办事项会沿着两条线推进：

* 你希望创建的用户体验待办事项。
* 开发构建交付流水线所需的工具和界面。（或者，也可以优化你现有的流水线，以服务贡献者以及你的开发团队。）

这两条线也将遵循两种不同的测试方法：

* 测试你的用户体验更接近传统的用户界面测试，而且不需要相同的脚本资源。
* 测试你的工具和流水线界面将需要更多技术资源。

你越早能将价值主张呈现在用户或玩家面前，就越早能获得反馈来确认或否定该主张。快速确认价值至关重要。许多经验丰富的开发者都会分享这样的故事：他们曾坚信某个新机制会无比出色，直到实际使用后才发现它笨拙、卡顿，玩家完全没有反应，或者它并未解决用户的需求。你希望尽可能少地付出努力、快速失败，这样你就可以从失败中学习并规划下一次迭代。

怎样才能快速失败？只做让玩家接触到你的产品所需的最少工作。

## 最小可行产品的因素

以下是为你的基础 MVP 需要考虑的因素列表。你可以说明你会先用某样东西作为占位符，然后随着你开发出更稳固的替代方案再将其替换掉。

1. 美术创建
   * 首先，从基础静态图像开始
   * 你的第一次测试应该是风格测试：你所选择的风格是否吸引你的用户？
   * 这可以作为提供给外包艺术家的风格指南的起点
2. 场景创建
   * 发展出对你的空间的基本感知
   * 玩家应当感觉自己置身于一个全新、独特的空间中
   * 将你的空间与相邻空间区分开来
   * 边界清晰且明显——哪怕只是通过一条画出来的线
   * 用静态内容/美术覆盖整个区域
3. 场景中渲染的美术
   * 使用广告牌也可以，或其他标识（这可以只是实际的广告牌，或者更复杂的朝向摄像机的精灵图）
   * 确立你空间的基调和美学（即风格、明亮、昏暗）
   * 记录你的流程：美术是如何创建并部署到场景中的？
   * 你希望如何组织你的美术文件以便反复部署？
4. 玩家体验
   * 玩家能够访问你的空间/场景
   * 玩家可以区分你的空间与相邻空间
5. 流水线目标
   * 部署示例静态场景：不与玩家交互
   * 部署动画场景：例如喷水池或飘动的旗帜会循环播放动画
   * 部署交互式场景：包括玩家参与
   * 通过重新部署内容来演示部署流水线：从美术创建到场景内呈现，包括脚本编写 + QA]
   * 暴露流水线缺口：识别特定内容部署领域中的未知项

## 原型层级

快速失败使你能够通过创建连续的原型来开发体验，每一次迭代都建立在前一次之上。

**从单人玩家原型开始。然后你可以规划多人交互的脚本。最后，你可以着手构建能展示事务层的持久核心循环。**

**什么是持久核心循环？**

在游戏设计中，持久核心循环是驱动玩家行为及游戏对这些行为作出响应的基础“游戏循环”。这种持久循环也适用于任何形式的虚拟体验（例如 Districts 提供的体验）。

**什么是事务层？**

事务层是系统之间的接口，例如区块链更新，或其他与你的体验对接的应用，用于维护玩家行为的持久记录。创建并维护这份持久记录，正是打造更个性化体验的关键。

我们建议你将 MVP 制作为单人体验。

例如，你可以设计一个具有以下连续体验的场景：

* 单个玩家可以进入世界。
* 玩家可以在场景中与一两个简单实体互动。
* 其他玩家可以加入，并与世界及其他玩家互动。
* 最后，你可以加入记住每位玩家进入场景的能力，并跟踪玩家的事件和活动。

## 如何分享你的 MVP

我们建议在将场景的新版本上传到 Decentraland 之前，先与测试用户一起测试更改。你可以将你的场景发布到一个 [Decentraland 世界](/creator/content-creator-zh/chang-jing-sdk7/fa-bu/publishing-options.md#decentraland-worlds) ，通过链接分享它，而无需任何 LAND，并且不会影响生产中的内容。

## 其他考虑事项

一旦覆盖了基本用例，你就可以开始通过聚焦机制，让版本管理策略变得更复杂。 **机制** 是一个广义术语，涵盖玩家可以采取的所有动作，以及系统基于这些玩家动作所提供的响应。

**设备互操作性** 是需要注意的重要事项。你的场景用户可能会通过桌面设备、移动设备或 VR 头显访问场景。用户应当能够使用任一种设备相对良好地与你的场景交互。对于使用 VR 头显的用户，请尽量避免可能导致晕动症的眩晕式运动。

**音频** 是场景氛围的另一个关键方面。风声、蟋蟀声、远处的谈话声，甚至音乐等背景声音，都是增强沉浸感并提供语境的非常有力的方式。你还可以调整音量与声源距离之间的关系，以更强或更弱地强调声音的位置。

阅读 [游戏设计约束](/creator/content-creator-zh/chang-jing-sdk7/she-ji-ti-yan/design-games.md) 以详细了解其他一些注意事项。

将 MVP 视为你可以使用的众多原型之一，一旦你的流水线建立起来，它可帮助你确立版本发布的节奏。每个版本的重点可能不同，也可能是体验各方面的混合体。不过，你应当以逐步交付更复杂的体验为目标，让每次迭代都建立在前一次之上。

1. **MVP**：单人模式
2. **版本 2**：添加多人和/或交互支持
3. **版本 3**：引入你的第一个机制
4. **版本 4**：添加音频支持
5. **版本 5**：完成你的美术流水线

例如，假设我们正在为飞盘高尔夫游戏构建一个 MVP。这个 MVP 将包含球场的一些静态图像。玩家甚至可能能够以非常粗糙、方块风格的方式投掷飞盘。这让我们能够梳理出基础的投掷机制。下一次版本发布可能会加入多人支持的原型，这样我们就可以演示并测试两个用户同时登录并在我们的 LAND 上游玩。

请记住，尽管最终目标是一个真正沉浸式的 3D 世界，但你的 MVP 并不会从那里开始。尽可能快地将玩家带入你的世界，应当是你的首要目标。测试你的版本要以周而不是月来衡量，这对于在不浪费精力的情况下学习和迭代至关重要。

我们强烈建议你始终关注你的体验所呈现出的第一印象。一个空白的体验会让玩家感到失望。另一方面，一个包含一些初始内容和基本体验的场景，会让玩家看到未来可能性的潜力，并鼓励他们与你的社区互动并期待接下来的几个版本。

## 需要考虑的持久性因素

最终，你希望达到一种持久性水平，能够证明你的架构中的事务层是可运行的。事务性不仅限于玩家的行为，也包括系统对玩家的反应。

1. **账户信息**：登录名、时区、你特定体验/游戏的位置
2. **排行榜统计**：之前的游戏结果、全球/地区排名、竞赛
3. **身份验证**：Ethereum 钱包地址，或任何其他后端身份管理
4. **区块链更新**：根据你的体验/游戏需要，更新区块链账本，以实现事务透明性
5. **运行时持久化**：用于在可能分布式的平台上跨会话保留的临时数据（即仅针对单次游戏体验的生命值）


---

# 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/mvp-guidelines.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.