Точка входа в юнити без монобеха для меня открытие, я столько видел туторов на тему старта в юнити и никто ни разу это не использовал. Больше 2-х лет работал с юнити и ни в одном проекте не видел. Понятно, что вещь не обязательная и не критическая, но выглядит очень полезно. Огромное спасибо за эту информацию.
Я делаю пет-проект под webGL и столкнулся с такой проблемой: при переходе во время игры в полноэкранный режим при переходе на следующую сцену ui новой сцены сползает. Я так понял, это происходит из-за того, что uiRoot мы сделали DontDestroyOnLoad и canvas uiRoot сохраняет старые размеры окна, а прикрепленный к нему ui canvas следующей сцены имеет уже другие значения размера нового окна. В итоге uiRoot canvas во весь экран, а UI сцены сползает, хотя у всех канвасов стоит scale with screen size. Если же менять размеры окна без перехода на следующую сцену, то все ок. На мой взгляд мое решение проблемы выглядит несколько костыльно. Я в uiRoot в fixedUpdate меняю размеры resolution scale у канваса, а затем у ui сцены размер и расположение как у канваса uiRoot. Андрей, как можно решить эту проблему более правильным способом?
Классно! Слушай, а что если делать не через resources.load, а через addressables. Сейчас мониторю вакансии, многие указывают addressables в требовании. На сколько оно вообще лучше и подойдет ли в данном случае?
Технически можно, но конкретно в этом случае (загрузка рутового UI) через addressables делать - это из пушки по воробьям стрелять. А вообще тема актуальная в целом
адаптивное управление (переназначение клавиш). перевод на разные языки и подгрузка всех надписей из xml файла или как удобно хранить? подгрузка ресурсов при запуске (новые предметы и шкурки) покупки в внутреннем магазине с секьюрностью и шифрация сетевого обращения и получения ответа от сервера, сам продажный магазин скрипт - он наверно на php?
gamedevlavka, как относишься к архитектуре kSyndicate ? Наверняка ты сталкивался. Там похожий bootstrapper, но стартует с монобеха, а не с InitializeOnLoad. Ещё у них там огромная state machnie. У тебя опечатка в слове "instance"
Я с ней не знакомился. Но по твоим словам могу предположить, что там такое. Старт с монобеха - окэй, хоть и больше завязывает на движок. Но кто сейчас на это смотрит? Однако, скажу такую вещь: чем меньше завязываешься на движок, тем легче с него потом перейти, если потребуется. Или портировать игру. У меня просто опыт смены движка на игре есть и я был рад таким мелочам. Огромная state machine - тут вариантов много в голове возникает. При этом какие-то решения могут быть хорошими, какие-то не очень. Но у меня в голове ОГРОМНАЯ машина состояний не складывается даже при нагруженных мобильных и ПК проектах. Надо как-нибудь ознакомиться с их решением, интересно. Так же стейт машина в явном виде может быть оверинжинирингом, и можно обойтись "стейт машиной" построенной на методах и "колбеках". Скорее всего на этом проекте мы так и сделаем. За опечатку спасибо)
Приятно увидеть по-настоящему компетентный код от профессионала. До сих пор ничего подобного не видел. Есть ли какие-то ссылки на best practice по архитектуре в Unity? Я сам сколько не гуглил, ничего глубже "ставить _ перед приватными полями" не видел.
Спасибо) Best Practice, к сожалению, не видел хороших подборок, хоть свою составляй) Есть, конечно, с неймингами практики, но и они наполовину вкусовщина. Ну а конкретно архитектурные делается на очевидные и сложные для понимания. Очевидные скорее всего уже где-то виделись, а сложные не перечислены в списках)
UniTask не будет, это старье никто не поддерживают уже несколько лет. Для асинхронности будет использована библиотека System.Reactive, то есть будем познавать реактивщину, что уровнем выше и удобнее всяких await функций. Addressables вероятно затронем в каком-то виде, а может и сильно затронем
@@gamedevlavka я думаю про UniTask ты не прав, он поддерживается, это ситуация ровно как с Zenject. Это законченные продукты/плагины, что там должно обновляется если оно работает ? максимум баг фиксы, которые ну очень редко возможно поймать, т.к. много проектов уже обкатали его на продакшине. Если у нас в юнити версия С# не менялась, что там поддерживать.
А я с такой проблемой столкнулся: В геймплей сцене у меня уже есть объект и свет Если запускать плеймод не с геймплейной сцены, то визуально сцена выглядит не корректно. Но если запускать с геймплейной сены, всё ок. Подскажите плиз почему так)
я так понимаю, чуть попозже будет сцена "главного меню" и потом переход в саму игру (геймплей)? а так полезный материал для начинающих, кто хочет до билда проекта дойти :) Спасибо
Спасибо большое, было очень полезно 😊 такой вопрос, а вы работаете в какой-то профессиональной студии? Или самоучка всё-таки? В последнее верится слабо 😅
Самоучки тоже работают в профессиональных студиях) Скажу так: я отучился на защитника информации, это профессия связана в том числе с программированием (но это не основное). Затем сам обучился создавать игры на юнити и попал в игрострой. Ну и далее развивался в этом направлении, последние 7+ лет работаю в коммерческом игрострое. Правда, сейчас студийный проект на Cocos движке, но я уже на том уровне, когда не важно, какой движок, какой язык) Но делиться кокосовыми "приколами" пока не тянет, не вижу запроса
Хотелось бы обратить внимание на несколько моментов. Во-первых, сцена Boot утратила своё первоначальное назначение и теперь используется лишь как промежуточный этап для выгрузки ресурсов из других сцен. Во-вторых, следует создать отдельный загрузчик сцен для повторного использования кода."
1. Так может показаться, потому что и Boot и Gameplay пустые (практически). Однако, Gameplay может и, скорее всего, будет содержать какой-то пред заготовленный контент 2. Переход по сценам может быть нетривиальным процессом, ведь часто нужно передавать параметры входа в сцену и выхода из сцены. И пока четко не понятны входные и выходные параметры, которые для разных сцен могут быть разнородными, а также сам процесс запуска сцены может включать разные действия - лучше воздержаться от создания загрузчика сцен, чтобы не тратить на это время
Про слип таймаут для мобилок никогда не слышал, расскажи еще фишки которые не все могут знать. Не лучше ли использовать несколько канвасов, для экранов и попапов отдельно? И можно ли избежать опечаток в #if UNITY_EDITOR как с названиями сцен? Я один раз опечатался, и целый кусок кода не выполнялся. Ведь #if UNITY_EDTIOR уже false.
Так на вскидку ещё фишек не скажешь, они всплывёт далее скорее всего. С управлением, например Да, несколько канвасов технически оптимизированнее. Но в этом проекте и так сойдёт, UI не сильно будет нагружен. Про опечатки - райдер подсказывает, у него оч хорошая интеграция с юнити. Но надо либо плотить за лицензию, либ9о искать "народную" версию) я плочу, если что)
![Felix "Unfair" | [Stray Kids : SKZ-PLAYER]](http://i.ytimg.com/vi/Oswujxm2Ag0/mqdefault.jpg)
Точка входа в юнити без монобеха для меня открытие, я столько видел туторов на тему старта в юнити и никто ни разу это не использовал.
Больше 2-х лет работал с юнити и ни в одном проекте не видел. Понятно, что вещь не обязательная и не критическая, но выглядит очень полезно.
Огромное спасибо за эту информацию.
Обязательно надо добавить еще сцену и организовать переход между ними!! Обязательно! =)
Плюсую. Вообще для меня менеджмент сцен и правильный перенос данных между сценами - одна из проблемных вещей сейчас.
плюсую
+
Полностью поддерживаю!)
Однозначно необходимо!
За RuntimeInitializeOnLoadMethod отдельный поклон :)
Отлично, продолжай, пожалуйста!
Просьба добавить сцену с главным меню, потому что чаще всего именно сцена меню запускается первой.
Спасибо за труд
Блин, где было это видео год назад?!? Почему мне раньше никто не сказал что можно так делать? Теперь хочется переделать все мои старые игры.
Спасибо большое :) Очень полезно и познавательно :)
Спасибо огромное за видео!
Бесценный просто контент
На все лайки и подписка
Ждем следующую часть всем селом
Добавить сцену обязатнльно.
Отличное видео
Да, я бы посмотрел на систему из трех сцен, чтобы закрепить материал так сказать
Я делаю пет-проект под webGL и столкнулся с такой проблемой: при переходе во время игры в полноэкранный режим при переходе на следующую сцену ui новой сцены сползает. Я так понял, это происходит из-за того, что uiRoot мы сделали DontDestroyOnLoad и canvas uiRoot сохраняет старые размеры окна, а прикрепленный к нему ui canvas следующей сцены имеет уже другие значения размера нового окна. В итоге uiRoot canvas во весь экран, а UI сцены сползает, хотя у всех канвасов стоит scale with screen size. Если же менять размеры окна без перехода на следующую сцену, то все ок. На мой взгляд мое решение проблемы выглядит несколько костыльно. Я в uiRoot в fixedUpdate меняю размеры resolution scale у канваса, а затем у ui сцены размер и расположение как у канваса uiRoot. Андрей, как можно решить эту проблему более правильным способом?
Игра у нас будет очень простая, поэтому мы запилим собственный кастомный DI контейнер. Ясно, понятно.
Классно! Слушай, а что если делать не через resources.load, а через addressables. Сейчас мониторю вакансии, многие указывают addressables в требовании. На сколько оно вообще лучше и подойдет ли в данном случае?
Можно. Но грузить и выгружать уже сцены не стартовые.
Технически можно, но конкретно в этом случае (загрузка рутового UI) через addressables делать - это из пушки по воробьям стрелять. А вообще тема актуальная в целом
Расширяем, все что можно расширить😅
Расширяем :)
Ура новые фишечки :3
адаптивное управление (переназначение клавиш). перевод на разные языки и подгрузка всех надписей из xml файла или как удобно хранить? подгрузка ресурсов при запуске (новые предметы и шкурки) покупки в внутреннем магазине с секьюрностью и шифрация сетевого обращения и получения ответа от сервера, сам продажный магазин скрипт - он наверно на php?
Очень радует, что минимум нагромождений в виде плагинов
Perfect!
gamedevlavka, как относишься к архитектуре kSyndicate ? Наверняка ты сталкивался. Там похожий bootstrapper, но стартует с монобеха, а не с InitializeOnLoad. Ещё у них там огромная state machnie.
У тебя опечатка в слове "instance"
Здесь на видео неплохая, приятная архитектура, мне нравится.
Я с ней не знакомился. Но по твоим словам могу предположить, что там такое. Старт с монобеха - окэй, хоть и больше завязывает на движок. Но кто сейчас на это смотрит? Однако, скажу такую вещь: чем меньше завязываешься на движок, тем легче с него потом перейти, если потребуется. Или портировать игру. У меня просто опыт смены движка на игре есть и я был рад таким мелочам.
Огромная state machine - тут вариантов много в голове возникает. При этом какие-то решения могут быть хорошими, какие-то не очень. Но у меня в голове ОГРОМНАЯ машина состояний не складывается даже при нагруженных мобильных и ПК проектах. Надо как-нибудь ознакомиться с их решением, интересно. Так же стейт машина в явном виде может быть оверинжинирингом, и можно обойтись "стейт машиной" построенной на методах и "колбеках". Скорее всего на этом проекте мы так и сделаем.
За опечатку спасибо)
Приятно увидеть по-настоящему компетентный код от профессионала. До сих пор ничего подобного не видел. Есть ли какие-то ссылки на best practice по архитектуре в Unity? Я сам сколько не гуглил, ничего глубже "ставить _ перед приватными полями" не видел.
Спасибо)
Best Practice, к сожалению, не видел хороших подборок, хоть свою составляй)
Есть, конечно, с неймингами практики, но и они наполовину вкусовщина. Ну а конкретно архитектурные делается на очевидные и сложные для понимания. Очевидные скорее всего уже где-то виделись, а сложные не перечислены в списках)
Было бы круто в рамках рубрики еще разобрать ассеты UniTask и Addresables, часто про них слышал, но не особо погружался )
UniTask не будет, это старье никто не поддерживают уже несколько лет. Для асинхронности будет использована библиотека System.Reactive, то есть будем познавать реактивщину, что уровнем выше и удобнее всяких await функций.
Addressables вероятно затронем в каком-то виде, а может и сильно затронем
@@gamedevlavka ну в целом асинхронщину хотелось увидеть-пощупать, так что круто :)
@@gamedevlavka я думаю про UniTask ты не прав, он поддерживается, это ситуация ровно как с Zenject. Это законченные продукты/плагины, что там должно обновляется если оно работает ? максимум баг фиксы, которые ну очень редко возможно поймать, т.к. много проектов уже обкатали его на продакшине.
Если у нас в юнити версия С# не менялась, что там поддерживать.
@@gamedevlavka Даешь Народу - Addressables, товарищ!
Приветствую, не проще работать с async, вместо coroutine?
Технически это одно и тоже, но в данный момент удобнее использовать корутины
Стесняюсь спросить, что за редактор кода?
@@danil_zz это Rider, удобнее пока не встречал
@gamedevlavka понял, спасибо. А я думал, это Visual Studio новая, которую я качать не хотел.
А я с такой проблемой столкнулся:
В геймплей сцене у меня уже есть объект и свет
Если запускать плеймод не с геймплейной сцены, то визуально сцена выглядит не корректно. Но если запускать с геймплейной сены, всё ок.
Подскажите плиз почему так)
@@GladyBoroda это проблема редактора, но признаюсь честно, не помню как ее решить, и решаема ли она вообще
Еще есть способ от сцены получить все корневые объекты и найти нужный компонент по ним.
Типо оптимизированней 😅
Да, можно так)
я так понимаю, чуть попозже будет сцена "главного меню" и потом переход в саму игру (геймплей)?
а так полезный материал для начинающих, кто хочет до билда проекта дойти :)
Спасибо
Получаца, что так)
Спасибо большое, было очень полезно 😊 такой вопрос, а вы работаете в какой-то профессиональной студии? Или самоучка всё-таки? В последнее верится слабо 😅
Самоучки тоже работают в профессиональных студиях)
Скажу так: я отучился на защитника информации, это профессия связана в том числе с программированием (но это не основное). Затем сам обучился создавать игры на юнити и попал в игрострой. Ну и далее развивался в этом направлении, последние 7+ лет работаю в коммерческом игрострое. Правда, сейчас студийный проект на Cocos движке, но я уже на том уровне, когда не важно, какой движок, какой язык)
Но делиться кокосовыми "приколами" пока не тянет, не вижу запроса
@@gamedevlavka понял, спасибо большое за ответ))
Хотелось бы обратить внимание на несколько моментов.
Во-первых, сцена Boot утратила своё первоначальное назначение и теперь используется лишь как промежуточный этап для выгрузки ресурсов из других сцен.
Во-вторых, следует создать отдельный загрузчик сцен для повторного использования кода."
1. Так может показаться, потому что и Boot и Gameplay пустые (практически). Однако, Gameplay может и, скорее всего, будет содержать какой-то пред заготовленный контент
2. Переход по сценам может быть нетривиальным процессом, ведь часто нужно передавать параметры входа в сцену и выхода из сцены. И пока четко не понятны входные и выходные параметры, которые для разных сцен могут быть разнородными, а также сам процесс запуска сцены может включать разные действия - лучше воздержаться от создания загрузчика сцен, чтобы не тратить на это время
Как насчет запушить на git?))
Отличная идея! Уже залил)
Про слип таймаут для мобилок никогда не слышал, расскажи еще фишки которые не все могут знать.
Не лучше ли использовать несколько канвасов, для экранов и попапов отдельно?
И можно ли избежать опечаток в #if UNITY_EDITOR как с названиями сцен? Я один раз опечатался, и целый кусок кода не выполнялся. Ведь #if UNITY_EDTIOR уже false.
Так на вскидку ещё фишек не скажешь, они всплывёт далее скорее всего. С управлением, например
Да, несколько канвасов технически оптимизированнее. Но в этом проекте и так сойдёт, UI не сильно будет нагружен.
Про опечатки - райдер подсказывает, у него оч хорошая интеграция с юнити. Но надо либо плотить за лицензию, либ9о искать "народную" версию) я плочу, если что)
@@gamedevlavka Насчет нескольких канвасов прочел и не совсем понял. Ето типа разделение, HUD и игровой магазин в два отдельн канваса?
@@romanbolkun3353 нет, это именно слой экрана и слой попапов предлагается разделить, чтобы рендерилось быстрее
@@gamedevlavka понял, спасибо)
@@gamedevlavka а я не понял... разделить HUD и POPUP по своим префабам?
heh, первый