Existe-t-il un moteur de jeu utilisant un langage de programmation fonctionnel? [fermé]

10

Dans l'état actuel des choses, cette question ne convient pas à notre format de questions / réponses. Nous nous attendons à ce que les réponses soient étayées par des faits, des références ou une expertise, mais cette question suscitera probablement un débat, des arguments, des sondages ou une discussion approfondie. Si vous pensez que cette question peut être améliorée et éventuellement rouverte, visitez le centre d'aide pour obtenir des conseils.

Fermé il y a 7 ans .

Existe-t-il un moteur de jeu utilisant un langage de programmation fonctionnel similaire à Scheme, Common Lisp, Clojure ou JavaScript?

J'ai essayé Unity3D mais leur "JavaScript" n'est pas réellement JavaScript, est fortement typé et n'est pas fonctionnel.

functional

— MaiaVictor
source

2

J'utilise ThreeJS, mais, bien qu'il soit plein de génialité, son manque de communauté active et de documentation est un problème grave.

— MaiaVictor

5

Pourquoi voudriez-vous programmer dans un langage de programmation fonctionnel? Quel est le problème auquel vous êtes confronté? Veuillez être plus précis. Dans l'état actuel des choses, cette question est trop générale pour donner une réponse correcte et elle est susceptible de générer une liste de réponses (toutes également «correctes») comme celle-ci: - Que diriez-vous de Clojure combiné avec n'importe quel moteur de jeu Java? - Que diriez-vous d'adopter un style de programmation fonctionnel dans un langage qui ne soit pas fonctionnel en soi? (Lire Programmation fonctionnelle en C ++ par Carmack.) - etc.

— Eric

2

Le Javascript de Unity3D est aussi fonctionnel que le Javascript ordinaire , il vous suffit d'utiliser des types C # 4.0, quelque chose comme:var add : Func<int, int, int> = ...

— fableal

2

Consultez la FAQ sur les questions "Quelle technologie utiliser". Cette question, comme le montrent les réponses, ne fait que générer une liste. Ce n'est pas constructif car il n'y a pas de réponse correcte unique (autre que "Oui il y en a"). Ce n'est pas l'endroit pour compiler des listes.

— MichaelHouse

2

Il s'agit en quelque sorte d'un problème de "bon outil pour le bon travail". La programmation fonctionnelle est fortement axée sur la réduction et l'élimination, dans la mesure du possible, de l'état mutable. Cela peut bien fonctionner pour certaines classes d'applications, mais c'est complètement contraire à la façon dont tout jeu fonctionne.

— Mason Wheeler

7

Il y a LambdaCube qui est écrit en Haskell (ce n'est pas exactement un moteur de jeu mais plutôt un moteur graphique).

— tumdum
source

2

Cela pourrait également vous intéresser (commentaire général de Tim Sweeney d'Epic)

— tumdum

Lien intéressant, il y a un ppt ici

— bobobobo

2

Vous pouvez toujours utiliser f # ou iron python (oui je sais, python n'est pas fonctionnel) ou tout autre langage .netified avec XNA sur la plate-forme .net.

http://fsharpgamedev.codeplex.com/ http://www.ironpython.info/index.php/XNA_Example_with_a_Bouncing_Sprite

edit: Un moteur de plus, écrit en Lisp: http://code.google.com/p/blackthorn-engine/

— Grzegorz Sławecki
source

2

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.

— Sean Middleditch
source

1

Voir: Clean Game Library (Clean) et Nikki and the Robots (Haskell).

— Andres F.

1

Cette réponse est généralement fausse et semble reposer sur une très mauvaise compréhension des langages fonctionnels réels.

— CA McCann

1

Avez-vous des contre-points réels?

— Sean Middleditch

4

... Quelle expérience avez-vous dans la livraison de jeux de qualité industrielle dans des langages fonctionnels? Si vous avez de l'expérience, partagez-la. Faites des déclarations avec des explications et des justifications, pas des appels à l'expertise ou à l'autorité, ou des accusations personnelles. La probabilité de ce genre d'arguments indignés et de querelles personnelles est exactement la raison pour laquelle cette question a été close.

— Sean Middleditch

4

Tu mets des mots dans ma bouche. Je n'indique pas mon niveau d'expérience car votre opinion sur mon expertise est totalement hors de propos. Ne prétendez pas que vous n'avez pas le temps d'énoncer des faits tout en ayant le temps d'attaquer les niveaux de compétences personnelles. Vous avez probablement de vraies corrections, mais vous devez les indiquer. "Ce type a tort", ce n'est pas une réponse valable pour quiconque. Je peux simplement affirmer que vous vous trompez, puis nous avons un cycle sans fin et inutile de querelles. Veuillez expliquer pourquoi une réponse est incorrecte.

— Sean Middleditch

0

La société Naugthy Dog a utilisé List sur ses moteurs de jeu et elle s'appelait Game Oriented Assembly Lisp.

Certaines informations peuvent être trouvées ici: http://en.wikipedia.org/wiki/Game_Oriented_Assembly_Lisp

Quelques exemples de code: http://web.archive.org/web/20070127022728/http://lists.midnightryder.com/pipermail/sweng-gamedev-midnightryder.com/2005-August/003804.html

Il n'est pas disponible pour un usage public.

— bcsanches
source

Si vous regardez la description de Wikipédia, il devient rapidement évident que GOAL n'était guère un langage fonctionnel, malgré l'ascendance LISP.

— Mason Wheeler