Je n'ai pas de réponse à la question telle qu'elle est écrite, mais je pense que vous essayez peut-être de demander "pourquoi n'y a-t-il pas de moteurs de jeu plus fonctionnels" plutôt que d'en chercher un spécifique à utiliser. Si c'est correct, vous devriez reformuler la question. Sinon ... ignorez-moi. :)
Une approche fonctionnelle pure ne convient pas aux jeux. Jeux (et graphiques, physique et IA) et essentiellement tout sur les changements d'état. L'approche fonctionnelle correcte de ces problèmes serait de calculer un nouvel état entier une fois par boucle, ce qui entraînera une pénalité de performance très sévère par rapport au codage plus direct du fonctionnement réel du matériel.
C'est pour cette raison que vous ne voyez aucun moteur de jeu de style fonctionnel en production. C'est tout simplement le mauvais paradigme de programmation pour la majorité des problèmes qu'un moteur de jeu est censé résoudre. C'est le mauvais paradigme de programmation pour la majorité des problèmes qui doivent également être résolus dans les scripts de niveau supérieur et le code logique du jeu. Bien qu'il soit presque certainement possible de créer un moteur de jeu fonctionnel, il serait lent, difficile et lourd à utiliser, et ne servirait à rien d'autre que d'être une démo / un jouet soigné à montrer.
Cela ne veut pas dire que la programmation fonctionnelle n'a pas sa place quelque part dans les jeux. J'utilise un style de codage très fonctionnel (le cas échéant) en C #, Unity JavaScript et même C ++ 11. Certains problèmes très spécifiques sont mieux ou du moins plus facilement résolus avec un style fonctionnel, et la plupart des langages populaires supportent aujourd'hui cette forme de programmation, quoique d'une manière plus lourde que les "vrais" langages fonctionnels. Habituellement, ces problèmes résolus avec des approches fonctionnelles ne sont pas dans le code du moteur de base, ni dans le code qui s'exécute dans le jeu lui-même. Le codage fonctionnel peut être très bénéfique pour les outils et le traitement de données hors ligne (modèles de cuisson et autres actifs, par exemple). On peut également soutenir que la programmation GPU est vaguement fonctionnelle dans la façon dont les algorithmes sont écrits,
Bien sûr, il peut être préférable d'éviter les approches fonctionnelles en dehors de circonstances très spécifiques, car vous souhaitez que ces outils hors ligne soient aussi rapides que possible. Les langages fonctionnels excellent dans le parallélisme, ce qui est bon pour certains problèmes, mais les abstractions du matériel ont tendance à conduire à des performances à un seul thread très inefficaces. (Des langages comme LISP fonctionnent bien ici car ils ne sont pas purement fonctionnels, et en fait Common LISP est multi-paradigme.) La pire chose absolue pour un moteur de jeu ou une boîte à outils associée est d'être un goulot d'étranglement pour l'itération de contenu. Un moteur sophistiqué avec beaucoup de fonctionnalités qui prend des heures aux artistes ou aux concepteurs de niveaux pour faire ce qui pourrait être fait en 5 minutes (ou idéalement presque instantanément) entraînera simplement des jeux de faible qualité ou une annulation en raison de l'escalade budgétaire.