Привет. А будут ролики еще про архитектуру приложения ?. Или посоветуй пожалуйста материла по построении архитектуры игры (Кинги статьи). Связи UI и Game например. Заранее спасибо. Классный канал спасибо за ролики.
Точнее разбор кода подписчиков, довольно не плохо, к синдикат тоже неплохой канал, а так читать, устроиться на работу в конце концов, это самый эффективный способ считается
Нуу... в статические классы (В НЕБОЛЬШИХ ПРОЕКТАХ) очень удобно пихать нужную в большинстве случаев Функциональцину. Ну например SaveLoad класса Сериализованного Сохранения Игрока. При условии, что использунтся один функционал. Ну например сохранения в Json. Или Загрузку уровней.
Ну минусы очень условные, скорее это просто особенности работы класса и просто условия использования Это как жаловаться на велосипед о том что он не может бетон возить Да, не стоит везде пихать статики, но это работает со всем кодом, где то нужно одно, где то другое Этот видос скорее просто разъясняет что и для чего нужно применять
Именно так, так и задумывалось, а название видео такое - по известным причинам. Но цель была показать, для каких случаев подходит и не подходит статика
Привет! Спасибо за видео! Есть вопрос по статическим полям: заметил, что если в Unity в режиме Play значение статического поля изменяется, то эти изменения сохранятся во всем проекте и после выхода из режима Play (а не как обычно сбрасываются). Изменения сбрасываются, только если менять что-то в коде (напр. тупо добавить какую-нибудь строчку, даже не относящуюся к стат полю, причем не обязательно в скрипте со статичным полем). Не нашел объяснения почему так, кто-нибудь поможет, объяснит?) И еще вопрос - статические поля ведут себя точно так же в реальных игровых сессиях? (т.е. если игрок выйдет из игры, значение стат поля сохранится?). Если так, то получается статические поля нельзя использовать с объектами, которые изменяются во время игры?
Значение не сохранится. То что у тебя оно сохраняется между PlayModes у тебя наверняка стоит EnterPlayMode Options, чтобы Play быстрее включался. Именно эта опция сбрасывает всю статику, но занимает большее время
Также, как и к статике в целом. Они должны быть на своем месте: сцена загружена, прошла секунда игрового времени, игру поставили на паузу или свернули - это можно делать статичными событиями. При чем некоторые из них в Unity уже реализованы в качестве внутренних методов, но масштаб ответственности приведенных примеров понятен. То есть об этих событиях может знать каждый. Но по умолчанию, этого не требуется, поэтому в 99.9% случаев события не статичны
В 0:18 ночи нужно спать, а не про сервис-локатор рассказывать XD А если серьёзно, то не получится ли такая же ситуация, как в мемасике со скейтбордистом? Я так понимаю, что использование сервис-локатора "в любом месте" приведет к той же самой проблеме, что и просто со статическими классами. Если вдруг "неизменный" сервис аналитики придется поменять, то его получение через локатор снова нужно будет вычищать ручками. У нас "в любом другом классе" переменная типа Penguin. Хоть с локатором, хоть без.
Сервис-локатор используется для глобальных сущностей, именно поэтому я говорил "представим, что пингвин это сервис", то есть это может быть фича (например магазин), или сервис аналитики, или сервис внутри игровых покупок и т.д. Не нужно в локатор хранить все подряд. Во-вторых, нужно делать сервис локатор не объектами, понятное дело, а через интерфейсы, тогда не нужно ничего вычищать руками, просто меняешь место инициализации и все. Думаю я расскажу подробности как раз в видео про сервис локатор)
@@gamedevlavka столкнулся с тем, что ютуб жестко трет мои комментарии. Кажется, я у него в немилости :-D Теперь по делу (повторю комментарий). Возможно, мне не хватает опыта, чтобы понять твою мысль. Однако, замена конкретного типа на интерфейс влечет за собой другую проблему. Я так понимаю, речь о чем-то вроде GetServices(). Но мы таким образом делаем контракт класса неявным. Мы скрываем зависимости. Не приведет ли это к большим проблемам? Да, я снова про DI
А можешь разобрать EventManager из Юнити примера FpsMicrogame. Он вроде не сложный совсем но чет не пойму как там с типами дело обстоит. Передают в конкретный тип пустой метод с параметром ,🙄
Тема не раскрыта: Чем статик хуже singleton? Интересует ни очевидные: singleton может наследоваться и несколько реализаций singleton можно положить в массив, например для какого-то Inject. Но на моей опыте почти никогда не наследуется singleton от какой-то абстракции и интерфейса, все singleton независмые системы Если нужен instantiate или другое api unity, то нужен singleton наследуемый от MonoBehaviour. А например: static может работать в edit mode. static может работать в любой сцене. у static есть api которое вызывается в момент открытия проекта и update. Static даже пишется приятней: ServiceLocator вместо ServiceLocator.Instance Которые уже круто перекрывают singleton, хотя в одной компании мое решение тз забраковали за сервис в static, мол лучше бы написал singleton. Что вы думаете на эту тему?
во первых,лягушки не всегда зеленые🙂 и во вторых вопрос: что имелось в виду "видео для джунов"?Лично я полное дно,но мне понятно,что рассказываете и ,мало того,я итак все это знал. А логика сервис-локатора у вас в архитектуре проекта достаточно подробно разложена.Хотя если будет что то новое-всегда интересно.
@@gamedevlavka дайте совет подписчику🤨 нужно создавать рандомно корабли(бриги,фрегаты и подобное). У каждого конкретного класса(например, у фрегата) один корабль имеет одни характеристики(скорость,кол-во пушек и т.д. ) другой фрегат другие.Какой паттерн использовать?Фабричный метод или Строитель?
@@АндрейПрокофьев-е7д что мешает использовать Prefab Variant? Где уже создать экземпляры с нужными характеристиками. Нужно больше контекста, чтобы дать ответ правильнее
Пересмотрел еще раз... Захотелось еще лайк поставить :) 👍 (особенно за сервис локатор)
Привет. А будут ролики еще про архитектуру приложения ?. Или посоветуй пожалуйста материла по построении архитектуры игры (Кинги статьи). Связи UI и Game например. Заранее спасибо. Классный канал спасибо за ролики.
Максим крюков рекомендую там есть разбор стримов
Точнее разбор кода подписчиков, довольно не плохо, к синдикат тоже неплохой канал, а так читать, устроиться на работу в конце концов, это самый эффективный способ считается
Разбери сервис-локатор поподробнее.
А чего разбирать? Обычный словарь, где ключ это тип.
@@mao3193 попросили написать в комментариях, если хотим, чтобы разобрали. Вот я и написал, в чем проблема?
Нуу... в статические классы (В НЕБОЛЬШИХ ПРОЕКТАХ) очень удобно пихать нужную в большинстве случаев Функциональцину. Ну например SaveLoad класса Сериализованного Сохранения Игрока. При условии, что использунтся один функционал. Ну например сохранения в Json. Или Загрузку уровней.
@@nightkot4917 да, в маленьких проектах на 1-2 разработчика можно вообще что угодно делать)
Ну минусы очень условные, скорее это просто особенности работы класса и просто условия использования
Это как жаловаться на велосипед о том что он не может бетон возить
Да, не стоит везде пихать статики, но это работает со всем кодом, где то нужно одно, где то другое
Этот видос скорее просто разъясняет что и для чего нужно применять
Именно так, так и задумывалось, а название видео такое - по известным причинам. Но цель была показать, для каких случаев подходит и не подходит статика
@@gamedevlavka Всё понимается, видосик то надо продвигать с:
Спасибо за урок!!
Вот так бывает) смотрел мнение по статике, а залип на сервис локаторе)
разбор сервис локатора очень актуален
Спасибо за видос)
спасибо за паттерн, очень полезно
Привет! Спасибо за видео!
Есть вопрос по статическим полям: заметил, что если в Unity в режиме Play значение статического поля изменяется, то эти изменения сохранятся во всем проекте и после выхода из режима Play (а не как обычно сбрасываются). Изменения сбрасываются, только если менять что-то в коде (напр. тупо добавить какую-нибудь строчку, даже не относящуюся к стат полю, причем не обязательно в скрипте со статичным полем). Не нашел объяснения почему так, кто-нибудь поможет, объяснит?)
И еще вопрос - статические поля ведут себя точно так же в реальных игровых сессиях? (т.е. если игрок выйдет из игры, значение стат поля сохранится?). Если так, то получается статические поля нельзя использовать с объектами, которые изменяются во время игры?
Значение не сохранится. То что у тебя оно сохраняется между PlayModes у тебя наверняка стоит EnterPlayMode Options, чтобы Play быстрее включался. Именно эта опция сбрасывает всю статику, но занимает большее время
Как ты относишься к статичным событиям?
Также, как и к статике в целом. Они должны быть на своем месте: сцена загружена, прошла секунда игрового времени, игру поставили на паузу или свернули - это можно делать статичными событиями. При чем некоторые из них в Unity уже реализованы в качестве внутренних методов, но масштаб ответственности приведенных примеров понятен. То есть об этих событиях может знать каждый. Но по умолчанию, этого не требуется, поэтому в 99.9% случаев события не статичны
Спасибо
Подписка
В 0:18 ночи нужно спать, а не про сервис-локатор рассказывать XD А если серьёзно, то не получится ли такая же ситуация, как в мемасике со скейтбордистом? Я так понимаю, что использование сервис-локатора "в любом месте" приведет к той же самой проблеме, что и просто со статическими классами. Если вдруг "неизменный" сервис аналитики придется поменять, то его получение через локатор снова нужно будет вычищать ручками. У нас "в любом другом классе" переменная типа Penguin. Хоть с локатором, хоть без.
Сервис-локатор используется для глобальных сущностей, именно поэтому я говорил "представим, что пингвин это сервис", то есть это может быть фича (например магазин), или сервис аналитики, или сервис внутри игровых покупок и т.д. Не нужно в локатор хранить все подряд.
Во-вторых, нужно делать сервис локатор не объектами, понятное дело, а через интерфейсы, тогда не нужно ничего вычищать руками, просто меняешь место инициализации и все. Думаю я расскажу подробности как раз в видео про сервис локатор)
А раньше не выходит записывать, у меня годовалая дочка, и пока она не уснёт, дома слишком шумно, кабинета своего пока нет)
@@gamedevlavka столкнулся с тем, что ютуб жестко трет мои комментарии. Кажется, я у него в немилости :-D Теперь по делу (повторю комментарий). Возможно, мне не хватает опыта, чтобы понять твою мысль. Однако, замена конкретного типа на интерфейс влечет за собой другую проблему. Я так понимаю, речь о чем-то вроде GetServices(). Но мы таким образом делаем контракт класса неявным. Мы скрываем зависимости. Не приведет ли это к большим проблемам? Да, я снова про DI
Хороший и познавательный ролик ?
Ждём сервис-локатор.
Лайк
А можешь разобрать EventManager из Юнити примера FpsMicrogame. Он вроде не сложный совсем но чет не пойму как там с типами дело обстоит. Передают в конкретный тип пустой метод с параметром ,🙄
Там экшон, наверно идёт подписка как-то не явно
@@def6141 надо будет глянуть
Тема не раскрыта:
Чем статик хуже singleton?
Интересует ни очевидные:
singleton может наследоваться и несколько реализаций singleton можно положить в массив, например для какого-то Inject.
Но на моей опыте почти никогда не наследуется singleton от какой-то абстракции и интерфейса, все singleton независмые системы
Если нужен instantiate или другое api unity, то нужен singleton наследуемый от MonoBehaviour.
А например:
static может работать в edit mode.
static может работать в любой сцене.
у static есть api которое вызывается в момент открытия проекта и update.
Static даже пишется приятней: ServiceLocator вместо ServiceLocator.Instance
Которые уже круто перекрывают singleton, хотя в одной компании мое решение тз забраковали за сервис в static, мол лучше бы написал singleton.
Что вы думаете на эту тему?
Гундяй)
Если уж начал про статику рассказывать, можно было про синглтон немного рассказать.
Видео о синглтоне есть на канале, но да, не упомянул, каюсь
Разбери пожалуйста сервис локатор!!
Подписался, поставил лайк, на колокольчик кликнул!
Оч жду!
Для начинающих практически ничего не понятно...,
собственно и написано, что рассчитано на джунов.
Классное видео! но дружище не чарактер а кэрэктер)
Интересный факт, когда я говорю на английском, я правильно говорю) откуда эта привычка - ума не приложу, уже много лет избавиться не могу)
во первых,лягушки не всегда зеленые🙂 и во вторых вопрос:
что имелось в виду "видео для джунов"?Лично я полное дно,но мне понятно,что рассказываете и ,мало того,я итак все это знал.
А логика сервис-локатора у вас в архитектуре проекта достаточно подробно разложена.Хотя если будет что то новое-всегда интересно.
Не каждый джун понимает вопрос на должном уровне, это ведь частный случай. С архитектурным видео согласен, там есть то, как работает сервис локатор.
@@gamedevlavka дайте совет подписчику🤨
нужно создавать рандомно корабли(бриги,фрегаты и подобное). У каждого конкретного класса(например, у фрегата) один корабль имеет одни характеристики(скорость,кол-во пушек и т.д. ) другой фрегат другие.Какой паттерн использовать?Фабричный метод или Строитель?
@@АндрейПрокофьев-е7д что мешает использовать Prefab Variant? Где уже создать экземпляры с нужными характеристиками.
Нужно больше контекста, чтобы дать ответ правильнее
@@gamedevlavka визуализация не важна.У меня корабли это кубики🤣.важно создание экземпляров классов,то есть программирование.
@@АндрейПрокофьев-е7д ты часом не пытаешься сделать игру по мотивам настолки из книжки Олега Орлова?XD