Вот уже почти 2 года я наяривал этот треклятый анриал, пытаясь создать оптимизированный открытый мир. И знаете что? Стоковый Unreal Engine вообще не рассчитан на так называемый Open World, который они с таким усердием продвигают последние годы. И сейчас я вам расскажу почему.
12 лет разработки. У игры всего 33 (теперь 34!) отзыва в Steam за 4 месяца. В то же время это самая крутейшая смесь RPG и визуальных новелл с необычной боевой системой. Без спойлеров.
Fire Emblem, XCOM, карточные рогалики, пошаговые тактики, очень много пикселей и красивого арта - рассказываю о интересных, многообещающих и не очень проектах, демоверсии которых попробовал на фестивале "Играм Быть".
Вообще ничего не ждал от вышедшего демо по предстоящей игре, но попробовав и пройдя её, загорелся интерес и вишлист пополнился.
Мои надежды растворились, как слёзы во время дождя. Сиквел - буквально технический и духовный клон оригинала, со всеми вытекающими.
И о чудо: игра замечательно воспроизводится на консолях и не требует для таких красот видеокарт уровня 4080. Речь о предстоящей Kingdom Come Deliverance 2.
Привет, DTF.
Я главный (и единственный) разработчик средневековой RPG-Strategy игры Mainland, аналога Mount and Blade, но с кооперативом.
Кстати, демо будет доступно уже в феврале
Последние 5 лет я занимаюсь разработкой в Unreal Engine в свободное время.
За это время у меня сложилось очень хорошее отношение к этому движку и сейчас я вам объясню, почем…
Кратко рассказываю, что это за игра такая. И правда ли, что она настолько крутая, как о ней говорят.
Решил коротко рассказать про некоторые хитрые штуковины, которые используются при разработке игр. Штуки эти общеупотребимы, поэтому используются почти во всех играх. И если вы далеки от разработки игр, то некоторые штуки, думаю, вам будет интересно узнать.
Небольшая заметка с перечислением и примерами механик которых не хватает в приключениях, реализация оных, как правило, не очень сложна - но их просто не делают.
Unreal Engine - это не волшебный движок с кнопкой "Сделать збс", опенворлды на анриле имеют кучу проблем, ряд из которых остался со времен четверки.
1. HLOD в целом запекатеся нормально, но может выжрать тонну памяти и ресурсов (в зависимости от чанка). Если проект крупный, то этим вообще занимается отдельная выделенная машина, которая пересобирает дальние лоды. После чего на финальном этапе разработке игры их еще и ручками лучше перерисовать.
2. World Partition все еще имеет ряд болячек с World Composition, о котором я писал когда-то статейку + о ряде болячек рассказывают на выступлениях, посмотри последний Unreal Fest, в том числе от CDPR. Как это лечится? Берется движок и переписывается стриминг, регистрация экторов или вообще отказ от экторов для статики и т.д.
3. Да, не надо делать сложной логики на констракшене и BeginPlay особенно у того, что стримится, пачка экторов появляется одновременно и бьет по производительности. Нужно следить за тем, что делаешь.
4. Да, работа в редакторе и в билде разнится. Потому финальную производительность нужно смотреть только в билде, и билды нужны регулярные.
5. Да, систему сохранений надо писать самому, ровно как и разбираться с возможностью перемещать объекты между чанками и чтоб это сохранялось и т.д. На эту тему тоже когда-то рассказывал, как подобное делать.
6. Про люмены и наниты, они жрущие, причем как для разработчика так и для игрока, нужно собирать сцену с учетом таргет железа и следить за тем, что загружено единовременно, что и как влияет на производительность.
В общем внезапно да, если собираешь что-то более менее сложное, с движком нужно работать. Если нет возможности менять исходники, значит следить за ограничениями и стараться не делать чего-то, что за эти ограничения вылезает (не пихать кучу логики на спаун, следить за тем что стримится и когда, за распределением ресурсов, количестве экторов в радиусе стриминга и т.д.)
Короче, "библиотечные методы" анрила - это буквально технодемки, которые в проекте лучше не использовать.
Все что выкладывают эпики (демка матрицы, лира и прочее) это технодемки и точно не является примером того как стоит делать.
А вот про "библиотечные методы", надо просто понимать их плюсы и минусы, разбираться в них, чтобы решать что использовать, а то нет и как это использовать.
UE - это инструмент, да еще и универсальный от медиапродакшена до мобилок (хотя с последним уже не особо для слабых дейвайсов). С инструментом надо уметь работать и учитывать его особенности, плюсы и недостатки. А просто так из коробки под все случаи жизни в нем нет.
С инструментом надо уметь работать и учитывать его особенности, плюсы и недостатки. А просто так из коробки под все случаи жизни в нем нет.Тут буквально примеры "ложки с дыркой".
- Система загрузки? Да, но она застряла в эпохе HalfLife1.
- Система проверки телепорта? Да, но она заточена только для пустого/прогруженного пространства.
- Система спавна статик объектов? Да, но мы сэкономили целую 1 булевую переменную/индексную таблицу и при спавне пересчитываем коллизии, вместо наивного добавления из индекса.
Это бувкально "вот тебе ложка" - "но в ней дырка!" - "С инструментом надо уметь работать и учитывать его особенности, плюсы и недостатки.".
Да, работа в редакторе и в билде разнится. Потому финальную производительность нужно смотреть только в билде, и билды нужны регулярные.
фига се у них конкурсы интересные
А мне и не нужна кнопка "Сделать збс", мне нужно чтобы инструмент работал так, как его продвигают. У меня он так не работает, и еще куча народа на форумах сталкиваются с тем же.
Как это лечится? Берется движок и переписывается стриминг, регистрация экторов или вообще отказ от экторов для статики и т.д.Так я и написал:
Стоковый Unreal Engine вообще не рассчитан на так называемый Open World
Короче надо работать. И походу за это денюшку разрабы и получают. Особенно хорошие, которые умеют делать игры с нормальным фпс.
Здравствуйте! "На эту тему тоже когда-то рассказывал, как подобное делать" - это где то в открытом доступе? Если у вас есть свой канал, можете дать на него ссылку?