Поиск сообщества

S&Box DevBlog Июль 2021 *Повествование ведется от первого лица, так как текст - это перевод с официального сайта разработчика игры. “Хедлайнерами этого месяца являются предикция и загрузка аддонов, но мы сделали массу вещей” Ввод курсора (Garry) Layla играется с какой-то штукой, для которой нужен был старый ввод курсора в стиле контекстного меню GModа, поэтому я ему его сделал. Присоединение к игре друга Играть с друзьями должно быть просто. В этом месяце я написал кучу всего в серверном лобби и RPC, чтобы действительно легко присоединяться к игре друга. Я уже упоминал об этом в предыдущих блогах, но думаю, что это важный момент. Если вы создадите игру, то люди смогут присоединиться. Вам не нужно будет играться с брандмауэром, оно просто будет работать. Предикция У меня вся предикция работает. Я откладывал это на пару месяцев, потому что думал, что это будет заноза в заднице, в конце концов это заняло 2 дня и было не так уж плохо. ЧТО ТАКОЕ ПРЕДИКЦИЯ В общем, по-быстрому объясню как предикция работает в Source. Клиент создает пользовательскую команду, которая представляет собой структуру, описывающую входные данные игрока. Основные данные, такие как кнопки и углы прицеливания. Он посылает эту пользовательскую команду на сервер, и сервер перемещает игрока, стреляет из пистолета и т.д. Во время отправки на сервер он также запускает его локально, поэтому все, что вы делаете, происходит мгновенно. Когда сервер запускает свою версию и мы получаем результаты, мы сравниваем их с результатами нашей предикции. Если все получилось, то игрок должен находиться в одном и том же месте, оружие должно иметь одинаковое количество патронов и т.д. АТРИБУТЫ Любые переменные, которые вы используете во время предикции, должны быть помечены как предикция. Если переменные не помечены как предикции, это может привести к дальнейшим ошибкам предикции, потому что клиент не сможет получить хорошую отправную точку, где он синхронизирован с сервером. Здесь нет ничего сложного, это как и любая другая сетевая переменная. ПЕРВЫЙ РАЗ Если есть ошибка предикции, клиент может вернуться назад и пересчитать несколько кадров назад, чтобы вернуть все на места, где оно должно быть. Когда предикция рассчиталась, вы не хотите делать такие события, как повторное воспроизведение звуков. Для этого мы создали защиту от дурака Predict.FirstTime. Оно всегда имеет значение true на сервере, но на клиенте принимает значение true лишь в том случае, если кадр прогнозируется впервые. ОТКЛЮЧЕНИЕ Когда ты стреляешь, проигрывается звук. Этот звук прогнозируется локально, но когда кадр воспроизводится сервером, звук проигрывается всегда. Мы немного подшаманили за кулисами, чтобы предотвратить проигрывание этого звука снова, если он был спрогнозирован локальным клиентом. Но иногда ты воспроизводишь какой-то код только на сервере.. Ну, например, если ты делаешь выстрел и кто-то помирает, то наверное стоило бы звуку проиграться для всех - в том числе для локального игрока - потому что они не могли спрогнозировать этот звук. В таких ситуациях используется Prediction.Off() чтобы выключить предикцию. Он создает IDisposable, с которым легко охватить его. Мне не очень нравится этот синтаксис, потому что мы все-равно должны проводить проверку, воспроизводится ли код на сервере, поэтому синтаксис может измениться. Обновленный Эффект Свечения(Sam) Гарри хейтил L4D-подобный эффект свечения, который был по дефолту с движком, поэтому я переписал его, вдохновляясь нашим Facepunch.Highlight эффектом свечения меша, выводящемуся в HDR, потому само свечение получается естественным образом от интенсивности контура, что хорошо помогает ему выделиться. Весь эффект достаточно легко настраивается, можно указать, аддитивен или прозрачен ли он, и сейчас он распознает глубину, видимую и скрытую часть свечения можно изменить, чтобы, к примеру, предметы, которые держатся физганом становились частично видимыми, когда закрыты каким-либо препятствием. Чтобы свечение так работало, нужно просто чтобы видимые и скрытые части имели одни и те же параметры. Можно сделать кучу всякого интересного с этим эффектом, он позволяет разработчикам создавать что-то неожиданное, например, если ты делаешь игровой режим в стиле Хищников / Зомби, ты можешь запросто использовать его чтобы создать что-то вроде волхака. Улучшения ModelDoc(Layla) В этом месяце я сделал еще несколько улучшений в ModelDoc. ModelDoc - инструмент, используемый для создания/импорта моделей в Source 2. МНОЖЕСТВО БИНД ПОЗ По умолчанию в ModelDoc FBX импорт поддерживает только одну бинд позу. И это вероятно хорошо, если вы делаете свои модели на заказ.. Но если вы, как мы - импортируете модели из других мест, вы столкнетесь с проблемами. ViewModel Арбалета из Rust был сломан из-за этого, теперь он пофикшен. VIEWMODEL РЕЖИМ Теперь есть режим камеры “ViewModel”, который просто блокирует обзор на нули, это полезно для того, чтобы увидеть, как выглядит ваш viewmodel в игре, и если вам нужно будет его сместить. Вероятно есть и другие полезные режимы камеры, которые я могу добавить в будущем. ИМПОРТ SOURCE МОДЕЛЕЙ Я добавил поддержку для импорта моделей из первого Source. Конечно спорно, должны ли мы вообще включать это в S&box, потому что нам хочется поощрять создание новых ассетов, а не портирование старых. Однако, я вижу это так: люди все равно будут портировать старые ассеты и я бы не хотел, чтобы люди качали какие-то старые паленые MDL декомпиляторы ФИКС PhysicsHullFromRender Раньше это не работало. Не визуализировалась или не рассчитывалась информация о массе, потому я это исправил. EntityIO(Garry) Каждый, кто достаточно глубоко погрузился в маппинг с использованием Hammer, наверное знает о Entity IO. Это система, которая позволяет связать выходы энтитей со входами других энтитей. К примеру, можно вызвать выход на кнопке, названной “OnPressed” ко входу света названного “Toggle”, и кнопка будет включать или выключать свет. В этом месяце я перенес это в C#. Чтобы создать вход на энтити, нужно просто отметить его с помощью атрибута “Input”. И чтобы запустить выходы, нужно просто вызвать “FireOutput”. Здесь есть чего еще доработать, но все работает так, как вы и ожидали. ПЕРЕДАЧА ФАЙЛОВ Изначально, здесь не было никакого кода для передачи файлов с сервера на клиент при его подключении, поэтому я чутка накодил. Этот метод получения файлов с сервера через сетевой сокет игры не идеален, но работает неплохо, как метод крайнего случая. Идеальный сценарий в релизе - это загрузка файлов в аддонах, или скачивание с вебсайта. Таким образом мы сможем поддерживать несколько загрузок одновременно, и все будет грузиться гораздо быстрее. Это то, как оно должно работать в 99% случаев и обязательно будет поддерживаться. Но мне кажется, что загрузка с сервера важна при разработке аддона. Если я делаю игровой режим и люди на моем сервере не хотят грузить аддон со свежими изменениями - они должны получить их в реальном времени. И это то что происходит сейчас. Если я меняю таблицу стилей на моем сервере, клиенты будут оповещены об этом, и в итоге осознают, что у них нет того нового файла, и затем загрузят его с сервера. Когда они загрузят его, он будет загружен “на горячую”, и все будет снова синхронизировано. Иметь возможность редактировать в реальном времени имеет огромную разницу. Таким образом преобразуется процесс разработки. Игроки на сервере становятся лабораторными крысами, реагирующими на каждую перемену разочарованием или радостью. Разработка превращается в игру. Асинхронная Стратегия Какое-то время я пытался понять, как же работает асинхронизация, но затем начал разбирать все это по полочкам на этой неделе. Вот вам FAQ. ЧТО ТАКОЕ АСИНХРОНИЗАЦИЯ Это позволяет воспроизводить вам функции асинхронно Таким образом, если вызвать функцию сверху, она будет воспроизводиться до await, затем <секунд> секунд позже она воспроизведет Toggle(). Может быть, это не так примечательно само по себе, но можно связать эти вещи. Также они могут возвращать значения, таким образом можно ожидать значение из функции - что довольно-таки полезно для вещей, вроде вызова API. ЭТО МУЛЬТИПОТОЧНОСТЬ? По умолчанию, это сделано так что это будет воспроизводиться на основном потоке, но возможно воспроизводить задачи и на других потоках. КАКОВА СТРАТЕГИЯ? Думая о задачах для аддонов, мы должны подумать о паре вещей. Во-первых, если использовать Задачу на энтити, и энтити удалена, что должно произойти. Я хочу обуздать это хорошим и автономным способом. Я не хочу страдать с CancellationTokens и прийти к тому, что асинхронизация станет невыносимо долгой. Также, если вы воспроизводите задачу и затем отключаетесь с сервера, задача должна отмениться. У нас не должна оставаться куча задач, воспроизводящихся в меню после отключения от игры. Существующие по умолчанию функции типа Task.Delay воспроизводятся в реальном времени, а мы, вероятно, хотим использовать внутриигровое время по умолчанию. И в конце концов, мы хотим иметь возможность возобновиться в какое-то конкретное время. Ну, например, может вы хотите подождать до начала следующего кадра, или до конца, или до следующего тика, или на следующий кадр физики. И КАК С ЭТИМ ДЕЛА? Мне кажется, у нас есть неплохое, сбалансированное решения для всех этих вещей. Использование Игроком В этом месяце я реализовал использование кнопки игроком. Я говорю о кнопке Use у игрока, но в целом она универсальна, так что технически NPC тоже могут ее использовать. Чтобы сделать объект пригодным для использования, вы просто подключаете этот интерфейс. Автозаполнение Я добавил автозаполнение в стандартное поле “TextEntry”. Он также может иметь историю на базе файлов cookie, так что история сохраняется между игровыми сессиями. Я сделал это для консоли, но оно доступно для использования всем.. Реализация Энтитей Вместо использования нативных энтити, нам лучше всего перенести их в C#. Такое чувство, что у нас есть возможность здесь, начать с чистого листа, удалить и очистить все, чтобы сделать их более осмысленными Я не думаю что у Valve была эта роскошь, я предполагаю, что они должны поддерживать демки, сохранения, карты десятилетней давности, они не могут проебать это все. Поэтому в этом месяце в качестве первого шага, я конвертировал энтити дверей, кнопок, и освещения в C#. Это раскрыло еще больше энтитей, которые я бы хотел перенести в C#. Нативный код имеет “MOVETYPE_PUSH“ систему, где энтити(как двери) двигаются, но и толкают энтити. Они могут убивать энтити, которые блокируют путь и т.д. Это система, которая нам нужна, потому что мы действительно не хотим делать такие вещи, как контроллеры игроков / npc базирующиеся чисто физически. Но я также думаю, что это система, которую нам лучше реализовать на C#, так что мы можем манипулировать ею немного легче. Из чего-то такого, что появилось, было платформами и лифтами. Эти вещи движутся весьма предсказуемо на уровне кода, но у них нету предикции. Я думаю мы можем исправить это, чтобы сделать их очень плавными. Голосовой чат(Layla) Голосовой чат это нечто, что уже было в Source 2, но как и большинство фич - если оно связано с геймплеем, в идеале мы хотим перенести это в C#, чтобы начать с нуля и иметь полный контроль над этой фичей. Игрок может записывать вход с микрофона, который передается на сервер, эти две функции ниже являются виртуальными функциями в игровом режиме. Существует серверная функция для входящих голосовых данных, и ваш игровой режим может затем решить, кто будет их слышать Затем есть функция на стороне клиента для голосовых данных, отправленных сервером. Здесь у вас есть возможность делать с ними что угодно, прямо сейчас это базовый вывод аудио, но когда мы углубимся в звуковую сторону движка, я уверен, что будет много классных фильтров, которые мы сможем использовать для воспроизведения звука. Рендер захвата сцены Мы хотели получить способ рендера 3D объектов на UI. Можно разделить это на две части. Первая часть заключается в том, что сцены, которые ты хочешь отрисовать на UI, в идеале, не должны существовать в основной сцене, ведь будет не очень круто спавнить энтити в основной мир и прятать его лишь ради того, чтобы отрисовать его на UI Вместо этого, новые миры - сцены могут быть созданы и объекты сцены добавлены к ним. Объекты сцены являются по сути тем, что вся игра использует для рендера мира, поэтому их можно просто использовать без расходов на создание новых энтитей. Вторая часть заключается в том, чтобы иметь возможность рендерить мир сцены на цель рендера. Как только есть цель для рендера, эта текстура может быть просто отрисована на UI Поскольку у нас есть доступ к объектам сцены, они также могут быть помещены в основной мир сцены. Представьте себе бильярдный стол: вместо создания по энтити на каждый шар, можно просто добавить их как объекты сцены и они будут рендерить модель также, как если бы это была энтити, но без всей лишней херни, которая вам не нужна. Эти объекты моделей сцены могут быть анимированы, но в данный момент API поддерживает только настройку костей. В следующем месяце я сделаю так, что их можно будет анимировать с помощью animgraph. Загрузки игровых режимов(Garry) Процесс установки - отстой. Представь, если бы тебе пришлось устанавливать вебсайт, который ты хочешь посетить. Такое мое отношение к игровым режимам и картам в S&box. В этом месяце у меня получился довольно жирный кусок работы по загрузке игровых режимов. Теперь игра будет автоматически загружать их с GitHub. Это веселый этап для меня, потому что это значит, что мы можем начать делать всякое и пробовать впечатлить друг друга. По большей части, это невидимо для конечного пользователя, в такой степени, что можно ввести “gamemode dm98” в консоль и затем “map testmap” и она автоматически установит dm98 и игра начнется в течение 5 секунд. Очевидно, загрузка до абсурдности быстрая, поскольку игровой режим весит только 500КБ, но держите в уме, что в этот маленький период загрузки отправляется запрос гитхабу на последнюю версию, загружается, разархивируется, компилируется и, наконец, запускается. МАСТЕРСКАЯ Разговоры о GitHub могут заставить людей волноваться, что мы больше не используем Workshop. Мы все еще собираемся использовать его, но как один из многих вариантов. Хотите ли вы загрузить игровой режим в Workshop, либо на Github, либо на свой собственный веб-сайт - не имеет значения, пока мы можем его скачать Баги, выявленные в игре Ранее в этом месяце, после того, как я расправился с предикшеном, мы немного протестировали игру, чтобы убедиться, что мультиплеер работает. Технически, в основном, он работал, но были и некоторые очевидные баги. ERROR МОДЕЛИ Много моделек были еррорками, потому что клиент не мог найти настоящие модели. Так случилось потому что модельки занетворчены как ResourceID, которые, в свою очередь, являются хэшами файловых имен и типов. Клиент имеет ResourceID, только если ресурс загружен. Я нашел кучу кода сетевого прекэша в движке, но он не был ни к чему привязан, поэтому я полностью снес его и перенес в C#. Это не то, о чем программист должен волноваться. Когда ты устанавливаешь модель для энтити, она добавляется в таблицу прекэша сети автоматически, которая, очевидно, отправляется на клиент, позволяя ему понять, что это за модель. ЧИТЫ Люди имели возможность использовать читы. В частности, Layla летал повсюду и спавнил ботов. Я попытался исправить это пару раз и у меня не вышло, потому все закончилось переписыванием большей части системы консольных команд. На самом деле, у нас было две системы консолей. Когда мы делали игру на Unreal Engine, я сделал нашу собственную систему консоли, которая была единственной системой консоли, которую мы использовали. Она в значительной степени отражала работу системы Source консоли. Теперь, когда мы используем Source 2, это имеет меньше смысла. Мы все еще хотим использовать консольные команды и консольные переменные, но единственная настоящая система консоли должна быть родной. Вот как это работает в данный момент. СМЕЩЕНИЕ ЭНТИТЕЙ У нас какое-то время был баг, когда клиентская энтити была смещена относительно серверной. Это можно наблюдать на картинке выше… зеленая сетка - серверная физика. Серебряная мусорка находится в самом конце карты для сервера, но для клиента она находится прямо перед игроком. Пока что, это нераскрытое дело, ожидающее расследования. Улучшения CSS Рендеринга(Sam) Я потратил довольно немало времени чтобы вернуться к элементам пользовательского интерфейса; рефакторинг; оптимизация и завершение некоторых незакрепленных итогов, это начинает казаться почти таким же, как если бы вы могли проектировать с полной силой CSS браузера сейчас, без гигантской массы фактического ношения браузера. Для каждого элемента мы делаем кучу тестов, чтобы убедиться, что все соответствует ожидаемому результату. CSSBOX CSSBox контейнер был почти целиком переписан, и границы, и сам “box” имеет очень хорошее, гладкое аналитическое субпиксельное сглаживание, оно выглядит особенно хорошо, когда оно анимировано, или движется динамически как в HUD, где есть динамическое перекрестие. РЕНДЕРИНГ ТЕКСТА Текст, включая рендеринг эмодзи, теперь очень четкий, раньше мы использовали некоторые хитрости, чтобы сделать его четче. И вы можете все видеть тесты что у нас есть для него: ГРАНИЦЫ КАРТИНОК Я также реализовал 9-сегментное масштабирование, вы можете использовать изображение в качестве границы вашего контейнера, и украшать его так, как вам нравится, игры типа MMO и RPG отлично используют его, вы можете спроектировать его так же, как и с CSS border-image параметром. Для референса, чтобы помочь визуализировать, используемое изображение в качестве 9-сегментной текстуры для тестирования границ выше выглядит примерно так: СООТВЕТСТВИЕ Даже когда мы добавляем больше поддерживаемых элементов, все эти элементы должны как можно лучше соответствовать W3C стандартам, большая часть знаний, которыми уже обладают люди, должна легко переводиться даже при составлении сложных эффектов при проектировании их пользовательского интерфейса на S&box, с тем преимуществом, что мы не несем на спине целый браузерный пакет. Карты Детматча(Louie) Я начал в Facepunch с экспериментов над картами для детматча, которые, надеюсь, выйдут достаточно универсальными, для использования в нескольких разных игровых режимах. Масштаб Карты Нам начала встречаться проблема с некоторыми ассетами из Rust, так как они имеют неоднозначные размеры. Большая часть ощущений от Source движка это неоднозначный масштаб для всего. И для того чтоб помочь нам с этим, я сделал карту для референса размеров при создании карт и моделей. Карты тестов объектов Гарри хотел несколько карт для тестирования кнопок, дверей, двигающихся платформ и пуш-тригеров. Эти карты были созданы до того как энтити были внедрены и были использованы для тестирования их во время разработки. CodeGen Оптимизации(Garry) При компиляции аддонов мы применяем поверх них codegen. Это модифицированная версия Source Generators и она добавляет кучу трюков которые мы используем с RPC и сетевыми переменными. Это занимало примерно 4 секунды на нашем базовом аддоне (у которого очень много файлов). Я переписал его и теперь это занимает 0.1 секунды. Виртуальный Скроллинг Когда у тебя огромный список чего-то в UI, ты часто сталкиваешься с проблемой что получается слишком много панелей. И не важно на сколько быстрая у тебя UI система, количество панелей всегда станет тем что сломает её. Виртуальный скроллинг решает это показывая только те панели что видимы. По мере прокрутки, панели что уходят из поля зрения - разрушаются, а те что появляются - создаются. Так что вместо создания панелей ты добавляешь данные в список. Потом ты просто говоришь какой тип дочерней панели создать. Итоги Еще один хороший месяц прогресса, хорошая скорость. Все обретает форму, где я хочу всё начать. У нас накопился большой список фич и ошибок, который расширяются каждый месяц, но самая большая оставшаяся задача - это серверная часть для регистрации игровых режимов/карт. Думаю, я смогу сделать это за день или два. Я говорю это в каждом девблоге, но в этом месяце я немного раздвоен по поводу выпуска раннего доступа. Часть меня хочет в течение месяца воздержаться и возиться с созданием разных игровых режимов. Если мы откроемся, я не думаю, что смогу это сделать, потому что надо будет работать над документацией, будут запросы фич и отчеты об ошибках. Но с другой стороны, будет больше людей, с которыми можно будет поиграть и поделиться. Думаю, я уговорил себя. Мы будем раздавать несколько ключей в Апреле.

S&Box DevBlog Февраль 2021 *Повествование ведется от первого лица, так как текст - это перевод с официального сайта разработчика игры. В этом месяце мы работали над системами декалей, свойствами поверхностей, звуками и тонной других вещей. Физика Упругости(Garry) Возясь со свойствами поверхности, я изо всех сил старался сделать объекты упругими. Если бы я хотел сделать мяч супер упругим, я мог бы увеличить его эластичность, но если бы он ударился о что-то другое, что было упругим, он выстрелил бы со скоростью миллион миль в час. Мне удалось подправить работу свойства эластичности, чтобы заставить упругость работать так, как мы хотим. Я не знаю, насколько это физически точно, но это позволяет нам делать упругую срань. Декали По соображениям производительности декали являются довольно захардкожеными, и их трудно заставить работать по пути моддинга как мы хотели. В этом месяце я придумал способ сделать их немного более модульными, и разработал API для их размещения. Так что теперь декали определяются как свободные файлы, как материалы. Они могут иметь несколько текстур, и вы можете определить очевидную срань как их размер, поворот, и т.д. Звуки Подобно декалям, звуки были в очень недружелюбном виде для моддеров. Теперь они являются свободными .sound файлами и редактируются таким же образом. У нас есть кое-какая работа, чтобы сделать этот интерфейс менее всратым, но вы поняли идею. Вы можете создавать и редактировать их во время работы игры, и они загружаются в горячем режиме, как и следовало ожидать. Эти звуки также появляются по всему редактору, поэтому, когда вам нужно выбрать звук в Hammer или ModelDoc - они есть Свойства Поверхностей Свойства поверхностей также хранились в некотором недружелюбном для моддеров виде. Так что теперь мы определяем свойства поверхностей в свободных файлах .surface, например так. Когда вы бросаете луч в игре, вы получите столкновение от поверхности, которое даст вам всю вышеприведенную информацию. Например, чтобы воспроизвести звук шагов DoFootstep - это расширение, которое живет в коде аддона. Мы помещаем его в код аддона, чтобы вы могли видеть, что он делает, и делать что-то еще, если вам это не нравится. Пользовательские Типы Ассетов Три вещи выше - это пользовательские ассеты. Вы сами можете задефайнить эти файлы. Вот что внутри sound.asset. Это FGD файл, который определяет структуру данных. Это позволяет вам создавать и редактировать материалы в редакторе ассетов Затем в вашем коде аддона вы создаете соответствующий класс, подобный этому: На этом все. Вы можете использовать их, как и любой другой ассет, и они автоматически загружаются. Они также интегрируются в систему ассетов Source 2, так что все это ощущается как часть движка. Это начиналось как только редактор для декалей, но я решил, что эти данные достаточно универсальны и легки, чтобы мы могли относиться к ним именно так, и попытаться сделать один редактор, который работает для кучи вещей.. таким образом, любые усилия, направленные на улучшение этого одного редактора, улучшают рабочий процесс тонны ресурсов.. так что это более вероятно. Hammer(2) На этой неделе я довольно часто пользовался Хаммером и чувствовал, как все старые тропы в моем мозгу восстанавливаются, когда я начал использовать горячие клавиши, которые никогда сознательно не помнил. Я столкнулся с несколькими проблемами (в основном исправляя вещи, которые я сломал), но я добавил пару новых вещей. Наши C# энтити теперь могут получать ключевые значения из карты. Для этого вы просто отмечаете одно из своих свойств с помощью [HammerProp], и оно автоматически устанавливается, когда объект создается картой. Однако это было бы бесполезно без добавления энтити вашего аддона в Hammer.. итак, теперь вы можете поместить fgd в папку config/ вашего аддона, и ваши пользовательские определения энтити будут доступны! Навмеш Я проделал кое-какую исследовательскую работу с навмешами, чтобы убедиться, что мы можем их использовать. Хорошая новость - мы можем. Большая часть навигационных путей привязана к базе сущностей NPC AI движка С++, которую мы не хотим использовать, но навмеш в основном абстрагирован. Это работает для нашего подхода, так как мы хотим связать голые основы и код как можно больше в c#. Вода + Плавание В коде есть много случаев, когда вам нужно проверить, находитесь ли вы в воде, и сделать что-то другое. По этой причине я хотел сделать это как можно скорее, чтобы нам не пришлось менять тонну кода после того, как мы его добавили. Физические объекты должны взаимодействовать с водой по-разному, некоторые вещи должны плавать, некоторые вещи должны тонуть, все движение должно быть смочено. Пули должны попасть в поверхность воды и продолжить свой путь. Под водой пули обычно действуют по-разному. Игроки должны двигаться под водой также по - разному. Они должны уметь плавать. Их вид нуждается в куче постобработки и тумана, звук на выходе должен быть более приглушенным. Source 2 не имеет ничего из этого, поэтому мы начинаем с нуля. В этом месяце я сделал все самое важное. Есть еще много вещей, которые нужно сделать, но я не хотел тратить целый месяц на создание идеальной воды. Эффекты от Выстрелов Свойства поверхностей позволяют определить, какие партикли должны появляться при попадании пули на определенную поверхность. Бесшовные Кубмапы (Sam) Отражения от карт окружающей среды(envmap) теперь рассматриваются скорее как непрямые источники света, а не назначаются каждому объекту, это позволяет нам сделать их незаметный переход не зависимо от того сколько их пересекается. Это не идеально, но это убедительное решение для игроков, художникам не нужно беспокоиться об их настройке. Шум(Garry) Я связал кучу шумовых функций, и мне захотелось посмотреть, что они делают, поэтому я быстро создал энтити, чтобы визуализировать их. Это довольно бесполезно для всех, но это выглядело круто. Улучшения Инструментов (Layla) Эти инструменты - огромный шаг вперед по сравнению с Source1, но я уверен, что есть еще много улучшений качества жизни, которые мы можем добавить, чтобы сделать их еще лучше. Вот некоторые изменения, которые облегчили нам жизнь в этом месяце. Теперь можно переносить fbx файлы из проводника в ModelDoc и добавлять их как «Render Meshes» Легкое создание материала с помощью ПКМ по картинке в браузере ассетов Импортируя меш в ModelDoc теперь можно выровнять его по min/max/center границам на каждой оси. Это полезно для тех случаев когда вы ходите чтобы ось модели находился в центре меша, но не был экспортирован таким образом Фильтр по типу в поиске браузера ассетов Вы можете принудительно поменять/применить веса Render Mesh к какой либо кости в ModelDoc Эксперименты с Транспортом Я запилил базовую физику транспорта. Она работает, прослеживая вниз на колесах и применяя пружинные усилия для подвески. Затем я могу приложить силы к телу, чтобы заставить его двигаться. Я портировал модульные транспортные ассеты из rust. Это не идеально, но это одна из многих попыток. Все это на C#, на уровне аддона, так что вы сможете создать свою собственную физику автомобиля. Сейчас нет хорошего способа водить машины, так что это то, над чем мы будем работать. Глубина Резкости (Sam) Я также реализовал настраиваемый эффект глубины резкости, сейчас он немного медленный и в некоторых случаях поломан, но результаты, которые мы получили с ним до сих пор действительно впечатляют. Если вы программист игрового режима, вы можете просто включить его, изменив значения диафрагмы в объекте камеры, как вы сделали бы это с любой физической камерой, и так же просто, как изменить FoV. Deathmatch(Garry) Я работал над игровым режимом deathmatch, добавляя новое оружие и решая, что еще нужно сделать. Конечная цель для этого - быть играбельным, чтобы быть хорошим тестом для всей системы аддонов gamemode. У меня есть код на Github. Я пытаюсь разрабатывать его как обычный разработчик, чтобы найти и исправить любые шероховатости в этом процессе За каждую вещь, которую мне удается запилить из моего списка, я нахожу еще 3, чтобы добавить к нему. Но это делает хороший прогресс, даже несмотря на то, что сам режим deathmatch, кажется, не движется вперед, он двигает все остальное вперед вокруг него.