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 самостоятельно.
Я видел этот документ и предпочитаю стоять на С++, как "отраслевой стандарт"
Есть и некоторые библиотеки для С++. Найдите "реактивное или временное программирование".
