Точка входа в юнити без монобеха для меня открытие, я столько видел туторов на тему старта в юнити и никто ни разу это не использовал. Больше 2-х лет работал с юнити и ни в одном проекте не видел. Понятно, что вещь не обязательная и не критическая, но выглядит очень полезно. Огромное спасибо за эту информацию.
Прекрасное видео! Спасибо за такой контент! Я, как начинающий в программировании и разработке игр, рад видеть такие уроки. Хотелось бы еще видео со сценой главного меню!
Классно! Слушай, а что если делать не через resources.load, а через addressables. Сейчас мониторю вакансии, многие указывают addressables в требовании. На сколько оно вообще лучше и подойдет ли в данном случае?
Технически можно, но конкретно в этом случае (загрузка рутового UI) через addressables делать - это из пушки по воробьям стрелять. А вообще тема актуальная в целом
адаптивное управление (переназначение клавиш). перевод на разные языки и подгрузка всех надписей из xml файла или как удобно хранить? подгрузка ресурсов при запуске (новые предметы и шкурки) покупки в внутреннем магазине с секьюрностью и шифрация сетевого обращения и получения ответа от сервера, сам продажный магазин скрипт - он наверно на php?
Спасибо большое, было очень полезно 😊 такой вопрос, а вы работаете в какой-то профессиональной студии? Или самоучка всё-таки? В последнее верится слабо 😅
Самоучки тоже работают в профессиональных студиях) Скажу так: я отучился на защитника информации, это профессия связана в том числе с программированием (но это не основное). Затем сам обучился создавать игры на юнити и попал в игрострой. Ну и далее развивался в этом направлении, последние 7+ лет работаю в коммерческом игрострое. Правда, сейчас студийный проект на Cocos движке, но я уже на том уровне, когда не важно, какой движок, какой язык) Но делиться кокосовыми "приколами" пока не тянет, не вижу запроса
gamedevlavka, как относишься к архитектуре kSyndicate ? Наверняка ты сталкивался. Там похожий bootstrapper, но стартует с монобеха, а не с InitializeOnLoad. Ещё у них там огромная state machnie. У тебя опечатка в слове "instance"
Я с ней не знакомился. Но по твоим словам могу предположить, что там такое. Старт с монобеха - окэй, хоть и больше завязывает на движок. Но кто сейчас на это смотрит? Однако, скажу такую вещь: чем меньше завязываешься на движок, тем легче с него потом перейти, если потребуется. Или портировать игру. У меня просто опыт смены движка на игре есть и я был рад таким мелочам. Огромная state machine - тут вариантов много в голове возникает. При этом какие-то решения могут быть хорошими, какие-то не очень. Но у меня в голове ОГРОМНАЯ машина состояний не складывается даже при нагруженных мобильных и ПК проектах. Надо как-нибудь ознакомиться с их решением, интересно. Так же стейт машина в явном виде может быть оверинжинирингом, и можно обойтись "стейт машиной" построенной на методах и "колбеках". Скорее всего на этом проекте мы так и сделаем. За опечатку спасибо)
Приятно увидеть по-настоящему компетентный код от профессионала. До сих пор ничего подобного не видел. Есть ли какие-то ссылки на best practice по архитектуре в Unity? Я сам сколько не гуглил, ничего глубже "ставить _ перед приватными полями" не видел.
Спасибо) Best Practice, к сожалению, не видел хороших подборок, хоть свою составляй) Есть, конечно, с неймингами практики, но и они наполовину вкусовщина. Ну а конкретно архитектурные делается на очевидные и сложные для понимания. Очевидные скорее всего уже где-то виделись, а сложные не перечислены в списках)
UniTask не будет, это старье никто не поддерживают уже несколько лет. Для асинхронности будет использована библиотека System.Reactive, то есть будем познавать реактивщину, что уровнем выше и удобнее всяких await функций. Addressables вероятно затронем в каком-то виде, а может и сильно затронем
@@gamedevlavka я думаю про UniTask ты не прав, он поддерживается, это ситуация ровно как с Zenject. Это законченные продукты/плагины, что там должно обновляется если оно работает ? максимум баг фиксы, которые ну очень редко возможно поймать, т.к. много проектов уже обкатали его на продакшине. Если у нас в юнити версия С# не менялась, что там поддерживать.
я так понимаю, чуть попозже будет сцена "главного меню" и потом переход в саму игру (геймплей)? а так полезный материал для начинающих, кто хочет до билда проекта дойти :) Спасибо
Хотелось бы обратить внимание на несколько моментов. Во-первых, сцена Boot утратила своё первоначальное назначение и теперь используется лишь как промежуточный этап для выгрузки ресурсов из других сцен. Во-вторых, следует создать отдельный загрузчик сцен для повторного использования кода."
1. Так может показаться, потому что и Boot и Gameplay пустые (практически). Однако, Gameplay может и, скорее всего, будет содержать какой-то пред заготовленный контент 2. Переход по сценам может быть нетривиальным процессом, ведь часто нужно передавать параметры входа в сцену и выхода из сцены. И пока четко не понятны входные и выходные параметры, которые для разных сцен могут быть разнородными, а также сам процесс запуска сцены может включать разные действия - лучше воздержаться от создания загрузчика сцен, чтобы не тратить на это время
Про слип таймаут для мобилок никогда не слышал, расскажи еще фишки которые не все могут знать. Не лучше ли использовать несколько канвасов, для экранов и попапов отдельно? И можно ли избежать опечаток в #if UNITY_EDITOR как с названиями сцен? Я один раз опечатался, и целый кусок кода не выполнялся. Ведь #if UNITY_EDTIOR уже false.
Так на вскидку ещё фишек не скажешь, они всплывёт далее скорее всего. С управлением, например Да, несколько канвасов технически оптимизированнее. Но в этом проекте и так сойдёт, UI не сильно будет нагружен. Про опечатки - райдер подсказывает, у него оч хорошая интеграция с юнити. Но надо либо плотить за лицензию, либ9о искать "народную" версию) я плочу, если что)
Обязательно надо добавить еще сцену и организовать переход между ними!! Обязательно! =)
Плюсую. Вообще для меня менеджмент сцен и правильный перенос данных между сценами - одна из проблемных вещей сейчас.
плюсую
+
Полностью поддерживаю!)
Однозначно необходимо!
За RuntimeInitializeOnLoadMethod отдельный поклон :)
Отлично, продолжай, пожалуйста!
Просьба добавить сцену с главным меню, потому что чаще всего именно сцена меню запускается первой.
Спасибо за труд
Точка входа в юнити без монобеха для меня открытие, я столько видел туторов на тему старта в юнити и никто ни разу это не использовал.
Больше 2-х лет работал с юнити и ни в одном проекте не видел. Понятно, что вещь не обязательная и не критическая, но выглядит очень полезно.
Огромное спасибо за эту информацию.
Блин, где было это видео год назад?!? Почему мне раньше никто не сказал что можно так делать? Теперь хочется переделать все мои старые игры.
Прекрасное видео! Спасибо за такой контент! Я, как начинающий в программировании и разработке игр, рад видеть такие уроки. Хотелось бы еще видео со сценой главного меню!
Спасибо большое :) Очень полезно и познавательно :)
Добавить сцену обязатнльно.
Отличное видео
Да, я бы посмотрел на систему из трех сцен, чтобы закрепить материал так сказать
Спасибо огромное за видео!
Бесценный просто контент
На все лайки и подписка
Классно! Слушай, а что если делать не через resources.load, а через addressables. Сейчас мониторю вакансии, многие указывают addressables в требовании. На сколько оно вообще лучше и подойдет ли в данном случае?
Можно. Но грузить и выгружать уже сцены не стартовые.
Технически можно, но конкретно в этом случае (загрузка рутового UI) через addressables делать - это из пушки по воробьям стрелять. А вообще тема актуальная в целом
Ждем следующую часть всем селом
адаптивное управление (переназначение клавиш). перевод на разные языки и подгрузка всех надписей из xml файла или как удобно хранить? подгрузка ресурсов при запуске (новые предметы и шкурки) покупки в внутреннем магазине с секьюрностью и шифрация сетевого обращения и получения ответа от сервера, сам продажный магазин скрипт - он наверно на php?
Ура новые фишечки :3
Расширяем :)
Расширяем, все что можно расширить😅
Спасибо большое, было очень полезно 😊 такой вопрос, а вы работаете в какой-то профессиональной студии? Или самоучка всё-таки? В последнее верится слабо 😅
Самоучки тоже работают в профессиональных студиях)
Скажу так: я отучился на защитника информации, это профессия связана в том числе с программированием (но это не основное). Затем сам обучился создавать игры на юнити и попал в игрострой. Ну и далее развивался в этом направлении, последние 7+ лет работаю в коммерческом игрострое. Правда, сейчас студийный проект на Cocos движке, но я уже на том уровне, когда не важно, какой движок, какой язык)
Но делиться кокосовыми "приколами" пока не тянет, не вижу запроса
@@gamedevlavka понял, спасибо большое за ответ))
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. Это законченные продукты/плагины, что там должно обновляется если оно работает ? максимум баг фиксы, которые ну очень редко возможно поймать, т.к. много проектов уже обкатали его на продакшине.
Если у нас в юнити версия С# не менялась, что там поддерживать.
Perfect!
я так понимаю, чуть попозже будет сцена "главного меню" и потом переход в саму игру (геймплей)?
а так полезный материал для начинающих, кто хочет до билда проекта дойти :)
Спасибо
Получаца, что так)
Приветствую, не проще работать с async, вместо coroutine?
Технически это одно и тоже, но в данный момент удобнее использовать корутины
Еще есть способ от сцены получить все корневые объекты и найти нужный компонент по ним.
Типо оптимизированней 😅
Да, можно так)
Хотелось бы обратить внимание на несколько моментов.
Во-первых, сцена Boot утратила своё первоначальное назначение и теперь используется лишь как промежуточный этап для выгрузки ресурсов из других сцен.
Во-вторых, следует создать отдельный загрузчик сцен для повторного использования кода."
1. Так может показаться, потому что и Boot и Gameplay пустые (практически). Однако, Gameplay может и, скорее всего, будет содержать какой-то пред заготовленный контент
2. Переход по сценам может быть нетривиальным процессом, ведь часто нужно передавать параметры входа в сцену и выхода из сцены. И пока четко не понятны входные и выходные параметры, которые для разных сцен могут быть разнородными, а также сам процесс запуска сцены может включать разные действия - лучше воздержаться от создания загрузчика сцен, чтобы не тратить на это время
Как насчет запушить на git?))
Отличная идея! Уже залил)
Про слип таймаут для мобилок никогда не слышал, расскажи еще фишки которые не все могут знать.
Не лучше ли использовать несколько канвасов, для экранов и попапов отдельно?
И можно ли избежать опечаток в #if UNITY_EDITOR как с названиями сцен? Я один раз опечатался, и целый кусок кода не выполнялся. Ведь #if UNITY_EDTIOR уже false.
Так на вскидку ещё фишек не скажешь, они всплывёт далее скорее всего. С управлением, например
Да, несколько канвасов технически оптимизированнее. Но в этом проекте и так сойдёт, UI не сильно будет нагружен.
Про опечатки - райдер подсказывает, у него оч хорошая интеграция с юнити. Но надо либо плотить за лицензию, либ9о искать "народную" версию) я плочу, если что)
@@gamedevlavka Насчет нескольких канвасов прочел и не совсем понял. Ето типа разделение, HUD и игровой магазин в два отдельн канваса?
@@romanbolkun3353 нет, это именно слой экрана и слой попапов предлагается разделить, чтобы рендерилось быстрее
@@gamedevlavka понял, спасибо)
@@gamedevlavka а я не понял... разделить HUD и POPUP по своим префабам?
heh, первый