Деревья поведения (машина состояний)

Программирование на Юнити.

Деревья поведения (машина состояний)

Сообщение olimpset 25 май 2017, 01:22

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

Re: Деревья поведения (машина состояний)

Сообщение olimpset 25 май 2017, 01:27

Или реализовать нужный функционал (методы) классов. А потом с помощью дерева поведения как бы делать логику ("ИИ") игры, котороя в нужный момент будет вызывать нужный метод нужного класса. Это так работает?
olimpset
UNITрон
 
Сообщения: 327
Зарегистрирован: 22 фев 2014, 15:16

Re: Деревья поведения (машина состояний)

Сообщение samana 25 май 2017, 07:18

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

Всё визуально-наглядное сделано лишь с одной целью - упрощение понимания происходящего внутри. Смотришь на график и сразу видно что куда, откуда и почему. Если связи не очень запутаны, то визуализация и не нужна, но когда всё переплетено, то конечно ориентироваться будет проще визуально. Впрочем можно и на листочке сделать себе схему.
Аватара пользователя
samana
Адепт
 
Сообщения: 4738
Зарегистрирован: 21 фев 2015, 13:00
Откуда: Днепропетровск

Re: Деревья поведения (машина состояний)

Сообщение olimpset 25 май 2017, 20:32

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

Re: Деревья поведения (машина состояний)

Сообщение samana 25 май 2017, 20:47

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

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

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

Я конечно не знаю, как именно вы реализовали этот паттерн, но никаких нарушений инкапсуляции я не замечал. У класса есть состояния (приватные) и публичный метод, который позволяет переключаться между состояниями. Причём можно ведь контролировать - на какие состояния объект "имеет право" переключится.
В том-то и прелесть State, что управление объекта можно менять на ходу, а не писать всевозможные варианты поведения в его скрипте. Ведь если у вас есть "человек", то он имеет право быть в любом состоянии, которое присуще любому человеку, почему бы и нет.
Аватара пользователя
samana
Адепт
 
Сообщения: 4738
Зарегистрирован: 21 фев 2015, 13:00
Откуда: Днепропетровск

Re: Деревья поведения (машина состояний)

Сообщение seaman 25 май 2017, 21:39

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

Re: Деревья поведения (машина состояний)

Сообщение olimpset 25 май 2017, 23:16

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


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

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

Видимо Unity не хочет дружить с ООП.
Вот как быть в такой к примеру ситуации, когда нужен полиформизм и когда нужно этот же класс сериализовать? Хрен там сериализуешь.
olimpset
UNITрон
 
Сообщения: 327
Зарегистрирован: 22 фев 2014, 15:16

Re: Деревья поведения (машина состояний)

Сообщение olimpset 26 май 2017, 09:02

Хотя я понял как обойтись без наследования. Создать monobehaviour класс Unit с общим функционалом. А потом создать различные поведения (классы state). И по сути не нужны классы наследники и полиформизм.
olimpset
UNITрон
 
Сообщения: 327
Зарегистрирован: 22 фев 2014, 15:16


Вернуться в Скрипты

Кто сейчас на конференции

Сейчас этот форум просматривают: нет зарегистрированных пользователей и гости: 9