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

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

Каков коренной причиной этих проблем? Мнения разнятся. Команда TabiChain считает, что значительным фактором является то, что талантливым традиционным разработчикам игр трудно попасть в экосистему Web3 из-за технических и обучающих барьеров. Для тех, кто не знаком с разработкой игр или программного обеспечения, переход от Web2 к Web3 может показаться просто сменой повествования и окружения, но реальность гораздо жёстче.

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

Технические причины, мешающие традиционным разработчикам игр войти в экосистему Web3

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

1. Разница между веб-приложениями web3 и традиционными программными структурами

Блокчейн и его приложения (dApps) фундаментально отличаются от традиционной архитектуры программного обеспечения и требуют от разработчиков новой системы знаний, такой как принцип работы блокчейна, протоколы консенсуса, модели программирования смарт-контрактов и т. д. Традиционным разработчикам игр нужно потратить много времени на изучение Solidity или других языков смарт-контрактов и понимание того, как работает EVM.

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

1. Ограничения дизайна смарт-контрактов

Хотя EVM является полным с точки зрения теории Тьюринга и теоретически может выражать произвольную логику, его характеристики очень неблагоприятны для разработки игр, такие как:

• Отсутствие таймера. Все операции на цепи Ethereum должны быть вручную запущены учетной записью EOA. Для достижения эффекта, аналогичного таймеру, разработчикам необходимо развернуть дополнительный сервис и поддерживать учетную запись EOA и список событий для вручную запуска запланированных задач. Из-за проблемы задержки на цепи, не гарантируется своевременное завершение этих запланированных задач.

• Здесь нет обратного вызова и других механизмов, и он не поддерживает многопоточность и асинхронность. Поскольку Solidity разработан для разработки смарт-контрактов Ethereum, его среда выполнения значительно отличается от традиционных сред выполнения. Работа EVM транзакционна, и каждый вызов функции должен быть полностью выполнен в рамках транзакции. В традиционном понимании нет концепции «асинхронности». Это означает, что вызов функции в Solidity является атомарным от начала до конца и не может быть прерван другими транзакциями.
• Нет возможности ссылаться на внешние данные. Хотя существуют оракулы, такие как Chainlink, независимо от интеграционной или перспективы вызова данных, их удобство использования сильно отличается от прямого получения вызовов данных через https-запросы, что позволяет разработчикам добавлять дополнительные интеграции. Бремя и зависимость.
• Ограничения масштабируемости и производительности. Логика игры должна быть упрощена или разбита на несколько простых транзакций, чтобы избежать того, чтобы газовый сбор за одну транзакцию стал слишком высоким или превысил максимальный предел, что ограничивает реализацию сложных взаимодействий и функций.

1. Ограничения на хранение и извлечение данных

• Умные контракты имеют дорогостоящее пространство для хранения и ограниченный дизайн, что делает их непригодными для хранения больших объемов игровых данных.
• Журналы событий могут потребоваться для косвенного отслеживания статуса игры, и захват событий может быть нестабильным. Проблемы, такие как необходимость обновления состояния игры, часто требуют, чтобы игроки или операторы игры сами запускали его вручную.
• Структура данных учетной записи, принятая EVM, приводит к плохим возможностям индексации данных. При запросе данных учетной записи вы можете знать только баланс ее ETH или цепного собственного токена, но какие у ERC-20 активов она владеет и баланс каждого актива не могут быть непосредственно известны. То же самое верно для NFT. Эта информация инкапсулируется в эксклюзивном контракте каждого актива, а не хранится на собственной учетной записи пользователя.

Мы можем увидеть, какие токены и информацию о балансе имеет определенный адрес, используя инструменты, такие как Etherscan. Они индексируются периферийными инструментами, такими как браузеры блокчейна, и последним необходимо построить специальную огромную базу данных и полностью просканировать ее. Только собрав все данные блока или отслеживая события в цепи, можно суммировать все данные на цепи.

Разработчики Web3 обычно должны интегрировать сторонние поставщики данных, такие как Etherscan, NFTscan, The Graph, и даже платить за их API KEY. Кроме того, эти сторонние сервисы по сути являются внеблоковыми базами данных, что может вызвать задержки, ошибки, превышение лимитов вызовов, недоступность сервиса и другие сбои.

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

1. Проблемы интеграции существующих игровых активов с блокчейном

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

1. Обновления, патчи и предотвращение бедствий

На Ethereum, после развертывания смарт-контракта код является неизменным, что делает обновления и патчи более сложными, чем в традиционном программном обеспечении. Разработчики часто используют прокси-контракты или шаблоны версионирования, чтобы обойти это ограничение, но это увеличивает сложность общей структуры. Прокси-контракты должны использоваться с особым вниманием, чтобы избежать повреждения данных, вызванного конфликтами слотов хранения. Кроме того, риск утечки административных прав также серьезен.

Обновление кода традиционных игр не такое уж сложное с технической точки зрения. Единственное, что может потребоваться ограничить, это централизованная власть в обновлении. Это можно достичь с помощью методов, таких как DAO, а не полагаться на смарт-контракты.

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

1. Экологическое фрагментирование и проблемы пользовательского опыта

На разных общедоступных цепочках и виртуальных машинах полностью различаются языки смарт-контрактов, архитектуры, структуры данных и т. д. В Web2 разработчики игр выбирают кросс-платформенные фронтенд-движки, такие как Unity, которые могут сделать набор кода слегка адаптированным для запуска в различных средах, таких как iPhone, Android и настольные компьютеры. Поскольку бэкенд не запускается на пользовательском терминале, нет проблем с кросс-платформенностью.

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

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

После перечисления вышеуказанных 6 основных аргументов давайте подытожим: разработчики с web2 на web3 сталкиваются с огромным порогом адаптации. Если они являются топ-разработчиками в web2, нет необходимости бросать свою карьеру в web2 и переходить к чему-то незнакомому, как web3. В этой среде мы разрабатываем некоторые бизнесы, о которых не знаем, смогут ли они быть успешными или нет.

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

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

Есть ли инфраструктурный проект, который может решить вышеупомянутые проблемы? Tabi Chain может быть проектом, очень близким к одному из конечных решений для игр Web3. Его основная концепция - это «Omni Execution Layer»: разработчикам больше не нужно беспокоиться о различиях между различными виртуальными машинами или операционными средами. Они могут напрямую использовать свои привычные или даже настраиваемые операционные среды для прямой разработки или портирования игр.

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

Уровень выполнения Omni: выбор среды выполнения на основе потребностей разработчика

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

По сути, блокчейн поддерживает универсально принимаемую конечную машину и ее рабочий статус:

• Каждый ввод детерминированный, записанный в каждом блоке;
• Функция перехода состояния является детерминированной, представленной виртуальной машиной или средой выполнения в клиенте блокчейна;
• Состояние вывода также детерминировано, записано в каждом блоке;

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

В Tabi каждая игра или dApp может создать собственный независимый сервис. Все сервисы отправляют свои собственные сгенерированные блоки в систему консенсуса цепи; Узлы-супервизоры включают время выполнения/виртуальную машину во всех сервисах для проверки статуса сервисных блоков. Ядро универсального слоя выполнения Tabi можно рассматривать как виртуальную машину с полиморфными возможностями, поэтому ее называют Полиморфной ВМ.

Для существующих блокчейн ВМ Polymorphism VM должна интегрировать эти ВМ в свою среду выполнения и предоставить необходимые методы вызова интерфейса. Концепция "интеграции" здесь может быть реализована двумя способами:

Общее состояние мира: Похоже на Ethermint, который поддерживает EVM на Cosmos. EVM действует как поверхностный слой, фокусируясь на взаимодействии пользователей и операциях с контрактами, делая все действия со стороны пользователя кажущимися выполненными на EVM. Однако окончательные результаты и данные этих операций хранятся в других модулях Cosmos. Таким образом, совместимость EVM в основном представляет собой отображение базовых данных.

Это отображение отношений можно распространить и на другие виртуальные машины. Например, Ethermint может включить дополнительный слой модуля SVM, где и SVM, и EVM соответствуют одним и тем же основным данным.

Это аналогично использованию VMWare на ПК для запуска виртуальной машины Windows. VMWare может получить доступ как к виртуальному жесткому диску виртуальной машины, так и к физическому жесткому диску компьютера. Если вы запустите виртуальную машину Mac, она может монтировать данные с физического диска тем же способом. Такая настройка позволяет нескольким виртуальным машинам эффективно использовать ресурсы и состояние одной и той же среды.

Основной сервис Tabi Chain будет использовать подход с общим состоянием мира. Это означает, что при условии адаптации соответствующей ВМ, dApps, разработанные для этой ВМ, могут быть развернуты непосредственно на Основном сервисе без необходимости создавать отдельный сервис.

Independent World State: Различные приложения и игры имеют уникальные требования, и некоторые игры используют пользовательские среды выполнения. Поэтому универсальный подход к интеграции всех ВМ через "общее состояние мира" в ВМ Полиморфизма не подходит для каждого случая. Независимое состояние мира также необходимо, так как оно проще в реализации и идеально подходит для служб с полностью отдельными данными.

Независимо от используемого подхода, он должен быть проверяемым Супервизорными Узлами. Это означает, что ВМ Полиморфизма должен включать в себя все ВМ или среды выполнения, используемые различными методами реализации.

Пример портирования игры Web2

Polymorphism VM может быть легко настроен, что особенно полезно для разработчиков Web2. Они могут использовать знакомые языки и фреймворки для переноса любой бизнес-логики на Polymorphism VM.

Предположим, что Minecraft хочет портировать на Tabi. Общий процесс будет следующим:

1. Измените код сервера: Немного измените код сервера Minecraft (Java или любой другой язык), переместив данные, которые должны быть в цепочке, в базу данных (или набор баз данных). Определите и выберите все функции, которые могут изменить эту базу данных (т. е. функции перехода состояния).
2. Упакуйте компоненты: Упакуйте эту базу данных и эти функции в файл JAR, который является исполняемой программой на Java. Включите JRE (Java Runtime Environment) в этот пакет. Весь этот пакет затем загружается в Polymorphism VM, гарантируя, что все данные находятся в блокчейне.
3. Запустить логику вне цепи: запустить другую логику бэкенда, которая не требуется в цепи (например, формирование команды, чат и т. д.) на серверах вне цепи.
4. Начать службу: инициировать службу в цепочке Tabi и уведомить полиморфный ВМ узлов-супервизоров о загрузке того же JRE.
   

С этим завершается весь процесс.

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

Подробности функций игры STR (State Transition Runtime)

Предыдущий пример дал общий обзор портирования игры Web2. Чтобы получить более глубокое понимание, нам нужно погрузиться в более подробные детали. На этот раз мы воспользуемся общим примером вместо конкретной игры, чтобы проиллюстрировать детали, связанные с работой Omni-Execution Layer во время выполнения.

Подходящим образом настройка среды выполнения игры можно рассматривать как создание на блокчейне конечного автомата игры, называемого средой выполнения перехода состояния (STR) в Tabi.

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

По сути, настройка игровой среды может быть рассмотрена как создание конечного автомата для определенной игры на блокчейне, который называется State Transition Runtime в Tabi.

STR может быть интегрирован в Polymorphism VM в виде двоичного или модульного файла.

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

1. World DBСодержит все данные пользователей, необходимые для записи в блокчейн. Эти данные должны быть ценными и важными, поэтому для обеспечения их доступности требуется структура, подобная блокчейну. Поэтому не все данные нужно записывать в блокчейн. Например, в играх контент чата пользователя обычно не является важным и может быть удален, поэтому нет необходимости записывать его в блокчейн.
2. Он может выражать полное состояние мира. Во многих сценариях, таких как в играх, это выражение не обязательно подразумевает высокую степень прослеживаемости - простой аккумулятор будет достаточным, что означает, что структура данных, например, дерево Меркля, не всегда необходима. Однако независимо от того, какая структура данных используется для представления состояния мира, крайне важно, чтобы состояние мира базы данных могло быть выражено в краткой форме.
3. Любая функция, способная вызвать изменения в базе данных мира, называется функцией перехода состояния и должна быть инкапсулирована во времени выполнения перехода состояния. Любое изменение базы данных мира за пределами времени выполнения должно считаться незаконным и отклоненным.
4. Интерфейсы ввода и вывода должны соответствовать дизайну Input Interpreter и Block Proposer. Это относительно просто и здесь не будет подробно объясняться.

Следующие организационные структуры являются неотъемлемыми элементами этого STR. Tabi по умолчанию предоставит SDK для облегчения создания разработчиками времени выполнения.

World DB

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

Ниже приведен простой пример реляционной базы данных:

1. UID: Представляет собой уникального пользователя, который может быть открытым ключом или другим идентификатором.
2. Nonce: используется для предотвращения атак повторной передачи.
3. Дополнительные поля данных: любой тип данных.

Это простая база данных ключ-значение:

Функция перехода состояния

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

Аккумулятор мирового состояния

Мы можем построить простой хэш-аккумулятор для представления состояния мира:

A_s+1 = хэш(A_s + хэш(запрос))

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

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

Процесс обновления базы данных ключ-значение (KVDB) следует тому же принципу.

Случайные числа

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

Суммировать

Из приведенных примеров мы видим, что Omni-Execution Layer Tabi Chain обеспечивает разработчикам игр значительную гибкость благодаря модульному подходу. Из-за ограничений места мы не можем обсудить здесь все детали, но указанные основные моменты достаточны для демонстрации того, что решение Tabi Chain является как практичным, так и инновационным.

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

С Tabi разработчики могут использовать свой оригинальный язык, платформу разработки и движок. Им нужно только внести простые адаптации и модификации, аналогично вызову SDK, чтобы перенести свои проекты в мир блокчейна. Это приводит к экспоненциальному улучшению эффективности и снижению сложности.

Мы надеемся, что Tabi Chain может стать катализатором массового принятия игр Web3, привлекая талантливых разработчиков игр Web2 и принося по-настоящему развлекательные и играбельные игры в пространство Web3.

Disclaimer：

1. Эта статья перепечатана из [极客 Веб3]. Все авторские права принадлежат оригинальному автору [罗奔奔]. Если у вас есть возражения к этому перепечатыванию, пожалуйста, свяжитесь с Gate Learnкоманда, и они незамедлительно справятся с этим.
2. Отказ от ответственности: Взгляды и мнения, выраженные в этой статье, являются исключительно мнением автора и не являются инвестиционным советом.
3. Переводы статьи на другие языки выполняются командой Gate Learn. Если не указано иное, копирование, распространение или плагиат переведенных статей запрещены.