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

[Racheengel]

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

[Igors]

Это должны быть инженеры, техники в предметной области или "обычные смертные"?
Для последних, думаю, будет не понятно, "шо нада делать"

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

Но если на них не рассчитано, то в принципе имеет право на жизнь...

Странный скепсис для человека утверждавшего что

из всех искусств для нас важнейшим является UI

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

[_Bers]

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

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

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

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

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

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

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

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

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

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

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

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

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

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

[Igors]

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

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

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

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

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

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

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

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

[Old]

Написав "Some Other Data" я имел ввиду пытон скрипт. Как считаете, насколько он сюда лепится?

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

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

[gil9red]

Написав "Some Other Data" я имел ввиду пытон скрипт. Как считаете, насколько он сюда лепится?

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

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

Можно сразу же делать на скриптовом языке
Для себя делал "Окно разработчика" для проверки каких то идей:



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

[_Bers]

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

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

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

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

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

[Igors]

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

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

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

if (event.what() == "collision" && event.collided().mass > 100)
  SetState("escape")

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

[Bepec]

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

[Igors]

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

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

Иди гуляй

[Bepec]

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

[Racheengel]

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

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

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

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

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

[Igors]

Тут мало просто "умения натянуть", тут надо понимать, что, куда и ЗАЧЕМ натягивать.

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

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

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

[Racheengel]

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

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

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

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

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

[Igors]

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

Да

Или должна быть возможность "склепать свою силу" с помощью гуя?

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