7:00 вот по хорошему бы с конца элементы дестроить. Дестрой в конце кадра по логике срабатывать должен, так что возможно нормально отработает, но выглядит страшно, очень страшно
Супер! Спасибо большое! Еще бы понять как Di юзать. Ок, мы в точке входа все засетапили, но я так понимаю, к контейнеру нужен глобальный доступ. Через singleton? Чувствую это как то красивее можно сделать....
У тебя наверное есть какой-то план на темы будущих видео. Но если их не много, или просто нужны идеи, дай знать, накидаю тебе список, который может кому-то показаться интересным или полезным!) Сейчас джуню на большом игровом проекте и часто сталкиваюсь с задачами, которые не всегда даже понимаю, как лучше решить.)
Привет, теперь стало намного понятней как взаимодействовать между меню и геймплей сценой. Есть вопрос как переключать несколько геймплей сцен. Я планирую делать игру с несколькими локациями, в которых геймплей будет идентичен, а переключение между локациями происходит не из меню, а с помощью вызова канваса на кнопку ESC и выбора локации из списка. В даном случае переключение геймплей локации будет на стороне скрипта канваса который хендлит все ето? Или можно как то прикрутить все в глобальний SceneManagement?
Да, это не совсем ошибка. Дело в том, что работать будет корректно, т.к. после проверки на сцену меню больше нет загрузок и в следующей проверке на пустую сцену метод завершится. То есть фактически ничего не сломается, но код пройдёт чутка больше проверок
При виде "грязного вонючего кода" глаза не закрывал, потому что у меня чистовые варианты ничуть не лучше 🤣 Вот прямо вот так и делаю: вешаю на кнопку скрипт с Action'ом, ОченьВажныйCoreОбъект подписывается на этот Action и по нажатию кнопки запускает ОченьВажныеCoreМетоды 🤣 Даже не представляю, как это должно реализовываться по-нормальному. Пока до конца не вкурил, почему UI делается НАСТОЛЬКО отдельно от содержимого сцены (ну, DontDestroyOnLoad с "глобальным" загрузчиком UI-ев и прочее).
Смотри: 1. UI должен быть независимым от сцены, потому что есть загрузочный экран, который должен закрывать как там за ним сцены меняются, объекты создаются, инициализируются и т.д. Это факт, тут просто по-другому не закроешь это дело. Конечно, если мы не говорим о ситуациях БЕЗ всяких закрытий, где на создании объектов в рантайме происходят фризы. 2. Каждая сцена содержит свой список префабов окошек. Если их поместить сразу в один список, то они загрузятся в оперативную память все сразу. То есть все ссылки, которые ты кидаешь в редакторе на префабы, они загрузят эти префабы в память сразу. Больше префабов - больше использования памяти. Поэтому разделив все окошки на списки, мы оптимизируем количество используемой памяти.
Я немного преувеличиваю их фу, экшны имеют право жить, это вкусовщина больше. Реактивный подход гораздо гибче, поэтому он мне нравится больше, однако, в нем нужно хорошо разобраться, прежде чем использовать
Долго не мог понять о чем речь, но все таки понял) Нет, это не причина. Canvas (Environment) - это подсказка, что префаб работает в окружении Canvas, а не World, то есть координаты работают по-другому. Смотри внимательней, где-то что-то пропустил)
Смотря чего ты от жизни ожидаешь. Когда понимаешь, как создавать архитектуру - то решаешь кучу проблем с отказоустойчивостью и багами. Плюс открывается бесконечное пространство для переплетения различных механик без риска оказаться в заднице с нерабочей лапшой вместо кода. То есть, если цель делать небольшие сингловые игры - то архитектурой можно не заморачиваться. Если цель - большие и сложные игры, то тут придётся позаботиться о коде
Вообще еще Иисус в Нагорной проповеди намекал на то, что дом нужно строить на каменном фундаменте, а не на песочке... Хотя да, на закладку фундамента, конечно, требуется время.
@@igor_mutny у меня достаточно опыта. Я соглашусь что разработчику нужно пойти через solid, ioc контецнеры. Обмазать всё интерфейсами. Проникнуться TDD. Я скорее сомневаюсь что этому можно научиться не набивая шишки. Сложно объяснить зачем нужна инверсия управления на примере. Это будет выглядеть как ненужное переусложнение.
На этой неделе скорее всего будет выпуск по реактивщине на базе R3, она нужна будет в проекте, так что вот. Я тут болел, так что совсем не мог что-то делать
Об этом я пояснял в предыдущем видео, это лучшая практика, если хочешь избежать проблем создания новых объектов, пока старые ещё не удалились (в юнити новая сцена стартует раньше, чем старая уничтожается)
@@DarkIllusoire некоторые платформы требуют переходы между сцен делать через пустую сцену (например, нинтендо), вероятно у них там свои "нюансики". Переход через пустую сцену не обеспечивает исключение асинхронной выгрузки, но делает этот процесс понятнее и менее рискованным
@@gamedevlavka а можно еще примеры платформ, где это требуется, кроме нинтендо? Можно так же пример обсуждения этой проблемы на нинтендо, очень интересно почитать решение данной рпоблемы?
Ждал продолжения и вот оно вышло ❤. Хочу сказать спасибо за такой обучающий конент.
Спасибо за SceneManagment! И спасибо что читаешь комментарии! Очень ценный канал.
7:00 вот по хорошему бы с конца элементы дестроить. Дестрой в конце кадра по логике срабатывать должен, так что возможно нормально отработает, но выглядит страшно, очень страшно
@@MagicProG да, именно потому что вконце кадра дестрой сработает, поэтому ничего не сломается. Это записано осознавая, как работает дестрой
Великолепно! Большое спасибо, что сделали!👍
🔥🔥🔥!
Большое спасибо, и жду продолжения!
Лучше любого курса за 50 000 руб и всяких "летних лагерей" имени краснознаменного Сакутина
Еще было интересно про хорошую систему DataPersistence между сценами
Ждём видосы почаще ;)
Супер, спасибо!
Супер! Спасибо большое! Еще бы понять как Di юзать. Ок, мы в точке входа все засетапили, но я так понимаю, к контейнеру нужен глобальный доступ. Через singleton? Чувствую это как то красивее можно сделать....
@@MrGolovewkin все будет, нужно подождать) двумя словами понятно не описать)
А они все ложат и ложат!)
У тебя наверное есть какой-то план на темы будущих видео. Но если их не много, или просто нужны идеи, дай знать, накидаю тебе список, который может кому-то показаться интересным или полезным!) Сейчас джуню на большом игровом проекте и часто сталкиваюсь с задачами, которые не всегда даже понимаю, как лучше решить.)
План более менее есть, но ты накидывай, вдруг чего упускаю)
Класс, спасибо за видео! А есть какое-то расписание выхода? Курс смотреть и игру делать хочется, а ролики непонятно когда выходят
@@Vorono4ka пока конкретно по проекту видео выходят раз в 1-2 недели, чаще у меня просто физически не получается
Привет, теперь стало намного понятней как взаимодействовать между меню и геймплей сценой. Есть вопрос как переключать несколько геймплей сцен. Я планирую делать игру с несколькими локациями, в которых геймплей будет идентичен, а переключение между локациями происходит не из меню, а с помощью вызова канваса на кнопку ESC и выбора локации из списка. В даном случае переключение геймплей локации будет на стороне скрипта канваса который хендлит все ето? Или можно как то прикрутить все в глобальний SceneManagement?
Конечно итоговый сигнал должен уходить в менеджер сцены. Не важно из каких глубин он идёт, конечная точка должна быть одна
еще вопрос: в методе RunGame(), в проверке на имя сцены главного меню, есть смысл от return? просто в видео ты его не написал, а у меня он написан :D
Да, это не совсем ошибка. Дело в том, что работать будет корректно, т.к. после проверки на сцену меню больше нет загрузок и в следующей проверке на пустую сцену метод завершится. То есть фактически ничего не сломается, но код пройдёт чутка больше проверок
При виде "грязного вонючего кода" глаза не закрывал, потому что у меня чистовые варианты ничуть не лучше 🤣 Вот прямо вот так и делаю: вешаю на кнопку скрипт с Action'ом, ОченьВажныйCoreОбъект подписывается на этот Action и по нажатию кнопки запускает ОченьВажныеCoreМетоды 🤣 Даже не представляю, как это должно реализовываться по-нормальному.
Пока до конца не вкурил, почему UI делается НАСТОЛЬКО отдельно от содержимого сцены (ну, DontDestroyOnLoad с "глобальным" загрузчиком UI-ев и прочее).
Смотри:
1. UI должен быть независимым от сцены, потому что есть загрузочный экран, который должен закрывать как там за ним сцены меняются, объекты создаются, инициализируются и т.д. Это факт, тут просто по-другому не закроешь это дело. Конечно, если мы не говорим о ситуациях БЕЗ всяких закрытий, где на создании объектов в рантайме происходят фризы.
2. Каждая сцена содержит свой список префабов окошек. Если их поместить сразу в один список, то они загрузятся в оперативную память все сразу. То есть все ссылки, которые ты кидаешь в редакторе на префабы, они загрузят эти префабы в память сразу. Больше префабов - больше использования памяти. Поэтому разделив все окошки на списки, мы оптимизируем количество используемой памяти.
@@gamedevlavka теперь понял, спасибо 👍
@@gamedevlavka подписался на Boosty 👍
Пасибо❤️
Почему такая нелюбовь к экшинам? Так ли реактивный подход лучше?
Я немного преувеличиваю их фу, экшны имеют право жить, это вкусовщина больше. Реактивный подход гораздо гибче, поэтому он мне нравится больше, однако, в нем нужно хорошо разобраться, прежде чем использовать
прости, что за Canvas (Environment) в префабах UI? Видимо у меня из за его отсутствия неправильно аттачатся префабы UI к основному UIRoot
Скажи временную метку, а то я что-то не понимаю вопроса
@@gamedevlavka 7:52, в префабах самый первый объект Canvas (Environment)
Долго не мог понять о чем речь, но все таки понял)
Нет, это не причина. Canvas (Environment) - это подсказка, что префаб работает в окружении Canvas, а не World, то есть координаты работают по-другому. Смотри внимательней, где-то что-то пропустил)
@@gamedevlavka всё, разобрался. спасибо
Это такая ловушка. Месяц придумываешь архитектуру вместо того что бы писать игру.
Смотря чего ты от жизни ожидаешь. Когда понимаешь, как создавать архитектуру - то решаешь кучу проблем с отказоустойчивостью и багами. Плюс открывается бесконечное пространство для переплетения различных механик без риска оказаться в заднице с нерабочей лапшой вместо кода. То есть, если цель делать небольшие сингловые игры - то архитектурой можно не заморачиваться. Если цель - большие и сложные игры, то тут придётся позаботиться о коде
Вообще еще Иисус в Нагорной проповеди намекал на то, что дом нужно строить на каменном фундаменте, а не на песочке... Хотя да, на закладку фундамента, конечно, требуется время.
@@igor_mutny у меня достаточно опыта. Я соглашусь что разработчику нужно пойти через solid, ioc контецнеры. Обмазать всё интерфейсами. Проникнуться TDD.
Я скорее сомневаюсь что этому можно научиться не набивая шишки. Сложно объяснить зачем нужна инверсия управления на примере. Это будет выглядеть как ненужное переусложнение.
Привет, а когда уже будет новая серия?
На этой неделе скорее всего будет выпуск по реактивщине на базе R3, она нужна будет в проекте, так что вот. Я тут болел, так что совсем не мог что-то делать
А ничего что про загрузке между сценами мы каждый раз переходим в бут сцену? Или в дальнейшем этого перехода не будет?
Об этом я пояснял в предыдущем видео, это лучшая практика, если хочешь избежать проблем создания новых объектов, пока старые ещё не удалились (в юнити новая сцена стартует раньше, чем старая уничтожается)
Это костыль с верой в чистое будущее, чтобы не делать асинхронную выгрузку сцены
@@DarkIllusoire некоторые платформы требуют переходы между сцен делать через пустую сцену (например, нинтендо), вероятно у них там свои "нюансики".
Переход через пустую сцену не обеспечивает исключение асинхронной выгрузки, но делает этот процесс понятнее и менее рискованным
@@gamedevlavka а можно еще примеры платформ, где это требуется, кроме нинтендо? Можно так же пример обсуждения этой проблемы на нинтендо, очень интересно почитать решение данной рпоблемы?
В пк играх все также работает?
@@issatay8876 на любой платформе. Вообще этот проект нацелен на мультиплатформенность, так что можно не бояться на этот счет
@@gamedevlavka спасибо за ответ. Просто я хочу сделать презентабельный рогалик, а такую систему с ui roots вижу впервые