Руководство по MVP

При создании минимально жизнеспособного продукта (MVP) для вашей сцены вам нужно подумать о двух основных направлениях:

1. Базовый пользовательский опыт и функциональность вашего проекта.

2. Создание базового «конвейера» или системы управления рабочим процессом команды и контентом для создания вашего опыта и его итеративного улучшения.

MVP не должен пытаться продемонстрировать все возможные результаты каждого возможного опыта. Вместо этого MVP должен быть лучшим первым впечатлением от вашего опыта, которое вы можете произвести с помощью SDK Decentraland.

Важно учитывать свои собственные ограничения, то, как вы планируете предоставлять контент своим пользователям, и ожидания ваших пользователей. Подход к вашему MVP таким образом требует трех разных точек зрения:

1. Как разработчик или продюсер, как я могу донести опыт до своего пользователя/игрока?

2. Как пользователь или игрок, что я ожидаю от этого опыта?

3. Как участник или заинтересованное лицо, как я могу внести свой вклад в разработку или опыт?

Важно отличать этот подход от традиционной гибкой разработки, поскольку вам, возможно, придется использовать неоптимальные методы для достижения целей проектирования.

Вам придется изучить свои собственные цели в контексте ожиданий ваших пользователей, чтобы решить, ориентирован ли конкретный релиз больше на игрока, конвейер и авторов контента или мало на то и другое.

При планировании каждого выпуска крайне важно, чтобы вы добросовестно и обдуманно устанавливали свои приоритеты в соответствии с каждой из этих трех точек зрения.

Вы можете ожидать, что ваш бэклог разработки будет следовать двум направлениям:

• Бэклог по пользовательскому опыту, которую вы хотите создать.

• Разработка инструментов и интерфейсов, необходимых для построения конвейера доставки. (Или оптимизировать существующий конвейер для участников, а также для вашей команды разработчиков.)

Эти два трека также будут следовать двум различным подходам к тестированию:

• Тестирование взаимодействия с пользователем больше похоже на традиционное тестирование пользовательского интерфейса и не требует таких же ресурсов сценариев.

• Тестирование ваших инструментов и интерфейсов пайплайнов потребует больше технических ресурсов.

Чем раньше вы сможете представить ценностное предложение вашему пользователю или игроку, тем скорее вы сможете получить обратную связь, подтверждающую или отвергающую это предложение. Быстрое подтверждение стоимости имеет решающее значение. Многие опытные разработчики поделятся историями о том, как они были без тени сомнения уверены в том, насколько потрясающей будет новая механика, пока они не использовали ее, и она не казалась неудобной и глючной, игроки вообще не реагировали на нее или она не работала. не решить потребительские хотят/потребности. Вы хотите потерпеть неудачу быстро с минимальными усилиями, чтобы вы могли извлечь уроки из своей неудачи и спланировать следующую итерацию.

Как быстро выйти из строя? Вы делаете минимум, необходимый для того, чтобы ваш игрок прикоснулся к вашему продукту.

Факторы для минимальных жизнеспособных продуктов

Вот список факторов, которые следует учитывать для вашего базового MVP. Допустимо заявить, что вы будете использовать что-то в качестве заполнителя, а затем поэтапно откажетесь от него, когда разработаете более надежную замену.

1. Искусство Творения

   • Во-первых, начните с основных неподвижных изображений

   • Ваш первый тест должен быть на стиль: нравится ли выбранный вами стиль вашим пользователям?

   • Это могло бы стать началом руководства по стилю для аутсорсингового художника.

2. Создание сцены

   • Развивайте базовое чувство вашего пространства

   • Игрок должен чувствовать, что находится в новом, уникальном пространстве.

   • Отделите свое пространство от соседних пространств

   • Границы наглядны и очевидны — хотя бы по нарисованной линии

   • Покройте всю область статическим контентом/артом

3. Искусство, представленное в сцене

   • Можно использовать рекламные щиты или другие вывески (это могут быть просто рекламные щиты или более сложные спрайты, обращенные к камере).

   • Установите тон и эстетику вашего пространства (например, стиль, светлый, темный)

   • Обратите внимание на свой процесс: как искусство было создано и развернуто на сцене?

   • Как вы хотите организовать свои художественные файлы для повторного развертывания?

4. Опыт игрока

   • Игроки могут посещать ваше пространство/сцену

   • Игроки могут отличать ваше пространство от соседних пространств

5. Цели конвейера

   • Разверните образец статической сцены: без взаимодействия с игроком

   • Разверните анимированную сцену: такие элементы, как фонтаны или развевающиеся флаги, повторяют свою анимацию.

   • Разверните интерактивную сцену: включая взаимодействие с игроками

   • Продемонстрируйте конвейер развертывания путем повторного развертывания контента: от создания изображения до сцены, включая сценарии + контроль качества]

   • Обнаружьте пробелы в конвейере: определите неизвестные в конкретных областях развертывания контента.

Уровни прототипов

Быстрая неудача позволяет вам развивать свой опыт, создавая последовательные прототипы, при этом каждая итерация основывается на предыдущей.

Начните с прототипа одиночной игры. Затем вы можете запланировать сценарии многопользовательских взаимодействий. Наконец, вы можете заняться постоянным базовым циклом, демонстрирующим уровни транзакций.

Постоянный основной цикл

В игровом дизайне постоянный основной цикл — это фундаментальный «игровой цикл», который управляет действиями игрока и реакцией игры на эти действия. Эти постоянные циклы распространяются на любую форму виртуального опыта (например, на те, что предоставляются Districts).

Примечание: Клиент Decentraland заимствует некоторые архитектурные идеи из React.js и рендерит сцену только тогда, когда происходит изменение, а не с постоянной скоростью.

Транзакционные уровни

Транзакционные уровни — это интерфейсы между системами, такие как обновление блокчейна или другое приложение, которое было связано с вашим опытом для ведения постоянной записи действий игрока. Создание и поддержание этой постоянной записи — это то, что создает более личный опыт.

Мы рекомендуем создавать MVP для одиночной игры.

Например, вы можете создать сцену со следующими последовательными событиями:

• Один игрок может войти в мир.

• Игрок может взаимодействовать с одним или двумя простыми объектами на сцене.

• Другие игроки могут присоединяться и взаимодействовать с миром и другим игроком.

• Наконец, вы можете добавить возможность запоминать, что каждый игрок вошел в сцену, и отслеживать события и действия игроков.

Как поделиться своим MVP

Хотя мир Decentraland еще не открыт для всех, вы можете загрузить предварительный просмотр сцены на сервер и легко поделиться ссылкой на него с людьми, которые могут дать вам отзыв.

Даже после того, как Decentraland станет доступен для всех, мы по-прежнему рекомендуем сначала протестировать изменения с тестовыми пользователями на отдельном сервере предварительного просмотра, прежде чем загружать новую версию вашей сцены в Decentraland.

Прочтите этот пост в блоге, чтобы узнать, как загрузить предварительный просмотр сцены на бесплатный сервер.

Дополнительные соображения

После того, как основные варианты использования будут рассмотрены, вы можете приступить к более сложной стратегии управления релизами, сосредоточившись на механике. Механика — это широкий термин, охватывающий все действия, которые может предпринять игрок, и ответы, которые система будет предоставлять на основе этих действий игрока.

Важно помнить о совместимости устройств . Пользователи вашей сцены могут получать доступ к вашей сцене с настольного компьютера, мобильного устройства или гарнитуры VR. Пользователи должны иметь возможность достаточно хорошо взаимодействовать с вашей сценой, используя любой из них. Для тех, кто использует гарнитуру VR, старайтесь избегать головокружительных движений, которые могут вызвать укачивание.

Звук — еще один важный аспект атмосферы сцены. Фоновые звуки, такие как ветер, сверчки, отдаленные разговоры, может быть, даже музыка могут быть очень мощным способом усилить погружение и придать контекст. Вы также можете изменить отношение уровня громкости к расстоянию от источника звука, чтобы сделать больший или меньший акцент на местоположении звука.

Прочтите ограничения дизайна для игр , чтобы подробно рассмотреть ряд других соображений.

Рассматривайте MVP как один из многих прототипов, которые вы можете использовать для определения частоты выпуска релизов после того, как вы установили конвейер. Фокус каждого релиза может меняться, или это может быть гибрид каждого аспекта опыта. Тем не менее, вы должны стремиться к последовательному созданию более сложного опыта, чтобы каждая итерация опиралась на предыдущую.

1. MVP: Одиночная игра

2. Релиз 2: Добавлена ​​многопользовательская игра и/или поддержка взаимодействия.

3. Выпуск 3: Представьте свою первую механику

4. Выпуск 4: Добавлена ​​поддержка звука

5. Выпуск 5: Доработайте свой художественный пайплайн

Например, предположим, что мы создаем MVP для игры в фрисби-гольф. MVP будет включать в себя несколько неподвижных изображений курса. Игрок может даже быть в состоянии бросить диск очень элементарным способом в стиле блока. Это позволяет нам отработать нашу основную механику броска. Следующий релиз может включать в себя прототип поддержки многопользовательской игры, чтобы мы могли продемонстрировать и протестировать двух пользователей, вошедших в систему и играющих на нашей ЗЕМЛЕ одновременно.

Помните, хотя конечной целью является действительно захватывающий трехмерный мир, ваш MVP начнется не с этого. Ваша первая цель — как можно быстрее привлечь игрока в свой мир. Тестирование релизов в течение недель, а не месяцев имеет решающее значение для обучения и итерации без лишних усилий.

Мы настоятельно рекомендуем вам помнить о первом впечатлении, которое производит ваш опыт. Пустой опыт оставит игроков разочарованными. С другой стороны, сцена с некоторым исходным контентом и базовым опытом показывает игрокам потенциал того, что должно произойти, и побуждает их взаимодействовать с вашим сообществом и возвращаться к следующим нескольким выпускам.

Факторы стойкости, которые следует учитывать

В конечном счете, вы хотите достичь такого уровня постоянства, при котором вы сможете продемонстрировать работоспособность транзакционных уровней вашей архитектуры. Транзакционная не ограничивается действиями игроков, но также и реакцией системы на игроков.

1. Информация об учетной записи : имя для входа, часовой пояс, место для вашего конкретного опыта/игры.

2. Статистика таблицы лидеров: результаты предыдущих игр, глобальные/региональные рейтинги, соревнования.

3. Подтверждение личности : адрес кошелька Ethereum или любое другое внутреннее средство управления идентификацией.

4. Обновления блокчейна: по мере необходимости в зависимости от вашего опыта/игры для обновления реестра блокчейна для обеспечения прозрачности транзакций.

5. Постоянство во время выполнения : временные данные для сохранения на потенциально распределенной платформе (т. е. работоспособность только для одной игры).