⚡⚡⚡ Полезные ссылки ⚡⚡⚡ 🔎 yakovlevgamedev.ru/unity_adventure - обучение разработке игр с нуля до создания полноценного проекта 🔎 t.me/yakovlev_advanced_bot - бот для регистрации на вебинар (подарок тут же) 🔎 t.me/yakovlev_gamedev - тут небольшое бонусное видео (в комментарии с постом к этому видео)
@@DeadRabbitCanDance Можно на сайте оставить заявку, мессенджер не важен) Откроется запись 22 числа. Если есть какие-то дополнительные вопросы, то также на сайте (почти в самом верху) есть форма, где можно оставить свои контактные данные), либо можно напрямую написать на почту yakovlev.youtube@yandex.ru
Огромное спасибо, ты как всегда во время, сел за разработку коммерческого проекта, а в архитектуре немного плаваю. Продолжай записывать видосы с рассмотрением более сложных систем, ЛЮБЛЮ ОБАЖАЮ
Здравствуйте, Илья, меня конкретно поражает ваша работа над контентом Именно такой контент по теме геймдева мы и заслуживаем! Спасибо вам большое! И если не составит большого труда, то могли бы вы записать видео похожего формата по Entities и DOTS в целом? Видео на эти темы крайне не хватает на русском ютубе, особенно на момент новых версий движка. Буду душевно благодарен за любую обратную связь!
Не останавливайтесь. Очень полезные и качественные видео. Речь грамотная, структура понятная. Тот контент, который мы не заслужили...но очень хотели. Рубрика - огонь. Но про асинхроны очень хочется дослушать тоже...)))
Супер кайф!!! Очень интересное видео! Многие вещи я, к сожалению, пока не знаю, так как не знаю языка на должном уровне, но базовую задачу я бы выполнил) продолжайте, пожалуйста!
Очень нравятся твои видео! Полезно, красиво, интересно и понятно. В этом ты упомянул про то, что иногда нужно сделать обучение... Обучение! Понятно, что все проекты разные, но было бы очень интересно узнать: может, есть какие-то общие правила/приёмы. Пока что механика обучения (только в начале или вообще по ходу игры) ощущается как один большой костыль
Спасибо за твои видео Илья! Рассмотришь тему для видео - лучшие практики переноса данных между сценами(желательно без DontDestroyOnLoad) и между сессиями(то есть SaveSystem - где какие данные лучше сохранять и как) (потому что я так понимаю что хорошими методами считается комбинирование PlayerPrefs и JSON с шифрованием)
Разбор конкретных кэйсов всегда полезен. Заранее извиняюсь (я новичок в юнити), может что-то прослушал, по-моему не был рассмотрен вариант с обсёрвером. Или триггерколлайдер и есть обсёрвер? Если не ошибаюсь, может в следующих подобных видео рассматривать побольше вариантов реализации и их плюсов и минусов.
чуваки, подскажите какие-нибудь уроки где объясняются все эти классы, конфиги скприптбл обджекты, а то я пока знаю что можно скрипт создать и на этом все
Толчок всегда нужен. А где толчок, там и землетрясение. Пожалуйста продолжай, Илья. Я ранее не видел хороших прогеров с интересной подачей (разве что Романа Сакутина, но у него мало свежего контента по юнити)
В теории звучит легко: "разбейте задачу на мелкие, начните с малого и по мере надобности рефакторите код", но когда дело доходит до реального проекта, где нужно построить автогенератор коридорных уровней с разными типами чанков под разные препятствия, и ещё нужно, чтобы генератор имел возможность работы как в play, так и в edit режиме, и чтобы весь трубочках и проводочках, и дыр дыр дыр под крышкой, тут конечно даа. Почему то сильно потею, постоянно модифицируя систему, не имея уже конечного, завершённого варианта, потому что появляется какая-то деталь, из-за которой приходится отойти от изначальной задумки разработки. Заранее хрен продумаешь такое, а строить постепенно утомляет из-за постоянных доработок и перестроек. Я надеюсь с опытом придёт власть над потоком разработки? Как научиться продумывать всё и искать верные решения сразу?
Если кратко, то никак:) Ты сейчас описал довольно неплохо размера проект, поэтому тут надо время, переработки и тп. Т.е. если не делал такого до, то сразу и не придумаешь. Но тут очень сильно может помочь четко выписать требования необходимые и, как ни странно, из этих требований опять таки выделить шаги, и в процессе уже думать как это все связывать между собой и где узкие места (итеративно)
1) автогенератор коридорных уровней - сначала сделать концепт 1 коридорного уровня, разбить его на составляющую по визуалу, по механикам, открыть какое нибудь рабочее пространство типа Mirror и прописать всё, сделать раскадровку того как персонаж передвигается по нему и что его ждёт 2) разными типами чанков - сначала сделать чанк и сопутствующую ему логике (можно сразу и в 3д потом до 2д ограничить(линейность) чтобы был инструмент на будущее) 3) в play он и так работать будет другой момент в edit режиме - создаем папочку Editor и спокойненько реализуем в ней скрипт интерфейс взаимодействия с основным скриптом генерации 4) делаем трубочки и проводочки и дыр дыр дыр под крышкой
Начинать нужно с вертикального среза игры и финализирования концепции. Вот эти "постоянные доработки и перестройки" - это общая ошибка подхода и никакая "власть над потоком" тут не придёт. Нужно сразу понимать максимально полно какая именно стоит задача. Подход "поди туда, не знаю куда" работает, увы, лишь в сказках.
@@CronaxDervish А тут с другой стороны тебе стучит проблема того, что геймдизайн это не четкая заранее начерченная во всех подробностях магистраль. Его корректируют плейтесты, хорошие или провальные метрики, вообще феномен того, что сама разработка игры как уничтожает какие-то геймдизайнерские гипотезы, которые казались рабочими, так и наоборот подбрасывает новые, которые не были видны до начала разработки. Порой некоторые даже великие проекты вообще с ног на голову переворачиваются и становятся совершенно другими относительно того, чем они задумывались изначально. Не всегда финализированная концепция игры в принципе существует, она сама по себе может быть процессом, причем параллельным реализации и процессу проверки гипотез.
@@СветозарБоголюбов Если гипотезы уничтожены в середине разработки - грош им цена. Именно про это было сказано в рамках вертикального среза. Если нет четкого понимания что именно делается, а лишь надежда на "да в процессе что-нибудь получится". Ну удачи, чо )))
Можете объяснить зачем создавать мины и инициализировать конфиги во время выполнения кода, если мины можно добавить на сцену заранее? В каких случаях или играх это используется? А если этих мин будет на карте штук 30? Нужно будет в бутстрапе 30 трансформов(точек спавна) создавать?
Кастовать сферу по всем коллайдерам с последующим поиском игрока по компонентам - это как раз такой же костыль как на триггер-стей ориентироваться. У нас есть только один игрок, так почему бы... не вычислить расстояние до него одной простой арифметической операцией, вместо того чтобы плодить гору мусора для гарбаджколлектора и производить кучу лишних вычислений, жрущих ресурсы впустую?! =Ъ Автор, конечно, молодец и в целом всё верно говорит. Но новичкам такие советы настолько же навредят, насколько и помогут. Всё же обучать с нуля забивать гвозди микроскопом - подход не очень...
А ещё спасибо за бесплатный материал. Чёт я не подумал, когда пару лет назад искал "Чистый кок", что окаааааазывается, его можно и бесплатно в пдф найти :) (Никогда такого не было и вот опять). Отдал 700 рублёв, бляха. Но главное, что читать книгу - было верное решение
6.09 вместо Physics.OverlapSphere предпочтительнее использовать Physics.OverlapSphereNonAlloc - для его работы не выделяется дополнительная память и, следовательно, не вызывается сборщик мусора. Что в целом положительно сказывается на производительности.
@@-it394 еще момент про оптимизацию, если у нас 1 сущность которая может активировать мину, то выгоднее иметь скрипт на сущности который ищет мины (1 проверка OverlapSphere) чем у каждой мины проверять N*OverlapSphere
@@-it394 Оптимизация "не так важна" только пока не начинаешь заниматься серьёзным проектом или не выходишь на платформу типа веба или мобайла. А потом выясняется, что привычка "делать вот так" уже выработалась, а на выходе - сплошные фризы из-за задыхающегося под тоннами лишнего мусора GC и куча машинного времени тратится на бессмысленные расчёты. =Ъ
Постараюсь, просто видео и так большими получаются, поэтому прям каждый момент разжевывать будет проблематично, но стараюсь выдерживать какой-то баланс)
14:40 А вообще вот такой даункаст и свитч кейсы - норм тема? У меня в проекте некоторые фабрики под капотом такую грязь тоже проворачивают. Прилетает абстракция, фабрика ее даункастит, и в зависимости от типа выдает какую-то из сущностей (тоже под абстракцией), но мне это показалось каким-то кривым временным решением, замену которого я пока не нашел. Разве что там, где я точно знаю, какой тип я засуну, я на дженерики перевел, но не везде в коде заранее знаешь, какой тип будешь использовать, а GetType() в дженерик не засунуть (только рефлексией, но это уже совсем костылище)
Здраствуйте Илья, после перехода версии движка с 2019 на 2021, у меня возникли проблемы с фпс на мобильных устройствах. Почему-то там по умолчанию 30 фпс. Какой лучший способ сделать нормальную оптимизацию? Достаточно ли просто в начале игры прописывать Application.targetFrameRate = 60;?
@andrei0_06 Сделал скрипт где прописано в старте Application.targetFrameRate = 60; Прикрепил этот скрипт на объект в меню, думаю это оптимальное решение
До сих пор не понимаю, как использовать конфиги. Да, звучит удобно и гибко, но мы ведь теряем визуальную настройки уровня. Я, допустим, хочу расставить мины именно в форме звёздочки, мне для этого специальный скрипт писать, который создаст конфиг именно с такими координатами мин?
@@zuzuBoba да, такой можно написать. Но получается что для каждой подобной мелочи придётся писать скрипт, который будет формировать конфиг. На уровне могут быть десятки различных объектов и самих уровней может быть много. Короче, на словах работа с конфигами звучит очень заморочно, как на практике - не знаю
@@zuzuBoba То есть сначала это все в редакторе юнити кто-то расставляет в виде звездочки. Потом специально написанный скрипт отправляет положение трансформов мин в скриптейбл обжект. Потом из него мы достаем назад в игру. И в чем особый смысл? Чем это лучше префаба уровня, например?
Если мин будет куча, то будет и куча коллайдеров т.к. мин много. А как мы знаем коллайдер в рантайме будет в апдейте физики обновляться каждый кадр и тянуть кучу инфы с проверками, что может повлиять на производительность (загрузка ЦП). Поэтому вариант с проверкой на вхождение как мне кажется не совсем оптимальный. Разве, что игра очень маленькая. Процесс Create и Destroy не такой дешевый, чтобы постоянно удалять и создавать объект. Например мины могут появляться через время. Лучше использовать пул объектов. Ну в самом конце органицая инфраструктуры скомкана т.е. лучше иерархию папок и файлов продумать изначально
@@vomiann6770 Допустим у нас 1000 мин и 10 игроков на сцене в зоне видимости и прогрузки. Получится что 1000 * 10 проверок = 10к проверок на кадр, а если игроков или сущностей будет больше 100? 1000? Под капотом Physic.OverlapSphere использует смежный подход определения триггерного входа. Да, для сложных форм (например, мешей) используются алгоритмы, такие как GJK и EPA, чтобы определить, пересекаются ли коллайдеры, но мы может представить сущность и мину в виде радиусов(сфер). Для проверки столкновений сфер используются оптимизированные алгоритмы, которые работают быстро и эффективно благодаря простоте геометрии сфер (ведь по сути это два радиуса в пространстве). Смежность подходов заключатся в том что есть Quadtree/Octree для 2д 3д и Sweep and Prune алгоритм, что сортирует по осям, уменьшает количество пар для проверки. Вдобавок еще BVH сверху если накинуть то вообще оптимизацией обмазываться можно ☠ А проверять N(n^2) любое устройство ляжет при увеличение кол-ва взаимодействующих сущностей ☠
@@vomiann6770 Если объектов, которые могут взорваться от мины на сцене много, то ей придется просчитать множество расстояний, прежде чем найти все, попавшие в радиус воздействия. А в физическом движке, и в физиксе для 3д и в бокс 2д это все оптимизировано, там не все подряд считается, а заранее отсеиваются объекты, находящиеся в секторах пространства, с которыми точно нет пересечений.
⚡⚡⚡ Полезные ссылки ⚡⚡⚡
🔎 yakovlevgamedev.ru/unity_adventure - обучение разработке игр с нуля до создания полноценного проекта
🔎 t.me/yakovlev_advanced_bot - бот для регистрации на вебинар (подарок тут же)
🔎 t.me/yakovlev_gamedev - тут небольшое бонусное видео (в комментарии с постом к этому видео)
Можно без телеграма записаться? могу на почту прислать свой номер телефона ;-)
@@DeadRabbitCanDance Можно на сайте оставить заявку, мессенджер не важен) Откроется запись 22 числа. Если есть какие-то дополнительные вопросы, то также на сайте (почти в самом верху) есть форма, где можно оставить свои контактные данные), либо можно напрямую написать на почту yakovlev.youtube@yandex.ru
Огромное спасибо, ты как всегда во время, сел за разработку коммерческого проекта, а в архитектуре немного плаваю. Продолжай записывать видосы с рассмотрением более сложных систем, ЛЮБЛЮ ОБАЖАЮ
Очень круто, познавательно и понятно. Жду следующие выпуски.
Спустя месяц пересмотрел, очень классно преподнёс тему. Спасибо тебе, буду ждать продолжение данной рубрики
Здравствуйте, Илья, меня конкретно поражает ваша работа над контентом
Именно такой контент по теме геймдева мы и заслуживаем! Спасибо вам большое!
И если не составит большого труда, то могли бы вы записать видео похожего формата по Entities и DOTS в целом? Видео на эти темы крайне не хватает на русском ютубе, особенно на момент новых версий движка.
Буду душевно благодарен за любую обратную связь!
В следующем году постараюсь на эту тему сделать контент))
очень нравятся темы, которые ты выбираешь последнее время, спасибо огромное❤
ждем вебинарчег
Вечная проблема в каком месте нужно остановится, что бы и не было сложно и было гибко.
Можно делать максимально просто, а добавлять сложность только когда она потребуется. Но мне самому сложно такого придерживаться.
Очень хорошее видео. Подобных каналов по программирования, чтоб так конкретно и понятно объясняли, еще не встречал
Спасибо большое, всегда испытываю проблемы с тем чтобы не думать часами о том как все правильно сделать, а уже взять и начат делать ))
Жиза
Смотрю тебя уже больше года, какое то время был подписан на бусти, всегда очень красивые, понятные, а главное полезные видосы, спасибо тебе!
Как обычно шикарный контент :D
Ждем еще подобного!
Столько видео за неделю! Класс! спасибо
Спасибо за это видео! Не останавливайся!
Прям то что нужно, спасибо
Наконец-то что-то в подобной тематике нашёл. Продолжай пилить подобные видосики, вот правда такого формата жуть как не хватает новичкам. Так держать !
Очень полезный контент! Ждём новых видосов, данная рубрика весьма интересна.
Спасибо тебе за то, что делишься опытом и знаниями. Это бесценно.
Видео супер, рубрика огонь!!! Спасибо за супер качественный контент!!
Формат супер! Ждем продолжения
Не останавливайтесь. Очень полезные и качественные видео. Речь грамотная, структура понятная. Тот контент, который мы не заслужили...но очень хотели. Рубрика - огонь. Но про асинхроны очень хочется дослушать тоже...)))
Привет друг! Хорошая рубрика, ее нужно продолжить 🔥
Видео прямо в тему, как-раз под мою задачу почти решение, как минимум определённо указание движения в нужном направлении ) вот уж точно благодарен!
внемлил каждому слову. Невероятно интересно и полезно, постоянно сталкиваюсь с описанными в ролике задачами
Супер кайф!!! Очень интересное видео! Многие вещи я, к сожалению, пока не знаю, так как не знаю языка на должном уровне, но базовую задачу я бы выполнил) продолжайте, пожалуйста!
Самая лучшая подача материала на ютубе. Грамотная речь. Нормативная лексика. Спасибо!!!
полезная рубрика, продолжай обязательно!
Очень нужный видос для начинающих. Спасибо!
good video. love it. please more. I am starting my game dev journey and these are the videos that i search for please release more.
Невероятно полезный видос, спасибо!
спасибо за такой качественный контент)
Хорошо преподносится материал.
Так держать🎉
Я всегда писал все в 1 скрипте😂. Тяжело теперь в все это воспринимать
Ты реально крут, давай ещё!
ну прям все по фактам раскидал)) мне вот очень понравился композиционный подход
Было бы хорошо посмотреть на addressables и подгрузка конфигов с сервера. Спасибо за видео!
О боги, блогер с нормально написаным кодом, аллилуя! =)
Спасибо за видос, позновательно о:
И в итоге каждый скрипт превращается в что-то, делающее что-то для чего-то... Главное при создании абстракций - узнать стоп-слово.
Флюгегенхаймен
Очень нравятся твои видео! Полезно, красиво, интересно и понятно. В этом ты упомянул про то, что иногда нужно сделать обучение... Обучение! Понятно, что все проекты разные, но было бы очень интересно узнать: может, есть какие-то общие правила/приёмы. Пока что механика обучения (только в начале или вообще по ходу игры) ощущается как один большой костыль
Идея крутая и очень полезная, было бы здорово если бы ты продолжил
Отличный контент. спасибо.
С примером мне не повезло, и до видео знал как делать
Спасибо за твои видео Илья! Рассмотришь тему для видео - лучшие практики переноса данных между сценами(желательно без DontDestroyOnLoad) и между сессиями(то есть SaveSystem - где какие данные лучше сохранять и как) (потому что я так понимаю что хорошими методами считается комбинирование PlayerPrefs и JSON с шифрованием)
Может рассказать о том как создается игра, в какой все последовательности делается и принимаются решения
Отличная рубрика!!
Разбор конкретных кэйсов всегда полезен. Заранее извиняюсь (я новичок в юнити), может что-то прослушал, по-моему не был рассмотрен вариант с обсёрвером. Или триггерколлайдер и есть обсёрвер? Если не ошибаюсь, может в следующих подобных видео рассматривать побольше вариантов реализации и их плюсов и минусов.
Я никогда не оставляю комментарии под видео, но этот ролике заставил.... Здесь прекрасно все
Ну я сначала так делаю, я сначала делаю, а потом думаю как это решение помогло мне прийти к решению задачи
Было бы конечно хорошо сделать единый базовый "стартер" или "прогреватель" для любого типа игры, так как эта логика не меняется.
топ контент
Сделай пожалуйста видео на тему асинхронность, только поглубже
чуваки, подскажите какие-нибудь уроки где объясняются все эти классы, конфиги скприптбл обджекты, а то я пока знаю что можно скрипт создать и на этом все
Толчок всегда нужен. А где толчок, там и землетрясение. Пожалуйста продолжай, Илья. Я ранее не видел хороших прогеров с интересной подачей (разве что Романа Сакутина, но у него мало свежего контента по юнити)
В теории звучит легко: "разбейте задачу на мелкие, начните с малого и по мере надобности рефакторите код", но когда дело доходит до реального проекта, где нужно построить автогенератор коридорных уровней с разными типами чанков под разные препятствия, и ещё нужно, чтобы генератор имел возможность работы как в play, так и в edit режиме, и чтобы весь трубочках и проводочках, и дыр дыр дыр под крышкой, тут конечно даа. Почему то сильно потею, постоянно модифицируя систему, не имея уже конечного, завершённого варианта, потому что появляется какая-то деталь, из-за которой приходится отойти от изначальной задумки разработки. Заранее хрен продумаешь такое, а строить постепенно утомляет из-за постоянных доработок и перестроек. Я надеюсь с опытом придёт власть над потоком разработки? Как научиться продумывать всё и искать верные решения сразу?
Если кратко, то никак:) Ты сейчас описал довольно неплохо размера проект, поэтому тут надо время, переработки и тп. Т.е. если не делал такого до, то сразу и не придумаешь.
Но тут очень сильно может помочь четко выписать требования необходимые и, как ни странно, из этих требований опять таки выделить шаги, и в процессе уже думать как это все связывать между собой и где узкие места (итеративно)
1) автогенератор коридорных уровней - сначала сделать концепт 1 коридорного уровня, разбить его на составляющую по визуалу, по механикам, открыть какое нибудь рабочее пространство типа Mirror и прописать всё, сделать раскадровку того как персонаж передвигается по нему и что его ждёт
2) разными типами чанков - сначала сделать чанк и сопутствующую ему логике (можно сразу и в 3д потом до 2д ограничить(линейность) чтобы был инструмент на будущее)
3) в play он и так работать будет другой момент в edit режиме - создаем папочку Editor и спокойненько реализуем в ней скрипт интерфейс взаимодействия с основным скриптом генерации
4) делаем трубочки и проводочки и дыр дыр дыр под крышкой
Начинать нужно с вертикального среза игры и финализирования концепции. Вот эти "постоянные доработки и перестройки" - это общая ошибка подхода и никакая "власть над потоком" тут не придёт. Нужно сразу понимать максимально полно какая именно стоит задача. Подход "поди туда, не знаю куда" работает, увы, лишь в сказках.
@@CronaxDervish А тут с другой стороны тебе стучит проблема того, что геймдизайн это не четкая заранее начерченная во всех подробностях магистраль. Его корректируют плейтесты, хорошие или провальные метрики, вообще феномен того, что сама разработка игры как уничтожает какие-то геймдизайнерские гипотезы, которые казались рабочими, так и наоборот подбрасывает новые, которые не были видны до начала разработки. Порой некоторые даже великие проекты вообще с ног на голову переворачиваются и становятся совершенно другими относительно того, чем они задумывались изначально. Не всегда финализированная концепция игры в принципе существует, она сама по себе может быть процессом, причем параллельным реализации и процессу проверки гипотез.
@@СветозарБоголюбов Если гипотезы уничтожены в середине разработки - грош им цена. Именно про это было сказано в рамках вертикального среза. Если нет четкого понимания что именно делается, а лишь надежда на "да в процессе что-нибудь получится". Ну удачи, чо )))
Можете объяснить зачем создавать мины и инициализировать конфиги во время выполнения кода, если мины можно добавить на сцену заранее? В каких случаях или играх это используется? А если этих мин будет на карте штук 30? Нужно будет в бутстрапе 30 трансформов(точек спавна) создавать?
Кастовать сферу по всем коллайдерам с последующим поиском игрока по компонентам - это как раз такой же костыль как на триггер-стей ориентироваться. У нас есть только один игрок, так почему бы... не вычислить расстояние до него одной простой арифметической операцией, вместо того чтобы плодить гору мусора для гарбаджколлектора и производить кучу лишних вычислений, жрущих ресурсы впустую?! =Ъ
Автор, конечно, молодец и в целом всё верно говорит. Но новичкам такие советы настолько же навредят, насколько и помогут. Всё же обучать с нуля забивать гвозди микроскопом - подход не очень...
А ещё спасибо за бесплатный материал. Чёт я не подумал, когда пару лет назад искал "Чистый кок", что окаааааазывается, его можно и бесплатно в пдф найти :) (Никогда такого не было и вот опять). Отдал 700 рублёв, бляха. Но главное, что читать книгу - было верное решение
6.09 вместо Physics.OverlapSphere предпочтительнее использовать Physics.OverlapSphereNonAlloc - для его работы не выделяется дополнительная память и, следовательно, не вызывается сборщик мусора. Что в целом положительно сказывается на производительности.
да, все верно) Но это уже вопрос оптимизации. В рамках видео не так важно
@@-it394 еще момент про оптимизацию, если у нас 1 сущность которая может активировать мину, то выгоднее иметь скрипт на сущности который ищет мины (1 проверка OverlapSphere) чем у каждой мины проверять N*OverlapSphere
@@-it394 Оптимизация "не так важна" только пока не начинаешь заниматься серьёзным проектом или не выходишь на платформу типа веба или мобайла. А потом выясняется, что привычка "делать вот так" уже выработалась, а на выходе - сплошные фризы из-за задыхающегося под тоннами лишнего мусора GC и куча машинного времени тратится на бессмысленные расчёты. =Ъ
Продолжай рубрику только одна просьба пожалуйста можешь обяснять код не много детальней для новичков
Постараюсь, просто видео и так большими получаются, поэтому прям каждый момент разжевывать будет проблематично, но стараюсь выдерживать какой-то баланс)
Я так понял, названия паттернов специально не упоминаются (например Эффект->Стратегия). Можно узнать причину?
Третий ролик за неделю? Кудааа
14:40 А вообще вот такой даункаст и свитч кейсы - норм тема? У меня в проекте некоторые фабрики под капотом такую грязь тоже проворачивают. Прилетает абстракция, фабрика ее даункастит, и в зависимости от типа выдает какую-то из сущностей (тоже под абстракцией), но мне это показалось каким-то кривым временным решением, замену которого я пока не нашел. Разве что там, где я точно знаю, какой тип я засуну, я на дженерики перевел, но не везде в коде заранее знаешь, какой тип будешь использовать, а GetType() в дженерик не засунуть (только рефлексией, но это уже совсем костылище)
формат нужен
10/10
Здраствуйте Илья, после перехода версии движка с 2019 на 2021, у меня возникли проблемы с фпс на мобильных устройствах. Почему-то там по умолчанию 30 фпс. Какой лучший способ сделать нормальную оптимизацию? Достаточно ли просто в начале игры прописывать Application.targetFrameRate = 60;?
Здравствуйте, смогли решить вопрос?
@andrei0_06 Сделал скрипт где прописано в старте Application.targetFrameRate = 60;
Прикрепил этот скрипт на объект в меню, думаю это оптимальное решение
До сих пор не понимаю, как использовать конфиги. Да, звучит удобно и гибко, но мы ведь теряем визуальную настройки уровня. Я, допустим, хочу расставить мины именно в форме звёздочки, мне для этого специальный скрипт писать, который создаст конфиг именно с такими координатами мин?
а что мешает написать обратный скрипт? Который берет кластер звездочек с уровня и заносит их координаты в конфиг
@@zuzuBoba да, такой можно написать. Но получается что для каждой подобной мелочи придётся писать скрипт, который будет формировать конфиг. На уровне могут быть десятки различных объектов и самих уровней может быть много. Короче, на словах работа с конфигами звучит очень заморочно, как на практике - не знаю
@@boost_456 так напиши абстракцию для мелочей :)
@@zuzuBoba То есть сначала это все в редакторе юнити кто-то расставляет в виде звездочки. Потом специально написанный скрипт отправляет положение трансформов мин в скриптейбл обжект. Потом из него мы достаем назад в игру. И в чем особый смысл? Чем это лучше префаба уровня, например?
Бьюсь об заклад, что таску завернут. Коробка не должна тригерить бомбу, но вполне имеет право получать урон! ☺
Как раз в бонусном видео в телеграмме про это говорю:) Сейчас немного не хорошо, что IDamageable тригерит бомбу)
Если мин будет куча, то будет и куча коллайдеров т.к. мин много. А как мы знаем коллайдер в рантайме будет в апдейте физики обновляться каждый кадр и тянуть кучу инфы с проверками, что может повлиять на производительность (загрузка ЦП). Поэтому вариант с проверкой на вхождение как мне кажется не совсем оптимальный. Разве, что игра очень маленькая. Процесс Create и Destroy не такой дешевый, чтобы постоянно удалять и создавать объект. Например мины могут появляться через время. Лучше использовать пул объектов. Ну в самом конце органицая инфраструктуры скомкана т.е. лучше иерархию папок и файлов продумать изначально
Как ты тогда проверишь, что игрок вошёл/вышел из зоны действия мины без каллайдеров? На счёт пула согласен.
@vockinmine3921 Считать по расстоянию отдельной сущностью, которая ивент посылает
@@vomiann6770 Допустим у нас 1000 мин и 10 игроков на сцене в зоне видимости и прогрузки. Получится что 1000 * 10 проверок = 10к проверок на кадр, а если игроков или сущностей будет больше 100? 1000? Под капотом Physic.OverlapSphere использует смежный подход определения триггерного входа. Да, для сложных форм (например, мешей) используются алгоритмы, такие как GJK и EPA, чтобы определить, пересекаются ли коллайдеры, но мы может представить сущность и мину в виде радиусов(сфер). Для проверки столкновений сфер используются оптимизированные алгоритмы, которые работают быстро и эффективно благодаря простоте геометрии сфер (ведь по сути это два радиуса в пространстве). Смежность подходов заключатся в том что есть Quadtree/Octree для 2д 3д и Sweep and Prune алгоритм, что сортирует по осям, уменьшает количество пар для проверки. Вдобавок еще BVH сверху если накинуть то вообще оптимизацией обмазываться можно ☠ А проверять N(n^2) любое устройство ляжет при увеличение кол-ва взаимодействующих сущностей ☠
@@vomiann6770 Если объектов, которые могут взорваться от мины на сцене много, то ей придется просчитать множество расстояний, прежде чем найти все, попавшие в радиус воздействия. А в физическом движке, и в физиксе для 3д и в бокс 2д это все оптимизировано, там не все подряд считается, а заранее отсеиваются объекты, находящиеся в секторах пространства, с которыми точно нет пересечений.
Где ассинхронка...🥲
Следующий видос в очереди)))
@-it394 уря
да хоспаде, когда ж вы уже перестанете всюду пихать эти корутины и перейдёте на нормальный Awaitable
yagni
зачем так сложно?
это же делается элементарно
Например как?
Было бы конечно хорошо сделать единый базовый "стартер" или "прогреватель" для любого типа игры, так как эта логика не меняется.