Паттерн State, паттерн состояние, Unity C#
Vložit
- čas přidán 25. 07. 2024
- Новый видосик по паттерну State
Ссылка на гитхаб на проект
github.com/Haywaar/ShawarmaFight - проект с шаурмой
github.com/Haywaar/PatternDem... - пример с башнями
Лежит по пути Assets/Patterns/State/GoodExample
Автору на кофе и шаурму
4276 5500 5792 8742 - карта Сбербанка
Если будут вопросы
мой тг @wargy
моя почта kazancev.s215@gmail.com
Тайминги:
00:00 Введение
00:26 Определение
01:08 Пример из жизни
02:40 UML-схема
04:05 Паттерн State и конечные автоматы
05:09 Практический пример, башни TD - введение
06:02 Практический пример - плохое решение через switch-case
07:28 Практический пример - хорошее решение через State
08:45 Где использовать паттерн State в геймдеве?
09:38 Паттерн State в проекте ShawarmaFight
11:05 State vs Strategy
12:55 Финал - Hry
Каждое видео автора смотрю с широко раскрытыми глазами и ушами 😁 В плане объяснения архитектурных приемов автор - просто лучший! Нигде не видел, чтобы кто-то мог объяснять подобные темы настолько просто и наглядно. Я уже не один раз применял знания, полученные с этого канала, в своих проектиках 👍 Моё огромное спасибо автору, не был бы я нищебродом - обязательно бы задонатил.
Очень доходчиво объясняете, спасибо.
Про паттерны у вас лучшее объяснение, надеюсь данная тема будет у вас продолжаться, хотелось бы про структурные паттерны.
Желаю успехов каналу!
p.s. Надеюсь с тапком все ок))
Спасибо за тёплые слова) Тапок в порядке :D
Спасибо, за твои уроки, очень понятно и интересно.
Молодец!! Самое лучшее объяснение паттерна state на ютубе
Спасибо большое за лаконичное объяснение паттерна, очень полезно! На смузи закинул)
Душевно благодарю) получил)
Спасибо за видео, увидел немного другую реализацию этого патерна (я делал переключение не энамах, а на словаре с типами). Постоянно юзаю этот паттерн в самой основе архитектуры игры (BootstrapState, LocationLoadState, ActiveGameState, PauseState итд). В любом случае спасибо, автор молодец!
Стейт машина, по моему скромному, должна учится применяться начинающим джунам как можно скорее, потому что меня удивляет, как человек годами может решать задачи путём создания 5 булок, вместо лаконичного и давно известного решения
По различиям стратегии и стейта, считаю что стейт подходит для описания поведения одной цельной и неразрывной сущности, а стратегия - для описания изменчивого аспекта какой-то сущности, или семейтсво алгоритмов
Писал я как-то раз условный скролер, где использовал стейт машину для описания состояний оружия - стрельба, перезарядка, простой, заклинило и тп.
А для реализации логики стрельбы использовал стретегию. Соответственно при подборе какого бонуса, допустим тройного выстрела, я просто менял реализации стрельбы с одной на другую прям на ходу. Вышло довольно занятно
Ну и как всегда спасибо за контент!
и шо много заработал?
Спасибо! Коммент для продвижения)
Cool)
Новое видео)
Канал обалденный, все видосы посмотрел. Обязательно продолжай! Можешь ли посоветовать какие-то материалы почитать для углубления знаний по архитектуре проекта? Как правильно делать и т.д.
могу посоветовать видео Евгения Дубовика czcams.com/video/7kkw-WwoPBs/video.html
но в целом ожидать готовых шаблонов которые можно быстро впитать и начать клепать не стоит
есть так же тг канал по архитектуре, его держат очень умные дяди, очень советую t.me/unity_architecture
@@sergeykazantsev1655 Спасибо большое! В группу вступил, буду ждать новых роликов. Успехов!
Не посмотрел, но видос крутой
а как ты это понял? :D
+REP за сравнения State и Strategy. На собесах спрашиваюь (мидл). От себя добавлю: не использовать синдикатовскую машину - циклическая зависимость.
А что такое синдикатовская машина? Оо
@@sergeykazantsev1655 K-syndicate. Чуваки сформулировали архитектуру и создали свой DI. Работяги при переписывании архитектуры на Zenject сталкиваются с циклическими зависимостями. Да и я сам так делал... и на VContainer пытался их машину написать...
@@sergeykazantsev1655 Думаю он про K-Syndicate
Понятно, надо будет посмотреть чего они там наворотили)
А какую тему в VS Code используете? И может дадите какие-то советы/рекомендации по настройке VS Code для Unity?
Я установил несколько плагинов для более удобной разработки. Ничего волшебного и сверх крутого - просто автоподставка текста, цветовая тема из райдера, хоткеи из Visual Studio.
Если интересно - можете написать мне в тг, я скину вам профиль в VS Code, если вы его загрузите у вас будет то же самое)
@@sergeykazantsev1655 Почему вы перешли на VSCode с Райдера (просто всегда видел, как наоборот, на Райдер перехдят). И как VSCode в плане удобства в сравнении с ним?
Райдер лучше, но VS Code бесплатный :D
Классный ролик как всегда.
Но есть несколько вопросов =) :
1. Зачем вообще разные методы, если у нас будет расширяться функционал, то мы будем вносить изменения в каждый класс, что нарушает OCP??? Ведь в состояние можно зайти и выйти + постоянное обновление состояния. Следовательно всего 3 метода в базовом классе (Enter, Exit, Tick(float delta)). Если ещё дженериковые стейты сделать, то вообще будет песня, типа State. И добавить класс FSM у которого есть словарь Dictionary , текущее состояние , сетер стейта, методы добавления/ получения текущего и обновление текущего стейта.
Если не брать в расчёт первый вопрос и продолжить смотреть текущий вариант, то другой вопрос.
2. Почему все абстрактные методы? ведь это обязывает реализовать метод, а как видели в видео там есть состояния у которых нет реализации, возможно стоит делать виртуальными чтобы не засорять класс-наследник?
1. С моей точки зрения, OCP не запрещает нам вносить изменения в класс. OCP запрещает нам изменять старую логику при модификации, а новая логика в существующем классе - это не изменение а то самое расширение. Если понимать OCP дословно, то тогда на каждый чих нужно будет наследоваться от написанного класса и это будет очень больно и трудно
2. Потому что по хорошему надо так организовать абстракцию чтобы любое состояние как-то выполняло тот или иной метод, и не было пустых. Туда например можно воткнуть Error-ы и информацию о том что починить активную башню невозможно. В конкретном примере да, можно сказать что нарушается LSP и ISP, но виртуальные методы мне кажется всё же мешают ясности и пониманию как то или иное состояние реагирует на тот или иной метод
@@sergeykazantsev1655 1. По текущему примеру.
Нужно добавить Поиск врага/ в процессе строительства/починки/ атака врага / оборона - всё это придётся вносить в каждый стейт, а оно нужно ли каждому стейту?
А есть уже 20 состояний, придёт ГД и такой давай сделаем чтобы башня при здоровье меньше 10 % усиливала дамаг и издавала спасательные звуки и придётся в 21 классе что-то писать, вместо того чтобы создать 1 класс нового состояния и когда здоровье меньше 10% просто сказать эй башня го в состояние такое-то = )
2. При абстрактном классе с пустым виртуальным методом ничего не сломается при вызове метода базового класса, следовательно если в наследнике будет или нет конкретная реализация то она корректно отработает в любом случае. Лучше в абстрактном классе оставить пустой виртуальный метод, чем прописывать эесепшены или возвращать null/default в каждом наследнике.
1. Поиск врага не требует, чтобы его по разному реализовали разные состояния, я бы для поиска и стрельбы либо сделал бы флаг CanAttack либо вообще стрелял только если бы state = active
То же самое касается усиленного урона, поведение урона башни не зависит от состояния, он зависит от хп, потому той проблемы что вы написали не будет)
2. С вашими аргументами согласен, но как и писал ранее, в идеале абстракция должна быть такой чтобы ни виртуальных методов, ни return null ни эксепшнов не было) но это в идеале
@@sergeykazantsev1655 это геймдев, идеальных проектировок не будет =) постоянно что-то меняется
А почему нельзя то, что реализовано в отдельных классах, запихать в методы и переключать их присваивая делегату определенный метод? Тогда прийдется дописывать еще методы для перехода состояний, получается у состояния есть дополнительно логика для его включения и выключения?
Ну там может быть слишком много логики, чтобы в методы запихивать. В той же игре про шаурму - представьте ход врага и игрока в методы запихивать - повеситься можно)
Несколько раз пересмотрел и понял что я про стратегию подумал.
бывает)
Паттерн Состояние больше похож на паттерн Команда, чем на Стратегию, имхо)
А в чём, по вашему, схожесть команды и состояния?)
@@sergeykazantsev1655 По назначению, конечно, абсолютно разные) Но, с точки зрения структуры очень даже похожи.
За каждое состояние отвечает отдельный класс, также и для каждой команды выделяется собственный класс
В классе контекста переключатель состояния выглядит вроде "SetState(new Idle(args))", и аналогично команда выглядит "Send(new InitCommand(args))".
ну в этом да, полиморфизм во всей его красоте)
Зачем хранить состояние в словаре? Почему не использовать статический класс? Синглтон это слишком)
Не состояние в словаре, а пул всех созданных состояний. Условно если у нас 5 состояний и если мы между ними переключаемся, лучше их сохранить в коллекции, а не пересоздавать заново каждый раз.
@@sergeykazantsev1655 А статика не пойдет - потому что экземпляров обьектов может быть много, и тогда все состояния будую для всез одинаковы, понял.
Спасибо за работу. Доставляет.
Вопрос более общего плана. Как научиться уметь в архитектуру?
Просто есть уровень условного Brackeys, когда главное заставить чтоб оно заработало, и пофиг что там внутри.
И есть уровень когда все уже трут за чистую архитектуру, шаблон инжект и прочий космос.
Может кто подскажет дорогу, как попасть на второй уровень? Отдельно по запчастям слушаешь, смотришь -все понятно. А откроешь любой проект с гитхаба с примером игрушки построеной по шаблонам, архитектуре и т.д. - и капец. Куда смотреть, как понимать, что за кого отвечает и зачем вообще нужно?
Непонятно, одним словом
По архитектуре мое мнение что все упирается в опыт, и чтобы уметь в архитектуру, либо тебе этот опыт кто-то должен передать (лид, ментор) который будет смотреть ваш код, бить по рукам, и объяснять почему так, либо этот опыт надо получить самому.
Во втором случае вы пишете игру и в какой то момент понимаете что дальше расширять игру очень сложно и неудобно. В этот момент вы пытаетесь понять почему это произошло, возвращаетесь к теории и понимаете о чем писалось в книжках и про что эти ваши паттерны и SOLID.
К счастью или сожалению, архитектуры не стандартизированы, потому тут нет четких шаблонов как в тех же паттернах, все пишут что-то свое но делиться не спешат ибо часто это корпоративная тайна) я так думаю, мне так кажется
Спасибо за ответ
А случаем нет волшебного пенделя в виде книги, тутора(eng, ru) с более широким пояснением на конкретной задаче, игре. Почему тут так, а туда лучше пока совсем не надо и т.д.
И по типу, чтоб начать - пойдем отсюда, потому что...
Я то понимаю, что пендель на самом деле = практика своей головой и руками.
Но может есть хоть путеводная тропа))
К сожалению, я не смотрел современные курсы по юнити потому не знаю, как там обстоят дела
Есть тг канал по архитектуре в юнити, может обсуждения или прикрепленные ресурсы вам помогут t.me/unity_architecture