У меня нет ответа на этот вопрос в письменном виде, но я полагаю, что вы, возможно, пытаетесь спросить «почему нет более функциональных игровых движков», чем искать конкретный для использования. Если это правильно, вы должны перефразировать вопрос. Если нет ... игнорируй меня. :)
Чисто функциональный подход не очень подходит для игр. Игры (и графика, и физика, и ИИ) и в основном все об изменениях состояния. Правильный функциональный подход к этим проблемам будет состоять в том, чтобы вычислять полностью новое состояние один раз за цикл, что будет иметь очень серьезное снижение производительности по сравнению с кодированием, более непосредственным для того, как работает реальное оборудование.
По этой причине вы не видите игровых движков в функциональном стиле в производстве. Это просто неправильная парадигма программирования для большинства задач, которые должен решить игровой движок. Это неправильная парадигма программирования для большинства проблем, которые также должны быть решены в сценариях более высокого уровня и в игровом логическом коде. Хотя почти наверняка возможно создать функциональный игровой движок, он будет медленным, сложным и громоздким в использовании, и не будет служить никакой реальной цели, кроме того, чтобы быть аккуратной демонстрацией / игрушкой для демонстрации.
Это не значит, что функциональному программированию не место в играх. Я использую очень функциональный стиль кодирования (где это уместно) в C #, Unity JavaScript и даже C ++ 11. Некоторые очень специфические проблемы лучше или, по крайней мере, легче всего решить с помощью функционального стиля, и большинство популярных языков сегодня поддерживают эту форму программирования, хотя и более громоздким способом, чем «настоящие» функциональные языки. Обычно эти проблемы, решаемые с помощью функциональных подходов, отсутствуют ни в коде ядра движка, ни в коде, который выполняется в самой игре. Функциональное кодирование может быть весьма полезным для инструментов и автономной обработки данных (например, моделей выпечки и других активов). Также можно утверждать, что программирование на GPU неопределенно функционально при написании алгоритмов,
Конечно, все же может быть лучше избегать функциональных подходов вне очень специфических обстоятельств, поскольку вы хотите, чтобы эти автономные инструменты работали как можно быстрее. Функциональные языки превосходят параллелизм, что хорошо для некоторых проблем, но абстракции от аппаратных средств обычно приводят к очень неэффективной однопоточной производительности. (Такие языки, как LISP, здесь хороши, потому что они не являются чисто функциональными, и на самом деле Common LISP - это мультипарадигма.) Абсолютно худшая вещь для игрового движка или связанного инструментария - быть узким местом для итерации контента. Причудливый движок с множеством функций, который требует от художников или дизайнеров уровней часов, чтобы сделать то, что можно сделать за 5 минут (или, в идеале, почти мгновенно), просто приведет к низкому качеству игр или отмене из-за увеличения бюджета.