Cyber wars: tactical view


Гео и язык канала: не указан, не указан
Категория: не указана



Гео и язык канала
не указан, не указан
Категория
не указана
Статистика
Фильтр публикаций


На этой неделе осилил сборку интерфейса для авторизации и выбора игровой сессии. Скоро, скоро болванчики забегают! 🏃‍♂️🏃‍♂️🏃‍♂️

#screenshotsaturday


Видео недоступно для предпросмотра
Смотреть в Telegram
Родион @er_rodionefremov сейчас работает над оптимизацией и текстурами 3д моделей, на видео уже видны первые из них!


Всем привет. Пост про изменения в проекте.
В связи с большим желанием реализовать в проекте уровень графики, заявленный нами ранее в концептах, было решено изменить концепцию проекта. Раньше весь уровень записывался в базу данных на сервере, хранился там и передавался клиенту при подключении к сессии, объекты расставлялись уже в рантайме, что очень ограничивало нас в настройке освещения сцены. Теперь сцена будет собираться в Юнити полностью, специальный скрипт будет собирать данные по объектам на сцене и полностью перезаписывать сцену на сервере. Кроме того на сервер будут записываться только необходимые данные: препятствия, стены, ограждения, двери/ворота. Все остальные объекты на сервер не полетят! Это значительная оптимизация и для сервера и для процесса разработки в целом и позволит уже в скором времени начать добавлять болванчиков на сцену!
На данный момент разработана новая основа для сборки уровня в Юнити и скрипт, который будет отправлять на сервер информацию об объектах. Разработаны скрипты для управления дверями.


Освещение и тени.
Так как карта (сцена) визуализируется только в рантайме при подключении к игровой сессии, у нас нет возможности использовать запекаемые (baked) лайтмапы в движке Unity для просчета освещения сцены. Для наружных элементов все остается не так плохо. А вот если накрыть крышами внутренние помещения, то свет пропадет. Если не накрывать крышами то сцена будет проигрывать визуально, тени от зданий не будут полноценными, внутренние тени от стен не соответствуют действительности.
Нам бы хотелось использовать Area light, но он только baked в URP. Эффект от Point light в каждом закрытом помещении выглядит не очень естественное и создает дополнительные проблемы и вопросы.

Проблема real-time освещения в URP для сцен, созданных динамически в рантайме:
- нет Area light
- нет рефлексов от Emission material
- нет вторичного освещения для темных мест
- нет рефлексов
- нет отражений (можно исключить)

Возможные варианты решения:
для Area light:
- Ассеты - есть парочка, но не нашел где их скачать, чтобы попробовать.
- LTCGI Optimized plug-and-play real-time area lighting using the linearly transformed cosine algorithm for Unity/VRChat.
- в HDRP есть Area light real-time (но нельзя Web сборки!)
- запекание (требуется переработка структуры проекта)

для рефлексов от Emission материалов и вторичного освещения для темных мест:
- ассет Radiant Global Illumination. Это хоть и не очень честный свет, но как раз не требует запекания и лайт проб.
- ассет LUMINA GI 2024: Real-Time Voxel Global Illumination (но нельзя Web сборки!)
- HDRP (но нельзя Web сборки!)
- запекание (требуется переработка структуры проекта)

Попробовал Radiant Global Illumination - выглядит неплохо, но нужен еще Area Light, сам по себе он не является решением проблемы. Иногда создает не нужные рефлексы/артефакты там где их не должно быть.
Попробовал LTCGI - как оказалось заявления о real-time не означает, что там не требуется запеканием лайтмап, еще как требуется. Но демонстрируемые экраны мониторов выглядят хорошо! Будем иметь ввиду, Unity URP не предлагает таких возможностей сам по себе.

На данный момент продолжается поиск решения проблемы освещения...


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


Карта или сцена.
Короче место прохождения боя. Для создания карт разрабатывается собственный редактор. Это необходимо потому, что карта должна быть загружена в память не только клиента, но и сервера. И она должна быть идентична между ними. Визуальное представление карты серверу конечно не требуется, ему требуется только структура. Каждый элемент карты при инициализации и на клиенте и на сервере записывается в занимаемые ячейки. Таким образом при загрузке воссоздается карта "проходимости" в памяти клиента и сервера. В каждом элементе карты записана информация о 3D объекте, который должен быть выставлен на карту для визуализации.
Таким образом карта хранится на сервере в базе данных. Записи в базе редактируются во время сборки в редакторе карты.
При подключении к игровой сессии клиент получает информацию о карте с сервера, воссоздает ее в памяти и визуализирует на игровом поле.


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


Траектория выстрела.
За основу взял вычисление принадлежности ячеек прямой линии, проведенной из ячейки А в ячейку Б. Вычисляется это на основе алгоритма Брезенхема, который был разработан для растеризации точек на экране монитора. Он идеально подойдет, для вычисления траектории выстрела. В каждой ячейке траектории надо вычислить ее занятость препятствием и переходы между ячейками, если все чисто можно стрелять - есть попадание.


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


Игровое поле.
Представляет из себя таблицу x*x, где x - размер игрового поля. Принимаем, что размер ячейки 1*1 метр.
Суть игрового поля в том, чтобы привязать объекты или бойцов к занимаемым ими ячейкам. Объекты это препятствия, сквозь которые бойцы не могут проходить или стрелять. Только один объект в один момент времени может занимать ячейку.
На поле существуют не только препятствия а также стены зданий, внутренние стены, двери или ограждения. Такие объекты не блокируют возможность занимать ячейки другим объектам, но они должны ограничить перемещение бойцов в определенных направлениях, а также перекрыть их видимость и возможность стрелять.
Для таких объектов в ячейках игрового поля есть отдельный список, так как их может быть несколько привязано к одной ячейке. Также у ячейки есть признаки переходов в другие ячейки, всего их 8 - лево, право, верх, них и 4 по диагонали. Когда такой объект "стенка", записывается в ячейку, он должен перекрыть соответствующие переходы.
К этому есть и другой подход, в котором не требуется учитывать проходы между ячейками, а вместо этого ячейка принимается равной толщине стен или дверей, самому малому игровому объекту. Каждая стенка будет занимать игровые ячейки и проходы учитывать не требуется. Боец будет занимать 2*2 или 4*4 игровых клеток.
Может есть и другие подходы, но я их не знаю. Мной был выбран первый вариант.
В каждом подходе есть свои плюсы и минусы. Особенно надо учитывать как будет осуществляться поиск пути для персонажей и вычисление траектории выстрела.


Игровая очередь.
В подобных играх используется несколько подходов к реализации очереди, наиболее известные и очевидные:
1. Длинный ход - каждый игрок ходит всеми бойцами затем ход передается другому игроку.
2. Короткий ход (или шахматная модель) - каждый игрок ходит только одним бойцом, затем ход передается другому игроку и он тоже ходит одним бойцом, пока все бойцы не сходят каждым бойцом.
Есть и другие, но они более замороченные и не подходят для онлайн игры по моему мнению, так как игроки могут чувствовать себя в неравных условиях.
Я выбрал короткий ход, он уменьшает возможность "сфокусированного огня", когда один игрок всеми бойцами разом убивает вражеского бойца (да именно так и играют в XCOM). Также позволяет сократить время хода и вероятность того, что "на другом конце провода" игрок уже устал ждать.

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

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


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


Репост из: Е.Р. I Родион Ефремов
🦾⚡Делюсь концептом помещения склада с рабочего проекта. ⚡🦾

#DigitalArt #ArtDaily #ArtStudy #ArtChallenge #ArtDailyStudyChallenge


Репост из: Е.Р. I Родион Ефремов
🦾⚡Делюсь концептом территории склада с рабочего проекта. ⚡🦾

#DigitalArt #ArtDaily #ArtStudy #ArtChallenge #ArtDailyStudyChallenge


Видео недоступно для предпросмотра
Смотреть в Telegram
Представляю вам обновленный доработанный улучшенный конструктор 😎
- Теперь отображается прототип устанавливаемого объекта
- Двери и пересечения стен переработаны
- Доработан тулбар, теперь появляется дочерний тулбар

#gamedev #indiedev #screenshotsaturday


Какие из решений вам нравятся? Если вам не в лом, проголосуйте :)
Опрос
  •   A. бирюзовый + оранжевый
  •   B. светло синий + желтый
  •   C. коричневый + желтый
  •   D. синий + желтый
  •   E. болотно зеленый + оранжевый
  •   F. темно красный + желтый
4 голосов


Процесс поиска цветового решения для локации @er_rodionefremov
#gamedev #indiedev #screenshotsaturday




интерьер.jpg
536.6Кб
Крупным планом! 🥹


Эскизы экстерьеров 🤩

Показано 20 последних публикаций.

9

подписчиков
Статистика канала