Будущее сетевых игр: "Перспективы движка MUD ECS

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

Но эти мощные идеалы остаются в стороне, поскольку нам еще предстоит увидеть их на практике. MUD - это первая смелая попытка создать полноценный фреймворк для игр на цепочке, искра, которая может зажечь следующее поколение игр. Это не несбыточная мечта. За свой недолгий период существования команда MUD отвечает за OPcraft - настоящую 3D-игру на тему Minecraft, полностью основанную на цепочке.

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

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

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

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

Трудно провести четкое различие между игровыми движками и самими играми. Как правило, игровые движки представляют собой фреймворки с набором правил и шаблонов проектирования, которые могут быть слегка изменены и расширены для создания различных игровых реализаций. В 90-х годах, после нескольких лет разрозненной разработки игр, что-то изменилось, и на первый план вышли "жанровые" игровые движки и некоторые попытки разработать движки общего назначения. Такие игры, как Doom и Unreal, имели основные компоненты, которые можно было повторно использовать для создания множества различных игр. Игры со схожими жанрами начали разделять многие из своих основных логических имплантов. Стоимость и сложность разработки гонок, файтингов и игр-стрелялок от первого лица снизились на порядки. Невозможное стало возможным, и поколения игр и модернизированного кода накапливались друг за другом. С точки зрения программного обеспечения, это одна из главных причин, по которой разработка игр стала огромной индустрией.

Существует несколько основных проблем, связанных с играми на цепочке:

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

Решение MUD:

Mud - это первая смелая попытка создать движок и фреймворк для игр на цепочке, обеспечив структуру для ремонтопригодности, модернизации и лепки. Модель Entity Component System (ECS), которую пропагандирует mud, имеет смысл не только в смысле общей разработки игр, но и тем более для разработки игр на цепочке.

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

Самые основные строительные блоки в MUD - это компоненты. Они представляют собой развернутые контракты, которые функционируют как базы данных, хранящие данные о сущностях. Например, возьмем такую сущность (адрес), как кошелек игрока. Эта сущность, представленная адресом, может иметь различные свойства, такие как значение позиции(x,y) в компоненте position, уровень 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 для игровых взаимодействий. Когда создается сетевой уровень, он содержит спецификацию всех различных компонентов и систем, с которыми будет взаимодействовать Ваш клиент, и Вы можете выбрать взаимодействие только с определенными компонентами/системами. Например, если Вы хотите создать движение в своей игре и дать ему представление на фронтенде, Вам нужно будет создать сетевой слой, который синхронизируется с развернутым смарт-контрактом компонента позиции, а также с системой движения. Теперь Вы можете создать API Move, который принимает позицию и некоторый внутриигровой объект (сущность) и устанавливает его положение или перемещает его из одного места в другое. В любое время игроки могут использовать API Move. Они собираются отправить транзакцию в блокчейн. В случае с системой движения они будут выполнять функцию в рамках смарт-контракта системы движения.

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

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

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

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

Уровень рендеринга - когда и как происходит рендеринг событий

MUD поставляется с PhaserX, "высокомасштабируемым движком, построенным поверх phaser", PhaserX не является обязательным. В OPcraft вместо PhaserX используется воксельный движок Noa. Теоретически, Вы можете использовать любой движок, который Вам нравится, если он соответствует структуре.

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

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

Отказ от ответственности：

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