Тёмная тема
- }:+()___ [Smile]
- Постоялец
pahaa
> Интересный вариант. Но будет тяжеловато тогда.
По идее, примерно аналогично короткому рейкасту.
Но это только если поддержка движка есть (сферический каст?)
pahaa
> Ты как будто сообщение не читал, чесслово. Там же всё расписано.
По моему опыту стандартное решение работает неправильно в том случае, если оно неправильно используется.
У меня, к примеру, были проблемы с управлением большими толпами, от 500 агентов одновременно. Тогда RVO начинает сбоить и агенты начинают наползать друг на друга и "прыгать" с точки на точку. Решил разнесением приоритетов агентов в толпе.
С толпами до 50 агентов проблем никогда не было.
Допускаю, что у тебя какой-то редкий случай, не решаемый штатными средствами. Такое бывает. Но я с такой проблемой не сталкивался.
> UI пока не делал (если не считать кнопки "Новая игра" в главном меню),
> подробностей не знаю.
Я нашел. Оказывается в UE экранный джойстик - это часть настроек ввода движка. Просто делаешь свой джойстик по шаблону, подставляешь его, и он органично вписывается в систему ввода.
В целом заметил, что UE - это более высокоуровневый движок, чем Unity. В нем многие подсистемы в полуготовом состоянии, их не нужно разрабатывать с нуля, как в Unity. Нужно просто их найти и разобраться как они работают.
}:+()___ [Smile]
> сферический каст
Да, сферический каст есть. Второй раз спасибо за наводку ))
Scarabus
> редкий случай, не решаемый штатными средствами
Не редкий, а любой случай, когда перемещение персонажа осуществляется с помощью мыши.
Scarabus
> их не нужно разрабатывать с нуля, как в Unity
Да, всё так. Отсутствие каких-то простых вещей в готовом виде как раз по-началу очень сильно припекало в юнити.
pahaa
> Не редкий, а любой случай, когда перемещение персонажа осуществляется с помощью
> мыши.
Не понимаю сложности, но ладно.
Scarabus
> Не понимаю сложности, но ладно.
1. Там прям в доках даже написано: агенты могут выходить за пределы навмеша.
2. Направление обхода фиксируется на определённый интервал. И когда ты видишь, что твой персонаж пытается обходить пустоту и ты ничего не можешь с этим сделать - это вообще не кайф.
3. Не говоря уже о том, что все будут постоянно друг друга блокировать, если движутся навстречу (видео на эту тему тоже есть в доках).
Проверить мои слова достаточно просто. Сетап минут за 20 собирается. Если интересно, могу записать как это у меня в игре выглядит (я интеграцию не стал выпиливать, просто отключил фичу). Хотя, насколько я понял, ты и те 2 видео, которые есть, не смотрел ))
pahaa
> Проверить мои слова достаточно просто.
Я нисколько не сомневаюсь, что проблема есть. Иначе зачем бы ты стал искать ее решение?)
Просто я с ней не сталкивался, хотя с навмешем работал на многих проектах.
Из описанного тобой выглядит, что может быть навмеш довольно большая, из-за чего появляется значительная задержка в расчетах. Ошибки в маршрутах могут возникать по причине слишком большого размера ячейки в навмеше.
Я бы увеличил число вычислительных шагов на кадр, поиграл бы с размером ячейки и попробовал бы уменьшить размер локации. Возможно это привело бы к решению.
_________
Плюс попробуй использовать NavMeshSurfase из NavMeshComponents вместо стандартного статического запекания. Там больше возможностей для кастомизации.
Scarabus
> может быть навмеш довольно большая
Так RVO вообще навмеш не использует. Ты, видимо, с чем-то путаешь. RVO просто смотрит объекты рядом, смотрит их велосити, и подгоняет велосити управляемого актора так, чтобы они по-меньше пересекались. Всё. Из-за этого акторы как раз и могут уезжать за пределы навмеша.
А то, что кроме стандартного запекания или динамического расчёта есть ещё варианты - не знал. Спасибо. Пригодится, когда буду генерацию уровней делать.
pahaa
> Так RVO вообще навмеш не использует
Это все не про не про RVO, а про поиск пути.
Закончил реализацию системы исполнения приказов. До этого юниты умели только бегать, а теперь умеют ходить, атаковать, колдовать, умирать, воскресать, получать hit recovery и т.п.
Постарался учесть проблемы предыдущих реализаций (до этого на юнити уже успел опробовать два разных варианта). Стало попроще, но не сильно.
Вероятно, придётся ещё раз переделывать, когда буду прикручивать мультиплеер. Скорее всего, будут проблемы квантования времени и разделения зон ответственноси клиента/сервера. Но пока сойдёт.
Главное сейчас в этой системе - отличное разделение логической и визуальной составляющей. В юнити как раз были проблемы, из-за того что контроллер управлял одновременно перемещением и анимациями (это было сложно разделить).
В UE всё взаимодействие с анимациями удобно инкапсулировалось в подкласс AnimationInstance и его блюпринт с абсолютно чёткой точкой входа.
Доступность блюпринтов в машине анимаций оказалась очень приятной. В то время как в юнити всё ограничивалось биндом именованных переменных.
Кроме того, машина анимаций в UE ещё раз порадовала своей гибкостью, в отличие от машины анимаций юнити.
Зато ещё раз расстроило отсутствие возможности делать обобщённый (не привязанный к скелету) шаблон машины состояний. Из-за этого пришлось собирать сразу всю машину целиком. Дальше её нужно будет копировать для каждого типа юнита через контрол+ц контрол+в. Надеюсь, ничего не пропустил, т.к. по нескольку раз этим заниматься нет никакого желания.
В процессе реализации настроек наконец-то столкнулся более близко с мета-системой в UE. Такого, мягко говоря, не ожидал.
1. Зарегистрировать класс, у которого базовый класс не зарегистрирован? - Невозможно.
2. Зарегистрировать подкласс зарегистрированного контейнера (хотя бы для фиксированного типа содержимого)? - Невозможно.
3. Использовать встроенные (но не очень часто используемые) типы (вроде TPair)? - Невозможно.
4. Зарегистрировать хотя бы синоним зарегистрированного типа (using ValueType = float)? - Невозможно.
5. Объявить вычисляемое свойство без хранящей переменной? - Невозможно.
И вот ЭТО кто-то ещё называет стандартом индустрии...
Почему-то:
а). В движках для "да что там этот матч3 вообще делать?" это всё работает даже без регистрации (в 2 из 3, с которыми я знаком).
б). В Qt можно зарегистрировать вообще всё, что угодно (а не только это).
в). Даже в юнити это всё легко реализуется.
В итоге приходится делать так:
Это была буквально одна из причин перехода на плюсы: не писать повторяющийся код вроде такого. А UE такую свинью подложили, просто жесть. В итоге кода стало даже больше.
Для крафтовых заклинаний придётся сочинять какую-то обёртку и писать свой редактор. А эпикам - минус 200 социального рейтинга и забрать кошка-жена, короче.
Я пишу на С и все куски кода повторяющиеся пихаю в макросы что бы и текста поменьше и рантайм побыстрее
Добавил поддержку метаморфозы юнитов. Она была в версии на юнити. Хотел сделать систему по-лучше и избавиться от этой надстройки, но она всё равно понадобилась.
В связи с этим опять плевался из-за отсутствия поддержки шаблонов машины анимаций.
Наконец-то перенёс все модели монстров, их материалы, анимации и настройки. Работы с этим просто уйма была.
Опять пришлось возиться и распиливать fbx, потому что UE не поддерживает субмеши. Уже на это жаловался. Наверное, никогда не устану. Очень уж печёт от подхода "мы считаем, что это вам не нужно".
Реализовал действия ближней и дальней атаки.
Расставил монстров на уровне.
Дальше начнётся самое интересное!
Добавил поддержку таблиц баланса, которые в версии на юнити были прикручены сбоку.
В УЕ понравилось разнообразие возможных подходов к организации таблиц данных (через наследование блюпринтов, через дата ассеты, через таблицы). Но не понравилось, что все эти варианты друг с другом не дружат. И ещё не понравилось отсутствие прокси-таблиц (т.е. таблица обязательно вкукоживается внутрь ассета, нельзя из коробки просто скормить csv в ран-тайме), но это, в целом, соответствует общей концепции интегрировании всего контента внутрь ассетов, так что было вполне ожидаемо.
Ещё понравилась концепция DataRegistry, но по ней очень мало материалов для изучения, и в некоторых местах совершенно не понятно "что имел в виду автор". Все нужные вещи пришлось реализовывать "на ощупь". В частности, те самые ран-тайм таблицы.
В юнити подробно встроенную работу с таблицами не изучал, но такой продвинутой вещи как DataRegistry там не видел точно. Поправьте, если я ошибся.
Ознакомился с процессом регистрации нового типа ассета. Он просто ужасен. Чтобы по ПКМ появилась заветная кнопочка "create my new awesome class instance" нужно проделать тонну манипуляций. В юнити с этим было гораздо проще.
Ещё ознакомился с тегами. Реально полезная штука, в отличии от тегов в юнити. Система весьма мощная. Посмотрим, что можно с этим сделать.
раб вакуумной лампы
> Я пишу на С и все куски кода повторяющиеся пихаю в макросы что бы и текста
> поменьше и рантайм побыстрее
inline функции/макросы и прочее вроде не всегда быстрее отдельной функции
pahaa
Это ты еще имел проблемы когда выходит новая версия и меняются методы интерфейсы
innuendo
> когда выходит новая версия и меняются методы интерфейсы
Дежавю прям.
Но, могу просто ещё раз с уверенностью сказать: новые версии не приносят никаких проблем, если ты на начальном этапе разработки выбираешь LTS-версию и никуда с неё не уходишь.