Лига Разработчиков Видеоигр

Техническое состояние будущего Penumbra Lighting на данный момент: отличное. Все идеи Light Occlusion CL перенесены успешно, производительность отличная, в среднем код кушает 3-5-7мс при бюджете кадра 16.7. На данный момент это если не самый, то один из самых производительных плагинов освещения для МЗ. Баги и ограничения патча устранены.

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

Причина, почему Penumbra Lighting ещё не выложен: сложность плагина для пользователя. Справка нуждается в адаптации, окно параметров ныне перегружено техническими настройками, нужными для тестов. Полировка всего этого может быть реализована только после цементирования планирующихся фич.

Будущие фичи: смена дня\ночи, тени от тайлов решёток, теневые крылья, теневая карусель, дамажащие тени, тени-щупальца.

Патч написан с использованием нейросетей. Дипсик писал код. Алиса искала баги. Я выступил в роли тестера и визуального оценщика. В соседнем диалоге Дипсик в роли профессора оценивал код на уязвимости. Новый плагин пишется с добавлением третьего участника: ии-агент Koda, который вставляет диффы и следит, как архитектура реагирует на фиксы. Так же добавился чат гпт, оценивающий откатные версии на предмет нейрослопных косяков.

Скачать можно бесплатно с Диска

Или с Бусти

Обсуждение патча и будущего проекта на Юнионе

Приветствуются любые пожелания, критика и новые идеи для проекта.

Исправления в Web билде:

• Исправил ошибку с разрешением, отключил изменение в настройках

• Исправил ошибки, связанные с локализацией: иногда тексты русском не отображались

• Исправил падение при выходе из боя

• Добавил тултип, при нажантии на заблокированную кнопку Хост в мультиплеере

• Немного улучшил производительность

Общие исправления:

• Исправил ошибку, из-за которой на локации "Спорный остров" у синей команды создавались лишние постройки

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

• Небольшие исправления в интерфейсе в сражении

• Немного уменьшил размер билда

Игра доступна по ссылкам:

• https://myindie.net/games/game/autobattler

• https://makskarabin.itch.io/autobattler

Новый пайплайн сборки

При выпуске этого обновления сборка билдов отнимала очень много времени. Процесс выглядел так:

1. Написать код и/или обновить ассеты;

2. Сделать билд на Windows (ожидание 5-10 минут) и протестировать

3. Переключить платформу на Web (ожидание 10-20 минут)

4. Собрать под Web (ожидание 20-30 минут) и протестировать.

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

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

Мой план был такой:

• Создать второй клон репозитория только под Web сборку. Тогда как основной клон - под Windows. Так исключается переключение между платформами.

• Написать набор скриптов, которые запускают сборки без запуска визуальной части редактора Unity.

• Скрипты также должны:

  • Актуализировать клон для Web сборки

  • Запускать тесты перед сборкой

  • Вырезать из проекта пакеты и плагины, которые используются только в редакторе, но по какой-то причине лезут в билд

  • Инкрементировать версию патча в проекте и начинать с нуля при инкременте мажорной или минорной версии

  • Выполнять сборку и архивировать ее в zip

  • Возвращать вырезанное

  • Коммитить изменение версии проекта

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

Разумеется, писать самостоятельно такие скрипты - расточительство, поэтому я попросил написать их Claude. После нескольких итераций получилось реализовать мою задумку.

Я остался доволен результатом: расход времени на простой из-за смены платформы и билда без кэша сильно снизился (правда, замерить слишком трудозатратно). Но все еще не идеально: так как во время сборки я не могу открывать редактор. В будущем, если проект разрастется, можно будет думать о полноценном CI/CD с отдельными билд агентами.

Следующим шагом хочу автоматизировать заливку билдов на платформы. И попробовать заменить клон репозитория для Web проекта на симлинки: сделать ссылки на папки Assets, Packages, ProjectSettings и некоторые другие, которые нужны для нормальной работы проекта Unity. Так я ожидаю исключить шаг с актуализацией клона.

Спасибо за то, что прочитали! Как бы вы улучшили процесс сборки? Как он организован у вас на проекте?

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

• Кривые Безье рассчитываются как в Spine Runtime. График, предпросмотр и запекание используют одну таблицу из десяти отрезков, построенную по исходным ручкам. При вставке ключа или циклическом сдвиге редактор может добавить линейные ключи, чтобы сохранить движение.

• Исправлен расчёт двухкостного IK и слайдеров. При обычном наследовании (Normal) IK учитывает скос (shear), отражение и неравномерный масштаб родительской кости. Исправлено смешивание слайдеров при отрицательном масштабе, на дискретных каналах и для параметров IK в аддитивном режиме.

• Ветер и гравитация по осям X и Y. Эти параметры предпросмотра физики учитываются при сохранении кадра в PNG и записи поз в ключи.

Интерфейс

• «Операции с весами» вынесены в отдельную панель. Её можно перемещать, прикреплять и менять её размер. Операции, включая Prune, применяются сразу и отменяются через Ctrl+Z. У кнопок и параметров появились подсказки.

• Панель «Сцена» стала компактнее. Компенсация костей и изображений и привязка к пикселям собраны в одном столбце кнопок со значками.

Скачать редактор можно бесплатно на сайте https://spline2d.com/

Итак, начнём, пожалуй, с самого основного в этой теме - сетка (координаты поля боя). Ни для кого не секрет, что сам жанр "пошаговой" игры должен иметь саму координату. Это же база. И их имеется 2 основных вида - гексы и сетка:

В любом случае сама сетка должна не только выглядеть удобно, но и иметь координату (в этом же её смысл), пусть хоть в шахматном виде A4 или в числовом 1/4 - не суть.

Как я упоминал в одном из своих постов (ссылка), я экспериментировал в своём проекте с изометрией (триметрией) в 2D и переездом с пошаговой системой в полноценное 3D.

И тут, на самом деле, всё гораздо интересней, чем может показаться...

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

Если ваше препятствие, например, полторы клетки - то это большая ошибка. Объект должен занимать то количество клеток, где он визуально находится, то есть в нашем случае либо полную одну клетку, либо 2 клетки. На своём проекте я могу наглядно показать так:

Обратите внимание: выпирающий красный (и зеленый) гекс - недоступен для игрока, а значит, на серверном расчёте этот гекс полноценно является препятствием для траектории полёта пули

Тут важно понимать - для онлайн-игры сервер обязан быть авторитарным (передавать расчёт луча пули с клиента нельзя, иначе читы неизбежны). А сам сервер 3D-моделей не видит - для него существует только матрица координат и булево значение: занят гекс или нет (в моём случае структура с булевым и переменной названия объекта, чтобы отличать уничтожаемый и простреливаемый объект от других видов).

То есть, несмотря на то, что для клиента (и пользователя) это выглядит вот так:

Для сервера холодный расчёт происходит так:

И получается такой забавный нюанс:

И если в квадратной сетке может показаться, почему всё квадратное из объектов, которые занимают клетку - вот она, истинная причина.

В 2D и в чистой изометрии 3D - ситуация та же самая, только она не столь заметна, сама фиксация камеры на карту это немного сглаживает, а в 2D это ещё более простительно выглядит.

И что тут можно сделать, чтобы не переходить в полноценную 3D-систему координат, от которой сервер начнёт гудеть?

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

Тут я нашёл два варианта решения...

Первый вариант: сделать вторую сетку которая будет в виде слоёв. Но проблема такого метода - корректно связать первый слой (где персонаж шагает) и второй слой, где отмечены мелкие детали - очень сложный, точнее в процессе отладки могут появиться разные проблемы того же смещения, правильного учета дробления мелкой сетки на корневые и прочее, можно, но зачем?

Второй вариант, который мне показался достаточно хорошим решением - создать массив в самой клетке, массив, который содержит ещё одни координаты и их занятость, примерно вот так:

Представьте, казалось бы, визуально мелочь - а хлопот доставляет прилично, но хочу отметить, таких нюансов в тактической пошаговой игре в 3D - прилично, хитростей приходится придумывать достаточно)

А по результату, пуля у нас теперь летит спокойно, не смотря на то что есть и граница объекта, и пустая зона:

В синглплеерных играх это, конечно, всё решается расчётом луча траектории пули через объекты - и там такие проблемы обходятся дешевле.

Надеюсь, статья была занятной)

Если интересен сам проект, добро пожаловать в телегу. Так же есть отдельный сайт

Всем добра и успехов в своих проектах!

Наткнулся на технический разбор Ghost of Tsushima от Sucker Punch. Мне всегда нравилось, как в этой игре выглядят поля с травой, особенно когда по ним проходят волны ветра. Оказывается, за этим стоит довольно интересная система

Разработчики хотели, чтобы весь мир постоянно находился в движении. Причём ветер должен был одинаково влиять на траву, деревья, листья, одежду персонажей и даже дым от костров

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

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

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

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

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

Больше интересных фактов о геймдеве в моём ТГК: lyashu_lab