Vladimir Shirshov
"Перечитай статью" - то что у автора не получилось справиться с задачей не показатель вообще =)
"Если я ТПшкаюсь в непрогруженную область, нужно проверить условия её прогрузки." - движок же не знает, нужно тебе проверить условия ее подгрузки или нет, движок универсальный под любые игры, а может у меня в игре летающий персонаж и мне не важно что загрузилось абсолютно все, может у меня в игре есть постпроцесс, который имитирует эффект и не паузит игру, а фоном я хочу прогрузить все асинхронно и т.д. Для явной прогрузки всего есть функция - дождаться пока закончится стриминг, которую автор не нашел.
Да, документация у эпиков говно это факт, надо либо учиться гуглить (а гуглится довольно просто), либо погружаться в исходники. И да, это тоже необходимый навык - читать исходники движка, если делаешь что-то более-менее серьезное.
Пойми, я не говорю что движок идеален, я на него ругаюсь каждый день уже лет 10 как, но при всем при этом я не могу сказать что в нем прям ничего не работает. Просто да, порог входа высокий, документация говно, а ряд фичей в сыром виде. Если это не устраивает, то нужно брать другой движок.
"Да, но она застряла в эпохе HalfLife1" - ну нет, в HL1 блокирующая загрузка, никакой асинхронной подгрузки ресурсов
"Система проверки телепорта?" что это такое? такого нет, движок не знает за тебя что нужно прогрузить что нет, хочешь дождаться окончания стриминга при телепорте, такой функционал есть из коробки, автор его просто не нашел
Приключений хватает конечно, но и писать с нуля не приходится все.
Все что выкладывают эпики (демка матрицы, лира и прочее) это технодемки и точно не является примером того как стоит делать.
А вот про "библиотечные методы", надо просто понимать их плюсы и минусы, разбираться в них, чтобы решать что использовать, а то нет и как это использовать.
UE - это инструмент, да еще и универсальный от медиапродакшена до мобилок (хотя с последним уже не особо для слабых дейвайсов). С инструментом надо уметь работать и учитывать его особенности, плюсы и недостатки. А просто так из коробки под все случаи жизни в нем нет.
Ну, есть ряд логики завернутой в WITH_EDITOR, там больше данных приходится стримить, ибо ассеты хранят дополнительные данные для редактора, много чего кешируется и не выгружается и т.д.
В итоге редактор жрет больше и по памяти и по производительности. Тот же Construction, например, вызовется в редакторе для объектов на уровне, но уже не будет вызван в билде.
Короче нюансов много, некоторые из них вполне логичны.
Unreal Engine - это не волшебный движок с кнопкой "Сделать збс", опенворлды на анриле имеют кучу проблем, ряд из которых остался со времен четверки.
1. HLOD в целом запекатеся нормально, но может выжрать тонну памяти и ресурсов (в зависимости от чанка). Если проект крупный, то этим вообще занимается отдельная выделенная машина, которая пересобирает дальние лоды. После чего на финальном этапе разработке игры их еще и ручками лучше перерисовать.
2. World Partition все еще имеет ряд болячек с World Composition, о котором я писал когда-то статейку + о ряде болячек рассказывают на выступлениях, посмотри последний Unreal Fest, в том числе от CDPR. Как это лечится? Берется движок и переписывается стриминг, регистрация экторов или вообще отказ от экторов для статики и т.д.
3. Да, не надо делать сложной логики на констракшене и BeginPlay особенно у того, что стримится, пачка экторов появляется одновременно и бьет по производительности. Нужно следить за тем, что делаешь.
4. Да, работа в редакторе и в билде разнится. Потому финальную производительность нужно смотреть только в билде, и билды нужны регулярные.
5. Да, систему сохранений надо писать самому, ровно как и разбираться с возможностью перемещать объекты между чанками и чтоб это сохранялось и т.д. На эту тему тоже когда-то рассказывал, как подобное делать.
6. Про люмены и наниты, они жрущие, причем как для разработчика так и для игрока, нужно собирать сцену с учетом таргет железа и следить за тем, что загружено единовременно, что и как влияет на производительность.
В общем внезапно да, если собираешь что-то более менее сложное, с движком нужно работать. Если нет возможности менять исходники, значит следить за ограничениями и стараться не делать чего-то, что за эти ограничения вылезает (не пихать кучу логики на спаун, следить за тем что стримится и когда, за распределением ресурсов, количестве экторов в радиусе стриминга и т.д.)
Бери лошадку, максимум брони что есть и пушку побольше, отлетает очень быстро Радан.
Однообразный?)
Игра чередует механики (а порой атмосферу) от начала и до конца.
Мирное вступление, пробег без оружия, перестрелки с опциональным пулеметом, взрывными бочками и т.д. секция с мэнхеками, секция с поездкой на транспорте, босс вертолет, мирная секция, Ревйвенхольм с множеством физической интеракции и ловушек, паркурная секция с хэдкрабами внизу, поездка на багги, паркурная секция по мостом, Дрожь Земли - используем предметы окружения, чтобы не наступать на песок, штурм с возможностью командовать муравьиными львами, оборона с автоматическим турелями, постановочная секция, управление отрядом с возможностью получить медицину и припасы, минные поля, снайпера и использование предметов для защиты от них, цитадель где у тебя забирают все оружие и дают убер гравипушку что меняет геймплей.
А можно мне побольше таких "однообразных" сюжетных шутеров?
Сейчас норм, а где не норм - правится модами (с элденом так делал). В остальном супер удобная штука, особенно люблю в шутерах и чтоб FOV в потолок ещё выставить.
Жил на 34 этаже, хватило одного дня, когда лифты не работали, чтобы отбить любое желание повторять такой опыт )
Да вроде не особо пылесосил, просто бегу по истории, иногда забегаю в сторону, где-то процентов 30% страниц пропускаю, сундуки не все нашел, оружие тоже где-то пропустил еще. Но вот фигурки они все встретились сходу. Да и как сайд история вполне себе интересные и атмосферные, но да, к основной истории они имеют не самое прямое отношение.
Ну и это ведь сайд, так что кто не хочет - ну не будет проходить.
А что не так со стишками? Куклы нашел все почти сразу и дальше это прям атмосферные моменты. Каждый раз жутко становится их решать
Ну там когда как было, я выше приводил пару примеров с Vice City и с SiN. Но вообще у меня это была частая история, не то что ужасное техническое состояние, но софтлоки из-за того, что скрипты не сработали, краши и другие проблемы я встречал вполне себе ) Были конечно и игры без подобных проблем, просто они были разные и "раньше было лучше" на моем опыте скорее "раньше было раньше" и не мешает играть в новые игры, но после патчей конечно )
Ибо особенно до 2000 года у меня были вообще огромные проблемы доставать не то что патчи, а вообще сами игры в сибирской деревне.
Он и раньше в целом был непредсказуем. Но осилить масштабирование не так просто, плюс проекты должны окупаться и т.д.
Нюансов много, координировать сотни человек невероятно сложно, учитывая то, что руководящий состав может меняться в процессе, каждая студия имеет свои привычные пайплайны (отчего новость, что на проект направили еще 5 студий не самая лучшая). Синхронизацию такого выстроить могут единицы людей в индустрии, наверно.
Но, в целом, после опыта игр в 90х и начале 2000х когда у меня не было возможности ставить патчи, я в целом скорее рад тому, что могу поиграть в масштабные проекты сейчас. Как и всегда надо тщательно подходить к выбору только, ну и ждать патчей, благо они теперь есть.
Потому что координировать 500 людей при разработке в разы и в разы сложнее, чем 25 =) логично, что бывают случаи, когда это ведет к вообще полному провалу, типа бф2042. Ибо вытянуть до релиза становится задачей в разы более сложной.
Ну т.е. вливание сотен миллионов долларов и подключение сотен людей из разных студий для одного проекта совершенно не упрощают разработку, а делают ее сложнее и еще дороже )
Плюсану, помню как сражался с багами в первом SiN и не понимал, почему игра дальше не идёт. Как в вайс сити в 15-20 фпс катал на PS2 (о том сколько было фпс узнал уже потом, а раньше думал что так надо).
Сейчас радует что я могу хоть патчей дождаться, раньше в своей деревне играл во что было :(
В этом плюс элдена, можно респекнуться ) я в свое время также под Радана из основой игры менял прокачку на силу и видимо ещё тогда освоился, а потом обратно менял
Любопытно, он же на лошадке убивается легко, потому что можно надеть самую жирную броню и взять самую тяжёлую пушку)
Радан на удивление очень легко проходится на парировании. Ни разу не пользовался парированием в соулзах, а тут у него уж очень приятные атаки для этого + во второй фазе спасает от лучей. Не ожидал такого даже, когда пробовал разные подходы к нему.
Мидир даёт кучу времени на атаку, и очень скучный из-за того, что просто не может ничего сделать тому, кто у него в хвосте. Очень быстро пал, даже фляг не ушло на него. Бэйл всё-таки имеет куда более эффектные и интересные атаки, хоть и убивается просто перехилом.
Lumen uses Software Ray Tracing through Signed Distance Fields by default, but can achieve higher quality on supporting video cards when Hardware Ray Tracing is enabled.
Существует софтварный и хардварный люмен. В первом случае используются SDF и никаких отражений персонажей в этом случае не получить, плюс в зеркальных отражениях будет виден тот самый SDF (все будет дико размыто и некрасиво, потому что работа идет с Distance Field, а не реальной геометрией).
Хардварный же люмен использует трассировку лучей с хардварным ускорением (от AMD, Nvidia, Intel и т.д.). В этом случае отражается все как надо, ну ибо это обычная трассировка лучей.
Насчет сравнения с планарками, там я несколько раз упоминал, что на реальных проектах можно провести ряд дополнительных оптимизаций, что улучшит результат, но все еще использовать несколько планарок в кадре будет тяжело (особенно в контексте UE без модификации рендера)
Особенно прикольно было дойти до выхода из логова и понять что одной личинки не хватает )
Прошел обе части на грандмастере - игры отличные, жду продолжения.
Додумки автора про культовость SiN, первая часть была прикольная, но технически мрак, куча багов было в релизный версии. Вторая только за счёт сисек запомниться могла, в остальном проходная игра (потому второй эпизод так и не вышел)
Это спорный пример с точки зрения зоны ответственности, и очень сильно может зависеть от того, как организована работа в команде. Потому что в случае Смуты делать сложное решение вышло бы дорого по времени, а стандартные средства в паре с дизайном уровнем, учитывающим камеру, позволяют адекватно это организовать.
Ну т.е. на практике эту задачу (кроме уникальных кейсов) решали тех. артисты без привлечения программистов вовсе.
Spring Arm в любом случае нужен, но для решения с dissolve под рядом объектов программисты бы тоже не потребовались. Только работа тех. арта, в целом вся необходимая информация доступна.
С другой стороны, имхо, эта проблема довольно минорная, куда интереснее вещи системные и комплексные. Сам еще не смотрел билд, но хочется посмотреть что сделано по оптимизации памяти, CPU, рендера, по стримингу, как организованы сохранения и другие критичные вещи.
Как раз со стандартными получается хорошо, нужно грамотно настроить просто =) В огромном числе проектов используется стандартный Spring Arm с обработкой столкновений и поведением настроенным.
С учетом сроков - это как раз правильное решение, не городить кастомные обработки коллизий для камеры. Другой вопрос в том, что это требует корректно настроить каналы коллизий на объектах и сконфигурировать компонент.
Имхо, тут стоит смотреть на более важные и системные вещи для расследования. Организацию стриминга, оптимизационные решения, избавления от ряда стандартных болячек движка, работу сохранения и прочее.
Потому что баги в целом могут пройти по той причине, что не попали по приоритету. А вот заложить ключевые системы на базе движка нужно сразу и стараться их поддерживать, потому что это влияет на общее техническое состояние сильнее, чем визуальные баги.
Опять же я не говорю ничего про то, была ли там продумана техническая сторона или нет. Глаз зацепился за перечисление проблем, характерных для UE без грамотной настройки и с которыми сталкивают многие. Проблема проваливающихся NPC в том числе, но тут поддержка со стороны программистов все-таки нужна отчасти.
Я не говорю, что это проблема левел дизайна, настройка того, с чем должна сталкиваться камера с чем нет идет со стороны геймдизайна и отдела, кто отвечает за настройки коллизий. Возможность отмечать объекты, возможность камерой учитывать препятствия - это системная вещь самого движка и для подобного проекта ее особо нет смысла трогать, скорее только настроить, программисты в данном случае не при делах =)
Не совсем так.
Если ты берешь кастомный, то там уже модифицируешь движок под свой проект и делаешь лучше, позволяешь себе впихнуть больше или иначе организовать работу систем.
Если ты берешь стоковый Unreal Engine под Open World, то надо отталкиваться от возможностей движка.
1. Не делай тяжелой логики на спауне экторов, тут кастомный движок не поможет.
2. Лимитируй количество экторов на чанке, чтобы регистрация проходила быстро и на рендер и для физики.
3. Фолягу дели на чанки, хорошо настрой ей лоды, чтобы на некой дистанции заменять на лоды, а начиная с еще большей дистанции вообще убирать все HISM и мержить их в один меш, где каждое дерево - это по сути два плейна крест на крест.
и так далее.
4. Следи за тем, сколько у тебя ресурсов единовременно загружено в радиусе, следи за соблюдением BB у объектов, чтоб не раздували чанки и прочее и прочее.
Ты пишешь "Когда я впервые подключил этот хваленый World Partition, первое что я увидел при попытке посетить/покинуть остров - страшные лаги.". А лаги где? В редакторе, да? В билде? Открывай профайлер и смотри что приводит к лагам. Разбирайся со всем что написано в Unreal Insights, логах, какие параметры есть для стриминга из коробки и прочее и прочее.
Ну т.е. надо прям сидеть и кропотливо работать, разобраться в оптимизации, профайлинге, организации мира, контролировать загруженные ресурсы, DC, нагрузку на CPU, разбираться с возникающими лагами, каждый день собирать билд и проверять производительность именно в нем.
Тот же фортнайт собран на ванильном UE и это вполне себе Open World, да, там есть проблемы с компиляцией шейдеров, но если это останется твоей единственной проблемой - уже можно будет сесть и разобрать под конец как их вытащить и посчитать на запуске.