Корсарская химера и чем её готовят. Диалоги, квесты, оптимизации. Заключительная часть

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

У меня тут не AAA, и не B, может даже и не C проект… назовем это проект уровня G. И по понятным причинам о нормальных анимациях речи идти не может. Но все же, мне хотелось бы, чтоб во время диалогов NPC мог воспроизводить какие то анимации. Например здоровался с игроком, делал какие то реакции в процессе и т.д. А не просто тупо стоял на месте и взирал на игрока своими безжизненными глазами(прям как у меня хаха…). Но в этом моем желании есть загвоздка!

Игрок может начать разговор как с каким то прохожим, так и с человеком который “занят каким-то делом”. И для каждого этого “дела” должна быть своя уникальная анимация. Я же не буду принудительно отрывать NPC от его занятия, чтобы он игроку помахал. Тут встает проблема с тем, как наладить связь между плагином NPC Manager, в котором реализованы все эти “точки занятий”, и моим полу-самописным диалоговым ядром на базе Logic Driver Pro. А я ненавижу копаться в NPC Manager! Отложу все оттенки коричневого говна связанного с этим плагином на другой раздел статьи, и перейду сразу к реализации.

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

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

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

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

Если вы копались в маркетплейсе эпиков в поисках какого-то плагина с готовым интерфейсом, то скорее всего разочаровались в навыках дизайна у разработчиков. Как правило там продается шлак с интерфейсом из нулевых годов, да и код, с высокой вероятностью, тоже будет оставлять привкус экскрементов на губах. Но произошло чудо, и в рамках поиска HUD-а с компасом, квестами, подсказками и прочей мелочью, я вышел на Pro HUD Pack V2. Вот малая часть функциональных иконок которые можно получить:

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

А теперь снова к душному...

Не знаю у кого как, но у меня AIController жрет процессор даже если отрубить у него дерево поведения и тик. Почему? Как обычно - хер его знает! Казалось бы, что там может загружать систему, максимум оперативку должен хомячить, но нет. Собственно обнаружил я это, когда переключил всех NPC на карте в состоянии паузы, когда игрок выходит в море. И единственный способ избавиться от этой нагрузки - убить ИИ контроллер. Но если так сделать, то все данные которые этот контроллер хранит - уйдут в небытие, и тогда нужно куда-то их сохранять, потом восстанавливать… в общем много головной боли. Но случилось чудо! В этот раз архитектура NPC Manager оказалась очень кстати, потому что хранит все данные внутри компонента, а ИИ контроллер просто раз в полсекунды подстраивается под обновления.

Но говна на этот раз завез анриал! Есть в нем такая функциональность как деактивация компонента, которая отключает в нем тик и вроде как еще что-то. Но если ваш компонент построен не на тике, а на событиях с таймером, то он продолжит работать как обычно. Круто правда?! Отличная деактивация, просто 10/10! И разумеется, наш дорогой NPC Manager построен именно на таких таймерах. И этих таймеров там несколько десятков. В нескольких десятках методов… А что это значит? А то что, если “усыпить” всех NPC, то компонент все равно продолжит пытаться обрабатывать эти таймеры, жрать небольшую производительность, но что более важно - приводить к неожиданным багам.

В общем пришлось снова покопаться в говне, чтобы полностью деактивировать NPC. А еще ко мне в голову пришла мысль: почему бы не отключить ИИ у NPC которые просто стоят на своих “точках занятий”, ведь логика перехода к следующему занятию, все равно будет выполнена по таймеру? Собственно так я и сделал, выиграв еще немного производительности. Было бы идеально точно так же сделать и для NPC которые ходят по улице, но без ИИ контроллера не работают ноды перемещения, так что тут осталось как есть.

Будь проклят тот день, когда я выбрал этот плагин в качестве базы для поведения NPC! Баганутый кусок говна! В чем собственно соль: в “точку занятия” непись может войти с помощью входящей анимации(сесть за стол), потом в процессе сидения за столом выполняются разные рандомные анимации(которые иногда еще могут повторяться четыре раза подряд из-за конченного рандомизатора в анриале), и затем по окончании таймера воспроизводится анимация выхода из-за стола. И вот анимация выхода в редком кейсе могла попросту не воспроизвестись. В итоге непись просто застревал в модельке стула. Круто, правда?

Еще есть в плагине такая “классная” фишка как симуляция толпы. Когда ты просто указываешь кривую по которой должны идти неписи, и они просто по ней идут, без какой-либо другой логики, ИИ или чего еще. И есть у этой фишки два режима: Обработка перемещения напрямую через блюпринт, где в цикле перебираются все неписи и им добавляется ускорение и указывается направление. И обработка через ИИ и ноды перемещения. Разраб значится говорит что первый вариант работает быстрее чем второй. На практике, первое - просто неиграбельное говно. А во втором, вместо событий достижения точки назначения у нас каждый тик проверяется, а мы сука добрались до цели?

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

На карте может быть множество маршрутов, и для того чтобы найти ближайший подходящий, создается одноразовая коллизия, которая, ВНИМАНИЕ, получает список всех объектов внутри этой коллизии, перебирает их в цикле и проверяет что это акторы класса маршрут! Т.е. понимаете, если у вас большая карта, с кучей объектов, и большой радиус поиска маршрута, то вы испытаете жуткие фризы. У меня старт игры просто секунд 15 занимал, только чтобы все персонажи проинициализировались!

Порвался, не жаль:

Знаете, я терпеть не могу все что связано с фронтендом. Да и частичный дальтонизм тоже вносит свою лепту в мою ненависть. И создание интерфейсов в анриале ни капельки не пошатнуло мою уверенность в этом, а может даже и усугубило. Потому что CSS я хотя бы знаю, а в анриале нужно собирать все из разных функциональных блоков с херовой документацией. Зачастую приходилось только по одним описаниям блоков разбираться что с их помощью можно сделать. Но зато хоть анимацию всех этих блоков делать легко! Хоть мне это и понадобилось всего в паре интерфейсов…

В общем, т.к. я слаб в таких вещах, то решил просто взять за основу интерфейсы из оригинально-модифицированной игры за авторствами Sith и команды Ship Pack. Да и то, пришлось в некоторых местах дизайн упростить просто потому что я криворукий урод. Можно было бы рассказать подробно как оно делалось, но меня тогда откачивать придется. Скажу лишь что для верстки всей этой херни использовались блоки Canvas(если нужно прикрепить элемент к какой-то определенной части экрана), Horizontal Box, Vertical Box, Scroll Box, Border(интересный блок, позволяет сделать красивые рамки у блоков), Text и Input.

А вот собственно криво переверстанное:

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

Это конец второй части. Можно было бы еще рассказать о механике перехода скорости корабля из повседневного в бытовой, мои костыли для инерции поворота корабля, механику переключения музыкального сопровождения(наверное самое интересное, может я даже это потом выпущу) и прочее, но у меня совсем нет на это сил. Последние несколько дней после простуды вообще по 12-14 часов в день сплю и никак не могу восстановить энергию.

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

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

#личныйопыт #девлог #unrealengine