FRP на игровом движке. Стоит ли оно того?

Сегодня я читал о FRP (функциональное реактивное программирование). Тем не менее, я не знаю, насколько это подходит в самом двигателе.

После прочтения статьи Gerold Meisinger мой вопрос заключается в том, стоит ли использовать FRP вместо компонентной архитектуры. Является ли это ближайшим будущим разработки архитектуры игрового движка? Это просто простой подход к решению небольших проблем, основанных на компонентах архитектуры? Я был бы признателен за любую статью, объяснение, личное мнение и т.д.

Подумайте о механизме для коммерческой игры, специально для стрелков или гоночных жанров (3D-игры). Не думайте о двумерном платформере или другом более простом (говоря о сложности двигателя). Я бы использовал C/С++ (я заметил, что люди, использующие FRP, полагаются на Haskell, по своей природе. Однако я видел этот документ и предпочитаю стоять на С++, так как "отраслевой стандарт" ).

Ответ 1

С++ не подходит для FRP; любые используемые вами библиотеки (Boost.Phoenix является хорошим) будут нести некоторые накладные расходы, которые вы, скорее всего, не хотите иметь в коммерческих 3D-игра.

Не только это, но FRP - не очень хорошо разработанная техника для игр, даже в Haskell, afaik; вы хотите сделать игру или хотите разработать технику для создания игр?

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

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

Кстати, вы так ошибаетесь, что в 2D-играх есть простые двигатели.:)

Обновление 2014

С тех пор появился новый язык, который широко использует функциональные реактивные методы и нацелен на веб-разработку, называемую Elm. Он очень похож на Haskell и поддерживается Prezi, afaik. У дизайнера языка был довольно хороший presentation, в котором он сделал небольшую игру с использованием FRP. Любой, кто интересуется тем, как FRP должен быть обработан, может захотеть посмотреть на это видео.

Ответ 2

Короткий ответ: возможно, никто из них!

Тем не менее, я не знаю, насколько это вписывается в сам движок.

Я не понимаю, что вы подразумеваете под этим, но каждый кусочный код, который включает время (т.е. использует update( float elapsedTime )), обычно подходит для FRP - теоретически. О "вписываться в двигатель", возможно HaskellWiki Yampa - Game Engine помогает ответить на ваш вопрос (урезанная и переведенная на английский язык версия моей диссертации, объясняет общую архитектуру). Из дискуссий о FRP и чтения некоторых статей FRP представляется, что все еще остаются нерешенными проблемы с общей теоретической концепцией, поэтому я бы рекомендовал провести тщательное тестирование перед использованием любой FRP-библиотеки в коммерческом проекте (особенно производительность и память вопросы). Посмотрите Frag video. Это стрелок, написанный в FRP и самый современный пример сегодня.

Подумайте о механизме для коммерческой игры, специально для стрелков или гоночных жанров (3D-игры).

Хм, в чем ваш фокус? Вы разрабатываете коммерческую игру? Затем используйте существующий движок и не беспокойтесь об этом! Вы разрабатываете двигатель? Тогда FRP может быть интересной концепцией. Различные игровые объекты с компонентами не должны быть нужны для стрелков и гоночных игр, так как они используют только очень мало различных игровых объектов и слишком много внимания уделяют архитектуре, которая может быть чрезмерной. У вас нет фокуса? Получите фокус! Вы не можете разработать следующий движок IdTech и следующую игру Doom самостоятельно.

Я видел этот документ и предпочитаю стоять на С++, как "отраслевой стандарт"

Есть и некоторые библиотеки для С++. Найдите "реактивное или временное программирование".