Как синхронизировать "состояние" всей игровой цепочки?

Фиона, IOSG Ventures

TL;DR

*Полная цепочка игр/автономных миров («FOG/AW») — одно из немногих важных повествований, связанных с Web 3. По сравнению с приложениями Web2.5, которые подключаются к Web3 только через NFT, FOG/AW помещает игровую логику в цепочку. Он использует блокчейн в качестве игрового сервера, становясь децентрализованным источником доверия к состоянию игры. Это дает такие преимущества, как постоянство, устойчивость к цензуре, компонуемость и т. д., но также ограничивает разнообразие и сложность игр, построенных на его основе.

  • С ростом требований к сложности и играбельности игры перед архитектурой движка выдвигается все больше задач: например, задержка кадров, случайное число, восстановление здоровья, непрерывный пассивный эффект, таймер и т. д. Концепция единиц времени и тиков в блокчейне отличается. Грязь дает множество идей для имитации течения времени и навыков пассивного восстановления. Например, когда игрок перемещается в комнате, транзакция происходит с перемещением всех предметов в комнате в соответствии с неким предопределенным планом. Используйте это, чтобы воспринимать изменения во времени и состоянии.
  • Технологический стек FOG/AW можно абстрагировать следующим образом: разработчики пишут внешние и внутренние коды для пользовательского интерфейса и логики ядра игры, затем синхронизируют все изменения через цикл состояния игры и, наконец, отражают новое состояние на внешнем локальном устройстве с помощью индексатора.
  • Поскольку многие типы игр, такие как RTS, требуют высоких тикрейтов, а блокчейны, созданные на основе консенсуса, могут обрабатывать только изменения времени блока, тикрейт — это большая проблема, которую необходимо решить здесь. Curio и Argus являются лидерами в этом отношении, и они увеличивают тикрейт игры на уровне цепочки нащупывания. Mud пытается максимизировать полную цепочку, и все состояние приложения сохраняется в EVM. Не планируется внедрять интеграцию вне сети для достижения более высокого тикрейта игры.
  • Для выбора различных цепей Додзе возглавляет экологию всей сети Старкнет. Согласно описанию @tarrenceva, у Starknet есть различия в состояниях состояний, которые отличаются от оптимистичных сверток и сосредоточены на выводе выполнения, а не на вводе. Влияние на игры, вероятно, в первую очередь связано с оптимизацией затрат, например, на игру в шахматы: за трехминутную игру может произойти 50 ходов. Из-за различий в состояниях единственное доказательство и конечное состояние могут доказать «выход». С другой стороны, оптимистичные свертки требуют «входных данных» из всех промежуточных состояний.

Определить FOG/AW: как синхронизируется состояние игры

Я думаю, чтобы судить о том, ВОГ ли это, бенчмарком является то, как синхронизируется состояние игры (источник правды).

Для игр Web 2.5 или традиционных многопользовательских игр существует централизованный сервер, который определяет текущее состояние игры, и когда игроки отправляют действия, сервер компилирует эти входные данные и возвращает обновленные результаты на устройство каждого подключенного игрока. Сервер обрабатывает все входные данные (тики), устраняет несоответствия и периодически отправляет обновления игроку, предоставляя снимок всех элементов в игре, обновляя состояние игры каждый тик. Состояние **игры («состояние игры или тик») — это снимок во времени свойств каждого объекта в игровом мире. Tickrate — это количество раз в секунду, которое игровой сервер вычисляет и передает обновленное состояние игры игрокам. Чем выше Tickrate, тем точнее и реалистичнее будет игровой процесс. В общем, стратегии в реальном времени или экшн-игры требуют высокого. тикрейт, а в пошаговых играх, таких как карточные игры, нет.

Как синхронизировать "состояние" всей игровой цепочки?

Источник:

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

** Решите проблемы с задержкой игры, временем и т. д. **

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

Задержка номера кадра На самом деле, это также очень распространено в мире Web2, включая задержки в клиентском рендеринге и пользовательских операциях. Особенно для игр с высоким тикрейтом, таких как FPS, когда возникает задержка, опыт игрока будет очень плохим.Одним из решений в Web2 является обновление состояния с фиксированным шагом, которое позволяет всем игрокам синхронизироваться в соответствии с самым высоким стандартом задержки среди игроков, чтобы решить честный опыт игрока. Эта задержка может быть еще хуже, когда вводится блокчейн и транзакции должны быть подтверждены. С этой целью Mud также добавляет механизм оптимистического рендеринга, обычно используемый в играх, предполагающий, что операция пользователя прошла успешно, и рендерит ее в клиенте до того, как сервер согласится (или, в данном случае, до подтверждения транзакции).

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

Концепция единиц времени и тиков отличается в блокчейне. @SebastienGllmt считает, что трудно использовать таймеры в цепочках, использующих концепции защиты от мошенничества (например, Op), потому что, если что-то пойдет не так, его нужно будет откатить.Если в игре используются таймеры, опыт будет плохим. Грязь дает множество идей для имитации течения времени и навыков пассивного восстановления. Например, увеличивая количество золотых монет с течением времени, каждый раз, когда игрок выполняет операцию, для которой требуются золотые монеты, вычисляйте количество золотых монет игрока на основе предыдущего количества золотых монет игрока, последнего количества обновлений и частоты обновления. В другом примере, когда игрок перемещается в комнате, транзакция сопровождается перемещением всех предметов в комнате в соответствии с заранее заданным планом. Используйте это, чтобы воспринимать изменения во времени и состоянии.

** Написание скриптов для "обмана" может не быть проблемой. **@BriefKandle не считает, что MEV игровой системы является читерством. Команда разработчиков должна подумать о предотвращении MEV с помощью простых скриптов. Разработка игр Web2 должна изменить образ мышления. Хороший бот MEV — это NPC в игре.

Некоторые из этих функций были реализованы в некоторых недавно запущенных сетевых играх, таких как Rhascau, где используются таймеры и непрерывные пассивные эффекты. В основном используя время блока в качестве тика. (В текущем L2 время блока = тикрейт).

Стек технологий FOG/AW

Платформа движка FOG/AW — это стек инструментов разработчика, который позволяет разработчикам создавать игры, используя блокчейн в качестве сервера и источника доверия. Также он может решить некоторые текущие проблемы:

  • Неэффективность построения FOG/AW on-chain из-за отсутствия стандартного/готового фреймворка;
  • Отсутствие модульности и повторного использования кода;
  • Отсутствие компонуемости. С развитием движка FOG/AW онлайн-игры могут стать более интересными и творческими.

Для простоты понимания в целом упрощенный технический процесс этого типа движка таков: разработчики пишут интерфейсные и внутренние коды для ui/ux и логики ядра игры, а затем синхронизируют все изменения через цикл состояния игры и, наконец, отражают новое состояние на локальное внешнее устройство с помощью индексатора.

Как синхронизировать "состояние" всей игровой цепочки?

Чтобы игры, работающие на блокчейне, работали бесперебойно, Mud, Dojo, Curio, Argus, Paima engine и Lootchain разрабатывают для этой цели свои собственные технологические стеки. Стек технологий состоит из 3 ключевых частей: цепочка, основной стек разработки и интерфейс игры. Все они имеют свои собственные нововведения, находя компромисс между децентрализацией и сложностью игры.

  • Игровой интерфейс: Содержит традиционные движки, такие как Unity, Unreal и т. д., а также языки React/Threejs и другие, а также мощные инструменты для обеспечения рендеринга и других функций, что является неотъемлемой частью улучшения игрового процесса и опыта. Вышеупомянутые проекты могут в основном предоставлять соответствующие SDK для использования разработчиками.
  • Основной стек разработки: Разработайте набор решений, позволяющих логике игры работать на блокчейне и вовремя синхронизироваться с внешним интерфейсом. Ключевые компоненты включают соответствующую структуру базы данных (определяющую поведение и логику игры), а также синхронизацию и возврат состояния игры.
  • Цепь: Большинство из них выбирают Ethereum, Optimism и Starknet.

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

  1. Разработчик вызовет некоторые интерфейсные инструменты Web2 в Mud для написания кода и использует эти мощные функции, такие как рендеринг, чтобы сделать игру более визуальной и увлекательной;
  2. В то же время разработчики будут писать персонажей, предметы и конкретную логику работы игры в соответствии со структурой смарт-контрактов Mud (Mud World), например, когда герой A перемещается из X в Y и инициирует крестовый поход против земли Y, какова вероятность или при каких обстоятельствах земля может быть успешно оккупирована;
  3. Вышеуказанные действия и состояние игры будут записаны в Mud Store, который представляет собой сетевую базу данных, отвечающую за глобальное состояние игры и источник доверия для синхронизации состояния игры;
  4. Когда герой А атакует Y, игрок на самом деле щелкает мышью на локальном компьютере переднего плана и отправляет команду для загрузки в цепочку.Команда основана на логике игрового дизайна разработчика и текущем состоянии игры в магазине, что приводит к результату.Результат обновляется до нового глобального состояния игры и синхронизируется с цепочкой;
  5. Игры на Mud поддерживают различные внешние интерфейсы, такие как веб и мобильные устройства, но могут столкнуться со сложными требованиями к индексации Mode — это автономный индексатор, разработанный для этой цели.

Как синхронизировать "состояние" всей игровой цепочки?

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

  • Большинство из них следуют дизайну Mud v1 и используют ECS в качестве структуры данных для разработки игр. Так написана и представлена игровая логика. Mud V2 улучшил его, и данные определяются в таблицах и s, что позволяет использовать другие стандарты данных (он не должен соответствовать стандарту моделирования данных ECS, как V1), что дает разработчикам больше выбора и делает его более инклюзивным.
  • Большинство используют децентрализованные базы данных, поскольку блокчейн, естественно, является источником доверия к состоянию игры и базе данных. Mud пытается максимизировать полную цепочку, и все состояние приложения сохраняется в EVM. Нет никакой жертвы децентрализации или внедрения схем интеграции вне сети для достижения более высокого тикрейта для игры.
  • Поскольку многие типы игр, такие как FPS, требуют высоких тикрейтов, а блокчейны, созданные на основе консенсуса, могут обрабатывать только изменения времени блока, тикрейт — это большая проблема, которую необходимо решить здесь. В своих инновационных проектах Curio и Argus первыми надеются увеличить тикрейт на уровне сети.
  • Для выбора различных цепочек и Curio, и Loot используют Caldera для построения цепочек стека Op. Кроме того, Dojo возглавляет всю экологию цепочки Starknet. Согласно описанию @tarrenceva, у Starknet есть различия в состоянии состояний, которые отличаются от оптимистичных сверток и сосредоточены на выводе выполнения, а не на вводе. Влияние на игры, вероятно, в первую очередь направлено на оптимизацию затрат, например, на игру в шахматы: за трехминутную игру может произойти 50 ходов. Из-за различий в состояниях единственное доказательство и конечное состояние могут доказать «выход». С другой стороны, оптимистичные свертки требуют «входных данных» из всех промежуточных состояний.

Уже есть несколько игр, построенных на этих движках. И Mud, и Dojo проводят хакатоны, чтобы привлечь разработчиков к созданию приложений. Curio только что выпустил демо-версию мини-игры Warcraft на ETHCC.

Как синхронизировать "состояние" всей игровой цепочки?

Очевидно, что FOG/AW становится ключевой экологией для конкуренции в публичных сетях.AW (Autonomous World), предложенный Lattice, представляет собой большую концепцию, не ограничивающуюся играми, но также включающую множество атрибутов, таких как социальные и финансовые. Итак, над этим построен воображаемый виртуальный мир, Метавселенная. Мы можем ожидать некоторых новых форм интегрированных приложений, таких как игры, социальные сети и финансы.

Ссылка:

Посмотреть Оригинал
This page may contain third-party content, which is provided for information purposes only (not representations/warranties) and should not be considered as an endorsement of its views by Gate, nor as financial or professional advice. See Disclaimer for details.
  • Награда
  • комментарий
  • Поделиться
комментарий
0/400
Нет комментариев
  • Закрепить