Возможно ли использование нескольких параллельных состояний в FSM?

Question

[ned4ded]

Всем добрый день!

Справочно: Пишу небольшой проект (мобильная детская игра) на ангуляре 4, у меня возникла необходимость создания небольшого модуля, который бы позволял отслеживать состояние перетаскивания некоторого элемента интерфейса на определенную область экрана. Звучит как drag'n'drop, но только отличается более высокой сложностью, в связи с чем я реализую этот функционал полностью через js, т.е. без фич html5.

Я бы хотел отслеживать состояние курсора с помощью FSM, но при составлении некоторой абстрактной модели (на бумаге) я постонянно прихожу к тому, что одновременно мне нужно знать 2 состояния: положение курсора на экране и состояние нажатия кнопки мыши.

Читая техн. информацию и рекомендации по написанию кода с помощью fsm, я пришел к выводу, что активное состояние всегда должно быть одно. Но я не совсем понимаю, имеется ли ввиду одно состояния из множества однотипных (например, в моем случае два активных состояния из разных множеств - положение: "курсор на дашборде", нажатие кнопки: "кнопка мыши не нажата"), или одно состояние в целом на курсор (состояние: "курсор на дашборде и кнопка мыши не нажата").

Сделал пока по первому варианту, но не уверен в его верности, т.к. приходится постоянно чекать на наличие двух состояний, что усложняет систему. Правильно ли я понимаю суть концепции или лучше переделать по второму варианту?

PS использую абстракцию для управления fsm + javascript-state-machine package.

Comments

[Евгений Шатунов]

ned4ded

мне нужно знать 2 состояния: положение курсора на экране и состояние нажатия кнопки мыши.

Нужно два состояния, хорошо. Первое вижу (клавиша нажата), а описание второго где? Хотя и первое описание тоже под большим сомнением.

положение: "курсор на дашборде"

Почему это должно быть именно свойством курсора? Что если чуть погодя у тебя появится еще N сущностей, с которыми надо будет по-сложному взаимодействовать курсором?

Ты, случайно, не путаешь свойства и состояния? Нажата ли клавиша - это свойство курсора. Находится ли курсор над операбельной сущностью - это тоже свойство, но, скорее всего, уже не курсора.
FSM нужен только для реализации самого D&D: захват невозможен, захват возможен, бросок возможен, бросок невозможен. Blackboard FSM должен заполняться из свойств курсора и элемента под курсором, тогда все будет работать как тебе хочется.

[ned4ded]

Евгений Шатунов,
Спасибо за ответ!

Почему это должно быть именно свойством курсора? Что если чуть погодя у тебя появится еще N сущностей, с которыми надо будет по-сложному взаимодействовать курсором?

Есть две области: дашборд - место, где расположены элементы для перетаскивания, и дисплей - место, куда эти элементы нужно перетащить. И я так вижу, что имеет зачение:
а) положение курсора на экране вообще (чтобы определить, находится ли он над дашбордом или над дисплеем, возможно потом уже над какой-то другой областью, но это просто одно множество состояний, от которых зависит система),
б) состояние нажатия кнопки (чтобы определить, происходит перетаскивание в данный момент или нет), наверное, я не совсем правильно выразился, лучше это назвать состояние перетаскивания элемента, т.е. в активном данном состоянии элемент "приклеен" к курсору.

Возможно даже не стоит привязывать эти состояния к курсору как таковому, достаточно сказать, что процесс игры зависит от этих состояний. Состояний чего? Я думаю, что можно сказать "состояний игры", но мне кажется, что формулирование четких терминов тут особо роли не играет.

Я опишу немного логики происходящего, возможно, так станет чуть понятнее:
Как я уже писал выше, две области, одна - это "дашборд", на этой области расположены элементы, которые можно перетаскивать, вторая - "дисплей", что-то вроде цели для перетаскивания, контейнера, куда можно положить элемент.

По нажатию на элемент создается его копия в специальном контейнере "item-holder", находящимся над дашбордом и дисплеем, с помощью позиционирования которого осуществляется перетаскивание элемента вслед за курсором. Т.е. сам процесс позиционирования этого контейнера происходит только в том случае, если на какой-то элемент игрок зажал ПКМ и стал водить мышью по экрану. Получается эффект перетаскивания.

Если пользователь оптускает кнопку мыши, то из контейнера удаляется копия элемента, и уже в зависимости от того, над какой область - дашбордом или дисплеем - была отпущена кнопка мыши, могут быть осуществлены следующие варианты действия:
1) кнопка отпущена над дашбордом - элемент возвращается на свое место, его можно активировать повторно
2) кнопка отпущена над дисплеем - элемент остается на дисплее, в дашборде его родитель остается заблокированным

Вот на оснвое этой логикой я смог выделить два описанных состояния. Возможно я не прав и что-то упускаю.

Но основная суть вопроса состояла в следующем: паттерн fsm предполагает управление состояниями, но активно может быть только 1 состояние в момент времени (если я правильно понимаю).

Мне каким образом лучше организовать код: создать две fsm, которые будут управлять двумя множествами состояний (состояние положения курсора над какой-либо областью, и состояние перетаскивания элемента) и уже вызывать разные функции в зависимости от двух fsm; или наборот сделать 1 множество состояний, но каждое состояние которого будет определяемо двумя параметрами, типо "курсор над дашбордом и элемент не перетаскивается" или "курсор над дисплеем и элемент перетаскивается".

Во втором случае просто возможно огромное количество вариантов, которыми сложнее будет управлять.

Саму логику игры я реализовал и без fsm, т.е. то, что я описал выше, уже реализовано, но я просто хочу нормальный код, а не 200 строк императива, в котором я через два дня сам не смогу разобраться :)