Ну там когда как было, я выше приводил пару примеров с 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 делать, доступных для него плагинов и прочих ресурсов, которые часто палятся. Возможностей самого движка, что из них было использовано и как.
Потому что "камера даже не пытается реагировать на то, что персонаж скрыт за другими объектами" звучит очень странно в контексте работы программистов, когда это совершенно не связанная с ними задача.
Динамическая тень не поможет, она перекроет свет на полу, но не повлияет на переотраженный свет, который запекся на окружение, т.е. по сути будет тень на более светлом фоне, потому что вокруг везде запечено уже влияние света который через дверь должен пройти
Куча артефактов, есть дверь, например. Что делать? Запечь свет для открытой двери? Тогда он будет даже когда ее закроют (очень часто такое наблюдается в Stray). Запечь для закрытой двери? Но тогда свет не появятся в другой комнате когда дверь откроется и т.д.
Элден фризил жестоко на любом железе на ПК, например ) с Хогвартсом у меня были проблемы на топовом железе прошлого поколения (ну видимо оно не катируется после появления нового). Но сами игры оказались интересным, потому просто резал настройки или менял конфиги, да играл
Потому что показательные примеры говорят, что в определенных рамках, если сама игра нравится пользователям, то на продажи не особо повлияет техническое состояние. Да ещё и оценки ставят отличные. Далеко ходить не надо, Элден и Хогвартс - продажи миллионы копий (вроде уже более 13 лямов каждый), не важно что есть фризы, проблемы с фпс на топовом железе. В итоге выходит, что голосуют рублем за такой подход вполне.
Ну там когда как было, я выше приводил пару примеров с 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 делать, доступных для него плагинов и прочих ресурсов, которые часто палятся. Возможностей самого движка, что из них было использовано и как.
Потому что "камера даже не пытается реагировать на то, что персонаж скрыт за другими объектами" звучит очень странно в контексте работы программистов, когда это совершенно не связанная с ними задача.
Динамическая тень не поможет, она перекроет свет на полу, но не повлияет на переотраженный свет, который запекся на окружение, т.е. по сути будет тень на более светлом фоне, потому что вокруг везде запечено уже влияние света который через дверь должен пройти
Куча артефактов, есть дверь, например. Что делать? Запечь свет для открытой двери? Тогда он будет даже когда ее закроют (очень часто такое наблюдается в Stray). Запечь для закрытой двери? Но тогда свет не появятся в другой комнате когда дверь откроется и т.д.
Не был, у Corridor Crew был в гостях чел который участвовал в разработке, они анимировали эту историю и получилась ужасно
На сундук
О да, потому что в пятом есть люмен и наниты, с которыми разобраться уж точно получится быстрее )
А что не так с анчартедом? Прошел его на стимдеке с качеством куда лучше чем на PS4 и ещё фпс лочил на 30, ибо обычно было 40+
Элден фризил жестоко на любом железе на ПК, например ) с Хогвартсом у меня были проблемы на топовом железе прошлого поколения (ну видимо оно не катируется после появления нового).
Но сами игры оказались интересным, потому просто резал настройки или менял конфиги, да играл
Потому что показательные примеры говорят, что в определенных рамках, если сама игра нравится пользователям, то на продажи не особо повлияет техническое состояние. Да ещё и оценки ставят отличные.
Далеко ходить не надо, Элден и Хогвартс - продажи миллионы копий (вроде уже более 13 лямов каждый), не важно что есть фризы, проблемы с фпс на топовом железе.
В итоге выходит, что голосуют рублем за такой подход вполне.