Russian Qt Forum

Добрый день

В симуляции участвуют 3D объекты которые движутся под воздействием разнообразных "сил". Напр в симуляции участвуют

Sphere1  // простой 3D объект - шарик
Sphere2  // еще 1 шарик
Cube1     // кубик
// любое число еще каких-то объектов

Force_Wind  // простая сила типа "ветер", смещает 3D объекты в заданном направлении
Force_Path  // сила двигающая объекты по заданному пути
Force_Seek  // сила двигающая каждый объект к заданной точке

Сейчас никаких сценариев нет, просто все силы прилагаются ко всем объектам. И вот вылазит проблема - силы могут оказаться "несовместимы". Напр сумма сил Force_Path + Force_Seek дает в рез-те полную ерунду. Зато есть смысл применить их последовательно, напр: шарики сначала следуют по заданному пути (действует Force_Path). Когда шарики проходят весь путь, они начинают лететь к заданным точкам (Force_Seek). Достичь этого простыми средствами не удается - одни шарики могут уже закончить движение по пути, другие еще нет, а для третьих движение по пути еще и не начиналось. Поэтому обе силы должны быть по-разному активны/неактивны для разных шариков/объектов.

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

Конечно реализовать каждый конкретный случай "просто в коде" не составляет никакого труда - но это "hard-coded". А надо в общнм виде, дать юзеру возможность создать произвольный сценарий. Как это лучше сделать, и как это должно выглядеть в UI?

Спасибо

Поставлю закладку, тоже интересует как это все делается.
ПС. У меня самого есть хотелка повозиться с такими вещами, сделать "каратиста" котроры бы на экране наносил бы удары в сторону смотрящего на экран. Хотелось бы знать как сделать.

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

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

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

С этим никто не спорит, но как это организовать, и как это должно выглядеть для юзера (UI) ?

Да, наверное, как и в других подобных приложения (типа флэша, например).
У каждого объекта есть таймлайн, на определенные моменты времени вешаются определенные экшены (силы в данном случае), и их время действия. Двойной клик по экшену откроет его параметры. Как-то так, наверное.

Как уже говорилось, это не катит

Для юзера это может выглядеть так:

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

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

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

Неясно в чем разница и что такое "просто список"? Как же обойтись без переходов?

Один из пользователей предложил такой вариант: каждая сила имеет параметр, целое число "приоритет". Значение -1 = "сила действует всегда", иначе силы применяются в порядке убывания приоритета. Напр если есть сила с приоритетом 10, то силы с приоритетом 9 неактивны до тех пор пока 10 не закончена для данного объекта (напр достигнут конец пути или точка назначения).

Это можно сделать "по-быстрому", но уж слишком чмошно. Все-таки "состояния" нужны, как говорится, это "сущность". С др стороны выплывает совсем немаленький редактор, и пока я очень смутно представляю как он должен выглядеть.

Да, кстати, а почему до сих пор еще не прозвучало (Q)StateMachine ?
 
До боли знакомая песня :'( Мол, чтобы что-то решить - нужно знать все-все подробности проекта. В результате перегрузка информацией, 99% которой только мешает, суть дела просто тонет в ненужных деталях. Может это просто отсутствие абстрактного мЫшления?  :)

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


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


К сожалению, 99% успеха зависит от понимания конечной цели, которая может быть выражена всего парой тезисов. Абстрактные вопросы порождают абстрактные ответы :).
Тем не менее, если мы обсуждаем серьезный продукт с возможностью пользователю управлять поведением объектов, то без состояний и редактора не обойтись.

* Каждое состояние может иметь 1 вход и N выходов, каждый из которых соответствует какому-либо условию выхода из данного состояния.
Например, 1 - закончилось заданное время, 2 - достигли точки назначения, 3 - нажатие кнопки мыши (условие с параметром) , и т.п.

* Соединить можно только выход и вход с одинаковыми выходными/входными параметрами.
* Каждый выход и вход может быть соединен только один раз.
* Пользователь должен задать начальное состояние для объекта.
* Пользователю доступны состояния только из библиотеки состояний.
* Каждое состояние, кроме входящих параметров, может иметь и индивидуальные настройки.
* С разными объектами может быть соотнесен как разные, так один и тот же граф состояний.

Можно попробовать обойтись переходами и без параметров, это будет немного проще.

Переход - это по существу реакция на "событие". Сейчас существуют такие события

1) Начало действия силы, которое может быть разным для разных объектов. Напр действует сила "Wander" (что-то типа броуновского движения). В какой-то момент времени появляется др сила действующая на объект, напр "Path" или "Seek". Очевидно нужно переключить объект в др состояние в котором "Wander" уже неактивна
 
2) Окончание действия силы - примеры уже были выше. Но только немногие силы имеют такую опции

3) Изменение поведения самой силы, напр сила Seek выдает событие когда объект приблизился к цели на заданное расстояние. Используется для "посадки" летящего объекта.

Да, возможно появятся и др события. Напр "истекло заданное время" вполне разумно. Кнопка мыши нет - симуляция не интерактивна. Ну и хорошо, появятся так появятся, что это меняет в общей схеме? По-моему ничего, ну добавится константа + строка. Также общее число сил невелико, обычно < 5. Ну десяток отсилы, хотя трудно представить для чего так городить.

По поводу "упрощенного списка" - ну как-то вряд ли, "окончание предыдущей" всего лишь один вариант.

Да

На деле опять идёт словоблудие в теме.

Как описать силы?
Список сил, для каждой силы период/время/усилие/условие завершения/условие начала.

Как описать взаимодействие сил?
Никак. Рассчитать пару тройку сценариев для объекта и их на выбор добавлять к силе. К примеру "прекращение других сил", "прекращение горизонтального/вертикального усилия", "остановка", "пауза".

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

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

Бред сивой кобылы. У вас симуляция растянутая по времени. Таймлайн у вас будет всегда в том или ином виде. Мб это будет счетчик тиков обработки, мб кратность симуляции, но в любом случае это будет ось времени для рассчитываемых объектов.


По сути получается следующие варианты для юзера.
Список общих сил
Список объектов
    Список сил для каждого объекта
Список контрольных точек (дублирующихся на таймлайне и доступных для выбора в настройках сил)

Примерный список свойств силы: название силы, время, периодичность, усилие, направление, условие завершения, условие начала, контрольная точка начала, контрольная точка завершения.
    Возможно добавление формулы расчёта в зависимости от переменных. К примеру "x=height/2" с направлением вниз, даст скорость падение в половину высоты, или же "x=time*0.1" - подобие усиливающегося ветерка.

От словоблуда слышу. Ну вот какого лезть если ни хрена не соображаете?

Да еще так борзо

Для особо одаренных еще раз повторяю.
А для Вас еще разжую: даже если я создам 1000 осей (для каждого из объектов) - юзер не сможет ими рулить. Поэтому ось времени одна

Ще раз: нема тями - слухай мовчки

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

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

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

PS такую вот модельку любой студент напишет за пару часов. Основная проблема в том, что вы пытаетесь объять всё сразу и немедленно. Так не получится. Создайте основу, пускай простую, и дорабатывайте её.

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

По сути даже сотня независимых таймлайнов всё равно приведут к одному. Обработка и расчёт всё равно будут происходить последовательно.
Никаких преимуществ даже десятка таймлайнов я не вижу. Только путаницы больше станет.

Единый таймлайн, для каждого объекта можно делать относительные "метки" вроде создания и изменения состояний.

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

PS как обычно тема Igors скатывается в отказ от любых предложений и "это не подходит" :D Я только оптимистично верю что хоть парочка его тем когда-нибудь станут закрытыми с примерами результатов :D

паттерн "умные объекты" жеж!



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

несколько очередей исполняются парралельно.
в каждой очереди - последовательность действий
(методов класса)

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


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

и тп.

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

Таймлайн - это ручной ввод юзера привязанный к значению глобального времени. Для одного объекта действительно все можно решить на одной линейке времени: напр когда объект достиг конца пути - включить следующую силу. Заметим что даже в этом, простейшем, случае проблемы уже имеем. Придется ловить "окончание пути", а если сила двигающая по пути изменится - придется всякий раз редактировать. Ну а хотя бы для десятка объектов - настроить каждый "вручную" уже нереально. А их может быть сотни, и даже тысячи.

А что это? И не понял что Вы имели ввиду под "согласованием между собой"?

К слову: эта задача у меня тоже есть. Только вот косяк должен плыть не так: сначала поворачивают только передние рыбки, потом те что плывут за ними и.т.д.

Сама реализация (в процессе симуляции) у меня трудностей не вызывает. Проблема как дать юзеру возможность "задавать сценарий(и)".

А сколько их было, этих "любых предложений"?  И каких? Как будто у меня богатейший выбор, а я, видите ли, нос ворочу :) Но все совсем не так. Пока из содержательных ответов я вижу только предложение ssoft рисовать граф - и в принципе я с ним согласен, все остальное тянет максимум на временное решение. 

Большинство задач что я предлагаю для обсуждения успешно решены. Не все конечно. Почему редко показываю рез-ты - ну меня об этом никто не просил, а лезть самому - как-то нескромно  :)

Так вы определитесь чего хотите. Пока что стоит вопрос "как пользователю задавать данные с помощью UI".
Вот в последнем сообщении у вас появляется вопрос "Как автоматизировать ввод данных пользователем".

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

Поставьте простую четкую задачу - её решим. Потом чуть усложните - доработаем и решим. А сейчас вы отказываетесь от базы, при этом выставляя новые требования :P

так ведь предложенные мною рыбки и есть прототип дизайна:


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

.programm
на самом деле добавляет в дерево узел,
который имеет тип "каталог очередей"

.queue
добавляет узел, который имеет тип "очередь команд"

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

например:
.alpha( uniformly_accelerated_motion(0.0,1.0,5, _) )

это узел, который все свои настройки принимает прямо в конструкторе.

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

и тд и тп.

главная киллер-фича паттерна
заключается в способе обработки дерева команд.

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

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

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


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

это делает процесс написания сценария поведения объекта
простым и быстрым.

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


время нужно для работы тех команд,
что завязаны на время (например: двигаться 5 секунд по указанным точкам)

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


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

на стадии инициализации объекты получают
предназначенные им программы действий.

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

Не понял. Может Вы имеете ввиду что юзер должен писать такое в текстовике? Если так, то я Вам точно скажу - мои юзеры этого делать не будут.

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

Поэтому "UI на бочку"

Думаю что понимаю о чем Вы говорите, но задача гораздо более узкая (или конкретная)

Вот собственно постановка "по минимуму"

Нужны ли здесь "состояния"? Думаю да, нужны, это "неотъемлемая сущность". Хотя возможно я рассуждаю шаблонно

Какие "новые требования" ??? От какой "базы" я отказался ??? Причем тут стая/группа ??? Поверьте, я изо всех сил пытаюсь вникнуть в изливаемый Вами поток (или понос) сознания - но это недоступно для моего понимания  :'(

не понял про "Пытон".

касательно UI:

умные объекты - это технология.
это - модель.

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

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

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

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

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

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

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

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

если "не программист" такое не осиливает,
то какой бы редактор вы бы ему ни подсунули,
он все равно не справится.

зы:
мы на кутешечке редактор для умных объектов делали.
со всеми причитающими свистелками-перделками.

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

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

а если он ни бум бум - никакой редактор ему не поможет.

Пользователь "должен" только одно - платить деньги

Безусловно. Но чем больше можно сделать "без всяких скриптов" - тем лучше

Это по меньшей мере спорно. Допустим мы начали с модели и формального языка. Как будут выглядеть скрипты? Думается примерно так (псевдо код/язык)
И так много раз. Ну и чего мы добились? Обременили юзера откровенно глупыми if'ами, которых может быть неск десятков? Навязали ему изучение языка/сынтаксыса? Тогда нечего удивляться что он "махнет хвостиком" и будет юзать др приложение вместо нашего.

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

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

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

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

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

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

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

[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. Ну и т.д.

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

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


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


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

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

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



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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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


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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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


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

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

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

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

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

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

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




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

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

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

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

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

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

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

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

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

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

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

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

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


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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Спасибо

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

А на пользователей какого уровня рассчитано данное приложение?
Это должны быть инженеры, техники в предметной области или "обычные смертные"?
Для последних, думаю, будет не понятно, "шо нада делать" :(
Но если на них не рассчитано, то в принципе имеет право на жизнь...

Ну напр Вы денно и нощно сидите в 3ds max.. Та не, круче, - в майке! Чтобы сделать какой-нибудь компутерный клип за который Вам должны заплатить. Ну и кто Вы? Ну не инженер точно, но никак и не "человек с улицы" - придется знать очень немало бубочек на которые надо давить, иначе ничего не заработаете. По меньшей мере надо иметь "силы" и "Set 1" (набор объектов) - значит все это придется сначала создать.

Странный скепсис для человека утверждавшего что
Неужели Ваши юзеры не смогли бы натянуть синий кружочек на зеленый?  :)

что-то не уловил принципа действия...

вы создаете некий "стейт" - контейнер,
в который мышкой перетаскиваете различные "силы",
которые будут действовать одновременно (как на картинке не очевидно,
на что именно они будут действовать)
на некоторый объект.

можно ткнуть на силу, и развернуть её свойства.

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

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

то бишь выполнение первого стейта будет прекращено.
вместо него на объект будут действовать силы 2го стейта?

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

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

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

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

и тогда на объект бы воздействовали бы действующие (не завершившиеся) силы уже сразу двух стейтов.

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

правда при таком подходе можно получить ситуацию,
как в басне Крылова: про лебедя, рака, и щуку.

Да, совершенно верно. Возможно вместо "State 1" лучше "Default" и как-то подчеркнуть в UI что он всегда есть, с него (исходного состояния) всегда все начинается

Придется пойти на дубляж стейта и в копии добавить новые силы

Да, тогда разрушается логика "состояния". 

Пока сил немного (до 10 в крайнем случае, обычно куда меньше) дублирование не так уж опасно. Но вот что мне не нравится - это явная "заточка" на силы. Как-то слишком конкретно, возможно негибко. Написав "Some Other Data" я имел ввиду пытон скрипт. Как считаете, насколько он сюда лепится?

По моему мнению, лучше все таки делать наоборот. Не пытаться встроить поддержку скриптов в графический редактор, а сделать полноценную поддержку движка из скриптов, а к нему уже делать графические редакторы, разной степени навороченности. Тем более, пользователи программы ближе к пользователям разных кадов, где скрипты активно используются.
Очень сложно дать удобный GUI на все случаи жизни. А со скриптом всегда будет выбор: если пользователь хочет зарабатывать побольше денег - он учит скрипты и делает навороченные вещи. Другому это не надо, он использует ограниченный GUI, и получает результаты похуже.

Кстати, питон может быть здесь избыточен, я бы использовал lua.

Можно сразу же делать на скриптовом языке :)
Для себя делал "Окно разработчика (https://github.com/gil9red/dev_window)" для проверки каких то идей:

(https://raw.githubusercontent.com/gil9red/dev_window/master/screenshot.png)

Предшественником был бот игры: https://github.com/gil9red/moswar_bot
Там чтобы не пришлось при каждых изменениях, во время разработки, перезапускать бота, а это длительный процесс, добавил в него редактор скриптов и во время работы бота тестировал идеи, получилось очень удобно. Когда алгоритмы получались работающими, их уже переносил в основной код

(https://raw.githubusercontent.com/gil9red/moswar_bot/master/screenshot.png)

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

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

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

и что можно улучшать, и развивать.

Само собой. Планов немедленно что-то делать нет, чтобы из наброска сделать нормальное UI там еще пахать и пахать. Просто хотел обсудить для развития моего "понимания" :) дальнейших/возможных задач.

Как уже упоминалось, немедленное тыкание скриптов в морду юзера вызывает обратный эффект. Но скрипты неизбежны. Простой пример: существует событие "collision", т.е. объект с чем-то столкнулся и, возможно, изменил свое движение. Тут "факт события" (по которому осуществляется переход в др состояние) еще ни о чем не говорит. То ли на танк упала пушинка, то ли шарик шмякнулся об стену - реакции требуются совсем разные. Неплохо бы иметь возможность сбацать напр такой скрипт (псевдокод)
Но приняв установку "редактор отдельно, скрипты отдельно" не удастся написать так коротко. Беда в том что state (состояние) определен/существует в редакторе, т.е. воспользоваться удобным SetState нельзя. А такое поведение может задумываться только для конкретного state (а не глобально). Да и к какому объекту это действие должно быть применено - без редактора придется вешать еще if(ы). Думаю state не должен быть "частью редактора", но куда его тащить (где создавать и.т.п) пока не представляю

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

Мой первый начальник (еще на ЕС машине) в таких случаях говорил

Лучше вместо написания таких комментариев подумали б :) Всё одно полезней вашей задумке было.

Значит, второе. Ладно, "лохов с улицы" откидываем.


Тут мало просто "умения натянуть", тут надо понимать, что, куда и ЗАЧЕМ натягивать.
Конечно, сейчас появятся "спецы", которые посоветуют "написать мануал ко всем окошкам",
или "написай свой тру языкъ описания графа".

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

В Qt дызайнере тоже надо бросать виджеты на форму ... нет-нет "обычный смертный" ни за что не разберется! Это ж надо понимать что такое виджеты и.т.п. На мой взгляд такие утверждения звучат "странно"  :)

Правду сказать, вопроса Вашего не понял, отвечу как умею. Объекты и силы - 2 очевидных сущности/класса. Да, силы не имеют смысла без объектов (им нечего делать). С др стороны, если нет сил то  в процессе симуляции с объектами ничего и не происходит. Ну это редко, обычно есть хотя бы сила гравитации. В общем, полет шарика определяется приложенными к нему силами. Если нужно добиться того или иного поведения в полете - надо менять силы, др средств нет.

Ну вот запустил чел, не знающий Qt, дизайнер. Накидал на форму кнопок. Ну а дальше то что? Чем ему помогло то, что он их накидал? Пока он Код Животворящий не напишет, форма "не заиграет" :)

Поэтому тут важно понимать, ЧТО и ЗАЧЕМ человек делает. А не просто упражнения в мышеклике :)


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

Да

Нет, такой задачи не ставится.

Вот тут были хорошие мысли
Да, state (состояние) имеет смысл и без всяких сил, чуть копнув в этом направлении я обнаружил что основания там мощнейшие. То есть надо state(ы) как-то отдельно создавать/удалять/редактировать, а в редакторе графа только "приклеивать" к ним силы. Хмм... растерялся, не знаю как это все "связать"

В принципе последний вопрос про создание силы лишён смысла.

Жестко забитая логика и привязка сил к триггерам(состояниям) позволит имитировать почти любую необходимую силу.

Здесь у Igors скорее всего начинается неразбериха с иерархией.