Как всегда, все на высшем уровне! Устроился в геймдев и теперь стабильно использую твои ролики для работы) Продолжай том же духе! Спасибо большое за твой труд, такого качественного контента на рускоязычном сегменте крайне мало!
@@gaitavr1992 По началу базовые были самые просматриваемые такие как: атрибуты, расширения, делегаты и т.п. Сейчас уже паттерны, так как грамотно подобрать архитектуру при разработке это чертовски важно. Правда из-за разницы в уровнях, приходится ролик продолжительностью минут в 10 пересматривать раз за разом, но я думаю это уже временные издержки)
Вроде как круто, но в тоже время довольно тяжко воспринимать. Я этот паттерн вдоль и поперёк знаю, но местами было трудно следить за видео. Есть ощущения что видос больше для тех, кто уже знаком с этим паттерном. Это кста не упрёк, просто чтобы автор лучше понимал, для какой аудитории делает видева. Спасибо за полезный контент.
@@gaitavr1992 Ну все понимают, что выдуманный, но всё же, было бы проще и привычнее полазить по файликам на гите, чем перематывать по 100 раз видео) p.s. Такого информативного контента на ютубе почти нет, а тут ещё и на русском) Спасибо
Как раз делал систему передвижения для игрока через if/else, если стоим на земле или плывём по воде и т.п. После ролика понял, что это все можно вынести в состояние и получить более удобную и гибкую систему. Конечно, чтобы вынести все зависимости из контекста, пришлось поломать голову, но оно того стоит. Спасибо за добротный контент)
Всё очень прекрасно. По поводу создания дополнительных класса Transition - тут же контролируется и в какие State может перейти объект. И логика будет в них. Выглядит очень удобно.
Ещё бы хотелось увидеть видос на тему специфики юнити при программировании. Как конфликтует система компонентов юнити и ООП. Как это влияет на архитектуру юнити приложения. Как решать проблемы с пробрасыванием зависимостей. Нужны ли архитектурные паттерны в юнити (mvp, mvc и т.д). Ну и ECS как архитектурное решение в ту же кучу.
Ух , никогда не учил паттерны, но и процедурным кодом , тоже уже не пишу.Оказывается всё уже придумали и додумали за меня и нужно просто найти паттерн для то или иной ситуации... Немного разочаровывающие умозаключение . Столько времени было потрачено на придумывание систем , если бы я сразу учил эти поведения ....Спасибо большое за урок жду новых паттернов ! )
@@gaitavr1992 Но знания о паттернах экономят немало времени , даже если приходиться нарушать их конструкцию, это всё равно быстрее, чем придумывать логику с чистого листа.
Пожелание: разбить ролик на части (сделать закладки), вступление, основная часть и заключение, плюс в основную часть добавить закладки на примеры кода и основные моменты. Многим сдесь будет удобно искать примеры кода в будущем. Второе: фон за теукстом размывать и сделать максимально контрасным фон и текст и НЕ использовать эффекты текстов и т.д. Посоветовал бы сделать один раз шаблон и им пользоваться. А так все отлично. Спасибо за ролик.
Спасибо, за ролик! Всё рассказано понятно, размеренно. Буду применять. А то хоть я и разбил код на вьюшки, модели и контроллеры, а мешанины все равно много получается.
Супер, больше бы таких каналов не за что не забивай на ютуб! Можешь сделать пожалуйста видео, если будет время, как стоит подходить к реализации паттерна состояние или его аналога в случае работы с фреймворком на ECS будь то unity dots или LeoEcs
Я использовал стандартный ECS и там огромная проблема с анимациями. У меня были префабы врагов и я не нашел никакой возможности проигрывать те же анимации(бег, смерть и тд).
Вместо листа со стейтами используй дикшинари Dictionary() и в SwitchState() where T : BaseState { if(!_allStates.TryGetValue(typeof(T), out _currentState) { //обработать ошибку если стейт не найден. } }
считаю этот паттерн обязательным для изучения/использования, у меня просто 2 примера игр над которыми я работал в одном и том же жанре с разницей почти 5 лет, в котором можно улучшать разные постройки, хоть и в большинстве случаев улучшение постройки не меняло ее механик, но были такие что совмещали в себе разные механики, это был ад с кучей наследований чтоб сделать нужные механики для одного юнита тратилось до нескольких дней работы, щас сделав все на стейтах, такой юнит может сделать даже геймдизайнер, просто добавив или убрав пару строчек в json файл
хорошие видео ,хотя и не много трудно уловить смысл , если ты не синьер, из за огромного количества профессиональных терминов, очень полезно и интерсно
Добрый день, Максим. Мне Очень нравятся ваши ролики и подход преподавания. Есть ли у вас курсы по паттернам? Если нет, то могу посоветовать какого рода курсы бы приглянулись изучающим данную тему. Пример "Проект в юнити с использованием паттерна проектирования". Можно на udemy залить или как вам угодно. Для зрителя - Ставь лайк комменту, если хочешь такой курс.
@@gaitavr1992, подскажите пожалуйста, в репозитории по товердефенс есть коммиты по урокам? Или только текущий проект? Сейчас повторяю пошагово Ваш проект и иногда по невнимательности что-то пропускаю, а потом не могу понять, где накосячил. Также подвопрос. Исходный проект с игрой это переработка статьи с Catlike Coding?
Как грамотно сделать таймер в BrokenState? Мы же не можем использовать корутину прямо в BrokenState, так как выдаст NullReferenceException из-за того что мы экземпляры делали через new. Я нашел на форумах что нужно использовать AddComponent. Я чувствую что есть элегантное решение, но я ,в силу малого опыта, не вижу.
Спасибо. А как смену анимации вплести в данную реализацию паттерна? Пытаюсь реализовать состояние NPC, все вроде понятно и работает, но не пойму, как подключать разные анимации (атака, погоня, патрулирование) при таком подходе. Примеры переключения анимаций в ютубе все с наследованием от StateMachineBehavior, но как-то интуитивно не хочется его использовать.
Ну и да, я бы все равно не говорил, что это то как всегда нужно делать стейтмашину. Вот допустим банальный парсер какого-нибудь сетевого протокола, который поверх TCP/IP. Допустим Http. Тут не будет добавляться новых состояний с одной стороны, с другой - логика будет в одном месте, а не размазана по куче классов. Да, я понимаю, что в случаях когда мы переходим на уровень выше - лучше использовать что-то типа того что в видео, но прозвучала мысль, про то что нам нужно всегда так делать, я вот с этим не совсем согласен. Да и майки, судя по тому как у них парсер того же Http реализован - тоже. В остальном - хорошее видео. Я бы советовал его тем, кто только знакомится с паттернами.
@@gaitavr1992 Кхм. Я могу быть не прав, нам лексический анализ на втором курсе давали, но классический парсер - это стейтмашина, которая получает на вход последовательность лексем, затем - обрабатывает их и в зависимости от правил грамматики - позволяет построить структуру, либо завершиться ошибкой. Банально: Text - мы получили вот такую вот строку, лексер разбил это на: [начало открывающего тега, текст, конец тега, текст, начало закрывающего тега, текст, конец тега], парсер, который должен построить DOM-дерево - должен иметь состояния, чтобы в зависимости от него - понимать - должны ли мы создать ноду, должны ли мы в метаданные документа что-то добавить или вообще кинуть ошибку. Как без состояний этот парсер-то должен работать?
@@gaitavr1992 Я вроде не говорил о противоречиях, просто отметил, что не для каждой стейтмашины нужно пользоваться паттерном состояние (банально стейтмашину в 100 строк, лично я бы не стал резать на несколько классов, особенно, если она - является чем-то классическим и не предполагает изменений). Ну да ладно. Я же вроде сказал, что видео - хорошее и новичкам полезно будет.
Отлично рассказано, но не до конца понятен дефолтный вариант перехода состояний. Условно говоря я должен в каждом стейте в GoToNextState забить все условия на основе которых он перескочит в то или иное состояние? До кучи к этому надо будет создать следующий стейт и как-то его вернуть в контекст?
@@gaitavr1992 вроде как да. Но я и тему со switch state не очень понял. Типа туда передается дженерик, это вроде понятно. Но где происходит сам контроль и решение по переключению.
Здравствуйте, Максим. Отличное видео, спасибо. Не знаете ли Вы реальных проектов с хорошим открытым исходным кодом и, в частности, с реализацией паттерна состояние? Проекты любой тематики, не обязательно игры и юнити. Хотелось бы увидеть на практике использование данного паттерна, так как остались некоторые вопросы по реализации. Например, как вызывать общие функции в классе-контексте из классов-состояний не нарушая инкапсуляцию, оставляя внутренние методы приватными для внешнего кода, но открытыми для классов-состояний.
@@gaitavr1992 Спасибо, буду ждать ревью. Вы очень доходчиво и понятно объясняете, хотелось бы увидеть видео о паттерне посетитель, visitor. Сколько о нем не читал, так до конца и не понял, когда его нужно использовать.
Либо я как-то просмотрел, либо это надо учесть: не хватает примеров клиентского кода по работе с стейт машиной, чтобы логическая завершенность что ли была, и понятно было до конца, куда мы приехали
У меня возник вопрос как передавать вечно изменяющиеся параметры, например трансформ врага если кидать его в конструктор будет ошибка, а если в апдейт будет ли это рационального? Если заметили и ничего не поняли отпишитесь я лучше опишу вопрос
А что делать если метод остался пустым? К примеру если у меня не было бы поля Text то можно ли было оставить методы в некоторых состояниях пустыми? Спасибо.
Привет! При использовании паттерна возникают неудобства, когда состояние нуждается в редактировании закрытых (приватных) членов контекста. Примером может служить состояние персонажа: В состоянии "Жив" персонаж может получать урон и как следствие поле его текущего здоровья меняется. Однако это поле не должно быть доступно изменению из вне никому, кроме класса состояния "Жив". Есть ли совет по решению этих проблем? Я нахожу 2 решения, где первое заключается в открытии полей для редактирования из вне (что является жутким костылем), а второе в использовании unsafe кода и указателей.
@@gaitavr1992 Хорошо, посмотрим что можно сделать:) Мог бы ты как-нибудь рассказать об unsafe коде и указателях? Как движок реагирует на изменение значений в памяти и т.п. По-моему очень интересная тема и много подводных камней. Было бы интересно услышать мнение эксперта.
@@gaitavr1992 Спасибо за это видео, первое настолько полное и грамотное объяснение FSM, которое я встречал. Хочу узнать твое мнение: Тоже оочень долго думал над лучшей реализацией этого паттерна и вот к чему сейчас пришел: 1. Класс контекст НЕ должен реализовывать интерфейсы, как IStateSwitcher, это нарушает инкапсуляцию, тк любой вызывающий код может привести его и изменить состояние. Вместо этого делаем класс StateSwitcher, который хранит в себе логику смены состояний и само состояние. Класс StateSwitcher находится внутри класса-контекст. Вот примерный интерфейс класса StateSwitcher: void SwitchState() {//logic...} where ConcreteStateT : AbstractStateT AbstractStateT CurrentState => _currentState; 2. Классы-состояния следует делать приватными и внутренними к классу-контексту, а в их конструктор стоит передавать класс-контекст. Пример класса-состояния: pastebin.com/J5wbGrh1 Из плюсов: больше инкапсуляции = больше безопасности использования. Из минусов: Классы-состояния больше нигде нельзя использовать, кроме как в классе контексте, в котором они содержатся.
А вот может кто-то ответит на такой, возможно нубский, вопрос? Все, что я о паттернах нахожу, даже на примере юнити, все красиво и понятно, но не пивязано к монобихевиорам. к чему я это. когда описывают какую-то вещь вроде наследования сущностей от какой-то общей болванки( человек: солдат, медик, гражданский) и красиво юзают всевозможные полиморфные штуки, то как эти иерархии привязываются к геймобжектам, олицетворяющим те сущности? У Сакутина видел визитер, где результат рейкастхита обрабатывался логикой визитера, но иерархия хитов полностью отвязана от игры. тут то я и сдулся. +-есть понимание применения тех или иных штук, но в разрезе юнити туплю. хелп)
За такую диаграмму классов меня бы выебали, если честно. Лучше держись стандарта uml. Хорошо сделанная диаграмма более информативна чем окна с кодом, которые в экран не влазят.
а при чем тут Unity в названии роликов ? каждый раз смотрю , надеясь что покажут наконец понятно для новичков. а тут движком и не пахнет. я вот опять нихрена с такой подачей не понял! хотя как раз для новичков это сложная для понимания вещь. показал бы куда какие скрипты накидываешь и как процесс самой организации паттерна происходит.
Не сочти за грубость, но ты не от Романа Сакутина? Он недавно подкинул каналу подписчиков, однако мне всегда казалось, что его канал больше про хейт и хайп, чем про разработку. Если же по существу, то открой список видео на канале. Особенно пошаговый разбор создания товердефенс. Там как раз рассказывается, что и куда нужно "накидывать". А канал у Максима архиполезный. Немного оффтопа. Хочешь контент совсем для новичков - сходи на какой-нибудь Игрострой, посмотри на подачу и код местного автора-неадеквата. Там всё очень понятно для новичков, но проблема в том, что взрослый мужик пишет код как школьник, а любые комменты с критикой кода трет. При чем критика не вида "твой код говно", а вполне себе листинги с кодом.
@@andrey_aka_skif я не сказал, что канал плохой(иначе не был бы подписчиком), я лишь прошу более расширенной подачи материала. Паттерны просто в сишарп и в движке немного разные вещи. Начальные знания по языку есть. Вот и прошу автора чуть шире все показывать. Игростой уже давно в прошлом. Как раз и смотрю более продвинутые каналы уже.и не забывай о том, что то, что уже понятно тебе, не совсем понятно другим. Как раз архитектура слабое место у меня
@@tomasgammister5776 , реально, повтори товердефенс. Я как раз в процессе. Это архи крутой материал. Придётся, конечно, параллельно ликвидировать пробелы в знаниях, но это как раз материал степ бай степ.
@@tomasgammister5776 кстати, не на столько они и разные. Некоторые наоборот считают, что упор на монобихевиер это зло и самое слабое место юнити. Делают разного рода контроллеры, которые задействуют один-два монобеха в сцене, реализуя подобие ecs. Это конечно жуткий велосипед, но его использование имеет некоторые архитектурные причины. Как пример можно привести событийную модель (хоть это немного и про другое). Можно юзать юнитиэвенты, а можно и шарповые делегаты. Короче, не надо привязываться к монобеху как к единственному способу накинуть объекту логики. В том же товердефенсе фабрика реализована через скриптаблобжект, что позволяет сериализировать ссылки на объекты вне сцены (и наоборот, не даёт сохранить ссылки на объекты сцены).
Как всегда, все на высшем уровне! Устроился в геймдев и теперь стабильно использую твои ролики для работы) Продолжай том же духе! Спасибо большое за твой труд, такого качественного контента на рускоязычном сегменте крайне мало!
Какие ролики помогают?
@@gaitavr1992 рефакторинг
@@gaitavr1992 По началу базовые были самые просматриваемые такие как: атрибуты, расширения, делегаты и т.п. Сейчас уже паттерны, так как грамотно подобрать архитектуру при разработке это чертовски важно. Правда из-за разницы в уровнях, приходится ролик продолжительностью минут в 10 пересматривать раз за разом, но я думаю это уже временные издержки)
Главное столкнуться на практике с проблемой, чтобы понимать решение с помощью паттерна
@@gaitavr1992 Получается все топорно, но верно. При рефакторинге уже идет понимание))
Вроде как круто, но в тоже время довольно тяжко воспринимать. Я этот паттерн вдоль и поперёк знаю, но местами было трудно следить за видео. Есть ощущения что видос больше для тех, кто уже знаком с этим паттерном.
Это кста не упрёк, просто чтобы автор лучше понимал, для какой аудитории делает видева.
Спасибо за полезный контент.
Все верно, цель канала - подхватывать тех, кто уже стал на эту дорогу
@@gaitavr1992 , может в качестве улучшения юзер френдли вашего канала зальете на гитхаб и ссылку в описание?
@@startup_tv_k по паттернам нечего заливать, это выдуманный код
@@gaitavr1992 макс, посоветуй пожалуйста Musthave статьи или книги по паттернам, да и вообще по unity
@@gaitavr1992 Ну все понимают, что выдуманный, но всё же, было бы проще и привычнее полазить по файликам на гите, чем перематывать по 100 раз видео)
p.s. Такого информативного контента на ютубе почти нет, а тут ещё и на русском) Спасибо
Как всегда прекрасно, Максим Паттернов))
Как раз делал систему передвижения для игрока через if/else, если стоим на земле или плывём по воде и т.п. После ролика понял, что это все можно вынести в состояние и получить более удобную и гибкую систему.
Конечно, чтобы вынести все зависимости из контекста, пришлось поломать голову, но оно того стоит. Спасибо за добротный контент)
Надеюсь перенос пройдёт гладко) не всегда так получается
Очень рад, что наткнулся на этот канал!
Большое спасибо, а то я оказывается использовал стратегию для смены состояний
Всё очень прекрасно. По поводу создания дополнительных класса Transition - тут же контролируется и в какие State может перейти объект. И логика будет в них. Выглядит очень удобно.
Ещё бы хотелось увидеть видос на тему специфики юнити при программировании. Как конфликтует система компонентов юнити и ООП. Как это влияет на архитектуру юнити приложения. Как решать проблемы с пробрасыванием зависимостей. Нужны ли архитектурные паттерны в юнити (mvp, mvc и т.д). Ну и ECS как архитектурное решение в ту же кучу.
Присоединяюсь к вопросу по MVP. Впечатление такое, что всем оно нужно, но никто не может объяснить, зачем.
Очень доходчиво и понятно!
Спасибо, было очень полезно!
Отличный видос! Очень нужный паттерн
Очень интересно и понятно объясняете, спасибо!!!
Максим, когда осенью готовился к своим занятиям -нигде не нашел норм видосов по шаблонам именно в Юнити. Шикарные уроки!! Людям это нужно
Ух , никогда не учил паттерны, но и процедурным кодом , тоже уже не пишу.Оказывается всё уже придумали и додумали за меня и нужно просто найти паттерн для то или иной ситуации... Немного разочаровывающие умозаключение . Столько времени было потрачено на придумывание систем , если бы я сразу учил эти поведения ....Спасибо большое за урок жду новых паттернов ! )
Очень часто паттерн не помогает и приходится его нарушать
@@gaitavr1992 Но знания о паттернах экономят немало времени , даже если приходиться нарушать их конструкцию, это всё равно быстрее, чем придумывать логику с чистого листа.
Согласен
Пожелание: разбить ролик на части (сделать закладки), вступление, основная часть и заключение, плюс в основную часть добавить закладки на примеры кода и основные моменты. Многим сдесь будет удобно искать примеры кода в будущем. Второе: фон за теукстом размывать и сделать максимально контрасным фон и текст и НЕ использовать эффекты текстов и т.д. Посоветовал бы сделать один раз шаблон и им пользоваться. А так все отлично. Спасибо за ролик.
Шикарно, благодарю Максим)
Спасибо, за ролик! Всё рассказано понятно, размеренно. Буду применять. А то хоть я и разбил код на вьюшки, модели и контроллеры, а мешанины все равно много получается.
Класс Transition еще глобальным для всех стейтов может быть, к примеру для разновидностей ботов
Если они не сложные
Есть очень хорошая и гибкая реализация этого паттерна на ScriptableObject. Шикарно работает.
Отличное, полезное, познавательное видео
Супер, больше бы таких каналов не за что не забивай на ютуб! Можешь сделать пожалуйста видео, если будет время, как стоит подходить к реализации паттерна состояние или его аналога в случае работы с фреймворком на ECS будь то unity dots или LeoEcs
С ecs проблема, оно сырое, как недоваренные пельмени. Я бы подождал чего-то более стабильногл
@@gaitavr1992 Entitas давно уже допилен, а LeoECS постоянно допиливается и уже используется в продакшене.
То, что я видел - далеко от допиленного
@@gaitavr1992 О буду рад, аргументированной критике. Спасибо заранее.
Я использовал стандартный ECS и там огромная проблема с анимациями. У меня были префабы врагов и я не нашел никакой возможности проигрывать те же анимации(бег, смерть и тд).
Контент огонь. Наверное по паттернам в Unity ничего подобного на рус. ютубе нет
Какая разница в юнити этот патерн или не в юнити
лайк и коммент, автору респект,)
Вместо листа со стейтами используй дикшинари Dictionary() и в
SwitchState() where T : BaseState {
if(!_allStates.TryGetValue(typeof(T), out _currentState) {
//обработать ошибку если стейт не найден.
}
}
считаю этот паттерн обязательным для изучения/использования, у меня просто 2 примера игр над которыми я работал в одном и том же жанре с разницей почти 5 лет, в котором можно улучшать разные постройки, хоть и в большинстве случаев улучшение постройки не меняло ее механик, но были такие что совмещали в себе разные механики, это был ад с кучей наследований чтоб сделать нужные механики для одного юнита тратилось до нескольких дней работы, щас сделав все на стейтах, такой юнит может сделать даже геймдизайнер, просто добавив или убрав пару строчек в json файл
Или через scriptable objects, как insane one показывал
ECS
То что нужно.
Твои видео как самородки в русскоязычной части ютуба
не только в русскоязычной
огонь, всё супер чётко, спасибо
(☞ﾟヮﾟ)☞
хорошие видео ,хотя и не много трудно уловить смысл , если ты не синьер, из за огромного количества профессиональных терминов, очень полезно и интерсно
Этот паттерн должен знать даже джуниор-мидл
спасибо!
Добрый день, Максим. Мне Очень нравятся ваши ролики и подход преподавания. Есть ли у вас курсы по паттернам? Если нет, то могу посоветовать какого рода курсы бы приглянулись изучающим данную тему. Пример "Проект в юнити с использованием паттерна проектирования". Можно на udemy залить или как вам угодно.
Для зрителя - Ставь лайк комменту, если хочешь такой курс.
Превьюха сочная)
Спасибо
Дякую
Спасибо
а state и state machine это одно и тоже или это разные вещи? А ещё можно попросить вас выкладывать код, хотелось бы пощупать его что бы лучше понять.
Одно и тоже. По паттернам нет смысла код выкладывать, так как он выдуманный
@@gaitavr1992, подскажите пожалуйста, в репозитории по товердефенс есть коммиты по урокам? Или только текущий проект? Сейчас повторяю пошагово Ваш проект и иногда по невнимательности что-то пропускаю, а потом не могу понять, где накосячил. Также подвопрос. Исходный проект с игрой это переработка статьи с Catlike Coding?
Недавно начал делать ветки под каждый урок и вливать их одним коммитом для удобства. По поводу cat like coding, да, я взял основу и пошел дальше
хорош
Как грамотно сделать таймер в BrokenState? Мы же не можем использовать корутину прямо в BrokenState, так как выдаст NullReferenceException из-за того что мы экземпляры делали через new. Я нашел на форумах что нужно использовать AddComponent. Я чувствую что есть элегантное решение, но я ,в силу малого опыта, не вижу.
Спасибо. А как смену анимации вплести в данную реализацию паттерна? Пытаюсь реализовать состояние NPC, все вроде понятно и работает, но не пойму, как подключать разные анимации (атака, погоня, патрулирование) при таком подходе. Примеры переключения анимаций в ютубе все с наследованием от StateMachineBehavior, но как-то интуитивно не хочется его использовать.
Ну и да, я бы все равно не говорил, что это то как всегда нужно делать стейтмашину. Вот допустим банальный парсер какого-нибудь сетевого протокола, который поверх TCP/IP. Допустим Http. Тут не будет добавляться новых состояний с одной стороны, с другой - логика будет в одном месте, а не размазана по куче классов.
Да, я понимаю, что в случаях когда мы переходим на уровень выше - лучше использовать что-то типа того что в видео, но прозвучала мысль, про то что нам нужно всегда так делать, я вот с этим не совсем согласен. Да и майки, судя по тому как у них парсер того же Http реализован - тоже.
В остальном - хорошее видео. Я бы советовал его тем, кто только знакомится с паттернами.
Не совсем понял при чем парсер к стейт машине? Если несколько степов то это цепочка обязанностей
@@gaitavr1992
Кхм. Я могу быть не прав, нам лексический анализ на втором курсе давали, но классический парсер - это стейтмашина, которая получает на вход последовательность лексем, затем - обрабатывает их и в зависимости от правил грамматики - позволяет построить структуру, либо завершиться ошибкой.
Банально: Text - мы получили вот такую вот строку, лексер разбил это на: [начало открывающего тега, текст, конец тега, текст, начало закрывающего тега, текст, конец тега], парсер, который должен построить DOM-дерево - должен иметь состояния, чтобы в зависимости от него - понимать - должны ли мы создать ноду, должны ли мы в метаданные документа что-то добавить или вообще кинуть ошибку. Как без состояний этот парсер-то должен работать?
Теперь понял, так а где противоречие в видео?
@@gaitavr1992 Я вроде не говорил о противоречиях, просто отметил, что не для каждой стейтмашины нужно пользоваться паттерном состояние (банально стейтмашину в 100 строк, лично я бы не стал резать на несколько классов, особенно, если она - является чем-то классическим и не предполагает изменений).
Ну да ладно. Я же вроде сказал, что видео - хорошее и новичкам полезно будет.
Отлично рассказано, но не до конца понятен дефолтный вариант перехода состояний. Условно говоря я должен в каждом стейте в GoToNextState забить все условия на основе которых он перескочит в то или иное состояние? До кучи к этому надо будет создать следующий стейт и как-то его вернуть в контекст?
Речь идет о втором варианте, где контекст сам решает когда переключать?
@@gaitavr1992 вроде как да. Но я и тему со switch state не очень понял. Типа туда передается дженерик, это вроде понятно. Но где происходит сам контроль и решение по переключению.
Так где дженерик был, состояния сами выбирают следующее. В второй вариант, когда состояния идут друг за другом и контекст по очереди их выполняет
@@gaitavr1992 А, во втором варианте в старте очередь задается, и они просто подряд выполняются. Примерно дошло, надо на практике попробовать.
Здравствуйте, Максим. Отличное видео, спасибо. Не знаете ли Вы реальных проектов с хорошим открытым исходным кодом и, в частности, с реализацией паттерна состояние? Проекты любой тематики, не обязательно игры и юнити. Хотелось бы увидеть на практике использование данного паттерна, так как остались некоторые вопросы по реализации. Например, как вызывать общие функции в классе-контексте из классов-состояний не нарушая инкапсуляцию, оставляя внутренние методы приватными для внешнего кода, но открытыми для классов-состояний.
Мне недавно на ревью стейт машину скинули, сделаю обзор. А по поводу контекста - выносить в интерфейс явно и работать с ним внутри состояний
@@gaitavr1992 Спасибо, буду ждать ревью. Вы очень доходчиво и понятно объясняете, хотелось бы увидеть видео о паттерне посетитель, visitor. Сколько о нем не читал, так до конца и не понял, когда его нужно использовать.
Он один из самых сложных
Либо я как-то просмотрел, либо это надо учесть: не хватает примеров клиентского кода по работе с стейт машиной, чтобы логическая завершенность что ли была, и понятно было до конца, куда мы приехали
Получается что Animator и есть пример машины состояний. Если я правильно понял. Дякую. Мирного неба.
Что за класс SliderFiller, не нахожу. Да и компонента такого.
У меня возник вопрос как передавать вечно изменяющиеся параметры, например трансформ врага если кидать его в конструктор будет ошибка, а если в апдейт будет ли это рационального? Если заметили и ничего не поняли отпишитесь я лучше опишу вопрос
Враг должен сам работать со своим трансформом
@@gaitavr1992 а как тогда реализовать состояние патрулирования? Если только враг может работать с трансформом?
Врагу задаются точки и он ходит. Если вопрос про сам класс состояния, то можно вынести метод move у врага и состояние будет использовать его
@@gaitavr1992 то есть нужно будет просто вынести движение, а не сам класс с состоянием патрулирования?
Состояние патрулирования будет управлять логикой перемещения, а функционал предоставится внутри врага
А что делать если метод остался пустым? К примеру если у меня не было бы поля Text то можно ли было оставить методы в некоторых состояниях пустыми? Спасибо.
А можно разбор нового input system?
Я еще не пользовался
Привет! При использовании паттерна возникают неудобства, когда состояние нуждается в редактировании закрытых (приватных) членов контекста. Примером может служить состояние персонажа:
В состоянии "Жив" персонаж может получать урон и как следствие поле его текущего здоровья меняется. Однако это поле не должно быть доступно изменению из вне никому, кроме класса состояния "Жив". Есть ли совет по решению этих проблем? Я нахожу 2 решения, где первое заключается в открытии полей для редактирования из вне (что является жутким костылем), а второе в использовании unsafe кода и указателей.
Либо выделять модель состояния и модифицировать ее либо через интерфейс работать с контекстом. Никакие указателей)
@@gaitavr1992 Хорошо, посмотрим что можно сделать:) Мог бы ты как-нибудь рассказать об unsafe коде и указателях? Как движок реагирует на изменение значений в памяти и т.п. По-моему очень интересная тема и много подводных камней.
Было бы интересно услышать мнение эксперта.
Я как нибудь попробую, но эта тема для меня не очень изведанная. Многое уже забылось, а многое и не встречал
@@gaitavr1992 Спасибо за это видео, первое настолько полное и грамотное объяснение FSM, которое я встречал. Хочу узнать твое мнение:
Тоже оочень долго думал над лучшей реализацией этого паттерна и вот к чему сейчас пришел:
1. Класс контекст НЕ должен реализовывать интерфейсы, как IStateSwitcher, это нарушает инкапсуляцию, тк любой вызывающий код может привести его и изменить состояние. Вместо этого делаем класс StateSwitcher, который хранит в себе логику смены состояний и само состояние. Класс StateSwitcher находится внутри класса-контекст.
Вот примерный интерфейс класса StateSwitcher:
void SwitchState() {//logic...} where ConcreteStateT : AbstractStateT
AbstractStateT CurrentState => _currentState;
2. Классы-состояния следует делать приватными и внутренними к классу-контексту, а в их конструктор стоит передавать класс-контекст. Пример класса-состояния:
pastebin.com/J5wbGrh1
Из плюсов: больше инкапсуляции = больше безопасности использования.
Из минусов: Классы-состояния больше нигде нельзя использовать, кроме как в классе контексте, в котором они содержатся.
В реальном проекте этого сложно добиться, когда все разрастается.
Запускать стейт машину как корутину - норм практика ведь?
А вот может кто-то ответит на такой, возможно нубский, вопрос? Все, что я о паттернах нахожу, даже на примере юнити, все красиво и понятно, но не пивязано к монобихевиорам. к чему я это. когда описывают какую-то вещь вроде наследования сущностей от какой-то общей болванки( человек: солдат, медик, гражданский) и красиво юзают всевозможные полиморфные штуки, то как эти иерархии привязываются к геймобжектам, олицетворяющим те сущности? У Сакутина видел визитер, где результат рейкастхита обрабатывался логикой визитера, но иерархия хитов полностью отвязана от игры. тут то я и сдулся. +-есть понимание применения тех или иных штук, но в разрезе юнити туплю. хелп)
Монобехи точно также могут учавствовать в этом параде паттернов, если нужно. Это тоже классы
Можете пояснить, что подразумевается под контекстом?
Класс из которого выносится логика в состояния, для остального кода с ним точно также можно работать
@@gaitavr1992 то-есть контекст - это класс из которого мы вынесли логику в состояния?
Да
@@gaitavr1992 Значит я правильно все понял, спасибо большое. Ролики класс
А что делать с методом SwitchState? Он ведь публичный получается
Явно интерфейс указать, тогда остальной код не будет о нем знать
@@gaitavr1992 спасибо. Буду применять
За такую диаграмму классов меня бы выебали, если честно. Лучше держись стандарта uml. Хорошо сделанная диаграмма более информативна чем окна с кодом, которые в экран не влазят.
Ох, как сложно, но как хочется понять это всё. Напрягаемсяяяя ыыыыыыыыыыыыыыыыыыыыыыыы
Код на гитхаб плиз
а при чем тут Unity в названии роликов ? каждый раз смотрю , надеясь что покажут наконец понятно для новичков. а тут движком и не пахнет. я вот опять нихрена с такой подачей не понял! хотя как раз для новичков это сложная для понимания вещь. показал бы куда какие скрипты накидываешь и как процесс самой организации паттерна происходит.
А что тут сложного, берешь и применяешь. А если новичок, то иди учиться.
Не сочти за грубость, но ты не от Романа Сакутина? Он недавно подкинул каналу подписчиков, однако мне всегда казалось, что его канал больше про хейт и хайп, чем про разработку. Если же по существу, то открой список видео на канале. Особенно пошаговый разбор создания товердефенс. Там как раз рассказывается, что и куда нужно "накидывать". А канал у Максима архиполезный.
Немного оффтопа. Хочешь контент совсем для новичков - сходи на какой-нибудь Игрострой, посмотри на подачу и код местного автора-неадеквата. Там всё очень понятно для новичков, но проблема в том, что взрослый мужик пишет код как школьник, а любые комменты с критикой кода трет. При чем критика не вида "твой код говно", а вполне себе листинги с кодом.
@@andrey_aka_skif я не сказал, что канал плохой(иначе не был бы подписчиком), я лишь прошу более расширенной подачи материала. Паттерны просто в сишарп и в движке немного разные вещи. Начальные знания по языку есть. Вот и прошу автора чуть шире все показывать. Игростой уже давно в прошлом. Как раз и смотрю более продвинутые каналы уже.и не забывай о том, что то, что уже понятно тебе, не совсем понятно другим. Как раз архитектура слабое место у меня
@@tomasgammister5776 , реально, повтори товердефенс. Я как раз в процессе. Это архи крутой материал. Придётся, конечно, параллельно ликвидировать пробелы в знаниях, но это как раз материал степ бай степ.
@@tomasgammister5776 кстати, не на столько они и разные. Некоторые наоборот считают, что упор на монобихевиер это зло и самое слабое место юнити. Делают разного рода контроллеры, которые задействуют один-два монобеха в сцене, реализуя подобие ecs. Это конечно жуткий велосипед, но его использование имеет некоторые архитектурные причины. Как пример можно привести событийную модель (хоть это немного и про другое). Можно юзать юнитиэвенты, а можно и шарповые делегаты. Короче, не надо привязываться к монобеху как к единственному способу накинуть объекту логики. В том же товердефенсе фабрика реализована через скриптаблобжект, что позволяет сериализировать ссылки на объекты вне сцены (и наоборот, не даёт сохранить ссылки на объекты сцены).
Спасибо.