⚡⚡⚡ Полезные ссылки ⚡⚡⚡ 🔎 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 с шифрованием)
Очень нравятся твои видео! Полезно, красиво, интересно и понятно. В этом ты упомянул про то, что иногда нужно сделать обучение... Обучение! Понятно, что все проекты разные, но было бы очень интересно узнать: может, есть какие-то общие правила/приёмы. Пока что механика обучения (только в начале или вообще по ходу игры) ощущается как один большой костыль
Кастовать сферу по всем коллайдерам с последующим поиском игрока по компонентам - это как раз такой же костыль как на триггер-стей ориентироваться. У нас есть только один игрок, так почему бы... не вычислить расстояние до него одной простой арифметической операцией, вместо того чтобы плодить гору мусора для гарбаджколлектора и производить кучу лишних вычислений, жрущих ресурсы впустую?! =Ъ Автор, конечно, молодец и в целом всё верно говорит. Но новичкам такие советы настолько же навредят, насколько и помогут. Всё же обучать с нуля забивать гвозди микроскопом - подход не очень...
14:40 А вообще вот такой даункаст и свитч кейсы - норм тема? У меня в проекте некоторые фабрики под капотом такую грязь тоже проворачивают. Прилетает абстракция, фабрика ее даункастит, и в зависимости от типа выдает какую-то из сущностей (тоже под абстракцией), но мне это показалось каким-то кривым временным решением, замену которого я пока не нашел. Разве что там, где я точно знаю, какой тип я засуну, я на дженерики перевел, но не везде в коде заранее знаешь, какой тип будешь использовать, а GetType() в дженерик не засунуть (только рефлексией, но это уже совсем костылище)
А ещё спасибо за бесплатный материал. Чёт я не подумал, когда пару лет назад искал "Чистый кок", что окаааааазывается, его можно и бесплатно в пдф найти :) (Никогда такого не было и вот опять). Отдал 700 рублёв, бляха. Но главное, что читать книгу - было верное решение
Толчок всегда нужен. А где толчок, там и землетрясение. Пожалуйста продолжай, Илья. Я ранее не видел хороших прогеров с интересной подачей (разве что Романа Сакутина, но у него мало свежего контента по юнити)
6.09 вместо Physics.OverlapSphere предпочтительнее использовать Physics.OverlapSphereNonAlloc - для его работы не выделяется дополнительная память и, следовательно, не вызывается сборщик мусора. Что в целом положительно сказывается на производительности.
@@-it394 еще момент про оптимизацию, если у нас 1 сущность которая может активировать мину, то выгоднее иметь скрипт на сущности который ищет мины (1 проверка OverlapSphere) чем у каждой мины проверять N*OverlapSphere
@@-it394 Оптимизация "не так важна" только пока не начинаешь заниматься серьёзным проектом или не выходишь на платформу типа веба или мобайла. А потом выясняется, что привычка "делать вот так" уже выработалась, а на выходе - сплошные фризы из-за задыхающегося под тоннами лишнего мусора GC и куча машинного времени тратится на бессмысленные расчёты. =Ъ
В теории звучит легко: "разбейте задачу на мелкие, начните с малого и по мере надобности рефакторите код", но когда дело доходит до реального проекта, где нужно построить автогенератор коридорных уровней с разными типами чанков под разные препятствия, и ещё нужно, чтобы генератор имел возможность работы как в play, так и в edit режиме, и чтобы весь трубочках и проводочках, и дыр дыр дыр под крышкой, тут конечно даа. Почему то сильно потею, постоянно модифицируя систему, не имея уже конечного, завершённого варианта, потому что появляется какая-то деталь, из-за которой приходится отойти от изначальной задумки разработки. Заранее хрен продумаешь такое, а строить постепенно утомляет из-за постоянных доработок и перестроек. Я надеюсь с опытом придёт власть над потоком разработки? Как научиться продумывать всё и искать верные решения сразу?
Если кратко, то никак:) Ты сейчас описал довольно неплохо размера проект, поэтому тут надо время, переработки и тп. Т.е. если не делал такого до, то сразу и не придумаешь. Но тут очень сильно может помочь четко выписать требования необходимые и, как ни странно, из этих требований опять таки выделить шаги, и в процессе уже думать как это все связывать между собой и где узкие места (итеративно)
1) автогенератор коридорных уровней - сначала сделать концепт 1 коридорного уровня, разбить его на составляющую по визуалу, по механикам, открыть какое нибудь рабочее пространство типа Mirror и прописать всё, сделать раскадровку того как персонаж передвигается по нему и что его ждёт 2) разными типами чанков - сначала сделать чанк и сопутствующую ему логике (можно сразу и в 3д потом до 2д ограничить(линейность) чтобы был инструмент на будущее) 3) в play он и так работать будет другой момент в edit режиме - создаем папочку Editor и спокойненько реализуем в ней скрипт интерфейс взаимодействия с основным скриптом генерации 4) делаем трубочки и проводочки и дыр дыр дыр под крышкой
Начинать нужно с вертикального среза игры и финализирования концепции. Вот эти "постоянные доработки и перестройки" - это общая ошибка подхода и никакая "власть над потоком" тут не придёт. Нужно сразу понимать максимально полно какая именно стоит задача. Подход "поди туда, не знаю куда" работает, увы, лишь в сказках.
Постараюсь, просто видео и так большими получаются, поэтому прям каждый момент разжевывать будет проблематично, но стараюсь выдерживать какой-то баланс)
До сих пор не понимаю, как использовать конфиги. Да, звучит удобно и гибко, но мы ведь теряем визуальную настройки уровня. Я, допустим, хочу расставить мины именно в форме звёздочки, мне для этого специальный скрипт писать, который создаст конфиг именно с такими координатами мин?
@@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) любое устройство ляжет при увеличение кол-ва взаимодействующих сущностей ☠
⚡⚡⚡ Полезные ссылки ⚡⚡⚡
🔎 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 с шифрованием)
Может рассказать о том как создается игра, в какой все последовательности делается и принимаются решения
Хорошо преподносится материал.
Так держать🎉
Очень нравятся твои видео! Полезно, красиво, интересно и понятно. В этом ты упомянул про то, что иногда нужно сделать обучение... Обучение! Понятно, что все проекты разные, но было бы очень интересно узнать: может, есть какие-то общие правила/приёмы. Пока что механика обучения (только в начале или вообще по ходу игры) ощущается как один большой костыль
Ты реально крут, давай ещё!
Отличная рубрика!!
Сделай пожалуйста видео на тему асинхронность, только поглубже
Ну я сначала так делаю, я сначала делаю, а потом думаю как это решение помогло мне прийти к решению задачи
Было бы конечно хорошо сделать единый базовый "стартер" или "прогреватель" для любого типа игры, так как эта логика не меняется.
Кастовать сферу по всем коллайдерам с последующим поиском игрока по компонентам - это как раз такой же костыль как на триггер-стей ориентироваться. У нас есть только один игрок, так почему бы... не вычислить расстояние до него одной простой арифметической операцией, вместо того чтобы плодить гору мусора для гарбаджколлектора и производить кучу лишних вычислений, жрущих ресурсы впустую?! =Ъ
Автор, конечно, молодец и в целом всё верно говорит. Но новичкам такие советы настолько же навредят, насколько и помогут. Всё же обучать с нуля забивать гвозди микроскопом - подход не очень...
14:40 А вообще вот такой даункаст и свитч кейсы - норм тема? У меня в проекте некоторые фабрики под капотом такую грязь тоже проворачивают. Прилетает абстракция, фабрика ее даункастит, и в зависимости от типа выдает какую-то из сущностей (тоже под абстракцией), но мне это показалось каким-то кривым временным решением, замену которого я пока не нашел. Разве что там, где я точно знаю, какой тип я засуну, я на дженерики перевел, но не везде в коде заранее знаешь, какой тип будешь использовать, а GetType() в дженерик не засунуть (только рефлексией, но это уже совсем костылище)
А ещё спасибо за бесплатный материал. Чёт я не подумал, когда пару лет назад искал "Чистый кок", что окаааааазывается, его можно и бесплатно в пдф найти :) (Никогда такого не было и вот опять). Отдал 700 рублёв, бляха. Но главное, что читать книгу - было верное решение
Толчок всегда нужен. А где толчок, там и землетрясение. Пожалуйста продолжай, Илья. Я ранее не видел хороших прогеров с интересной подачей (разве что Романа Сакутина, но у него мало свежего контента по юнити)
6.09 вместо Physics.OverlapSphere предпочтительнее использовать Physics.OverlapSphereNonAlloc - для его работы не выделяется дополнительная память и, следовательно, не вызывается сборщик мусора. Что в целом положительно сказывается на производительности.
да, все верно) Но это уже вопрос оптимизации. В рамках видео не так важно
@@-it394 еще момент про оптимизацию, если у нас 1 сущность которая может активировать мину, то выгоднее иметь скрипт на сущности который ищет мины (1 проверка OverlapSphere) чем у каждой мины проверять N*OverlapSphere
@@-it394 Оптимизация "не так важна" только пока не начинаешь заниматься серьёзным проектом или не выходишь на платформу типа веба или мобайла. А потом выясняется, что привычка "делать вот так" уже выработалась, а на выходе - сплошные фризы из-за задыхающегося под тоннами лишнего мусора GC и куча машинного времени тратится на бессмысленные расчёты. =Ъ
В теории звучит легко: "разбейте задачу на мелкие, начните с малого и по мере надобности рефакторите код", но когда дело доходит до реального проекта, где нужно построить автогенератор коридорных уровней с разными типами чанков под разные препятствия, и ещё нужно, чтобы генератор имел возможность работы как в play, так и в edit режиме, и чтобы весь трубочках и проводочках, и дыр дыр дыр под крышкой, тут конечно даа. Почему то сильно потею, постоянно модифицируя систему, не имея уже конечного, завершённого варианта, потому что появляется какая-то деталь, из-за которой приходится отойти от изначальной задумки разработки. Заранее хрен продумаешь такое, а строить постепенно утомляет из-за постоянных доработок и перестроек. Я надеюсь с опытом придёт власть над потоком разработки? Как научиться продумывать всё и искать верные решения сразу?
Если кратко, то никак:) Ты сейчас описал довольно неплохо размера проект, поэтому тут надо время, переработки и тп. Т.е. если не делал такого до, то сразу и не придумаешь.
Но тут очень сильно может помочь четко выписать требования необходимые и, как ни странно, из этих требований опять таки выделить шаги, и в процессе уже думать как это все связывать между собой и где узкие места (итеративно)
1) автогенератор коридорных уровней - сначала сделать концепт 1 коридорного уровня, разбить его на составляющую по визуалу, по механикам, открыть какое нибудь рабочее пространство типа Mirror и прописать всё, сделать раскадровку того как персонаж передвигается по нему и что его ждёт
2) разными типами чанков - сначала сделать чанк и сопутствующую ему логике (можно сразу и в 3д потом до 2д ограничить(линейность) чтобы был инструмент на будущее)
3) в play он и так работать будет другой момент в edit режиме - создаем папочку Editor и спокойненько реализуем в ней скрипт интерфейс взаимодействия с основным скриптом генерации
4) делаем трубочки и проводочки и дыр дыр дыр под крышкой
Начинать нужно с вертикального среза игры и финализирования концепции. Вот эти "постоянные доработки и перестройки" - это общая ошибка подхода и никакая "власть над потоком" тут не придёт. Нужно сразу понимать максимально полно какая именно стоит задача. Подход "поди туда, не знаю куда" работает, увы, лишь в сказках.
формат нужен
Третий ролик за неделю? Кудааа
Продолжай рубрику только одна просьба пожалуйста можешь обяснять код не много детальней для новичков
Постараюсь, просто видео и так большими получаются, поэтому прям каждый момент разжевывать будет проблематично, но стараюсь выдерживать какой-то баланс)
До сих пор не понимаю, как использовать конфиги. Да, звучит удобно и гибко, но мы ведь теряем визуальную настройки уровня. Я, допустим, хочу расставить мины именно в форме звёздочки, мне для этого специальный скрипт писать, который создаст конфиг именно с такими координатами мин?
а что мешает написать обратный скрипт? Который берет кластер звездочек с уровня и заносит их координаты в конфиг
@@zuzuBoba да, такой можно написать. Но получается что для каждой подобной мелочи придётся писать скрипт, который будет формировать конфиг. На уровне могут быть десятки различных объектов и самих уровней может быть много. Короче, на словах работа с конфигами звучит очень заморочно, как на практике - не знаю
@@boost_456 так напиши абстракцию для мелочей :)
Где ассинхронка...🥲
Следующий видос в очереди)))
@-it394 уря
да хоспаде, когда ж вы уже перестанете всюду пихать эти корутины и перейдёте на нормальный Awaitable
Если мин будет куча, то будет и куча коллайдеров т.к. мин много. А как мы знаем коллайдер в рантайме будет в апдейте физики обновляться каждый кадр и тянуть кучу инфы с проверками, что может повлиять на производительность (загрузка ЦП). Поэтому вариант с проверкой на вхождение как мне кажется не совсем оптимальный. Разве, что игра очень маленькая. Процесс 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) любое устройство ляжет при увеличение кол-ва взаимодействующих сущностей ☠
Бьюсь об заклад, что таску завернут. Коробка не должна тригерить бомбу, но вполне имеет право получать урон! ☺
Как раз в бонусном видео в телеграмме про это говорю:) Сейчас немного не хорошо, что IDamageable тригерит бомбу)
10/10
зачем так сложно?
это же делается элементарно
Было бы конечно хорошо сделать единый базовый "стартер" или "прогреватель" для любого типа игры, так как эта логика не меняется.