Точка входа и менеджмент сцен в Unity. Проект
Vložit
- čas přidán 17. 07. 2024
- Поддержать проект можно по ссылкам:
www.donationalerts.com/r/game...
boosty.to/gamedevlavka
paypal.me/gamedevlavka
Вступаем в игру! В прямом смысле! Вход в игру подразумевает под собой некий алгоритм действий, при этом игрок не видит большую часть этих действий! Нужно показать экран загрузки, создать всякие "самые важные" переменные и объекты, загрузить сцену какую нужно, а ведь нужно еще и определить, какая сцена-то нужна! А если у нас много сцен? А если сцена одна, а уровней много? Каждый раз мы должны инициализировать одну и ту же сцену по разному! Так что в этом видео начинается процесс входа в первую сцену игры. В нашем случае в единственную, но если очень нужно - мы добавим еще :)
Описание игры в телеграм-канале Лавки Разработчика:
t.me/c/1748704478/7458
Проект на GitHub:
github.com/vavilichev/mBuilding
Отсылки:
t.me/gamedevlavka - телеграм канал Лавки Разработчика
t.me/gamedevtavern - ламповый чат
/ discord - дискорд
__________
0:00 Вступление-анонс
1:01 Инициализируем игру через аттрибут RuntimeInitializeOnLoad
3:01 Применение системных настроек
3:51 Конструктор и что в нем будет, например держатель корутин
6:30 И рутовый UI объект тоже создается в конструкторе
9:05 Сетапим префаб UIRoot
12:02 Сетапим сцены Boot и Gameplay
13:18 Чуток про новые Build Profiles в Unity 6
14:26 Занимаемся непотребством, чтобы сделать жизнь чуток стабильнее
15:00 Пишем хак, чтобы сцены не из проекта не ломались в редакторе
17:08 Пишем загрузку геймплейной сцены
19:37 Вход в сцену с точки зрения логики
22:38 Последние сетапы перед проверкой
22:57 Фейловая проверка и фикс
23:15 Финальная проверка и заключение
Обязательно надо добавить еще сцену и организовать переход между ними!! Обязательно! =)
Плюсую. Вообще для меня менеджмент сцен и правильный перенос данных между сценами - одна из проблемных вещей сейчас.
плюсую
+
Полностью поддерживаю!)
Однозначно необходимо!
Блин, где было это видео год назад?!? Почему мне раньше никто не сказал что можно так делать? Теперь хочется переделать все мои старые игры.
Отлично, продолжай, пожалуйста!
Просьба добавить сцену с главным меню, потому что чаще всего именно сцена меню запускается первой.
Спасибо за труд
За RuntimeInitializeOnLoadMethod отдельный поклон :)
Прекрасное видео! Спасибо за такой контент! Я, как начинающий в программировании и разработке игр, рад видеть такие уроки. Хотелось бы еще видео со сценой главного меню!
Да, я бы посмотрел на систему из трех сцен, чтобы закрепить материал так сказать
Спасибо большое :) Очень полезно и познавательно :)
Очень радует, что минимум нагромождений в виде плагинов
Добавить сцену обязатнльно.
Отличное видео
Ждем следующую часть всем селом
Спасибо огромное за видео!
Бесценный просто контент
На все лайки и подписка
Классно! Слушай, а что если делать не через resources.load, а через addressables. Сейчас мониторю вакансии, многие указывают addressables в требовании. На сколько оно вообще лучше и подойдет ли в данном случае?
Можно. Но грузить и выгружать уже сцены не стартовые.
Технически можно, но конкретно в этом случае (загрузка рутового UI) через addressables делать - это из пушки по воробьям стрелять. А вообще тема актуальная в целом
адаптивное управление (переназначение клавиш). перевод на разные языки и подгрузка всех надписей из xml файла или как удобно хранить? подгрузка ресурсов при запуске (новые предметы и шкурки) покупки в внутреннем магазине с секьюрностью и шифрация сетевого обращения и получения ответа от сервера, сам продажный магазин скрипт - он наверно на php?
Расширяем, все что можно расширить😅
Ура новые фишечки :3
Расширяем :)
Было бы круто в рамках рубрики еще разобрать ассеты UniTask и Addresables, часто про них слышал, но не особо погружался )
UniTask не будет, это старье никто не поддерживают уже несколько лет. Для асинхронности будет использована библиотека System.Reactive, то есть будем познавать реактивщину, что уровнем выше и удобнее всяких await функций.
Addressables вероятно затронем в каком-то виде, а может и сильно затронем
@@gamedevlavka ну в целом асинхронщину хотелось увидеть-пощупать, так что круто :)
@@gamedevlavka я думаю про UniTask ты не прав, он поддерживается, это ситуация ровно как с Zenject. Это законченные продукты/плагины, что там должно обновляется если оно работает ? максимум баг фиксы, которые ну очень редко возможно поймать, т.к. много проектов уже обкатали его на продакшине.
Если у нас в юнити версия С# не менялась, что там поддерживать.
Спасибо большое, было очень полезно 😊 такой вопрос, а вы работаете в какой-то профессиональной студии? Или самоучка всё-таки? В последнее верится слабо 😅
Самоучки тоже работают в профессиональных студиях)
Скажу так: я отучился на защитника информации, это профессия связана в том числе с программированием (но это не основное). Затем сам обучился создавать игры на юнити и попал в игрострой. Ну и далее развивался в этом направлении, последние 7+ лет работаю в коммерческом игрострое. Правда, сейчас студийный проект на Cocos движке, но я уже на том уровне, когда не важно, какой движок, какой язык)
Но делиться кокосовыми "приколами" пока не тянет, не вижу запроса
@@gamedevlavka понял, спасибо большое за ответ))
Приятно увидеть по-настоящему компетентный код от профессионала. До сих пор ничего подобного не видел. Есть ли какие-то ссылки на best practice по архитектуре в Unity? Я сам сколько не гуглил, ничего глубже "ставить _ перед приватными полями" не видел.
Спасибо)
Best Practice, к сожалению, не видел хороших подборок, хоть свою составляй)
Есть, конечно, с неймингами практики, но и они наполовину вкусовщина. Ну а конкретно архитектурные делается на очевидные и сложные для понимания. Очевидные скорее всего уже где-то виделись, а сложные не перечислены в списках)
gamedevlavka, как относишься к архитектуре kSyndicate ? Наверняка ты сталкивался. Там похожий bootstrapper, но стартует с монобеха, а не с InitializeOnLoad. Ещё у них там огромная state machnie.
У тебя опечатка в слове "instance"
Здесь на видео неплохая, приятная архитектура, мне нравится.
Я с ней не знакомился. Но по твоим словам могу предположить, что там такое. Старт с монобеха - окэй, хоть и больше завязывает на движок. Но кто сейчас на это смотрит? Однако, скажу такую вещь: чем меньше завязываешься на движок, тем легче с него потом перейти, если потребуется. Или портировать игру. У меня просто опыт смены движка на игре есть и я был рад таким мелочам.
Огромная state machine - тут вариантов много в голове возникает. При этом какие-то решения могут быть хорошими, какие-то не очень. Но у меня в голове ОГРОМНАЯ машина состояний не складывается даже при нагруженных мобильных и ПК проектах. Надо как-нибудь ознакомиться с их решением, интересно. Так же стейт машина в явном виде может быть оверинжинирингом, и можно обойтись "стейт машиной" построенной на методах и "колбеках". Скорее всего на этом проекте мы так и сделаем.
За опечатку спасибо)
Приветствую, не проще работать с async, вместо coroutine?
Технически это одно и тоже, но в данный момент удобнее использовать корутины
Perfect!
Еще есть способ от сцены получить все корневые объекты и найти нужный компонент по ним.
Типо оптимизированней 😅
Да, можно так)
я так понимаю, чуть попозже будет сцена "главного меню" и потом переход в саму игру (геймплей)?
а так полезный материал для начинающих, кто хочет до билда проекта дойти :)
Спасибо
Получаца, что так)
Хотелось бы обратить внимание на несколько моментов.
Во-первых, сцена Boot утратила своё первоначальное назначение и теперь используется лишь как промежуточный этап для выгрузки ресурсов из других сцен.
Во-вторых, следует создать отдельный загрузчик сцен для повторного использования кода."
1. Так может показаться, потому что и Boot и Gameplay пустые (практически). Однако, Gameplay может и, скорее всего, будет содержать какой-то пред заготовленный контент
2. Переход по сценам может быть нетривиальным процессом, ведь часто нужно передавать параметры входа в сцену и выхода из сцены. И пока четко не понятны входные и выходные параметры, которые для разных сцен могут быть разнородными, а также сам процесс запуска сцены может включать разные действия - лучше воздержаться от создания загрузчика сцен, чтобы не тратить на это время
Как насчет запушить на git?))
Отличная идея! Уже залил)
Про слип таймаут для мобилок никогда не слышал, расскажи еще фишки которые не все могут знать.
Не лучше ли использовать несколько канвасов, для экранов и попапов отдельно?
И можно ли избежать опечаток в #if UNITY_EDITOR как с названиями сцен? Я один раз опечатался, и целый кусок кода не выполнялся. Ведь #if UNITY_EDTIOR уже false.
Так на вскидку ещё фишек не скажешь, они всплывёт далее скорее всего. С управлением, например
Да, несколько канвасов технически оптимизированнее. Но в этом проекте и так сойдёт, UI не сильно будет нагружен.
Про опечатки - райдер подсказывает, у него оч хорошая интеграция с юнити. Но надо либо плотить за лицензию, либ9о искать "народную" версию) я плочу, если что)
@@gamedevlavka Насчет нескольких канвасов прочел и не совсем понял. Ето типа разделение, HUD и игровой магазин в два отдельн канваса?
@@romanbolkun3353 нет, это именно слой экрана и слой попапов предлагается разделить, чтобы рендерилось быстрее
@@gamedevlavka понял, спасибо)
@@gamedevlavka а я не понял... разделить HUD и POPUP по своим префабам?
heh, первый