S&Box DevBlog Декабрь 2020

[OriginalShaman]

S&Box DevBlog Декабрь 2020

*Повествование ведется от первого лица, так как текст - это перевод с официального сайта разработчика игры.

Привязка (Garry)

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

Поэтому я предпринял дополнительные шаги, чтобы сделать ее простой в использовании на этот раз.

 

Шейдеры (Sam)

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

Мы ожидаем, что создатели аддонов будут компилировать их в автономном режиме и включать их так же, как они включали бы текстуры или модели в свои пакеты аддонов.

УЛУЧШЕНИЯ НАЧИНАЯ С SOURCE 1

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

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

ДЕЛАЕМ ШЕЙДЕРЫ ПРОЩЕ

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

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

Теперь весь рабочий процесс шейдера — это замкнутый цикл, от создания до распространения.

 

 

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

 

 

 

 

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

 

 

VFX

О да, Source 2 использует новый исходный формат шейдера, на ядре это все еще HLSL-код, только предварительно обработанный в их синтаксис и выставляющий множество помощников.

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

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

Например, я играл с ним для создания тестового вершинного шейдера для blob меша

 

 

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

ДИНАМИЧЕСКИЕ ВЫРАЖЕНИЯ

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

Это несомненно то, что мы собираемся расширить в будущем.

ЭФФЕКТЫ ПОСТ-ОБРАБОТКИ

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

Эффекты постобработки могут варьироваться от простых эффектов виньетки до некоторых сумасшедших идей, которые вы можете найти в чем-то вроде Reshade, только лучше, потому что вы действительно контролируете все.

В БЛИЖАЙШЕМ ВРЕМЕНИ

Мы еще за многое в конвейере можем рассказать игрокам, и это должно быть сделано самым разумным способом.

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

Физические Ограничения(Layla)

В Source 1 все ограничения были некого рода скрыты от нас. Единственный способ получить к ним правильный доступ - через энтити. Это означало, что каждое ограничение, добавленное в GMod, на самом деле было энтитей.

На этот раз ограничения могут быть добавлены и доступны непосредственно из физического мира. Это делает API приятным и чистым.

Мы используем дизайн конструктора для API ограничений, вот пример:

 

 

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

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

 

Вы можете подумать, является ли сварной шов шатким, как желе, или жестким и твердым, как вы всегда мечтали?

Сварное соединение не является идеально жестким, поэтому его следует использовать только в качестве фиксированного ограничения.

 

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

Сварные швы все еще имеют некоторые классные применения, их можно использовать для изготовления физгана!

 

Инвентарь (Garry)

Для меня важно, чтобы мы не делали предположений о том, какие игры будут сделаны с s&box. Я не должен хардкодить слот в стиле HL2 и систему инвентаризации ведер и ожидать, что каждая игра будет использовать его.

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

Каждая сущность имеет элемент инвентаря, который по умолчанию равен null.

 

 

Если он не равен null, то когда энтити получает новый дочерний элемент или удаляется дочерний элемент, она сообщает об этом инвентарь.

 

 

Так что теперь любой класс, который вы установили в качестве своего инвентаря, отвечает за эту логику. Я закодировал простой класс инвентаря, который, как я предполагаю, удовлетворит 90% потребностей людей, но весь этот код является аддонновым, так что вы можете посмотреть на него, вывести из него или просто создать свой собственный класс.

Система инвентаризации отвечает за две основные задачи.. ведение списка энтитей в инвентаре игрока и обработка активной энтити. Активная энтити - это та, которая находится в ваших руках, та, которая выбрана.

Оружия (Garry)

В гмоде система оружия была основана в движке на CBaseEntity. В S&box мы даже не используем нативные классы. В S&box оружие - это просто энтити с кучей реализованных интерфейсов.

Система оружия на самом деле глупо проста. Он основан на системе ActiveEntity.

 

 

Эта функция вызывается во время тика игрока. Если у вас есть ActiveChild и это IPlayerControllable, он также будет тикать.

Так что на вашей энтити пушки вы можете делать такие вещи.

 

 

Вьюмодели(Garry)

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

Так что после нескольких дней попыток найти в этом смысл, я сделал их полностью клиентскими. Я рассуждаю это так: они должны вести себя как HUD, как будто они нарисованы на экране.

Это сделало вещи в миллиард раз проще... и хотя есть вещи, которые, я знаю, нам придется ускориться, это работает именно так, как я ожидал.

Вот некоторые кодовые переменные.

 

 

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

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

 

 

 

Замена Панорамы (Garry)

Вспомните тот блог, где я рассказывал о том, как великолепна Панорама и как сильно я ее люблю. Что же, в этом месяце я распорол ее и заменил самодельной системой на C#.

ПОЧЕМУ

Я знаю себя. Я знаю, что в конце концов сделал бы это. Проще и лучше переписать его на c#, чем исправить то, что меня раздражает в c++.

ЧТО ИЗМЕНИЛОСЬ

Система компоновки теперь основана на yoga, так что все это основано на flex. Панорама имеет нестандартную систему компоновки, которая является своего рода flex'ной, но она не так мощна/полна, как правильный flexboxing. (Любой, кто попросит поддержки сетки, может быть выебан имхо)

CSS-переходы в Панораме подключены в обратном направлении, поэтому, если у вас есть переход, установленный на :hover, он использует этот переход, когда вы не ховерите. Есть куча таких мелочей, которые сами по себе ничего не значат, но заставляют вас спотыкаться, когда вы работаете с ними, и все они начинают складываться.

Такие вещи, как ивент указателя и работа курсора.

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

ПРИНУДИТЕЛЬНЫЕ ПРИВЯЗКИ

Делая это, мы имели очевидное преимущество, заставляя нас связывать кучу вещей для рендеринга и получения / управления входными данными. Чем больше вещей мы перемещаем в область аддонов, тем больше вещей связывается.. что означает больше функциональности для моддинга.

Суммарно

Достаточно много в этом месяце много довольно низкоуровневых фундаментальных вещей. Я действительно доволен нашей скоростью. Такое чувство, что каждый шаг вперед, который мы делаем, также увеличивает нашу скорость на 20%.

Все, что мы реализуем, делает реализацию кучи других вещей в миллион раз проще.

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