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

[Racheengel]

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

[Igors]

Чем плох вариант, когда каждое действие представляется параметрами плюс триггером активации?

"Не вкурил", можно пример?

[Racheengel]

[Object]        [Action]        [Trigger]           [Other params...]
Obj1            
--------------Action1         Time: 0s
--------------Action2         Time: 10s
--------------Action3         Action1: finished
--------------Action4         Action2: finished 10s
Obj2
--------------Action5         Action4: started

Т.е. идея в том, что каждый экшен имеет определенные параметры "триггерования". Например, Time: 0 означает - триггероваться сразу после старта анимации. Action1: finished - триггероваться, когда закончится экшен 1. Action2: finished 10s - триггероваться через 10с после окончания экшена 2.  Action4: started - триггероваться, когда запустится экшен 4. Ну и т.д.

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

[Bepec]

Igors ответил вам в предыдущем сообщении.

Мне показалось что _Bers предложил сначала разобраться со сценариями в виде текста (скриптами), а потом уж парить UI. Но я не вижу никакой мотивации такого решения.

Он просто не понимает что всё UI, все эти свистоперделки только для глаз. А сценарий всегда будет в виде скриптового языка.
Написать UI для генерации скриптов - дело на день.
Но написать скриптовый язык - дело в разы дольше.


Как он себе представляет конвертацию UI в расчёты, я не знаю. Но т.к. до него не доходит даже по пунктам расписанные предложения реализации, я просто не знаю что делать. То ли не читает, то ли не размышляет.

[_Bers]

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

Для сценария необходим парсить, который нужно будет писать. Можно, конечно, взять готовый формат, например svg со всеми его достоинствами и недостатками.
Наглядность сценария для пользователя в виде текста практически нулевая, поэтому нужно графическое представление (которое, скорее всего, все равно сведется к графу).

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

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

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

Мне показалось что _Bers предложил сначала разобраться со сценариями в виде текста (скриптами), а потом уж парить UI. Но я не вижу никакой мотивации такого решения. Зачем здесь вообще скрипты? Разве что "для солидности", мол "UI вторично". 

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

однако, невозможно визуализировать то,
чего ещё не существует.

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

вы не знаете, как предполнести UI пользователям,
потому что у вас нет понимания: что нужно преподнести.
нет самой модели.

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

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

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

и да, UI вторично. это - всего лишь оболочка.
бизнес-логика - вот где сердце продукта.

[Igors]

Как он себе представляет конвертацию UI в расчёты, я не знаю.

Сейчас в процессе симуляции каждый объект хранит контейнер эл-т которого

- указатель на силу (ее тип, параметры и.т.д)
- доп опции специфичные для связки объект+сила

Все что мне нужно - на каждом фрейме знать активна ли сила для объекта.

Т.е. идея в том, что каждый экшен имеет определенные параметры "триггерования". Например, Time: 0 означает - триггероваться сразу после старта анимации. Action1: finished - триггероваться, когда закончится экшен 1. Action2: finished 10s - триггероваться через 10с после окончания экшена 2.  Action4: started - триггероваться, когда запустится экшен 4. Ну и т.д.

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

Теперь понял, спасибо. Где-то (в описании игры?) я видел подобное. Все-таки давайте заменим "Action" на "Force" (сила). Тогда табличка будет

[Object]        [Force]         [Trigger]           [Other params...]
Obj1             
--------------Force1          Time: 0s
--------------Force2          Time: 10s
--------------Force3          Force1: finished
--------------Force4          Force2: finished 10s

Попробуем осмыслить.

Force1 - сразу же активна, Ok.

Force2 - стартует через 10 сек. Хмм... а хз что там будет через 10 сек, напр закончится ли Force1? Ну ладно, это триггер для примера, Ok.

Force3 - стартует по окончанию Force1. А что делать если Force3 несовместима с Force2 и/или Force4? И их надо выключить при старте Force3. Возможно по окончанию Force3 опять включить. Как это сделать в табличке?           

[Igors]

..вы пытаетесь..
..вы не знаете..
..у вас нет понимания...

Ах как часто я такое слышу Это означает: готовые (или известные, или заученные) решения не проходят

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

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

Теоретически Ваши утверждения бесспорны. Но для данной задачи я в упор не вижу что будет делать скрипт и нахрен он тут нужен?

Вот Вы привели абстрактный пример

Код:

рыбка1.Программа Действий()
    .Очередь команд(0, активна)
        .Двигаться по закону(труля ля ля 15 секунд)
        .уйти в прозрачность()
    .Очередь команд(1, активна)

Можно это конкретизировать для простого примера в стартовом посте?

..напр: шарики сначала следуют по заданному пути (действует Force_Path). Когда шарики проходят весь путь, они начинают лететь к заданным точкам (Force_Seek).

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

Спасибо

[Igors]

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

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

[Bepec]

StateMachine - описывает фиксированные состояния.
Скрипт - позволяет менять состояние любого объекта и допускает изменение логики без изменения кода программы.

StateMachine для сотни объектов - необходимо рассчитать их взаимодействие заранее и жестко зафиксировать в коде.
Скрипт для сотни объектов - необходимо описать лишь правила взаимодействия в коде, всё остальное будет рассчитано.

[Racheengel]

StateMachine для сотни объектов - необходимо рассчитать их взаимодействие заранее и жестко зафиксировать в коде.
Скрипт для сотни объектов - необходимо описать лишь правила взаимодействия в коде, всё остальное будет рассчитано.

Скрипт, по сути, альтернатива UI для StateMachine. Скрипт также парсится и в конечном счете строится и исполняется StateMachine.

[Igors]

StateMachine для сотни объектов - необходимо рассчитать их взаимодействие заранее и жестко зафиксировать в коде.

StateMachine имеет состояния и переходы между ними. Достаточно вызывать переходы по "событию" а потом использовать данные текущего состояния

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

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

Какие вообще возражения против StateMachine? Может она чем-то здесь не подходит, или, в дальнейшем, "плохо расширяема"? Или просто-напросто, как говорит один товарищ

с <xxx> не работал

Я тоже еще нет, но все когда-то бывает впервые...

[Racheengel]

Force2 - стартует через 10 сек. Хмм... а хз что там будет через 10 сек, напр закончится ли Force1? Ну ладно, это триггер для примера, Ok.

А какая разница? Force2 не зависит от Force1, ему все равно, что там с кем будет.

Force3 - стартует по окончанию Force1. А что делать если Force3 несовместима с Force2 и/или Force4? И их надо выключить при старте Force3. Возможно по окончанию Force3 опять включить. Как это сделать в табличке?           

Типов триггеров можно добавить сколько угодно. Сейчас, допустим, есть триггер типа Force::start. Можно так же само сделать Force::end или Force::pause и вешать на них любые другие события.

[_Bers]

Ах как часто я такое слышу Это означает: готовые (или известные, или заученные) решения не проходят

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

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

об этом вы сообщаете в №37

Но для данной задачи я в упор не вижу что будет делать скрипт и нахрен он тут нужен?

это ответ на вопросы которые вы задаете на протяжении всей этой темы.
в частности - ответ на №37.

Вот Вы привели абстрактный пример

Код:

рыбка1.Программа Действий()
    .Очередь команд(0, активна)
        .Двигаться по закону(труля ля ля 15 секунд)
        .уйти в прозрачность()
    .Очередь команд(1, активна)

Можно это конкретизировать для простого примера в стартовом посте?

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

[Igors]

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

об этом вы сообщаете в №37

На всякий случай приведу #37

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

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

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

я не знаю всей полноты задачи.

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

Что же подразумевается под "полнотой" или "задачей" (мол, "не зная всех деталей задачи..")? На этот вопрос никто и никогда ответа не дает (и не даст). Ну что, я должен пускаться в пояснения деталей каждой силы? Так их там десяток и у каждой десятки опций. А главное ЗАЧЕМ? Задача стоит четко - дать юзеру возможность создать "сценарий" чтобы включать/выключать силы для каждого объекта индивидуально во времени. Изучение ненужных подробностей - напрасная трата мозгов и времени.

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

А почему Вы думаете что он еще не стоит у меня на вооружении? Только вот думаю в данном случае он не очень подходит.

[Igors]

Типов триггеров можно добавить сколько угодно. Сейчас, допустим, есть триггер типа Force::start. Можно так же само сделать Force::end или Force::pause и вешать на них любые другие события.

Что находится в колонке "Force" (в оригинале "Action")? Фактически Force.start (сила становится активной когда триггер взвелся), верно? Тогда придется добавить/иметь и Force.end, а как иначе? Также сила может переключаться on/off по неск триггерам, стало быть в колонке Force может быть любое кол-во Force.start/Force.end - боюсь это запутает юзера.

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

Намазюкаю скрыншот как я вижу UI с "состояниями" - обсудим