Трудности та вихід з кризи Web3 гри

Автор: Лола, Delphinus Lab

З виходом «Чорної міфології: Вуконґ» феноменально вибухнуло, у галузі знову з’явився голос, який гадає у Web3 ігри, в останній час дуже пригнічений та сумнівний ринковий настрій, додатково накладається дебафф.

Чи не люблять ігри люди Web3? Звичайно, в етап пухлини ринку неминуче було багато спекуляції, але багато builder все ще входять в цю галузь з бажанням створити хорошу гру, гру, яка належить гравцям, і яка може допомогти Web3 досягти справжньої масової адопції. Ігри - це шлях, який не можна обійти і який найбільше може заглибитися в ринок.

Але реальність жорстка. Коли люди намагаються перерахувати небагато ігор, які можна вважати лідерами в Web3, вони виявляють, що якість цих ігор невелика, більшість ігор не вражають своєю якістю, вони не надають гарного користувацького досвіду, і далеко не досягають очікувань масової адопції. Багато команд з успішним досвідом в Web2 зазнають невдачу в Web3, і, на мою думку, основна причина полягає в наступному:

1. Порівняно з традиційними іграми, Web3 ігри важко забезпечити постійне оновлення ігрового контенту

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

Труднощі оновлення вмісту гри

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

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

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

1 Переміщення

2. При проектуванні контракту вже на початкових етапах передбачено розділення Рівня даних та логічного рівня.

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

Не робити логічне оновлення інтерфейсу даних

Проведено логічне оновлення інтерфейсу даних

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

Прямий запуск логічного оновлення в Віртуальна машина

Після вирішення проблеми повторного використання даних та оновлення логіки, проблема оновлення структури даних все ще становитиме певний виклик для оновлення гри. Звичайна міграція даних у блокчейні часто потребує використання Оракул-машина, щоб змінити дані згідно з певним скриптом та повторно ввести їх у блокчейн, що займає багато часу.

У архітектурі App As A rollup, після аудиту міграції даних можна виконувати в zkVM, щоб забезпечити повну перевірку логіки міграції. Оскільки в багатьох випадках міграція даних є перегрупуванням даних, обчислювальна логіка є меншою, якщо кожен лист Нода містить близько 1000 рядків коду, то приблизно для мільйона листових Нод знадобиться виконати трейс приблизно в 1000*100w. Наразі звичайний час підтвердження трейсу в zkVM для мільйона рядків складає від 9 до 15 секунд, тому час загальної міграції даних в zk залишається під контролем.

Саме незалежність даних у додатку Rookup надає нову методологію для ітерації вмісту веб-гри Web3.

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

Економіка та проблеми розподілу користі

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

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

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

У цих складних взаємозв’язках немає чіткого визначення того, як розподіляти фактичні витрати користувачів, щоб це було розумно. Для холодного старту гри потрібні великі кошти, а перший дохід користувачів часто ґазовий рейтинг ланцюга, що призводить до дуже довгого циклу негативного та позитивного зворотного зв’язку для авторів ігор, іноді навіть після досягнення командою розробників ігор фіктивної торгівлі базового значення DAU ланцюга, вони змушені відновлювати втрати за допомогою незначних grant. Це змушує ігри в початкових стадіях привертати гравців за допомогою очікуваного токена, щоб вони оплатили газ для взаємодії. Це покладення витрат на газ вже не може бути ігнорованим для гравця, так що ланцюгові ігри ускладнюють процес спонукання користувачів до витрати свого токена, а саме покупки грошового токена гри, порівняно з традиційними іграми.

Оскільки гра депозит є найважливішим кроком у позитивному зворотному зв’язку гри, газ значно уповільнює здатність гри залучати клієнтів. Але через те, що ланцюжкова гра повинна нести традиційне бремя обов’язку ланцюжка, навіть на layer2, газ безжально випереджає перший депозит гри з власним токеном. Таким чином, Web3 насправді не має справжнього досвіду гри “спочатку грай, потім витрачай”.

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

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

Додаток як rollup + zkVM: можлива вихідна точка

Перераховуючи цей ряд викликів, ми несподівано виявили, що архітектура Application As Rollup може досить ефективно пом’якшити ці проблеми.

Спочатку власний rollup дійсного газу значно зменшиться на 1/20 або навіть менше по всій ланці гри. Це дозволить вечірці проєкту повністю уникнути газових комісій на початкових етапах гри, забезпечуючи справжнє геймплей безкоштовної гри, створюючи краще середовище для початкового запуску гри зі збору великої кількості гравців.

По-друге, Application As Rollup може надати платформу для позики з одним натисканням кнопки, де користувачі можуть позичати внутрішні токени гри за допомогою USDC, щоб спонукати їх випробувати функцію платежів у грі. Оскільки очікуваний вихід гри зазвичай більший за витрати, після досягнення користувачем прибутку від гри, він може повністю викупити USDC, які він позичав. Забезпечення.

У процесі обігу, Application As a Rollup може ефективно виконувати функції моста крос-ланцюга для гри взаємодії з активами. Коли нам потрібно перемістити активи між різними у блокчейні, нам потрібно лише здійснити депозит в гру, а потім здійснити виведення на іншому у блокчейні. Ця вбудована функціональність крос-ланцюжкової взаємодії дозволяє грі отримати частину вартості угод з похідними продуктами гри.

Більш радикальним є те, що гра може надавати можливість здійснювати депозит стейблкоїну для позики, що дозволяє грі самій захоплювати значення TVL, яке раніше могло бути захоплене лише ланцюжком. Нарешті, Application Rollup може надавати можливість захоплювати традиційні газові витрати шляхом введення механізму, схожого на газові витрати для гравців-кетаїнів у грі, що в кінцевому підсумку дозволить захоплювати традиційні ланцюжкові газові витрати. Один з можливих варіантів цього механізму полягає в тому, що вартість газу нижча, коли вартість токена висока, і навпаки: в основі цього лежить зв’язок між вартістю газу та вартістю токена через незалежність на рівні layer3, який полегшує Коливання вартості токена.

Звичайно, все це не відбувається вночі, Delphinus Lab zkWASM, як один з перших гравців, які використовують zkVM в ігрових застосуваннях, недавно випустив zkWASM Mini Rollup. Це набір інструментів для швидкої розробки та розгортання додатків ZK Rollup. Він дозволяє розробникам писати код на Rust, компілювати його в WebAssembly і запускати його в середовищі Node.js. Цей SDK обробляє транзакції, генерує zk-SNARKs та взаємодіє з Блокчейном.

Його основний процес полягає в наступному: отримання транзакції, обробка транзакції у віртуальній машині WASM, генерація доказу за допомогою хмарного сервісу zkWASM та подання доказу для перевірки та розрахунку у блокчейні. Весь цей процес гарантує конфіденційність та безпеку транзакцій, а також значно підвищує масштабованість блокчейну. Розробнику потрібно лише підписатися на логіку додатка, не заглиблюючись у складні деталі технології zk-SNARKs. Він також включає систему моніторингу Rollup, яка може спрацювати на основі доказів та даних транзакцій для розрахунку у блокчейні, використовуючи збережені корені Merkle та API перевірки доказів. Це забезпечує розрахунок відповідно до порядку коренів Merkle у блокчейні. Крім того, цей SDK спрощує налаштування локального середовища розробки, потрібно лише запустити MongoDB та Redis, запустити службу dbservice, а потім виконати команду npm run server у каталозі ts, щоб запустити повний локальний сервер.

Поява SDK zkWASM Mini Rollup надає потенційне рішення для подвійного виклику, з яким стикається Web3-ігрова галузь. Завдяки архітектурі Application As A Rollup воно не лише спрощує процес оновлення вмісту гри, але також надає нові можливості для оптимізації економічної моделі гри.

Цей інноваційний підхід спочатку полягає в тому, що він використовує сумісність з WASM, щоб дозволити великій кількості традиційних розробників використовувати їх найбільш знайому мову програмування, таку як Rust, для написання коду гри; відділяє грошові витрати на газ значно знижується, і навіть можливо досягти справжнього «газування з нульовими витратами» та «спочатку грай, а потім купуй» враження. Одночасно це надає більше можливостей для збору цінності в проектах гри, включаючи крос-ланцюжні взаємодії з активами, функції позики тощо, що сприяє побудові більш стійкої ігрової економічної системи.

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

З ростом використання цієї технології більшою кількістю розробників ігор, все більше операторів гри та протоколів позику готові долучитися до економічної моделі, запропонованої вище. Ми маємо підстави вірити, що Web3-ігри поступово подолають існуючі труднощі. Ми не маємо надії мати свого власного чорного бога міфів Сунь Ву-кунга або Місії виклику, але роблячи складні, але правильні речі, безперервно працюючи на досягнення кінцевої мети, а не на короткостроковий виграш, Web3-ігри також зустрінуть свій момент «переслідування долі» і проведуть всю галузь через довгу ніч перед масштабним застосуванням.