Gibt es eine Spiel-Engine, die eine funktionierende Programmiersprache verwendet? [geschlossen]

10

Gibt es eine Spiel-Engine, die eine funktionale Programmiersprache verwendet, die Scheme, Common Lisp, Clojure oder JavaScript ähnelt?

Ich habe Unity3D ausprobiert, aber ihr "JavaScript" ist eigentlich kein JavaScript, ist stark typisiert und funktioniert nicht.

functional

— MaiaVictor
quelle

2

Ich verwende ThreeJS, aber obwohl es voller Großartigkeit ist, fehlt es an einer aktiven Community, und die Dokumentation ist ein ernstes Problem.

— MaiaVictor

5

Warum sollten Sie in einer funktionalen Programmiersprache programmieren wollen? Was ist das Problem, mit dem Sie konfrontiert sind? Bitte sei spezifischer. Derzeit ist diese Frage zu allgemein, um eine richtige Antwort zu erhalten, und es besteht die Gefahr, dass eine Liste von (alle gleichermaßen "richtigen") Antworten wie folgt erstellt wird: - Wie wäre es mit Clojure in Kombination mit einer Java-Game-Engine? - Wie wäre es mit einem funktionalen Programmierstil in einer Sprache, die per se nicht funktionsfähig ist? (Lesen Sie die funktionale Programmierung in C ++ von Carmack.) - usw.

— Eric

2

Unity3D ist Javascript ist ebenso funktional wie regelmäßige Javascript, Sie müssen nur C verwenden # 4.0 Typen, so etwas wie:var add : Func<int, int, int> = ...

— fableal

2

Weitere Informationen finden Sie in den häufig gestellten Fragen zu den zu verwendenden Technologien. Diese Frage generiert, wie die Antworten zeigen, nur eine Liste. Es ist nicht konstruktiv, da es keine einzige richtige Antwort gibt (außer "Ja, das gibt es"). Dies ist nicht der Ort, um Listen zu erstellen.

— MichaelHouse

2

Dies ist eine Art "richtiges Werkzeug für den richtigen Job" -Problem. Die funktionale Programmierung konzentriert sich stark auf die Minimierung und Beseitigung von veränderlichen Zuständen, wo immer dies möglich ist. Das mag für bestimmte Anwendungsklassen gut funktionieren, ist aber völlig entgegengesetzt zu der Art und Weise, wie fast jedes Spiel funktioniert.

— Mason Wheeler

7

Es gibt LambdaCube, der in Haskell geschrieben ist (es ist nicht gerade eine Spiel-Engine, sondern eher eine Grafik-Engine).

— Tumdum
quelle

2

Dies könnte auch für Sie von Interesse sein (allgemeiner Kommentar von Tim Sweeney aus Epic)

— Tumdum

Interessanter Link, gibt es eine ppt hier

— bobobobo

2

Sie können jederzeit f # oder Iron Python (ja, ich weiß, Python funktioniert nicht) oder eine andere .netified-Sprache mit XNA auf der .net-Plattform verwenden.

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

Bearbeiten: Eine weitere Engine, geschrieben in Lisp: http://code.google.com/p/blackthorn-engine/

— Grzegorz Sławecki
quelle

2

Ich habe keine Antwort auf die Frage wie geschrieben, aber ich glaube, Sie versuchen möglicherweise zu fragen, "warum es keine funktionaleren Spiel-Engines gibt", anstatt nach einer bestimmten zu suchen. Wenn das richtig ist, sollten Sie die Frage umformulieren. Wenn nicht ... ignoriere mich. :) :)

Ein rein funktionaler Ansatz passt nicht zu Spielen. Spiele (und Grafiken, Physik und KI) und im Grunde alles über Zustandsänderungen. Der richtige funktionale Ansatz für diese Probleme wäre, einmal pro Schleife einen völlig neuen Zustand zu berechnen, was eine sehr schwerwiegende Leistungseinbuße mit sich bringt, verglichen mit einer direkteren Codierung der tatsächlichen Hardware.

Aus diesem Grund sehen Sie in der Produktion keine funktionalen Game-Engines. Es ist einfach das falsche Programmierparadigma für die meisten Probleme, die eine Spiel-Engine lösen soll. Es ist das falsche Programmierparadigma für die meisten Probleme, die auch in übergeordneten Skripten und im Spielelogikcode gelöst werden müssen. Während es mit ziemlicher Sicherheit möglich ist, eine funktionierende Spiel-Engine zu erstellen, wäre ihre Verwendung langsam, schwierig und umständlich und würde keinem anderen Zweck dienen, als eine ordentliche Demo / ein Spielzeug zu sein, um sich zu präsentieren.

Das heißt nicht, dass funktionale Programmierung keinen Platz in Spielen hat. Ich verwende einen sehr funktionalen Codierungsstil (wo zutreffend) in C #, Unity JavaScript und sogar C ++ 11. Einige sehr spezifische Probleme lassen sich am besten oder zumindest am einfachsten mit einem funktionalen Stil lösen, und die meisten gängigen Sprachen unterstützen diese Form der Programmierung heutzutage, wenn auch umständlicher als "echte" funktionale Sprachen. Normalerweise sind diese mit funktionalen Ansätzen gelösten Probleme weder im Code der Kern-Engine noch im Code enthalten, der im Spiel selbst ausgeführt wird. Die funktionale Codierung kann für Tools und die Offline-Datenverarbeitung (z. B. Backmodelle und andere Assets) von großem Vorteil sein. Es ist auch fraglich, ob die GPU-Programmierung bei der Schreibweise von Algorithmen vage funktioniert.

Natürlich kann es immer noch am besten sein, funktionale Ansätze außerhalb ganz bestimmter Umstände zu vermeiden, da diese Offline-Tools so schnell wie möglich sein sollen. Funktionale Sprachen zeichnen sich durch Parallelität aus, was für einige Probleme gut ist, aber die Abstraktionen von der Hardware führen tendenziell zu einer sehr ineffizienten Single-Threaded-Leistung. (Sprachen wie LISP machen sich hier gut, weil sie nicht rein funktional sind, und tatsächlich ist Common LISP ein Multi-Paradigma.) Das absolut Schlimmste für eine Game Engine oder ein verwandtes Toolkit ist, ein Engpass für die Iteration von Inhalten zu sein. Eine ausgefallene Engine mit vielen Funktionen, für die Künstler oder Leveldesigner Stunden benötigen, um das zu tun, was in 5 Minuten (oder im Idealfall fast sofort) erledigt werden kann, führt aufgrund der Budgeteskalation nur zu Spielen von geringer Qualität oder zur Stornierung.

— Sean Middleditch
quelle

1

Siehe: Clean Game Library (Clean) und Nikki und die Roboter (Haskell).

— Andres F.

1

Diese Antwort ist größtenteils falsch und scheint auf einem sehr schlechten Verständnis der tatsächlichen funktionalen Sprachen zu beruhen.

— CA McCann

1

Haben Sie tatsächliche Gegenpunkte?

— Sean Middleditch

4

... Wie viel Erfahrung haben Sie mit Spielen in Industriequalität in funktionalen Sprachen? Wenn Sie Erfahrung haben, teilen Sie diese. Geben Sie Erklärungen mit Erklärungen und Begründungen ab, ohne sich auf Fachwissen oder Autorität oder persönliche Anschuldigungen zu berufen. Die Wahrscheinlichkeit dieser Art von empörtem Streiten und persönlichem Streit ist genau der Grund, warum diese Frage geschlossen wurde.

— Sean Middleditch

4

Du steckst mir Worte in den Mund. Ich gebe mein Erfahrungsniveau nicht an, da Ihre Meinung zu meinem Fachwissen für das Thema völlig irrelevant ist. Behaupten Sie nicht, dass Sie keine Zeit haben, Fakten darzulegen, während Sie Zeit haben, persönliche Fähigkeiten anzugreifen. Sie haben wahrscheinlich echte Korrekturen, aber Sie müssen sie angeben. "Dieser Typ ist falsch" ist für niemanden ein wertvolles Antwortfeedback. Ich kann nur behaupten, dass Sie falsch liegen, und dann haben wir einen endlosen und sinnlosen Kreislauf von Streitereien. Bitte sagen Sie, warum eine Antwort falsch ist.

— Sean Middleditch

0

Die Firma Naugthy Dog verwendete List für ihre Game Engines und hieß Game Oriented Assembly Lisp.

Einige Informationen finden Sie hier: http://en.wikipedia.org/wiki/Game_Oriented_Assembly_Lisp

Einige Codebeispiele: http://web.archive.org/web/20070127022728/http://lists.midnightryder.com/pipermail/sweng-gamedev-midnightryder.com/2005-August/003804.html

Es ist nicht für den öffentlichen Gebrauch verfügbar.

— bcsanches
quelle

Wenn Sie sich die Beschreibung von Wikipedia ansehen, wird schnell klar, dass GOAL trotz der LISP-Abstammung kaum eine funktionale Sprache war.

— Mason Wheeler