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

[ssoft]

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

[Bepec]

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

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

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

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

[_Bers]

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

Код:

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

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

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

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

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

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


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

и тп.

[Bepec]

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

[Igors]

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

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

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

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

[Igors]

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

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

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

Код:

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

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

PS как обычно тема Igors скатывается в отказ от любых предложений и "это не подходит"

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

Я только оптимистично верю что хоть парочка его тем когда-нибудь станут закрытыми с примерами результатов

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

[Bepec]

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

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

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

[_Bers]

Код:

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

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

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

Код:

auto fish = media::create<animation>("ololo")
    .programm()
        .queue(0, true)
            .set_x( uniformly_accelerated_motion(0,200,15, _) )  
            .activate(me, 1)
        .done()
        .queue(1, false)
            .alpha( uniformly_accelerated_motion(0.0,1.0,5, _) )
        .done()
    .done()
.done();

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

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

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

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

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

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

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

Код:

.alpha()
    .from(0)
    .to(1.0)
    .timeInseconds(5)
    .acceleration()       //<--- пустое значение обозначает "рассчитать автоматически"
.done()

и тд и тп.

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

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

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

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


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

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

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

Код:

smart1.program() ... .done();
smart2.program() ... .done();
smart3.program() ... .done();

// --- живи живое

while(true)
    smart1.live(dt), 
    smart2.live(dt), 
    smart3.live(dt); 

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

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


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

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

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

[Igors]

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

Код:

auto fish = media::create<animation>("ololo")
    .programm()
        .queue(0, true)
            .set_x( uniformly_accelerated_motion(0,200,15, _) )  
            .activate(me, 1)
        .done()
        .queue(1, false)
            .alpha( uniformly_accelerated_motion(0.0,1.0,5, _) )
        .done()
    .done()
.done();

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

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

I'm not a programmer

(с плохо скрываемым раздражением). Ну написал сам неск скриптов и воткнул их в меню - так понравилось.

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

[Igors]

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

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

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

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

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

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

- объект может реагировать на событие, включая/выключая какие-то силы (примеры выше). Это не оказывает влияния на др объекты

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

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

[Igors]

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

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

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

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

[_Bers]

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

Код:

auto fish = media::create<animation>("ololo")
    .programm()
        .queue(0, true)
            .set_x( uniformly_accelerated_motion(0,200,15, _) )  
            .activate(me, 1)
        .done()
        .queue(1, false)
            .alpha( uniformly_accelerated_motion(0.0,1.0,5, _) )
        .done()
    .done()
.done();

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

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

I'm not a programmer

(с плохо скрываемым раздражением). Ну написал сам неск скриптов и воткнул их в меню - так понравилось.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

[Igors]

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

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

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

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

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

Это по меньшей мере спорно. Допустим мы начали с модели и формального языка. Как будут выглядеть скрипты? Думается примерно так (псевдо код/язык)

if (event.what == "Force1.end") {
  Force2.SetEnabled(True)
  Force3.SetEnabled(False)
}
if (event.what == "Force2.start") {
  Force3.SetEnabled(True)
...

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

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

[ssoft]

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

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

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

[Igors]

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

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