> 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/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 World](/creator/content-creator-zh/chang-jing-sdk7/fa-bu/publishing-options.md#decentraland-worlds) ，通过链接分享它，而无需任何 LAND，并且不会影响生产内容。

## 其他注意事项

一旦覆盖了基本用例，你就可以通过专注于机制，开始以更复杂的方式来管理发布策略。 **机制** 是一个广义术语，涵盖玩家可以采取的所有行动，以及系统会根据这些玩家行动提供的响应。

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

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

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

将 MVP 视为众多原型之一，在你建立好流水线后，可用它来确定你的发布节奏。每次发布的重点可能不同，或者可能是体验各个方面的混合体。不过，你应当以逐步交付更复杂的体验为目标，让每次迭代都建立在上一次的基础之上。

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

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

记住，虽然最终目标是真正沉浸式的 3D 世界，但这不是你的 MVP 的起点。尽可能快地把玩家带入你的世界应当是你的首要目标。用几周而不是几个月来测试你的发布，对于在不浪费精力的情况下学习和迭代至关重要。

我们强烈建议你时刻关注你的体验所呈现的第一印象。一个空荡荡的体验会让玩家失望。另一方面，一个包含一些初始内容和基础体验的场景，会向玩家展示未来的潜力，并鼓励他们参与你的社区并在接下来的几次发布中回访。

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

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

1. **账户信息**：登录名、时区、你特定体验/游戏的所在地
2. **排行榜统计**：以往游戏结果、全球/地区排名、竞赛
3. **身份验证**：以太坊钱包地址，或任何其他后端身份管理
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 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/mvp-guidelines.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.