Це очевидно суперечить моделі розвитку традиційних ігор. Успішні традиційні ігри привертають багатьох користувачів за допомогою захоплюючих геймплей механік, що дозволяє розробникам будувати прибуткові шляхи та потенційно розширюватися на пов'язані товари та IP. Ці ігри працюють в позитивному циклі, де гравці насолоджуються грою та часто отримують економічні вигоди як всередині, так і поза грою.

Напротив, поточні блокчейн-ігри головним чином привертають гравців через фінансові виручки. Окрім їх низької гратися, веб3 ігри також стикаються з давніми проблемами, такими як високі бар'єри для входу та незручні процеси взаємодії.

Які є кореневі причини цих проблем? Думки відрізняються. Команда TabiChain вважає, що значним фактором є те, що талановиті традиційні розробники ігор мають проблеми з входженням в екосистему Web3 через технічні та навчальні бар'єри. Для тих, хто не знайомий з розробкою ігор чи програмного забезпечення, перехід від Web2 до Web3 може здатися просто зміною наративу та середовища, але реальність набагато жорстокіша.

Так як ми можемо створити більш сприятливе середовище для традиційних розробників ігор або пов'язаних компаній за допомогою технологій? У наступних розділах ми докладно проаналізуємо виклики, з якими стикаються гри Web3 та їх рішення, пояснюючи, як майбутня галузь геймінгу Web3 може бути технічно адаптована для кращого відповідати потребам традиційних розробників ігор.

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

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

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

Блокчейн та застосунки на ньому (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 може бути проектом, дуже близьким до одного з кінцевих рішень для веб-ігор. Його основна концепція - «Omni Execution Layer»: Розробники більше не повинні турбуватися про відмінності між різними віртуальними машинами або операційними середовищами. Вони можуть безпосередньо використовувати свої знайомі або навіть налаштовані операційні середовища для безпосередньої розробки або портування ігор.

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

Omni-Execution Layer: Вибір середовища виконання на основі потреб розробника

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

По суті, блокчейн підтримує універсально прийнятий становий автомат та його робочий статус:

• Кожен вхід є детермінованим, записаним в кожному блоку;
• Функція переходу стану є детермінованою, представленою ВМ або часом виконання всередині клієнта блокчейну;
• Вихідний стан також є детермінованим, записаним в кожному блоку;

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

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

Для існуючих віртуальних машин блокчейну потрібно інтегрувати в цей середовище виконання Polymorphism VM та надати необхідний інтерфейс виклику методів. Концепцію «інтеграції» тут можна реалізувати двома способами:

Спільний світовий стан: Схоже на Ethermint, який підтримує EVM на Cosmos. EVM діє як поверхневий шар, фокусуючись на взаємодії користувача та операціях з контрактами, що робить всі дії з боку користувача, здається, що вони виконуються на EVM. Однак фінальні результати та дані цих операцій зберігаються в інших модулях Cosmos. Таким чином, ця сумісність EVM суттєво є відображенням базових даних.

Це відображення може бути розширене й на інші ВМ. Наприклад, Ethermint може включати додатковий модуль SVM, де як SVM, так і EVM відповідають однаковим базовим даним.

Це подібно до використання VMWare на ПК для запуску віртуальної машини Windows. VMWare може отримати доступ до віртуального жорсткого диска віртуальної машини та фізичного жорсткого диска комп'ютера. Якщо ви потім запустите віртуальну машину Mac, вона зможе змонтувати дані з фізичного диска таким самим чином. Ця настройка ефективно дозволяє кільком віртуальним машинам спільно використовувати ресурси та стан одного й того ж середовища.

Основна послуга Tabi Chain використовуватиме підхід спільного стану світу. Це означає, що при адаптації відповідної VM розроблені для цієї VM dApps можуть бути розгорнуті безпосередньо на основній послузі, без потреби створювати окрему послугу.

Independent World State: Різні додатки та ігри мають унікальні вимоги, і деякі ігри використовують власні часи виконання. Тому універсальний підхід до інтеграції всіх віртуальних машин через «спільний світовий стан» в VM поліморфізму не підходить для кожного випадку. Також необхідний незалежний світовий стан, оскільки його простіше реалізувати та ідеально підходить для сервісів з повністю окремими даними.

Незалежно від використаного підходу, його необхідно перевірити Супервізорними Вузлами. Це означає, що Polymorphism VM повинен включати всі ВМ або часи виконання, які використовуються різними методами реалізації.

Приклад портування гри 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. Ми все ще повинні дізнатися більше про деталі. Цього разу ми використовуємо загальний приклад замість конкретного прикладу гри, щоб показати деталі, пов'язані з часом виконання в усюдишньому шарі виконання.

Фактично, налаштування середовища гри може бути розглянуто як створення машини стану для певної гри на блокчейні, яка називається Виконавчий час переходу стану в Tabi.

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

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

1. World DBContains all user data within the application that needs to be recorded on the blockchain. This data should be valuable and important, so a blockchain-like structure is needed to ensure its availability. Therefore, not all data needs to be recorded on the blockchain. For example, in games, the user’s chat content is generally not important and is disposable, so there is no need to put it on the blockchain.
2. Воно може виражати повний стан світу. У багатьох сценаріях, наприклад у грах, це вираження не обов'язково підтверджує високий рівень відстежуваності - досить простий аккумулятор, що означає, що структура даних, така як дерево Меркля, не завжди необхідна. Однак, незалежно від того, яка структура даних використовується для представлення стану світу, важливо, щоб стан світу бази даних світу можна було виразити у формі резюме.
3. Будь-яка функція, яка може викликати зміни в базі даних світу, називається функцією переходу стану, і повинна бути інкапсульована в час виконання переходу стану. Будь-яка модифікація бази даних світу за межами часу виконання повинна вважатися незаконною і відхиленою.
4. Інтерфейси вводу та виводу повинні відповідати дизайну Введення Інтерпретатора та Пропозера Блоку. Це досить просто і не буде детально пояснено тут.

Наступні організаційні структури є важливими елементами цього STR. Tabi за замовчуванням надасть SDK для сприяння розробникам у створенні часу виконання.

Світова база даних

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

Наступне - це простий приклад реляційної бази даних:

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 може стати каталізатором масового прийняття веб-ігор 3, привертаючи талановитих розробників веб-ігор 2 та принесе справжньо розважальні та грати гри у веб-простір 3.

Відмова від відповідальності:

1. Ця стаття перепечатана з [GateGeek Web3]. Усі авторські права належать оригінальному автору [罗奔奔]. Якщо є заперечення стосовно цього перевидання, будь ласка, зв'яжіться з Gate Learnкоманда, і вони оперативно займуться цим.
2. Відповідальність за відмову: погляди та думки, висловлені в цій статті, є виключно тими, що належать авторові і не становлять жодної інвестиційної поради.
3. Переклад статті на інші мови виконує команда Gate Learn. Якщо не зазначено інше, копіювання, поширення або плагіатування перекладених статей заборонене.