Сценарий действия сил

[Bepec]

StateMachine описывает состояния одного объекта, при этом упуская взаимодействие между ними.
Скрипт же выполняется движком, при этом движок имеет на руках все данные для обработки взаимодействия между всеми объектами.

[Old]

StateMachine описывает состояния одного объекта, при этом упуская взаимодействие между ними.

Вот что вам можно написать? ... это не соответствует действительности? ... странные мысли? ... глупость?

[Bepec]

Ну опишите мне StateMachine  для 10 объектов взаимодействующих друг с другом по 10 различным вариантам.
Это будет не одна stateMachine, а 10 stateMachine.

PS последние ваши реплики это беспочвенные обвинения без доказательств. Жаль что нормальный человек начинает пустословить

[Old]

Ну опишите мне StateMachine  для 10 объектов взаимодействующих друг с другом по 10 различным вариантам.
Это будет не одна stateMachine, а 10 stateMachine.

Почему? У сцены будет своя машина, у каждого объекта может быть своя машина и т.д. При возникновении каких-то событий, машина сцены может генерировать новые объекты или убирать старые, менять их параметры и т.д.

PS последние ваши реплики это беспочвенные обвинения без доказательств. Жаль что нормальный человек начинает пустословить

Не правда. Вы утверждали (не понятно для чего) то, что не соответствует действительности, к сожалению, не первый раз. Или вы до сих пор думаете, что mouseMove вызывается на каждый пиксель?

[Igors]

Ну опишите мне StateMachine  для 10 объектов взаимодействующих друг с другом по 10 различным вариантам.
Это будет не одна stateMachine, а 10 stateMachine.

Про "взаимодействие объектов друг с другом" никто не говорил, откуда Вы это взяли - хз. Говорилось что есть "события" при получении которых какие-то силы становятся активны или неактивны для каждого объекта индивидуально. Это как раз хорошо вписывается в термины StateMachine - есть "состояния" и "переходы" между ними. Машина одна для всех объектов, но в каждый момент времени разные объекты находятся в разных состояниях т.к. получают события в разное время.

PS последние ваши реплики это беспочвенные обвинения без доказательств. Жаль что нормальный человек начинает пустословить

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

А если не дойдет - я еще найду слова. Будьте добры, покиньте мою тему. Спасибо за понимание.

[_Bers]

Вот пришла в голову такая формулировка:

Ясно что UI лишь "визуализирует" какие-то структуры данных. Но почему такой базовой структурой должен быть скрыпт? Почему не StateMachine? На мой взгляд оснований для этого куда больше

скрипт определяет дизайн исходных данных.
и принцип их обработки.

а машина состояний - это то,
что находится под капотом скриптомашины.

Почему же у меня "нет понимания идеи"? Вот я вижу хорошо известный "паттерн" (или технику) StateMachine и хочу его применить. Основания для этого имеются, а по мне так даже "напрашиваются" - ведь мне нужно переводить объекты из одного "состояния" в другое. В одном на объект одни силы действуют, в другом другие. Если я ошибаюсь - пожалуйста, критикуйте, за этим я и создал эту тему.

машина состояний - это деталь реализации движка,
который должен всем управлять.

но при этом вы пишите, что не знаете,
как предоставить пользователям возможность донести свои хотелки.

это означает, что вы не знаете,
каким должен быть формат исходных данных.

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

я предложил вам забить пока на реализацию,
и сосредоточится на дизайне использования.

вот такие хотелки:

Также юзер может захотеть по-всякому использовать Force_Wind. Возможно он захочет добавить "легкий ветерок"  действующий одновременно с 2 др силами. Но может и по-другому - только когда шарик достиг заданной (Force_Seek) точки - он сдувается штормовым ветром.

может удовлетворить только скрипт.

Оба-на! Как же так? Только что Вы весьма уверенно заявляли что у меня "нет понимания" - стало быть, у Вас-то оно точно имеется. А тут рраз! - и в кусты, совсем как Верес  

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

сейчас мне не очень важно, каким он будет внутри.
важно, каким вы его видите снаружи.

каким вы его себе представляете.

[Bepec]

В вашем предложении отказано.

И да, на каждый пиксель вызывается mouseMove, с исключением в виде резких рывков мышью.

[Igors]

скрипт определяет дизайн исходных данных.
и принцип их обработки.

а машина состояний - это то,
что находится под капотом скриптомашины.

Неужели StateMachine невозможна без всяких скриптов? Да почему Вот у того же Qt есть класс QStateMachine - но никаких скриптов не наблюдаю

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

сейчас мне не очень важно, каким он будет внутри.
важно, каким вы его видите снаружи.

каким вы его себе представляете.

Ну "сотрудничать" пожалуй громко сказано. Скорее я "пригласил принять участие в (творческом) обсуждении" Как я уже говорил, попробую намалевать скриншот, там довольно много, поэтому 1-2 дня "be patient"

[_Bers]

Неужели StateMachine невозможна без всяких скриптов? Да почему Вот у того же Qt есть класс QStateMachine - но никаких скриптов не наблюдаю

выше я писал, что машина состояний существует под капотом движка,
который исполняет скрипт.

то бишь, она нужна скрипто-движку,
а не наоборот.

вы пытаетесь рассматривать реализацию некоторого механизма,
акцентрируясь на всяких там стейт-машина,
но при этом обошли вниманием интерфейс этого механизма.

по сути - способ его применения.

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

вы сейчас уже находитесь на этапе разработки
интерфейса скрипто-машины.
просто ещё пока не осознаете этого.

Ну "сотрудничать" пожалуй громко сказано. Скорее я "пригласил принять участие в (творческом) обсуждении"
Как я уже говорил, попробую намалевать скриншот, там довольно много, поэтому 1-2 дня "be patient"

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

из этого я сделал вывод, что вам нужно что-то вроде "умных объектов",
о которых я и написал выше.

однако я не представляю себе,
чем на самом деле должен быть конечный продукт.

каким вы его себе предсталвяете?
что он должен уметь делать?
для чего он вообще нужен?

вот этой информации у меня нет.

[Bepec]

У вас пользователь будет формировать действия сил произвольно, используя ваш UI.
А результатом этой работы будет скрипт.
Из вики:
Сцена́рный язы́к (язык сценариев, жарг. скрипто́вый язык, от англ. scripting language) — высокоуровневый язык сценариев (англ. script) — кратких описаний действий, выполняемых системой. Разница между программами и сценариями довольно размыта.

По сути stateMachine это захардкоренный скрипт.

[ssoft]

По сути stateMachine это захардкоренный скрипт.

Не согласен с таким утверждением.

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

В качестве интерпретатора может выступать любая модель - последовательное исполнение команд, конечные автоматы, событийная модель, динамический сигнал-слот, клиент-сервер взаимодействие, активные объекты, модель актеров и т.п. Может даже использоваться также произвольное их сочетание. Какую конкретно модель выбрать зависит от условий решаемой задачи и/или предпочтений разработчика.

Здесь конечный автомат не захардкоден, так как предполагается, что его схема динамически редактируется пользователем.
Схема может быть представлена в виде скрипта, скрипт в виде схемы. Можно реализовать и то и другое, они взаимозаменяемы. Но для того и другого необходим интерпретатор - среда, в которой они должны функционировать.

[Bepec]

После компиляции он будет захардкорен.
А скрипт можно будет менять без перекомпиляции программы.

Хотя конечно можно сделать никому не нужный финт и написать скрипт в виде StateMachine.

[ssoft]

После компиляции он будет захардкорен.
А скрипт можно будет менять без перекомпиляции программы.

После компиляции программы? Нет.
Предлагается ведь не программу реализовать с помощью конечных автоматов, а пользователю дать возможность формировать схемы поведения в виде графа состояний и переходов.
Когда пользователь сформирует схему или скрипт, команда Run запустит интерпретатор, который в runtime сформирует конечный автомат или любую другую модель поведения. Никакого хардкода.

[Igors]

Так, ну вот обещанный скриншот в аттаче. Рисовать картинки оказалось утомительно, поэтому написал простой код. Выглядит конечно чмошно - ну это только набросок.  Ф-ционал простой

- для создания "перехода" юзер берет синюю бубочку и натягивает ее (DnD) на зеленую. Удаление перехода - схватил любую бубочку но "не донес". Редактирование аналогично - "перенес". Никаких др вариантов (кроме синей на зеленую) сейчас нет.

- новые состояния создаются (и старые удаляются) по команде из меню/тулбара (на скриншоте не показано)

- силы добавляются в состояния дропанием из таблицы слева. Удаляются по клавише или DnD

Это пока все. Ясно что простенькие задачки из первого поста этот редактор решает на ура. А вот с точки зрения расширения/перспектив - хз. Попинайте

Спасибо

[Bepec]

Похоже на LabView, если вам интересно посмотрите его, мб идея дальше продвинется.
 
Но на мой взгляд это чрезвычайно утомительно для пользователя. Точнее программист спокойно нарисует программу в таком редакторе. А вот обычный пользователь забьёт просто