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

Але ці потужні ідеали залишаються осторонь, оскільки ми ще не бачили їх на практиці. MUD - це перша смілива спроба створити повноцінний фреймворк для мережевих ігор, іскра, яка може запалити наступне покоління ігор. Це не нездійсненна мрія. За короткий період свого існування команда MUD відповідальна за OPcraft - справжню 3D-гру на тему Minecraft, яка повністю працює в мережі.

Уроки традиційної ігрової індустрії

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

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

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

Важко точно встановити чітку межу між ігровими рушіями та самими іграми. Загалом, ігрові рушії - це фреймворки з набором правил і шаблонів проектування, які можна дещо модифікувати та розширювати для створення різних реалізацій ігор. У 90-х роках, після багатьох років фрагментарної розробки ігор, щось змінилося, і "жанрові" ігрові рушії та деякі спроби розробити рушії загального призначення зайняли лідируючі позиції. Такі ігри, як Doom та Unreal, мали базові компоненти, які можна було повторно використовувати для створення багатьох інших ігор. Ігри зі схожими жанрами почали ділитися багатьма своїми основними логічними імплантаціями. Вартість і складність розробки гоночних ігор, файтингів і шутерів від першої особи знизилися на порядки. Неможливе стало можливим, і покоління ігор та оновленого коду накопичувалися одне на одному. З точки зору програмного забезпечення, це одна з головних причин, чому розробка ігор стала величезною індустрією.

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

1. Відсутність фреймворків: Кожна команда намагається побудувати все з нуля, що призводить до низької ефективності та відсутності системних знань, що випливають із сукупного досвіду будівельників, які вирішували ті самі проблеми та оптимізували свої рішення.
2. Відсутність можливості повторного використання коду: Візьміть хоча б багато мережевих ігор, що розробляються сьогодні. Скільки з них можна успішно скопіювати, щоб створити дещо інші ігри? Скільки з них мають чітке розмежування між різними шарами та компонентами гри, що дозволяє створювати нове покоління зі схожою кодовою базою? Обіцянка створити найбільш значущий і взаємопов'язаний проект з відкритим вихідним кодом для ігор здається далекою.
3. Відсутність можливості компонування даних: Повторне використання коду не закінчується. Йдеться також про здатність мережевих ігор використовувати спільний стан блокчейну для побудови один над одним, використовуючи дані гри А в грі Б. На практиці, щоб включити дані і логіку однієї гри в іншу, потрібно багато роботи і ресурсів.

Розчин MUD:

Mud - це перша смілива спроба створити рушій і фреймворк для мережевих ігор, забезпечивши структуру для супроводу, модернізації та формоутворення. Шаблон Entity Component System (ECS), який пропагує mud, має сенс не тільки в сенсі загальної розробки ігор, але навіть більше - для розробки онлайн-ігор.

ECS у смарт-контрактах:

Основними будівельними блоками в MUD є компоненти. Це розгорнуті контракти, які функціонують як бази даних, що зберігають дані про суб'єктів. Наприклад, візьмемо таку сутність (адресу), як гаманець гравця. Ця сутність, представлена адресою, може мати різні властивості, такі як position value(x,y) у компоненті position, level 10 у компоненті level і 50 у компоненті coins . Компоненти складаються лише з відображення та базової конфігурації. Системи складніші і реалізують логіку зміни вартості в компонентах. Ви можете думати про це як про системну специфіку API для POST-запитів до баз даних (компонентів). Вони могли б це зробити лише за умови надання доступу на запис до певних компонентів. Тут починається найцікавіше. Системи можуть взаємодіяти з різними компонентами для створення детальної логіки. У вас може бути система пересування, яка визначає допустимі рухи, які може зробити гравець (наприклад, два кроки кожного разу), і система винагороди, яка дає гравцям монети кожного разу, коли вони підвищують рівень. Всі вони зареєстровані у "World contact" таким чином, що кожна зміна даних про компонент супроводжується випромінюваною подією. Світові контракти - це беззаконня. Будь-хто може додавати нові системи та компоненти. Теоретично, різні світи можуть взаємодіяти один з одним.

Використання ECS в мережевих іграх призвело до створення дуже елегантної структури, так що OPcraft складається лише з 10 компонентів і близько 15 систем. Ви можете прочитати цю чудову статтю в блозі на MUD.dev

Справжня сумісність

Система ECS має сенс не тільки в традиційній розробці ігор, але й у мережевих іграх, надаючи дві важливі функції

1. Можливість оновлення розгорнутої гри
2. Найвищий ступінь сумісності

Уявіть собі два шляхи. Одна з них - зберегти базовий дизайн. А другий - зміна основної ігрової логіки.

Подумайте про стандартну PVP-стратегію, в якій гравці можуть створювати армії, щоб битися один з одним. Базова версія була 2D, але тепер команда вирішила, що хоче створити детальний 3D-рендеринг гри. Все, що їм потрібно зробити, це взяти всі системи, пов'язані з позицією, і створити оновлені версії з координатами (x,y,z) замість (x,y). Всі інші системи і компоненти (наприклад, система атаки, HP і побудова армії) можуть залишатися незмінними. Це навіть виходить за рамки початкових команд розробників, спільноти можуть створювати різні моди гри, перерозподіляючи системи та компоненти, або навіть взаємодіяти з тими самими компонентами, надаючи доступ до написання нових систем (якщо це гра, що належить спільноті, для прийняття таких рішень можуть застосовуватися різні моделі управління).

Інший підхід збереже ті самі компоненти та системи, не надаючи новим системам доступу до запису. Але з доданими компонентами та системами для розширення функціональності гри, як вона може виглядати? Розглянемо базову ланцюгову шахову гру. Системи рухів і правил вже розгорнуті. Люди можуть грати в гру так, ніби вони грають в реальні шахи, але, можливо, ваша команда вирішить, що вам потрібно створити додатковий рівень, соціальний, який складається з рейтингової системи для пошуку партнерів або будь-якого іншого використання. Все, що вам потрібно зробити, це додати компонент рейтингу та систему з правилами рейтингу. Це призводить не тільки до дуже плавного переходу на нові версії гри (покращений UX), але й створює технічні засоби для співіснування різних версій пліч-о-пліч або одна над одною на рівні смарт-контрактів. Гравці можуть перебувати в різних версіях гри, взаємодіючи з одними й тими самими даними основних компонентів, що є дуже інноваційним, якщо не брати до уваги застосування композитності. Це створює функцію незмінності вибору, створюючи ще один вимір власності, який надавали б ігри в мережі. Справжнє володіння різними ігровими активами (такими як рахунок, NFT, досягнення), що забезпечується незмінною логікою, яка може бути розширена за допомогою додаткових оновлень, але не змінюється в своїй основі. Він вирішує одну з головних проблем web3-ігор, яка полягає в тому, що творці можуть забирати активи без згоди гравців.

Загальна перспектива з боку клієнта:

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

Досі ми розглядали MUD на рівні смарт-контрактів. Але це ще не все. MUD надає повний набір клієнтських бібліотек та шарів. Існує кілька унікальних функцій, для яких розроблено MUD.

1. Зручність роботи з клієнтом
2. Клієнт повністю синхронізований зі зміною стану блокчейну (ігрові дані)
3. PhaserX як шар візуалізації

Давайте зануримося в технічні деталі, щоб зробити це більш конкретним.

Мережевий рівень:

Мережевий рівень - це базовий рівень клієнта. Він містить базову конфігурацію (світовий контракт, гру та мережеву конфігурацію) та API для ігрової взаємодії. Коли мережевий рівень створено, він містить специфікацію всіх різних компонентів і систем, з якими ваш клієнт зможе взаємодіяти, і ви можете вибрати взаємодію лише з певними компонентами/системами. Наприклад, якщо ви хочете створити рух у вашій грі і надати йому представлення у фронтенді, вам потрібно створити мережевий рівень, який синхронізується з розгорнутим смарт-контрактом компонента позиції, а також з системою руху. Тепер ви можете створити Move API, який приймає позицію і деякий ігровий об'єкт (сутність) і встановлює його позицію або переміщує його з одного місця в інше. Гравці можуть використовувати Move API будь-коли. Вони збираються відправити транзакцію в блокчейн. У випадку з системою пересування, вони будуть виконувати функцію в рамках смарт-контракту системи пересування.

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

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

По-перше, MUD реалізував функцію моментальних знімків, яка дозволяє клієнту синхронізуватися зі станом світу (тобто значеннями сутностей за компонентами) без обробки всіх минулих подій для реконструкції стану, що призводить до низької затримки та зменшення складності.

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

Рівень рендерингу - коли і як відбувається рендеринг подій

MUD постачається з PhaserX, "високомасштабованим рушієм, побудованим на основі фазера", PhaserX не є обов'язковим. В OPcraft замість PhaserX використовується воксельний рушій Noa. Теоретично, ви можете використовувати будь-який движок, якщо він відповідає структурі.

Як зазначалося раніше, кожен компонент і система зареєстровані у світовому контракті, і коли відбуваються зміни, відбувається подія (з ідентифікаційними даними, такими як ідентифікатор компонента та ідентифікатор організації). Тут потоковий сервіс ECS може надати клієнту можливість вибрати, на які події він хоче підписатися.

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

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

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