Передмова перекладача: «BOLT — це повноланцюговий ігровий рушій, розроблений командою Magicblock для екосистеми Solana. Ця стаття складена з презентацій двох засновників Magicblock на заході Breakpoint 2023. "
Всім привіт, це останній виступ перед Хелловіном, і я сподіваюся, що зміст виступу буде цікавий усім. Мене звати Андреа, і я моя співзасновниця Габріеле. Сьогодні ми представимо новий ігровий фреймворк (движок) з повним ланцюгом.
01.Навіщо потрібна повноланцюжкова гра
Я почну з основ, тому потурбуюся про створення повноланцюгової гри як зі станом, так і з логікою в ланцюжку, і розберуся з усіма складнощами, які з цим пов'язані. Проста причина полягає в тому, щоб отримати функції, яких немає в традиційній ігровій інфраструктурі.
Перша особливість – інклюзивні модифікації. Це означає, що всі гравці та розробники можуть налаштувати будь-який компонент у грі, включаючи впровадження плагінів або модів, починаючи з розширеного клієнта. Навіть логіка гри, що лежить в основі, може бути розширена за допомогою смарт-контрактів. По суті, це новий режим, де кожна гра за замовчуванням є новою платформою, і ви можете стати Content Powerhouse, незалежно від того, наскільки маленька ваша команда.
Друга характеристика – наполегливість. Автономні світи і той факт, що ці віртуальні враження можуть існувати вічно, спричинили багато наслідків. Оскільки жодні сервери не можуть бути піддані цензурі або закриті, ці можливості фактично вносять абсолютно нове значення. Ігри стали платформою для гравців, щоб грати, спілкуватися та вести глобальну торгівлю, яка є більш універсальною, ніж традиційні ігрові платформи.
Останньою особливістю є відкрита економіка. Ігри можуть скористатися перевагами відкритої глобальної безперешкодної платіжної системи блокчейну, особливо мікроплатежів у нашій екосистемі, і повторно використовувати існуючу ончейн-інфраструктуру, таку як DEX або NFT-маркетплейси.
02.Існуюче рішення
Поточна проблема омнічейн-ігор полягає в тому, що досвід розробки дуже поганий, і ми дивимося на рішення на ринку і виявляємо, що є деякі фреймворки розробки, які намагаються спростити роботу розробника.
Деякі з них дуже цікаві тим, що вони намагаються виконувати ітерації на доказових сесіях, де ви можете виконувати обчислення поза мережею та доводити цілісність обчислень ончейн. Або запровадити середовище виконання, кероване подіями, яке більше підходить для ігрових рушіїв блокчейну, а не середовище виконання на основі циклу.
Але всі ці фреймворки вимагають компромісів між продуктивністю та компонуванням, щоб досягти вищої продуктивності та вищого TPS. Як правило, ви або створюєте ізоляцію, або вводите інше середовище виконання з шардами.
Але нас не влаштовує такий компроміс. Ми запитали себе, а що, якби існував фреймворк, який міг би підтримувати TPS, який нам потрібен? Коли ваша гра успішна, вам не потрібно жертвувати їхнім користувацьким досвідом, навіть з мільйонами гравців, тому що газових воєн не станеться. А фреймворк не вимагає шардингу та фрагментації, тому ви можете використовувати доказові ігрові сесії та навіть імітувати плин часу, не сплачуючи комісію gas. Немає необхідності фрагментувати систему або використовувати рівень 3 взагалі.
03.Движок розробки ігор на Solana: BOLT
Ось чому ми раді представити BOLT, високопродуктивний, компонований фреймворк для розробки ігор з повним ланцюгом, заснований на SVM.
BOLT є модульним і компонованим, що дозволяє йому використовувати всю існуючу інфраструктуру на Solana. Він працює з нашими існуючими ончейн-засобами, такими як ончейн-ідентичність, безгазовий API, ключ сеансу, а також існуючим фреймворком розробки Anchor і всіма існуючими програмами на Solana. Обидва можуть масштабуватися на вищий порядок завдяки Ephemeral Rollups, тобто ігровим сесіям, які відкриваються та закриваються відповідно до вимог користувача та масштабуються за потреби.
BOLT є блискавично швидким, і ми можемо досягти такого ж рівня продуктивності, як і традиційний ігровий рушій, перш ніж використовувати ці спеціальні середовища виконання для прискорення певних операцій.
Це панорамний дисплей рами BOLT. Очевидно, що він створений для Solana, але він може використовувати його на будь-якій SVM-сумісній платформі, наприклад, SVM-сумісному Layer 2. BOLT переслідує дві основні цілі: компонування та масштабованість.
Система ECS (Entity Component) — це один із способів, за допомогою якого ми спрощуємо використання ончейн-компонентів. Інша – це Ephemeral Rollup, про яку ми коротко згадували раніше, і я зараз занурюся в обидві ці технології.
BOLT був інтегрований з найбільш часто використовуваними застарілими ігровими движками, такими як Unity, які часто служать інтерфейсом для ігор. Звичайно, сюди також входять інші улюблені ігрові рушії з відкритим вихідним кодом, такі як Godot і Phaser. Ми навіть працюємо з оновленим ігровим клієнтом Turbo, який зосереджений на покращенні досвіду для інді-розробників і сприянні швидкому створенню ігор. У майбутньому партнерів може бути більше.
Я почну з цього і продовжу пояснювати, навіщо нам потрібна система компонентів сутностей ECS. Відповідь проста, тому що він дозволяє максимально компонувати, а це означає, що ми можемо створювати і повторно використовувати готові компоненти.
Як випливає з назви, ECS вбудована в три основні елементи: сутності, які, по суті, є ідентифікаторами, які реєструються в окремому екземплярі ігрового світу, компоненти, які визначають структуру даних таким чином, що вони в основному є даними, пов'язаними з сутністю, і, нарешті, система, яка є логікою, яка маніпулює компонентами, пов'язаними з сутністю.
Перевага такої архітектури полягає в тому, що всі системи та компоненти є багаторазовими. Вони можуть бути опубліковані в загальнодоступному реєстрі, і розробники можуть легко вносити, створювати, виявляти та інтегрувати будь-який тип компонентів, тому вам більше не потрібно писати жодного рядка коду з нуля, але ви можете повторно використовувати всі існуючі компоненти та зрештою вносити в них свій внесок. Наприклад, ми можемо мати сіткову структуру даних (наприклад, лабіринт або поле бою), рухому систему або систему доказу з нульовим розголошенням для туману війни.
04.Практика програмування ECS двигуна BOLT
(Примітка перекладача: Ця частина рекомендована розробникам для перегляду оригінального відео, не-розробники можуть пропустити цю частину)
ТЕПЕР Я ПЕРЕЙДУ НА СВОЮ IDE І ПОКАЖУ ВАМ ПРОСТИЙ ПРИКЛАД ГРИ З ВИКОРИСТАННЯМ ДВИЖКА BOLT ECS.
Ми визначимо кілька сутностей, компонент розташування та дві системи, які маніпулюватимуть і змінюватимуть дані для цього компонента розташування. Отже, першою точкою входу є взаємодія зі Всесвітньою програмою. Світова програма є частиною фреймворку BOLT і розкриває деякі вилучення, які дозволяють реєструвати нові світові інстанції.
Ви можете додавати сутності до вашого World Instance, і ви можете реєструвати компоненти з щойно визначеними вами сутностями, які, по суті, визначені програмою-компонентом. Програма-компонент містить дві директиви, перша з яких - ініціалізація, створення та виділення місця для зберігання рядків даних, які будуть використовуватися у вашому компоненті. У цьому простому прикладі ми визначаємо компонент розташування, і якщо ми подивимося на контекст директиви ініціалізації, ми побачимо, що у нас є дані компонента, а дані компонентів просто визначають структуру з координатами XYZ, яка може зберігати, наприклад, місцезнаходження гравця.
Зараз, друга директива, мабуть, найцікавіша, це точка входу, яка дозволяє нам виконувати будь-яку логіку. Він прийматиме наші компоненти та довільні системи як вхідні дані та виконуватиме логіку, визначену всередині системи, виконуючи їх у різних місцях програмування. Тепер, якщо ви подивитеся на рядок 15, у нас є наш виклик CPI (Common Programming Interface), який буде виконувати внутрішньо визначену логіку через CPI. Він виконає всі обчислення, визначені системою, а потім повернеться до нашого місця розташування, де програма-компонент отримає та поверне його назад у наші дані.
Тепер давайте спробуємо поглянути на контекст нашої функції apply, де ми можемо побачити, що у нас в основному є лише два облікові записи. Перший - це обліковий запис, який містить дані наших компонентів, а другий - системна програма. В результаті системна програма тепер є інтерфейсом, а не окремою програмою. Таким чином, будь-яка програма, яка дотримується нашого системного інтерфейсу BOLT, може бути виконана через цей додаток.
05.Значення системи ECS
По суті, це змінює те, як ви розробляєте логіку вашої гри, і перевертає традиційні процеси з ніг на голову. Раніше, якщо ви хотіли створити або інкапсулювати якусь логіку у своїй програмі, ви зазвичай спочатку додавали функції, кожна з яких була директивою в програмі, а потім, врешті-решт, в якийсь момент, ви блокували ігрову програму, яку ви розробляли.
З моделлю ECS, однак, ми можемо замість цього мати незмінну програму з самого початку, а потім, за допомогою цього проксі-механізму, ми можемо додати систему, створену власними силами або ким-небудь, так що ми можемо мати гру, яка може працювати вічно, є масштабованою, і будь-хто може дійсно змінити логіку гри.
Вони можуть розгорнути нові системи, які працюватимуть на цих компонентах. Тепер інтерфейс також дозволяє виконувати деякі перевірки, тому ми можемо розробити ігрову механіку, яка дозволить без дозволу додавати нові системи, які можуть змінювати дані компонентів.
Або ми можемо налаштувати інтерфейс, щоб перевірити, чи дозволяє система виконання компонента. Наприклад, ви можете розробити систему управління, в якій, якщо хтось пропонує нову логіку, і ця логіка затверджена, то всі гравці можуть використовувати цю логіку в грі.
Це може навіть призвести до розгалуження у світі гри (Світовий контракт). У світі ви володієте системою польотів. А в іншому світі, якщо система не буде затверджена, можуть бути інші правила, і кожен все одно зможе зробити свій внесок у свою версію світу.
Тепер давайте розглянемо, як побудувати систему, яка може модифікувати цей компонент. Система, по суті, є просто програмою на Solana, яка визначає інструкцію виконання, а інструкція виконання — це та, яку ми викликаємо з програми-компонента в CPI (Common Programming Interface). Тут він просто інкапсулює дуже просту логіку, в якій він отримує вхідний напрямок, обчислює дельту, а потім змінює позиції X і Y компонента.
Отже, давайте подивимося на іншу систему, яка може бути розгорнута кимось іншим, навіть після того, як ми випустимо гру. Ось ще один приклад системи, яка реалізує ute. Тут позиція Z збільшується на 1, тому хтось намагається додати флангову систему, яка може бути інтерфейсом з іншим шаром поверх вашої гри.
Отже, ідея зараз полягає в тому, що всі ці системи, всі ці компоненти дійсно компонуються, користувачі гри більше не є простими користувачами, гра стала відкритою, масштабованою та постійною платформою. Тому я спробую виконати модульні тести, які я підготував у цьому прикладі, і я збираюся використовувати BOLT CLI, який побудований на основі Anchor, фреймворку смарт-контрактів для Solana, тому, якщо ви вже знайомі з Solana, вам не потрібно вивчати нічого нового.
Тепер ви можете розробляти програми на Solana, просто розробляти програми, тестувати програми, тому тут я запускаю bolt build і bolt test, і тут я розгортаю нашу програму, а потім я роблю тест типу, який я підготував тут.
Отже, тут тест надсилає транзакцію для ініціалізації нового світу. Ми реєструємо кілька об'єктів, приєднуємо до деяких з них компоненти локації, а потім, можливо, найцікавіше те, що тут роблять деякі системи. Отже, тут ми викликаємо функцію apply, а потім використовуємо одну з цих систем. Отже, ось лише система за замовчуванням.
Тут ми викликаємо простий хід, а потім ми летимо сюди. Ну а тепер, якщо ми подивимося на логи тесту, то в першій угоді тут ми використовуємо рухому систему з висхідним напрямком, збільшуючи позицію Y на 1. У другій транзакції ми використовуємо ту саму систему, щоб рухатися вправо, а потім, нарешті, виконуємо систему польоту, яка робить протилежне, збільшуючи нашу позицію Z на 1. Це лише простий приклад, але він пропонує дуже потужну механіку, яка дозволяє будь-кому розвивати, розширювати та потенційно робити вашу гру цікавою.
06.Ефемерний зведення
Тепер, коли ми повернемося до слайда, я збираюся описати другий цікавий аспект фреймворку BOLT, який є нашим рішенням для масштабованості, яке ми називаємо Ephemeral Rollup.
Прийнято вважати, що Solana вже дуже швидка і дешева, і що в даний час вона генерує блок кожні 400 мілісекунд і може обробляти тисячі транзакцій, тому вона фактично готова до створення повноцінної гри. Однак, якщо у вас є старий логічний ланцюжок для мультиплеєра, оновлення локацій буде відбуватися занадто повільно.
Таким чином, ми можемо побудувати короткочасний шар прискорення, який повністю сумісний з часом роботи Solana. Використовуваний час необов'язковий, він може служити реальним прискоренням тієї чи іншої операції, при цьому більша частина логіки все одно виконується на головному ланцюжку, тому він спирається на ту особливість, що весь стан на Solana зберігається в обліковому записі.
Як правило, у вас є ігрова програма, яка визначає логіку, а потім весь стан буде зберігатися в цьому обліковому записі, тому ми можемо делегувати деякі з цих облікових записів цьому ефемерному шару, який використовує рушій BOLT.
У цьому прикладі є два авторизовані облікові записи, які зберігають місцезнаходження гравця, і провайдер активно прослуховує запити на делегування та ініціалізацію. Він збирається розпочати новий час виконання за потреби, який є швидким, настроюваним, не може мати газових транзакцій або тиків, і дозволяє нам дійсно здійснювати транзакції нижче 50 мс і, можливо, масштабуватися, маючи кілька виділених часів виконання.
Інша цікава частина полягає в тому, що всю цю складність можна абстрагувати від користувача. У нас є маршрутизатор RPC, який по суті схожий на традиційний маршрутизатор RPC. Клієнт RPC може безпосередньо взаємодіяти з RPC для надсилання транзакцій. Оскільки в Solana всі транзакції попередньо оголошені для всіх змінних і читабельних облікових записів, маршрутизатори RPC можуть, по суті, направляти транзакції, запити даних і отримання даних на правильний рівень.
Потім у якийсь момент Ефемерний шар (як випливає з його назви) буде закрито, і всі стани будуть врегульовані на базовому рівні Solana, за що відповідає секвенсор, який відстежує всі облікові записи.
Інший погляд на цей механізм полягає в тому, що у нас є два рівні, і вони виконують транзакції паралельно. У нас є делеговані облікові записи, які дозволяють нам оновлюватися з меншою затримкою, не використовуючи пропускну здатність основного ланцюга. А ще у нас є інші акаунти, які не делегуються, а виконуються в основному ланцюжку.
Зараз дуже цікаво те, що програми, інструменти, фреймворки та інфраструктура знаходяться в основному ланцюжку. Вам не потрібно розгортати програму в Rollup, хоча це поширене явище в багатьох інших архітектурах. Все знаходиться на одному рівні, все можна компонувати, і, як ми вже згадували, це спеціалізоване середовище виконання також розширюється і може бути дійсно налаштовано.
Тепер це відкриває абсолютно нову категорію ігор, які він будує на блокчейні та мають низьку затримку. Так само, як і з традиційним багатокористувацьким сервером, але все ще здатний поєднуватися з усім, що доступно в екосистемі рівня 1.
Ви отримуєте доступ до існуючої ліквідності, можете надсилати повідомлення через протоколи, карбувати NFT, використовувати абстракції акаунтів, сесійні ключі, таблиці лідерів та єдину екосистему, всі збагачують одну екосистему.
Велике спасибі за увагу. Ви можете зареєструватися для отримання раннього доступу до нашого фреймворку за допомогою QR-кодів і перевірити репозиторій. Ви вже можете знайти надійну документацію та офіційні документи, які детально описують структуру, яку ми щойно представили. Дуже тобі дякую.
Переглянути оригінал
Ця сторінка може містити контент третіх осіб, який надається виключно в інформаційних цілях (не в якості запевнень/гарантій) і не повинен розглядатися як схвалення його поглядів компанією Gate, а також як фінансова або професійна консультація. Див. Застереження для отримання детальної інформації.
BOLT: повноланцюговий ігровий движок ECS на базі Solana
Посилання на відео:
Спікери: Андреа, Габріеле, співзасновник Magicblock
演讲标题:ФРЕЙМВОРК ДЛЯ ОНЧЕЙН-ІГОР
Передмова перекладача: «BOLT — це повноланцюговий ігровий рушій, розроблений командою Magicblock для екосистеми Solana. Ця стаття складена з презентацій двох засновників Magicblock на заході Breakpoint 2023. "
Всім привіт, це останній виступ перед Хелловіном, і я сподіваюся, що зміст виступу буде цікавий усім. Мене звати Андреа, і я моя співзасновниця Габріеле. Сьогодні ми представимо новий ігровий фреймворк (движок) з повним ланцюгом.
01.Навіщо потрібна повноланцюжкова гра
Я почну з основ, тому потурбуюся про створення повноланцюгової гри як зі станом, так і з логікою в ланцюжку, і розберуся з усіма складнощами, які з цим пов'язані. Проста причина полягає в тому, щоб отримати функції, яких немає в традиційній ігровій інфраструктурі.
Перша особливість – інклюзивні модифікації. Це означає, що всі гравці та розробники можуть налаштувати будь-який компонент у грі, включаючи впровадження плагінів або модів, починаючи з розширеного клієнта. Навіть логіка гри, що лежить в основі, може бути розширена за допомогою смарт-контрактів. По суті, це новий режим, де кожна гра за замовчуванням є новою платформою, і ви можете стати Content Powerhouse, незалежно від того, наскільки маленька ваша команда.
Друга характеристика – наполегливість. Автономні світи і той факт, що ці віртуальні враження можуть існувати вічно, спричинили багато наслідків. Оскільки жодні сервери не можуть бути піддані цензурі або закриті, ці можливості фактично вносять абсолютно нове значення. Ігри стали платформою для гравців, щоб грати, спілкуватися та вести глобальну торгівлю, яка є більш універсальною, ніж традиційні ігрові платформи.
Останньою особливістю є відкрита економіка. Ігри можуть скористатися перевагами відкритої глобальної безперешкодної платіжної системи блокчейну, особливо мікроплатежів у нашій екосистемі, і повторно використовувати існуючу ончейн-інфраструктуру, таку як DEX або NFT-маркетплейси.
02.Існуюче рішення
Поточна проблема омнічейн-ігор полягає в тому, що досвід розробки дуже поганий, і ми дивимося на рішення на ринку і виявляємо, що є деякі фреймворки розробки, які намагаються спростити роботу розробника.
Деякі з них дуже цікаві тим, що вони намагаються виконувати ітерації на доказових сесіях, де ви можете виконувати обчислення поза мережею та доводити цілісність обчислень ончейн. Або запровадити середовище виконання, кероване подіями, яке більше підходить для ігрових рушіїв блокчейну, а не середовище виконання на основі циклу.
Але всі ці фреймворки вимагають компромісів між продуктивністю та компонуванням, щоб досягти вищої продуктивності та вищого TPS. Як правило, ви або створюєте ізоляцію, або вводите інше середовище виконання з шардами.
Але нас не влаштовує такий компроміс. Ми запитали себе, а що, якби існував фреймворк, який міг би підтримувати TPS, який нам потрібен? Коли ваша гра успішна, вам не потрібно жертвувати їхнім користувацьким досвідом, навіть з мільйонами гравців, тому що газових воєн не станеться. А фреймворк не вимагає шардингу та фрагментації, тому ви можете використовувати доказові ігрові сесії та навіть імітувати плин часу, не сплачуючи комісію gas. Немає необхідності фрагментувати систему або використовувати рівень 3 взагалі.
03.Движок розробки ігор на Solana: BOLT
Ось чому ми раді представити BOLT, високопродуктивний, компонований фреймворк для розробки ігор з повним ланцюгом, заснований на SVM.
BOLT є модульним і компонованим, що дозволяє йому використовувати всю існуючу інфраструктуру на Solana. Він працює з нашими існуючими ончейн-засобами, такими як ончейн-ідентичність, безгазовий API, ключ сеансу, а також існуючим фреймворком розробки Anchor і всіма існуючими програмами на Solana. Обидва можуть масштабуватися на вищий порядок завдяки Ephemeral Rollups, тобто ігровим сесіям, які відкриваються та закриваються відповідно до вимог користувача та масштабуються за потреби.
BOLT є блискавично швидким, і ми можемо досягти такого ж рівня продуктивності, як і традиційний ігровий рушій, перш ніж використовувати ці спеціальні середовища виконання для прискорення певних операцій.
Це панорамний дисплей рами BOLT. Очевидно, що він створений для Solana, але він може використовувати його на будь-якій SVM-сумісній платформі, наприклад, SVM-сумісному Layer 2. BOLT переслідує дві основні цілі: компонування та масштабованість.
Система ECS (Entity Component) — це один із способів, за допомогою якого ми спрощуємо використання ончейн-компонентів. Інша – це Ephemeral Rollup, про яку ми коротко згадували раніше, і я зараз занурюся в обидві ці технології.
BOLT був інтегрований з найбільш часто використовуваними застарілими ігровими движками, такими як Unity, які часто служать інтерфейсом для ігор. Звичайно, сюди також входять інші улюблені ігрові рушії з відкритим вихідним кодом, такі як Godot і Phaser. Ми навіть працюємо з оновленим ігровим клієнтом Turbo, який зосереджений на покращенні досвіду для інді-розробників і сприянні швидкому створенню ігор. У майбутньому партнерів може бути більше.
Я почну з цього і продовжу пояснювати, навіщо нам потрібна система компонентів сутностей ECS. Відповідь проста, тому що він дозволяє максимально компонувати, а це означає, що ми можемо створювати і повторно використовувати готові компоненти.
Як випливає з назви, ECS вбудована в три основні елементи: сутності, які, по суті, є ідентифікаторами, які реєструються в окремому екземплярі ігрового світу, компоненти, які визначають структуру даних таким чином, що вони в основному є даними, пов'язаними з сутністю, і, нарешті, система, яка є логікою, яка маніпулює компонентами, пов'язаними з сутністю.
Перевага такої архітектури полягає в тому, що всі системи та компоненти є багаторазовими. Вони можуть бути опубліковані в загальнодоступному реєстрі, і розробники можуть легко вносити, створювати, виявляти та інтегрувати будь-який тип компонентів, тому вам більше не потрібно писати жодного рядка коду з нуля, але ви можете повторно використовувати всі існуючі компоненти та зрештою вносити в них свій внесок. Наприклад, ми можемо мати сіткову структуру даних (наприклад, лабіринт або поле бою), рухому систему або систему доказу з нульовим розголошенням для туману війни.
04.Практика програмування ECS двигуна BOLT
(Примітка перекладача: Ця частина рекомендована розробникам для перегляду оригінального відео, не-розробники можуть пропустити цю частину)
ТЕПЕР Я ПЕРЕЙДУ НА СВОЮ IDE І ПОКАЖУ ВАМ ПРОСТИЙ ПРИКЛАД ГРИ З ВИКОРИСТАННЯМ ДВИЖКА BOLT ECS.
Ми визначимо кілька сутностей, компонент розташування та дві системи, які маніпулюватимуть і змінюватимуть дані для цього компонента розташування. Отже, першою точкою входу є взаємодія зі Всесвітньою програмою. Світова програма є частиною фреймворку BOLT і розкриває деякі вилучення, які дозволяють реєструвати нові світові інстанції.
Ви можете додавати сутності до вашого World Instance, і ви можете реєструвати компоненти з щойно визначеними вами сутностями, які, по суті, визначені програмою-компонентом. Програма-компонент містить дві директиви, перша з яких - ініціалізація, створення та виділення місця для зберігання рядків даних, які будуть використовуватися у вашому компоненті. У цьому простому прикладі ми визначаємо компонент розташування, і якщо ми подивимося на контекст директиви ініціалізації, ми побачимо, що у нас є дані компонента, а дані компонентів просто визначають структуру з координатами XYZ, яка може зберігати, наприклад, місцезнаходження гравця.
Зараз, друга директива, мабуть, найцікавіша, це точка входу, яка дозволяє нам виконувати будь-яку логіку. Він прийматиме наші компоненти та довільні системи як вхідні дані та виконуватиме логіку, визначену всередині системи, виконуючи їх у різних місцях програмування. Тепер, якщо ви подивитеся на рядок 15, у нас є наш виклик CPI (Common Programming Interface), який буде виконувати внутрішньо визначену логіку через CPI. Він виконає всі обчислення, визначені системою, а потім повернеться до нашого місця розташування, де програма-компонент отримає та поверне його назад у наші дані.
Тепер давайте спробуємо поглянути на контекст нашої функції apply, де ми можемо побачити, що у нас в основному є лише два облікові записи. Перший - це обліковий запис, який містить дані наших компонентів, а другий - системна програма. В результаті системна програма тепер є інтерфейсом, а не окремою програмою. Таким чином, будь-яка програма, яка дотримується нашого системного інтерфейсу BOLT, може бути виконана через цей додаток.
05.Значення системи ECS
По суті, це змінює те, як ви розробляєте логіку вашої гри, і перевертає традиційні процеси з ніг на голову. Раніше, якщо ви хотіли створити або інкапсулювати якусь логіку у своїй програмі, ви зазвичай спочатку додавали функції, кожна з яких була директивою в програмі, а потім, врешті-решт, в якийсь момент, ви блокували ігрову програму, яку ви розробляли.
З моделлю ECS, однак, ми можемо замість цього мати незмінну програму з самого початку, а потім, за допомогою цього проксі-механізму, ми можемо додати систему, створену власними силами або ким-небудь, так що ми можемо мати гру, яка може працювати вічно, є масштабованою, і будь-хто може дійсно змінити логіку гри.
Вони можуть розгорнути нові системи, які працюватимуть на цих компонентах. Тепер інтерфейс також дозволяє виконувати деякі перевірки, тому ми можемо розробити ігрову механіку, яка дозволить без дозволу додавати нові системи, які можуть змінювати дані компонентів.
Або ми можемо налаштувати інтерфейс, щоб перевірити, чи дозволяє система виконання компонента. Наприклад, ви можете розробити систему управління, в якій, якщо хтось пропонує нову логіку, і ця логіка затверджена, то всі гравці можуть використовувати цю логіку в грі.
Це може навіть призвести до розгалуження у світі гри (Світовий контракт). У світі ви володієте системою польотів. А в іншому світі, якщо система не буде затверджена, можуть бути інші правила, і кожен все одно зможе зробити свій внесок у свою версію світу.
Тепер давайте розглянемо, як побудувати систему, яка може модифікувати цей компонент. Система, по суті, є просто програмою на Solana, яка визначає інструкцію виконання, а інструкція виконання — це та, яку ми викликаємо з програми-компонента в CPI (Common Programming Interface). Тут він просто інкапсулює дуже просту логіку, в якій він отримує вхідний напрямок, обчислює дельту, а потім змінює позиції X і Y компонента.
Отже, давайте подивимося на іншу систему, яка може бути розгорнута кимось іншим, навіть після того, як ми випустимо гру. Ось ще один приклад системи, яка реалізує ute. Тут позиція Z збільшується на 1, тому хтось намагається додати флангову систему, яка може бути інтерфейсом з іншим шаром поверх вашої гри.
Отже, ідея зараз полягає в тому, що всі ці системи, всі ці компоненти дійсно компонуються, користувачі гри більше не є простими користувачами, гра стала відкритою, масштабованою та постійною платформою. Тому я спробую виконати модульні тести, які я підготував у цьому прикладі, і я збираюся використовувати BOLT CLI, який побудований на основі Anchor, фреймворку смарт-контрактів для Solana, тому, якщо ви вже знайомі з Solana, вам не потрібно вивчати нічого нового.
Тепер ви можете розробляти програми на Solana, просто розробляти програми, тестувати програми, тому тут я запускаю bolt build і bolt test, і тут я розгортаю нашу програму, а потім я роблю тест типу, який я підготував тут.
Отже, тут тест надсилає транзакцію для ініціалізації нового світу. Ми реєструємо кілька об'єктів, приєднуємо до деяких з них компоненти локації, а потім, можливо, найцікавіше те, що тут роблять деякі системи. Отже, тут ми викликаємо функцію apply, а потім використовуємо одну з цих систем. Отже, ось лише система за замовчуванням.
Тут ми викликаємо простий хід, а потім ми летимо сюди. Ну а тепер, якщо ми подивимося на логи тесту, то в першій угоді тут ми використовуємо рухому систему з висхідним напрямком, збільшуючи позицію Y на 1. У другій транзакції ми використовуємо ту саму систему, щоб рухатися вправо, а потім, нарешті, виконуємо систему польоту, яка робить протилежне, збільшуючи нашу позицію Z на 1. Це лише простий приклад, але він пропонує дуже потужну механіку, яка дозволяє будь-кому розвивати, розширювати та потенційно робити вашу гру цікавою.
06.Ефемерний зведення
Тепер, коли ми повернемося до слайда, я збираюся описати другий цікавий аспект фреймворку BOLT, який є нашим рішенням для масштабованості, яке ми називаємо Ephemeral Rollup.
Прийнято вважати, що Solana вже дуже швидка і дешева, і що в даний час вона генерує блок кожні 400 мілісекунд і може обробляти тисячі транзакцій, тому вона фактично готова до створення повноцінної гри. Однак, якщо у вас є старий логічний ланцюжок для мультиплеєра, оновлення локацій буде відбуватися занадто повільно.
Таким чином, ми можемо побудувати короткочасний шар прискорення, який повністю сумісний з часом роботи Solana. Використовуваний час необов'язковий, він може служити реальним прискоренням тієї чи іншої операції, при цьому більша частина логіки все одно виконується на головному ланцюжку, тому він спирається на ту особливість, що весь стан на Solana зберігається в обліковому записі.
Як правило, у вас є ігрова програма, яка визначає логіку, а потім весь стан буде зберігатися в цьому обліковому записі, тому ми можемо делегувати деякі з цих облікових записів цьому ефемерному шару, який використовує рушій BOLT.
У цьому прикладі є два авторизовані облікові записи, які зберігають місцезнаходження гравця, і провайдер активно прослуховує запити на делегування та ініціалізацію. Він збирається розпочати новий час виконання за потреби, який є швидким, настроюваним, не може мати газових транзакцій або тиків, і дозволяє нам дійсно здійснювати транзакції нижче 50 мс і, можливо, масштабуватися, маючи кілька виділених часів виконання.
Інша цікава частина полягає в тому, що всю цю складність можна абстрагувати від користувача. У нас є маршрутизатор RPC, який по суті схожий на традиційний маршрутизатор RPC. Клієнт RPC може безпосередньо взаємодіяти з RPC для надсилання транзакцій. Оскільки в Solana всі транзакції попередньо оголошені для всіх змінних і читабельних облікових записів, маршрутизатори RPC можуть, по суті, направляти транзакції, запити даних і отримання даних на правильний рівень.
Потім у якийсь момент Ефемерний шар (як випливає з його назви) буде закрито, і всі стани будуть врегульовані на базовому рівні Solana, за що відповідає секвенсор, який відстежує всі облікові записи.
Інший погляд на цей механізм полягає в тому, що у нас є два рівні, і вони виконують транзакції паралельно. У нас є делеговані облікові записи, які дозволяють нам оновлюватися з меншою затримкою, не використовуючи пропускну здатність основного ланцюга. А ще у нас є інші акаунти, які не делегуються, а виконуються в основному ланцюжку.
Зараз дуже цікаво те, що програми, інструменти, фреймворки та інфраструктура знаходяться в основному ланцюжку. Вам не потрібно розгортати програму в Rollup, хоча це поширене явище в багатьох інших архітектурах. Все знаходиться на одному рівні, все можна компонувати, і, як ми вже згадували, це спеціалізоване середовище виконання також розширюється і може бути дійсно налаштовано.
Тепер це відкриває абсолютно нову категорію ігор, які він будує на блокчейні та мають низьку затримку. Так само, як і з традиційним багатокористувацьким сервером, але все ще здатний поєднуватися з усім, що доступно в екосистемі рівня 1.
Ви отримуєте доступ до існуючої ліквідності, можете надсилати повідомлення через протоколи, карбувати NFT, використовувати абстракції акаунтів, сесійні ключі, таблиці лідерів та єдину екосистему, всі збагачують одну екосистему.
Велике спасибі за увагу. Ви можете зареєструватися для отримання раннього доступу до нашого фреймворку за допомогою QR-кодів і перевірити репозиторій. Ви вже можете знайти надійну документацію та офіційні документи, які детально описують структуру, яку ми щойно представили. Дуже тобі дякую.