Про Functional Hybrid Modeling
Делаю сейчас на работе новую игру (я для игровых автоматов пишу, если кто не в курсе). И вот думаю, как бы поудобнее логику сделать.
Предыдущую игру я сделал на основе Functional Reactive Programming (FRP от Conal Elliot). Оказалось очень даже ничего, только вот всплыли пара проблем: малая производительность (вся игра - один большой continuation, который каждый фрейм пересоздается заново, спасает только то, что игра не особо большая), и не совсем удобное описание логики в некоторых местах (причем, как грамотно описывать, сам пока не знаю).
Так вот - полез я посмотреть: какие-же продвижения в области FRP произошли за последнее время? И нашел я очень интересную статью, про Functional Hybrid Modelling. Моих вопросов оно не решает (хотя и дает некоторые направления). Но, в целом, крайне рекомендую для прочтения тем, кто хочет узнать, как надо делать симуляции физических и игровых систем.
Основная фича, которые придумали авторы - неявная связь между сигналами (signal relation), как основной строительный кирпичик. Т.е. мы больше не описываем, что из чего следует, а только описываем взаимосвязи. Из этих хреней можно автоматически выводить систему диффференциальных алгебраических уравнений (DAE), что является гораздо более мощным средством описания физических задач, нежели относительно низкоуровневые ODE.
Также эта хрень показывает верность моего старого предположения, что на ограничениях (constraints) можно строить практически любые системы. Ведь отношение (relation) - есть частный случай ограничения.
Конечно реализация всего этого пока что не просто хромает, а вообще отсутствует. Почитал отчет их студента о языке Hydra - пробной реализации задуманных фич и не увидел там ничего нового, кроме описания семантики и примера перевода этой семантики в тупое FRP на continuation-ах.
Короче, идея интересная. Буду думать, как реализовать ее подмножество для своих задач. Решать DAE я не буду, т.к. физики у меня в игре не будет. А вот описывать задачу не иерархической комбинацией, а системой взаимосвязей может оказаться очень даже удобно. Буду продолжать думать: как совместить описание взаимосвязей задачи и динамическую симуляцию, да еще и сделать все это работающим с нормальной скоростью.
4 комментария:
Да, оч интересная статья, даже непонятно как она мимо меня прошла в свое время :)
Только я не очень понимаю как без DAE обойтись, в играх тож куча функциональных связей, и непрерывных, и дискретных (триггеров всяких)... Надо как-то это всё разрешать.
И в реалтайм-системе я это с трудом представляю, т.к. решать же все эти системы уравнений надо всякими итеративными методами.
PS Там между словом "дифференциальных" и "алгебраических" стоит "и" :) Без него странно смотрится..
Без, думаю, DAE вполне можно. Т.к. для физики есть куча готовых физических движков. А для других анимаций - их все равно аниматор делает, а не программист (и также много готового кода).
Про рилтайм системы см. выше - куча готового низкоуровневого оптимизированного кода (по крайней мере для игр).
А то, что при помощи FHM (как мужской журнал прямо :), можно работать со всем этим на гораздо более высоком уровне - вот это ценно. Ну и сама идея, как можно делать симуляцию много проще, чем это есть сейчас, тоже интересна.
PS про DAE: все правильно без "и" см. тут.
Физика да, физика отдельно, особенно если это какой-нибудь novodex то внутрь и не заглянешь при всем желании..
Мне просто это напомнило проблему создания удобного Scene Graph'а, со сложными отношениями и циклическими зависимостями между объектами, ну что-то в этом духе.
PS мда действительно, был не прав.. просто в доке про FHM "and" было.. :)
Кстати, примерно над тем же и думаю. Как из описания зависимостей создавать быстрый dependency graph (или какую-нить другую имтацию data flow programming). А то постоянно пересоздавать и пересчитывать весь scene graph слишком дорого. Да и неиерархические зависимости тоже хочется.
Отправить комментарий