5:36 Накопление каждый тик - Event tick - Set timer by (Function/Trigger) 6:32 Блюпринт в квадрате - Избегание кастов - Blueprint Interface 8:37 Solid программирование - Single Responssibility - Один блюпринт отвечает за одно (Виджет показывает, программа в компоненте) 10:32 Short and Simple - Движок не всегда интуитивно понятен, но он всегда логичен - Пишем код используя предоставленные разрабом интрументарий 13:05 Don't Repeat Yourself (DRY) 13:50 Не держите все объекты на карте - Оптимизирует LevelStreamin, WorldPartition, LODs 15:00 Не боимся пробовать, ошибемся в любом случае (графон больше жрёт ресурсов, чем программная часть) Графическая Часть 16:00 Коллизии 17:40 Физика - про Carmageddon :) - SetSimulatePhysic - все зависит от количества физики в игре 21:00 Текстуры и Материалы - Compession (Default/Normal/Masks) 22:00 LODs - Starfield - Cities Skyline 25:00 Nanite - Static vs Skeletal Mesh (Примитивы и пропсы / анимации и персонажи) -возможно в будущем добавят Skeletal Nanite 25:40 Materials и Shaders 27:00 Particle System
Мне так нравится, как вы объясняете, всё глобально разжёвываете. Смотришь видео и отдыхаешь. Так приятно вас слушать. Ещё нравится, что выдаёте перевод английских слов.
Я не могу это слушать, слишком много сказано неправильно. 1. Тик можно выключать и включать так же как и таймер, эвентом например, (set actor tick) но это выключает тик у всех компонентов актора, можно выключать тик и отдельно у каждого компонента (set component tick). 2. В акторе можно задавать как часто будет происходить тик (tick interval) и это тоже можно менять динамически, необязательно каждый кадр должен выполняться тик тогда и просадок серьезных не будет. 3. Cast можно делать, они для этого и созданы и никакой груз это не тащит это чуть по другому работает, допустим вы в виджете делаете cast на персонажа за которого играете, он не будет его дублировано загружать ещё раз, так как он уже в памяти и вы за него играете повторяюсь и в основном так и происходит, когда вы делаете каст на какой то объект он уже есть на уровне и загружен в память, лишнего там вряд ли что прогрузит. Я это всё говорю из своего опыта, у меня есть игра на Nintendo Switch (на самую слабую консоль с телефонным железом) которую я разрабатывал будучи новичком и там вся игра сделана из кастов и куча логики на тике, я тогда даже не знал что такое Inteface, игра там там работает хорошо, даже с такой плохой логикой как говорит автор. Перебарщивать с кастами конечно не стоит, лучше сделать через интерфейс если это возможно, это даже не про производительность, а про удобство, кучу кастов кастов лупить это тупо, проще 1 интерфейс сделать, если что внтури интерфейса тоже происходит каст, просто этого не видно. 4. Не нужно выбирать рандомные категории для метода сжатия текстур лишь бы весили по меньше, каждая категория нужна для своего, в видео автор выбрал Alpha компрессию и у него выключились все каналы текстуры кроме R, если бы эта текстура была в материале и использовала другие каналы которые вы выключили, была бы ошибка, если не знаете лучше оставьте категорию по стоку. 5. Лодов много лупить не нужно максимум 5-6, они тоже занимают приличное количество памяти, в зависимости от модели конечно. 6. Нанит нужен только для сеток с большим количеством вершин, не стоит включать его на сетку 15к -100к треугольников. Нанит только сожрёт ваш фпс и визуально разницы особо не будет, ещё если кто не знал сетка с нанитом никогда не исчезнет на расстоянии и я считаю это косяком т.к. на супер большом расстоянии объект будет всегда видно и очевидно что это сжирает производительность. Но вот если нанит включен на растительность и расставлен инструментом Foliage, то там почему он пропадает на расстоянии, в общем нанит это пока сырая фигня для ваших игр это не нужно, это больше подходит для синематиков и трейлеров, чем для игр.
Он полный идиот, и у меня бомбит когда такие придурки снимают видео в серьёз, он даже базовых терминов незнает; Рекурсивные функции, Компиляция и т. д. Как этот неуч вообще появился на свет?! Даже ответить за слова эта ляля ни сможет. КАК ОН МОЖЕТ КОГОТО УЧИТЬ ЕСЛИ ОН НИЖЕ АНРИЭЛА НИ КУДА НЕ ОПУСКАЛСЯ?!! СИДИТ ХРЕНН В ПАЛЬТО И ХЕРНЮ ГОРОДИТ...!!!🤬
Согласен с тобой во всём. Он еще сказал, типо, блупринты медленне чем с++, только прикол в том, что блупринты - это и есть с++, просто любая нода блупринта, это просто скрипт, который написан на с++. Про каст он реально бред сказал, типо, каст на перса тащит на себе всего актора перса😂😂😂. По факту, каст направлен на прямую к компоненту, к которому через этот каст обращаюся, и не затрагивает чарактер мувемент и другие неиспользуемые кастом компоненты.
отличный урок, ❤ но у меня появился вопрос. если в одном блюпринте очень много логики. допустим у меня есть UMG для главного персонажа, и в этом интерфейсе, очень много логики, с разными variables, Functions, Macros и так далее. Что лудше? > Cast to Player < или > Get actor< и выбрать Player? какой из них работает быстрее? какой из них подсоединить к > On event begin play? хочу уточнить, Не .. >Get All actors of class< а именно >Get actor of class< зарание спасибо за ответ.
большое спасибо за твои уроки! подскажи по своему опыту, можно ли полностью настроить все механики, интеллект и анимации врага для игры на шаблонном манекене, не дожидаясь окончания разработки игровой модели, а потом просто заменить манекен на готовую модель? или это будет двойная работа и может возникнуть ряд ошибок?
По поводу кастов, очень интересно. Что если у меня в сотне блупринтов есть каст на главного персонажа в котором много логики, но который и так всегда загружен в память потому что игра ж за него. Это создаст какуето внушительную загрузку или нет, так как он всеравно загружен?
Код быстрее в 30 раз. БП не заменяет код, БП это прямое следствие системы рефлексии и использование БП зависит от сложности абстракций (функций, классов и т.д.), слишком объемные абстракции требуют большей скорости работы и БП просто снизят производительность, .К тому же БП нагружены визуально. Наример юай легче и нагляднее сделать на плюсах. Буквально пять строчек кода. Также одна из ключевых особенность БП, прежде всего кастомных, это взаимодействие дизайнера с кодом без необходимости влезать в код и перезапускать движок. Пример - изменение меша БП-ассета. Еще на плюсах можно написать абсолютно все, а на бп нельзя. Например отрыв плоти при выстреле в зомби на БП не напишешь. - Ваш кодовый душнила PS: забыл, БП не совместимы с гитхабом, а гитхаб это один из аспектов проф. разработки.
разве нельзя в бп заставить условный меш руки удалять и заменить на меш оторванной руки? Или просто удалить простым бп руку а под ним уже оторванная часть?
А будет поподробнее видео ? Типа если какой то объект переведен в мувабл у него становится динамическая коллизия, а это жрёт и довольно не мало, потому по возможности надо отключать коллизию у всех подвижных объектов или делать феейковую коллизию. Про текстуры, что есть виртуальые текстуры и они обязаны быть с нанитами. Ну и как бы ещё очень очень много нюансов в видео не рассказано
@@makeyourgame2210 да, определённо, видео хорошее, особенно как вы сказали в первые секунды видео-"если вы заинтересовались уже хорошо ", но в планах есть сделать подробно про оптимизацию ?:) я просто нигде не находил нормального разбора про оптимизацию :)
юнити лучше для мобильных и 2д игр.. в Анриле все лучше и производительность и обработка изображений/материалов а особенно многополигональных моделей с поддержкой нанитов а это вообще революция в гейминдустрии
ЕСЛИ НЕ ЗНАЕШ ЧТО ВЫБРАТЬ, ВОТ МОЙ СОВЕТ: 1) иди учи C. 2) потом учи С++ 3) потом учи openGL на С++ 4) Создавай свой игровой движок он состоит из: Графический движок openGL либо Vulkan API, Физический движок обычно это PhysX, ну и для окна: WINAPI. И на своём движке делай что хочешь.
А как оптимизировать меню игры? Система даже без коллизий и графики нагружается просто так в пустую. А хотелось бы, чтобы меню было статичным полностью как в отключенном режиме реал-тайме. Возможно ли так сделать для меню игры чтобы был отключенный режим реал-тайма уже у упакованной игре?
Если не ограничить, движок старается рисовать максимальное количество кадров. Поэтому в менюшках можно включать ограничитель где-то на 30 FPS - вполне будет достаточно, а мир можно поставить на паузу соответствующей нодой(искать по слову pause). Ещё по умолчанию стоит включать vSync, чтобы движок не рисовал больше кадров чем может отобразить монитор, и не было разъезжающейся картинки по вертикали, хотя эту опцию стоит давать возможность отключить игрокам, ато есть особо одарённые любящие лишние отрисовки в пустоту, да и просто для тестов.
Лоды - увеличивают число моделей которые нужно хранить в движке то есть размер игры растет А наниты НЕПРАВИЛЬНо используют. Они для массового дублирования небольшого числа повторяемых ассетов
Лоды экономят память твоей видюхи в разы. Не было бы лодов, сидел бы в комнатушке с миллионами полигонов своих и гигами текстур, и никуда бы не выходил )))) А то что они в памяти, так память оперы проще нарастить, от куда и достается лод.
@@SilverMLP Это если говорит о моделях что отображаются вдалеке Есть куча игр где с лодами ПЕРЕТРУЖДАЛИСЬ создаваляя слишком много на каждый шаг - и движки тупо висли) Лоды хорошо работают в уловиях когда ассеты локально распределены по уровню А вот если равномерно... все модели будут в видеокарте Представь что у дерева будет 10 лодов Пока этот лес от тебя в километре - то тебе достаточно последнего А если ты в лесу ?! То все 10!
Хочешь попасть в закрытый Telegram-чат по Unreal Engine, играм и 3D, где опытные и новички помогают друг другу? За любой донат от 100 рублей на Бусти: boosty.to/makeyourgame я пришлю ссылку на закрытый Telegram-канал, куда ты сможешь вступить и присоединиться к единомышленникам. Доступ - навсегда;) Игра на обложке - The Day Before ================================= Группа в ВКонтакте: vk.com/makeyourgameunreal ================================= Подписка на канал - только приветствуется! ================================= #games #unreal #unrealengine
К сожалению, когда тебе нужно процедурно анимировать например покачивание ствола оружия - без тика никак. Каст просто обязывает держать в памяти экземпляр объекта того типа, ссылку на который мы получаем, ресурсов приведение типа особо не потребляет а вот интерфейс - штука в исполнении куда более тяжелая. Врядли разумно например в анимблупринте обходиться без каста - он и так будет висеть в памяти с персонажем, так что жесткие ссылки вполне уместны. А вот с выключателем на уровне нужно работать интерфейом, особенно если мы грузим контент асинхонно. Вообще, большую часть ресурсов вашего проэкта кушает не логика а графоний. Вот там оптимизировать не переоптимизировать. Вообще полезные основы для новичков.
крути в аним бп, там многопоток и в теории оно дешевле обходится, чем блупринты гонять) По факту в бп крутить надо лишь базовые переменные для передвижения (примерно раз 10 в секунду), и каст для абилити системы (как раз чтобы взаимодействовать со всякими лампочками), но можно и триггеров натыкать в каждый выключатель или шкаф (но это васянский метод), хотя в ААА любят такое дерьмо.
Привет !, подскажи пожалуйста делаю ли я правильно - Для будущей игры я создаю запросы например - как сделать гранату или же как сделать систему оружия, и все это я добавляю в отдельную папку некоторым видео по 1-2 года, и будет ли это работать например на версии 4.7 когда гайд сделан на 4.2 ?.
Вся логика в игре НЕОБЫЧНО ТЯЖЁЛАЯ и сделана на Евент Тик, и касты тоже есть немного. Более 100 объектов одновременно высчитывают каждый свою тяжёлую логику... Ничего НЕ тормозит вообще до 250 объектов. Процессор i3 9000. 16GB RAM. 3060 12GB. Буду оптимизировать всё равно. Пару месяцев займёт. Выпущу игру в Steam в 2024 - напишу название сюда, если не забуду. Игра любопытная. P.S: C++ это прошлый век как и Ассемблер, относительно C++... С удовольствием НЕ использую C++ и делаю на блупринтах. Быстрее игра делается. Прям кайф. F*ck old coding.
Как может C++ быть прошлым веком? Это же предкомпилированный код. Виртуальная машина сжирает колоссальное количество ресурсов по сравнению с нативной компиляцией. Самые тяжелые места по любому надо переводить на плюсы.
Я очень люблю блупринт, но если профайлер покажет мне что они много на себя берут, перепишу на крестах не задумываясь. Просто аккуратная работа с блупринтом очень производительна. Даже слабые мобилки прекрасно с ними работают.
@@ArmlessMxster «c++ прошлый век» - ты написал это на операционке, написанной на C++ и С и на софте который собирал компилятор, написанный на С++. Продолжай верить в прохладу. Без негатива.
самый уродский язык из всех, что я видел это анриловский С++ в связке с VS. Даже ассемблер лучше. Подсказки не работают, высвечиваются ошибки, которых нет, текст сообщений о ошибках выводится на какой то лютейшей тарабарщине. Компилится может целую вечность - от 6 сек до10 МИНУТ! С чем это связано никто не ставит в известность. Отвратительно. Ну и сам язык, очень душный и недружелюбный. Со своими звездочками слева справа и тд. И об этом все лицемерно помалкивают. Нельзя работать на этом языке. Ты просто станешь слишком злой и не напишешь интересную игру. А если ты еще сойдешь с ума и займешься мультиплеером... то излечить тебя станет уже невозможно Только блюпринты. Но конечно я не навязываю. Это я сам для себя так решил. Но и других предупреждаю. Кто не знает. Возможно, кому то поможет сверхтоповый комп. Но это не точно. У меня вроде не такой уж плохой. SSD правда нужно больше. Причем, ведь эпики могут заняться этой проблемой, дать какие то рекомендации. Но им похер! Они молчат. Делают вид, что не замечают. Это очень плохо. Ну, значит и не надо ничего разрабатывать на С++.
атласы хороший вариант для мелких деталей того же окружения, для стен и больших объектов лучше делать модули и собирать их них, но если что то очень большое, то лучше обойтись rgb масками, условно церковь большая и делать сплошные стены её проще будет и лучше для оптимизации тайлом/тримом растянуть в одном uv сете, а потом украсить rgb масками и вертекс пейнт накинуть, декали возможно
5:36 Накопление каждый тик - Event tick - Set timer by (Function/Trigger)
6:32 Блюпринт в квадрате - Избегание кастов - Blueprint Interface
8:37 Solid программирование - Single Responssibility - Один блюпринт отвечает за одно (Виджет показывает, программа в компоненте)
10:32 Short and Simple - Движок не всегда интуитивно понятен, но он всегда логичен - Пишем код используя предоставленные разрабом интрументарий
13:05 Don't Repeat Yourself (DRY)
13:50 Не держите все объекты на карте - Оптимизирует LevelStreamin, WorldPartition, LODs
15:00 Не боимся пробовать, ошибемся в любом случае (графон больше жрёт ресурсов, чем программная часть)
Графическая Часть
16:00 Коллизии
17:40 Физика - про Carmageddon :) - SetSimulatePhysic - все зависит от количества физики в игре
21:00 Текстуры и Материалы - Compession (Default/Normal/Masks)
22:00 LODs - Starfield - Cities Skyline
25:00 Nanite - Static vs Skeletal Mesh (Примитивы и пропсы / анимации и персонажи) -возможно в будущем добавят Skeletal Nanite
25:40 Materials и Shaders
27:00 Particle System
Мне так нравится, как вы объясняете, всё глобально разжёвываете. Смотришь видео и отдыхаешь. Так приятно вас слушать. Ещё нравится, что выдаёте перевод английских слов.
Я не могу это слушать, слишком много сказано неправильно. 1. Тик можно выключать и включать так же как и таймер, эвентом например, (set actor tick) но это выключает тик у всех компонентов актора, можно выключать тик и отдельно у каждого компонента (set component tick). 2. В акторе можно задавать как часто будет происходить тик (tick interval) и это тоже можно менять динамически, необязательно каждый кадр должен выполняться тик тогда и просадок серьезных не будет. 3. Cast можно делать, они для этого и созданы и никакой груз это не тащит это чуть по другому работает, допустим вы в виджете делаете cast на персонажа за которого играете, он не будет его дублировано загружать ещё раз, так как он уже в памяти и вы за него играете повторяюсь и в основном так и происходит, когда вы делаете каст на какой то объект он уже есть на уровне и загружен в память, лишнего там вряд ли что прогрузит. Я это всё говорю из своего опыта, у меня есть игра на Nintendo Switch (на самую слабую консоль с телефонным железом) которую я разрабатывал будучи новичком и там вся игра сделана из кастов и куча логики на тике, я тогда даже не знал что такое Inteface, игра там там работает хорошо, даже с такой плохой логикой как говорит автор. Перебарщивать с кастами конечно не стоит, лучше сделать через интерфейс если это возможно, это даже не про производительность, а про удобство, кучу кастов кастов лупить это тупо, проще 1 интерфейс сделать, если что внтури интерфейса тоже происходит каст, просто этого не видно. 4. Не нужно выбирать рандомные категории для метода сжатия текстур лишь бы весили по меньше, каждая категория нужна для своего, в видео автор выбрал Alpha компрессию и у него выключились все каналы текстуры кроме R, если бы эта текстура была в материале и использовала другие каналы которые вы выключили, была бы ошибка, если не знаете лучше оставьте категорию по стоку. 5. Лодов много лупить не нужно максимум 5-6, они тоже занимают приличное количество памяти, в зависимости от модели конечно. 6. Нанит нужен только для сеток с большим количеством вершин, не стоит включать его на сетку 15к -100к треугольников. Нанит только сожрёт ваш фпс и визуально разницы особо не будет, ещё если кто не знал сетка с нанитом никогда не исчезнет на расстоянии и я считаю это косяком т.к. на супер большом расстоянии объект будет всегда видно и очевидно что это сжирает производительность. Но вот если нанит включен на растительность и расставлен инструментом Foliage, то там почему он пропадает на расстоянии, в общем нанит это пока сырая фигня для ваших игр это не нужно, это больше подходит для синематиков и трейлеров, чем для игр.
Он полный идиот, и у меня бомбит когда такие придурки снимают видео в серьёз, он даже базовых терминов незнает; Рекурсивные функции, Компиляция и т. д. Как этот неуч вообще появился на свет?! Даже ответить за слова эта ляля ни сможет. КАК ОН МОЖЕТ КОГОТО УЧИТЬ ЕСЛИ ОН НИЖЕ АНРИЭЛА НИ КУДА НЕ ОПУСКАЛСЯ?!! СИДИТ ХРЕНН В ПАЛЬТО И ХЕРНЮ ГОРОДИТ...!!!🤬
Ещё надо прибавить что NANITE не работает на андроид и айос
Можно пожалуйста узнать как называется игра на Nintendo Switch?
Согласен с тобой во всём.
Он еще сказал, типо, блупринты медленне чем с++, только прикол в том, что блупринты - это и есть с++, просто любая нода блупринта, это просто скрипт, который написан на с++.
Про каст он реально бред сказал, типо, каст на перса тащит на себе всего актора перса😂😂😂. По факту, каст направлен на прямую к компоненту, к которому через этот каст обращаюся, и не затрагивает чарактер мувемент и другие неиспользуемые кастом компоненты.
Ну в целом слышно как он даже говорит, по дилетантски. Глубоко ничего не знает, он видимо даже не программист в целом
Огромное спасибо за труды!)
Ещё хотелось бы подробный урок по оптимизации света в люмене.
По поводу mesh лучше размещать в блюпринт? Потом множить или mesh размещать чисто отдельно
отличный урок, ❤ но у меня появился вопрос.
если в одном блюпринте очень много логики.
допустим у меня есть UMG для главного персонажа, и в этом интерфейсе, очень много логики, с разными variables, Functions, Macros и так далее.
Что лудше? > Cast to Player < или > Get actor< и выбрать Player? какой из них работает быстрее? какой из них подсоединить к > On event begin play?
хочу уточнить, Не .. >Get All actors of class< а именно >Get actor of class<
зарание спасибо за ответ.
*Сделай видео , как подключить к проекту Memory Insights и отслеживать в нём утечки памяти , либо же весящие указатели. Было бы интересно посмотреть.*
СПАСИБО ЗА ВИДЕО!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
Спасибо!
большое спасибо за твои уроки! подскажи по своему опыту, можно ли полностью настроить все механики, интеллект и анимации врага для игры на шаблонном манекене, не дожидаясь окончания разработки игровой модели, а потом просто заменить манекен на готовую модель? или это будет двойная работа и может возникнуть ряд ошибок?
По поводу кастов, очень интересно. Что если у меня в сотне блупринтов есть каст на главного персонажа в котором много логики, но который и так всегда загружен в память потому что игра ж за него. Это создаст какуето внушительную загрузку или нет, так как он всеравно загружен?
Код быстрее в 30 раз. БП не заменяет код, БП это прямое следствие системы рефлексии и использование БП зависит от сложности абстракций (функций, классов и т.д.), слишком объемные абстракции требуют большей скорости работы и БП просто снизят производительность, .К тому же БП нагружены визуально. Наример юай легче и нагляднее сделать на плюсах. Буквально пять строчек кода. Также одна из ключевых особенность БП, прежде всего кастомных, это взаимодействие дизайнера с кодом без необходимости влезать в код и перезапускать движок. Пример - изменение меша БП-ассета. Еще на плюсах можно написать абсолютно все, а на бп нельзя. Например отрыв плоти при выстреле в зомби на БП не напишешь. - Ваш кодовый душнила
PS: забыл, БП не совместимы с гитхабом, а гитхаб это один из аспектов проф. разработки.
разве нельзя в бп заставить условный меш руки удалять и заменить на меш оторванной руки? Или просто удалить простым бп руку а под ним уже оторванная часть?
Ну для справедливости в анриле есть инструмент для мёрджа блупринтов
рофлю с челов у которых плюсы головного мозга
доказывают мне в каждой конфе что я ОБЯЗАН на них писать ))))
Спасибо за урок бомба
это же мамкины прогеры. убийцы гта 5
c 2015 жду такого видео, нормального, достаточно полного.
имеем в виду)
Спасибо за урок
Так ето,что делать если нету set text? когда нпс с квестами делаешь.я на 4.27 делаю.
Я не помню что было на 4.27. Я уже больше года на пятерке. Если нет Set Text, но попробуйте Format Text.
@@makeyourgame2210 не сработало (
@@makeyourgame2210 может есть ещё какие-то варианты?
@@makeyourgame2210 пж ответь если можешь
это лишь малая часть о там как оптимизировать игры, но все по делу
кривой лод из Старфилда - это был фейк от реддитора ради хайпа. в реальности там все норм было. стоит проверять конечно матчасть
25:20 привет из 2024 года 😊 уже работает ))
А будет поподробнее видео ? Типа если какой то объект переведен в мувабл у него становится динамическая коллизия, а это жрёт и довольно не мало, потому по возможности надо отключать коллизию у всех подвижных объектов или делать феейковую коллизию. Про текстуры, что есть виртуальые текстуры и они обязаны быть с нанитами. Ну и как бы ещё очень очень много нюансов в видео не рассказано
На то они и нюансы, что их нужно обсуждать отдельно. Главное, что это видео задает вектор, куда смотреть.
@@makeyourgame2210 да, определённо, видео хорошее, особенно как вы сказали в первые секунды видео-"если вы заинтересовались уже хорошо ", но в планах есть сделать подробно про оптимизацию ?:) я просто нигде не находил нормального разбора про оптимизацию :)
@@kiraaa80 думаю, что да, сделаю такое видео, где включу командную строку с фпс и буду показывать, как фпс уменьшается)
@@makeyourgame2210 спасибо огромное! Буду ждать :) без шуток очень интересно что за 10 лет работы в движке я ещё не знаю
А так понимаю что Юнити больше фпс выдает для средних и маленьких проектов но в больших анрил лучше?
юнити лучше для мобильных и 2д игр.. в Анриле все лучше и производительность и обработка изображений/материалов а особенно многополигональных моделей с поддержкой нанитов а это вообще революция в гейминдустрии
ЕСЛИ НЕ ЗНАЕШ ЧТО ВЫБРАТЬ, ВОТ МОЙ СОВЕТ: 1) иди учи C. 2) потом учи С++ 3) потом учи openGL на С++ 4) Создавай свой игровой движок он состоит из: Графический движок openGL либо Vulkan API, Физический движок обычно это PhysX, ну и для окна: WINAPI. И на своём движке делай что хочешь.
А как оптимизировать меню игры? Система даже без коллизий и графики нагружается просто так в пустую. А хотелось бы, чтобы меню было статичным полностью как в отключенном режиме реал-тайме. Возможно ли так сделать для меню игры чтобы был отключенный режим реал-тайма уже у упакованной игре?
Если не ограничить, движок старается рисовать максимальное количество кадров. Поэтому в менюшках можно включать ограничитель где-то на 30 FPS - вполне будет достаточно, а мир можно поставить на паузу соответствующей нодой(искать по слову pause). Ещё по умолчанию стоит включать vSync, чтобы движок не рисовал больше кадров чем может отобразить монитор, и не было разъезжающейся картинки по вертикали, хотя эту опцию стоит давать возможность отключить игрокам, ато есть особо одарённые любящие лишние отрисовки в пустоту, да и просто для тестов.
Лоды - увеличивают число моделей которые нужно хранить в движке
то есть размер игры растет
А наниты НЕПРАВИЛЬНо используют. Они для массового дублирования небольшого числа повторяемых ассетов
Лоды экономят память твоей видюхи в разы. Не было бы лодов, сидел бы в комнатушке с миллионами полигонов своих и гигами текстур, и никуда бы не выходил )))) А то что они в памяти, так память оперы проще нарастить, от куда и достается лод.
@@SilverMLP Это если говорит о моделях что отображаются вдалеке
Есть куча игр где с лодами ПЕРЕТРУЖДАЛИСЬ создаваляя слишком много на каждый шаг - и движки тупо висли)
Лоды хорошо работают в уловиях когда ассеты локально распределены по уровню
А вот если равномерно... все модели будут в видеокарте
Представь что у дерева будет 10 лодов
Пока этот лес от тебя в километре - то тебе достаточно последнего
А если ты в лесу ?!
То все 10!
Ещё как вариант кастомные ивенты
Format text его нету
Хочешь попасть в закрытый Telegram-чат по Unreal Engine, играм и 3D, где опытные и новички помогают друг другу?
За любой донат от 100 рублей на Бусти: boosty.to/makeyourgame я пришлю ссылку на закрытый Telegram-канал, куда ты сможешь вступить и присоединиться к единомышленникам. Доступ - навсегда;)
Игра на обложке - The Day Before
=================================
Группа в ВКонтакте: vk.com/makeyourgameunreal
=================================
Подписка на канал - только приветствуется!
=================================
#games #unreal #unrealengine
К сожалению, когда тебе нужно процедурно анимировать например покачивание ствола оружия - без тика никак. Каст просто обязывает держать в памяти экземпляр объекта того типа, ссылку на который мы получаем, ресурсов приведение типа особо не потребляет а вот интерфейс - штука в исполнении куда более тяжелая. Врядли разумно например в анимблупринте обходиться без каста - он и так будет висеть в памяти с персонажем, так что жесткие ссылки вполне уместны. А вот с выключателем на уровне нужно работать интерфейом, особенно если мы грузим контент асинхонно. Вообще, большую часть ресурсов вашего проэкта кушает не логика а графоний. Вот там оптимизировать не переоптимизировать. Вообще полезные основы для новичков.
крути в аним бп, там многопоток и в теории оно дешевле обходится, чем блупринты гонять) По факту в бп крутить надо лишь базовые переменные для передвижения (примерно раз 10 в секунду), и каст для абилити системы (как раз чтобы взаимодействовать со всякими лампочками), но можно и триггеров натыкать в каждый выключатель или шкаф (но это васянский метод), хотя в ААА любят такое дерьмо.
Привет !, подскажи пожалуйста делаю ли я правильно -
Для будущей игры я создаю запросы например - как сделать гранату или же как сделать систему оружия, и все это я добавляю в отдельную папку некоторым видео по 1-2 года, и будет ли это работать например на версии 4.7 когда гайд сделан на 4.2 ?.
Будет но возможно с некоторыми оговорками, надо смотреть ченжлоги если че то не работает или чего то нет
ставь таймкоды. время экономит
Чёт воды многовато, побольше бы примеров как правильно
Вся логика в игре НЕОБЫЧНО ТЯЖЁЛАЯ и сделана на Евент Тик, и касты тоже есть немного.
Более 100 объектов одновременно высчитывают каждый свою тяжёлую логику...
Ничего НЕ тормозит вообще до 250 объектов.
Процессор i3 9000. 16GB RAM. 3060 12GB.
Буду оптимизировать всё равно. Пару месяцев займёт.
Выпущу игру в Steam в 2024 - напишу название сюда, если не забуду.
Игра любопытная.
P.S:
C++ это прошлый век как и Ассемблер, относительно C++...
С удовольствием НЕ использую C++ и делаю на блупринтах.
Быстрее игра делается.
Прям кайф. F*ck old coding.
Как может C++ быть прошлым веком? Это же предкомпилированный код. Виртуальная машина сжирает колоссальное количество ресурсов по сравнению с нативной компиляцией. Самые тяжелые места по любому надо переводить на плюсы.
Я очень люблю блупринт, но если профайлер покажет мне что они много на себя берут, перепишу на крестах не задумываясь. Просто аккуратная работа с блупринтом очень производительна. Даже слабые мобилки прекрасно с ними работают.
c++ прошлый век xD. Быстрее - может быть, производительнее - нет. И расскажешь как будешь GAS подключать на БП) без негатива
@@ArmlessMxster «c++ прошлый век» - ты написал это на операционке, написанной на C++ и С и на софте который собирал компилятор, написанный на С++. Продолжай верить в прохладу. Без негатива.
@@ArmlessMxster быстрее = производительнее. Это же нативный код.
самый уродский язык из всех, что я видел это анриловский С++ в связке с VS.
Даже ассемблер лучше.
Подсказки не работают, высвечиваются ошибки, которых нет, текст сообщений о ошибках выводится на какой то лютейшей тарабарщине.
Компилится может целую вечность - от 6 сек до10 МИНУТ! С чем это связано никто не ставит в известность.
Отвратительно. Ну и сам язык, очень душный и недружелюбный. Со своими звездочками слева справа и тд.
И об этом все лицемерно помалкивают.
Нельзя работать на этом языке. Ты просто станешь слишком злой и не напишешь интересную игру.
А если ты еще сойдешь с ума и займешься мультиплеером... то излечить тебя станет уже невозможно
Только блюпринты. Но конечно я не навязываю. Это я сам для себя так решил. Но и других предупреждаю. Кто не знает.
Возможно, кому то поможет сверхтоповый комп. Но это не точно. У меня вроде не такой уж плохой. SSD правда нужно больше.
Причем, ведь эпики могут заняться этой проблемой, дать какие то рекомендации. Но им похер! Они молчат. Делают вид, что не замечают.
Это очень плохо. Ну, значит и не надо ничего разрабатывать на С++.
Про материалы бы поподробнее, никак не могу понять как правильно текстурить, либо атласы юзать либо многослойные материалы с масками
материалы - это жирнющая тема. Можно переборщить с каким-нибудь отражением и всё, ФПС говорят "прощай".
@@makeyourgame2210 какое оптимальное количество уникальных материалов должно быть примерно?)
атласы хороший вариант для мелких деталей того же окружения, для стен и больших объектов лучше делать модули и собирать их них, но если что то очень большое, то лучше обойтись rgb масками, условно церковь большая и делать сплошные стены её проще будет и лучше для оптимизации тайлом/тримом растянуть в одном uv сете, а потом украсить rgb масками и вертекс пейнт накинуть, декали возможно
Спасибо!