3D.ru

Изучая эти вещи (машины состояния), понял, что они никакого прнимущества не несут. Я про ассеты с графическим скриптингом дерева поведения, в котором по нужным условиям вызывается нужный метод обьекта. Стоит ли пользоватся графическим построением машины аль нет? Ведь тоже самое можно сделать, создав классы State и т.д, можно даже вообще примитивно сделать, без состояний вообще обойтись. А просто с помощью событий отловить условие и вызвать нужный метод-функцию.
К примеру так: метод обьекта
State1() { (~~~~~~) State2(); }
И никакие паттерны машин состояний не нужны.
Что думаете по этому поводу, поделитесь опытом, кто пользуется машинами состояний?

Или реализовать нужный функционал (методы) классов. А потом с помощью дерева поведения как бы делать логику ("ИИ") игры, котороя в нужный момент будет вызывать нужный метод нужного класса. Это так работает?

olimpset писал(а):Стоит ли пользоватся графическим построением машины аль нет?

Всё визуально-наглядное сделано лишь с одной целью - упрощение понимания происходящего внутри. Смотришь на график и сразу видно что куда, откуда и почему. Если связи не очень запутаны, то визуализация и не нужна, но когда всё переплетено, то конечно ориентироваться будет проще визуально. Впрочем можно и на листочке сделать себе схему.

Как по мне, паттерн State (конечный автомат), нарушает принципы ООП, в частности инкапсуляцию. Ведь по канонам ООП весь функционал (состояния; движение, атака и т.д) должны быть в классе нужного обьекта. И он может ними оперировать. А в этом паттерне каждое состояние выводится в отдельные классы (класс Движение, класс Атака), это как то не правильно. Ведь эти методы должны быть именно в классе, который будет этим пользоваться. Как бы общедоступные методы. Или я это не правильно понимаю?

olimpset писал(а):Ведь по канонам ООП весь функционал (состояния; движение, атака и т.д) должны быть в классе нужного обьекта.

Честно говоря я не сталкивался с таким правилом и даже не согласен с ним. Что же получается, всё теперь писать в одном классе?)

olimpset писал(а):Как по мне, паттерн State (конечный автомат), нарушает принципы ООП, в частности инкапсуляцию.

Я конечно не знаю, как именно вы реализовали этот паттерн, но никаких нарушений инкапсуляции я не замечал. У класса есть состояния (приватные) и публичный метод, который позволяет переключаться между состояниями. Причём можно ведь контролировать - на какие состояния объект "имеет право" переключится.
В том-то и прелесть State, что управление объекта можно менять на ходу, а не писать всевозможные варианты поведения в его скрипте. Ведь если у вас есть "человек", то он имеет право быть в любом состоянии, которое присуще любому человеку, почему бы и нет.

Вся идеология Юнити - некоторое нарушение ООП. Все компонентное программирование.
Вообще чистое ООП - это имхо недостижимый идеал. Вот есть игровой объект. У него может быть а может и не быть миллионы разных свойств и поведений. Вы все это в один класс объекта собираетесь засунуть? И физику (даже если она не нужна?) и спрайты (даже если их в игре в помине нет?).

seaman писал(а):Вся идеология Юнити - некоторое нарушение ООП. Все компонентное программирование.
Вообще чистое ООП - это имхо недостижимый идеал. Вот есть игровой объект. У него может быть а может и не быть миллионы разных свойств и поведений. Вы все это в один класс объекта собираетесь засунуть? И физику (даже если она не нужна?) и спрайты (даже если их в игре в помине нет?).

Я пытался делать на чистом ООП, без наследования от monobehaviour. Если обьект - класс должен заспавиться на сцену, делал так: приват ссылка на обьект на сцене (инстанс), и так им управлял с класса (не monobehaviour), предваительно создав его на сцену. Так как не моно, то на созданом обьекте не висели компоненты, кроме некоторых стандартных. Понял еще, что ООП нельзя сериализовать (классы, которые наследуются не сериализуются). Да, функционал думал делать так: Класс
Unit : non monobehaviour {
private ~~~

Интерфейс (public методы, естественно):
void Move(Vector);
void Attack();
И т.д

Видимо Unity не хочет дружить с ООП.
Вот как быть в такой к примеру ситуации, когда нужен полиформизм и когда нужно этот же класс сериализовать? Хрен там сериализуешь.

Хотя я понял как обойтись без наследования. Создать monobehaviour класс Unit с общим функционалом. А потом создать различные поведения (классы state). И по сути не нужны классы наследники и полиформизм.