Scripting/Modding Sprache

[Artificial Mind]

Hallo Community,

ich habe mal wieder eine seltsame Technologie-Frage.

Wir sind dabei unser nächstes Game in unserer SpieleProgAG zu planen und würden gerne potentiell Modding und Scripting Support für eine potentielle Player-Community anbieten (natürlich ist das noch Zukunftsmusik, allerdings muss man sich ja vorher über die benutzten Technologien einigen).
Ich würde also gerne mal ein wenig unsere bisherigen Gedankengänge zusammenfassen und etwas Feedback von Euch bekommen.

Damit das Spiel so performant wie möglich bleibt, soll die "Grund-Engine" in C++ geschrieben sein. Außerdem soll das Game auf Mac, Linux und Windows laufen.

Es soll zum einen Mods geben, die quasi im Hintergrund laufen und im großen Stil das Spiel verändern bzw. erweitern können. Zum anderen soll es Scripts geben, die für sich genommen eher überschaubar sind, allerdings potentiell häufig ausgeführt werden bzw. viele Instanzen haben (z. B. könnte jede Einheit durch ein Script gesteuert werden oder jedesmal, wenn ein bestimmtes Objekt auf den Boden auftrifft, wird ein Script aufgerufen, um das Objekt durch zerbrochene Versionen zu ersetzen. Zum Beispiel.)

Da es mir nicht sinnvoll erscheint, sowohl eine Scripting, als auch eine Modding API zu haben, würde ich gerne nur eine API haben, die für Scripte und für Mods geeignet ist. Insbesondere sollten also Scripte und Mods in der gleichen Sprache geschrieben sein.

Für Modder ist es m.M.n. unzumutbar, in C++ Mods zu schreiben, die nicht nur stabil, sondern auch noch plattformunabhängig laufen.

Zum Entwickeln wäre es am besten, eine Sprache zu haben, die man vernünftig dynamisch (lies: zur Laufzeit) neu interpretieren/kompilieren kann, damit man das Spiel nicht neustarten muss, um Änderungen an Mods/Scripten durchzuführen. Außerdem würde man sich gute Debug-Möglichkeiten wünschen.

Größere Mods können durchaus komplex und anspruchsvoll werden, weswegen die Sprache auch nicht allzu inperformant sein sollte.

TL;DR
Ich suche eine Programmiersprache/Technologie für Skripte und Mods, die:

1. Man zur Laufzeit kompilieren kann, bzw. interpretiert ist
2. Von möglichst vielen Leuten geschrieben werden kann
3. Plattformunabhängig ist
4. Kein Performance Bottleneck wird
5. Sich gut debuggen lässt
6. Sowohl für kleinere Scripte, als auch ganze Mods geeignet ist
7. Man gut mit C++ Interop benutzen kann (also gute/schnelle/einfache Kommunikation von und nach C++)

Aussichtsreiche Kandidaten:

• JVM
  + bietet die Möglichkeit in Java, Scala, Clojure etc. zu programmieren
  + Java ist nach C/C++ die am weitesten verbreitete Sprache
  + es gibt gute IDEs und Tools für Java (inklusive Debugging)
  ~ Compile Geschwindigkeit soll bei ca. 10k lines per sec liegen, was ausreichen sollte
  ~ Ausführungsgeschwindigkeit ist nicht die Beste, sollte aber mit JIT akzeptabel sein
  - die JVM bläht das Programm auf
  - der GC kann einem Ärger bereiten (ich weiß allerdings nicht, wieviel sich dort in den letzten Jahren verbessert hat)
  - die C++ Interoperabilität kann zu wünschen übrig lassen (welche Lib würdet Ihr empfehlen/habt Ihr gute Erfahrungen mit? JNI/JNA/...?)
• LLVM VM-Kit (http://vmkit.llvm.org/)
  + man könnte nahezu jede Sprache benutzen, die sich nach llvm compilen lässt (inklusive aller JVM und .NET Sprachen)
  + die Ausführungsgeschwindigkeit sollte sehr gut sein
  ~ ich weiß nicht, wie gut man den Code debuggen kann
  ~ keine Ahnung bezüglich C++-Interop
  - das Projekt ist glaube ich noch sehr jung
  - das Kompilieren könnte u.U. lange/länger dauern
• Lua
  + sehr einfache Anbindung an C++
  + man kann zwischen JIT und interpretieren entscheiden und damit gut dynamisch Code ändern und Performanz vereinen
  ~ hat Debug Möglichkeiten, IDE-Features müsste man wahrscheinlich selbst implementieren
  - Könnte für große Mods zu unhandlich werden
  - Ist nicht allzu sehr verbreitet (allerdings unter Spiele-Moddern wahrscheinlich mehr, als "normale" Sprach-Rankings vermuten lassen, hat da jemand Zahlen?)
• .NET/Mono
  + relativ schnell
  + sehr komfortabel (Achtung: meine Meinung)
  + kompiliert ziemlich schnell
  ~ C++-Interop unter Unix ist mir unklar, unter Windows nur C-style
  ~ Ist mittlerweile relativ weit verbreitet (auch wegen Unity)
  - man hätte wieder ne ganze VM, inklusive .NET Framework dabei

Ich wäre Vorschläge, Kommentare, Feedback, Unklarheiten, Diskussion sehr dankbar.

[antisteo]

Wieso taucht JavaScript in deiner Aufzählung nicht auf?

Nimm die V8. Die hat eine gute JIT-Engine, JavaScript ist Plattformunabhängig und flexibel. JavaScript kann jeder und man hat zudem eine gute Standard-Bibliothek. Die Closures machen es dir einfach, Callbacks und verzögerte Events zu definieren.
In die V8-API arbeitet man sich schnell ein, der einzige Nachteil der API ist, dass sie nur mit C++ funktioniert. Ein C-Interface gibt es meines Wissens nicht, ist auch schwierig, da V8 sich ziemlich viele Scoping-Seiteneffekte von C++ zu Nutze macht.

[Artificial Mind]

Objektorientierung in Javascript fand ich damals sehr unintuitiv. Laut den Rankings ist Java auch wesentlich verbreiteter als JavaScript. Ich habe auch das Gefühl, dass JavaScript nur momentan "beliebter" wird, weil es Projekte wie das Google Web Toolkit gibt, die im Endeffekt auch nicht direkt Javascript sind.
Dass es nur mit C++ funktioniert wäre kein Problem.
Ist es denn mittlerweile performant genug, um es auch für größere Mods zu benutzen?
Wie angenehm kann man Vektor-Arithmetik in JavaScript programmieren?
Möchte man wirklich komplexere Architekturen in JS schreiben?
(Ich muss dazu sagen, ich kenne mich mit neuerem JS nicht mehr aus, habe vor ein paar Jahren zum letzten Mal mehr mit JavaScript gearbeitet und das war meistens eine Qual)

[Chromanoid]

GC ist übrigens bei fast allen deiner genannten Sprachen vorhanden. Und da sollte der von Java noch am schnellsten sein. Java ist unter Linux nach C++ und Co. das schnellste, was du bekommen kannst. Ich frage mich nur, warum nicht gleich alles in Java machen und höchstens sensibelste Teile in C++? Eine JNI Anbidung von Bullet solltest du im jMonkeyEngine-Projekt finden. Das schöne bei allem in Java (oder wenn dich der Geschwindigkeitsverlust nicht stört Mono, siehe http://shootout.alioth.debian.org/u32/w ... astest.php [da wird auch V8 und Co. getestet]) wäre, dass der Modding-Support sozusagen automatisch entsteht. Wie flexibel Java da ist, hat man an den ganzen Minecraft-Mods gesehen, die es schon gab, als MineCraft noch keine Moddingschnittstelle angeboten hat....

[Artificial Mind]

@GC: Ich bin nicht gegen GCs im Allgemeinen, habe nur früher (und auf Android) schlechte Erfahrung mit dem Sun GC gemacht, der regelmäßig das Programm für einen Bruchteil einer Sekunde spürbar eingefroren hat. Vom .NET GC habe ich das allerdings noch nie gemerkt, obwohl ich schon den größten Schwachsinn dort gemacht habe (Reference type Vector Arithmetik).

@Modding: Also das was in Minecraft als "Modding" galt war doch eine reine Katastrophe. Im obfsucated Java Code rumwerkeln ist doch echt nicht feierlich. Dann lieber von Anfang an eine gute Schnittstelle einplanen.

@Java: Was gegen "alles in Java" spricht: Vector/Matrix-Arithmetik (insbesondere fehlende value types und Operatorüberladung), Terrain Generation, Path finding auf dem Terrain Mesh, Bullet (auch hier haben wir viele und häufige Änderungen auf zehn- bis hundertausenden von Dreiecken). Also dein Link beruhigt und bestärkt mich darin, die JVM als Modding/Scripting-Technologie zu nehmen. Hätte nicht gedacht, dass es mittlerweile SO gut ist. Aber ich glaube, dass wir echt viele arithmetisch anspruchsvolle Berechnungen haben und auch die Rendering Pipeline sollte performant gehalten werden (dort werden wir insbesondere viele Culling-Berechnungen haben). Ein wahrscheinlich noch viel größeres Problem ist die Speicherverwaltung. Die Spielgrundlage ist ja salopp gesagt ein "Minecraft-Clone" und ich sehe bereits jetzt an meinem Terrain Prototypen, dass man sehr schnell an RAM-Grenzen stößt. Bei so indeterministischer Speicherverwaltung wie bei Java hat man da glaube ich echt Probleme. Der Minecraft Server ist bei mir deswegen erst ab 4GB Java VM Ram vernünftig benutzbar und sobald ich im Multiplayer in den Nether gehe, fängt der Server nur noch an zu ruckeln. Der Blockscape Entwickler (Sprache: C#) hat letztens getwittert: "I'm finally back from memory optimization hell. Don't go there! Ever!". Ich glaube dort sind die GC-Sprachen einfach etwas schwach, stimmts?

Die Idee ist trotzdem, möglichst viel vom Game Code in Java zu schreiben, damit man das Runtime ändern/entwickeln kann und das Game nicht neugestartet werden muss. Das ist vom Entwicklungsflow her einfach genial.

[Chromanoid]

Ich glaube dort sind die GC-Sprachen einfach etwas schwach, stimmts?

Jo, sicher, daher bau dir für die Teile wo du Angst um Speichermüll hast doch eine JNI Schnittstelle. Das sorgt außerdem gleich dafür, dass das ganze schön gekapselt wird. Ich habe übrigens recht gute Erfahrungen mit JBullet gemacht (http://zfx.info/viewtopic.php?f=10&t=112&p=27266#p27266). JBullet nutzt Pooling um den Müll, der durch Mathe-Objekte erzeugt wird, im Griff zu behalten.

[Artificial Mind]

Ich denke wir meinen mittlerweile das Gleiche nur aus ner anderen Perspektive.
Du sagst, nimm Java und für alles Performance/Speicherkritische dann JNI.
Ich sage, die Core Engine in C++, Gameplay in Java. Die Core Engine ist aber wahrscheinlich genau all das Kritische ;)

Wie ist denn das eigentlich mit der Java Anbindung. JNI ist ja nicht das Einzige, es gibt auch mindestens noch JNA und noch einige andere. Gibt es da gravierende Unterschiede wegen Debugbarkeit, Wartung, Code Duplication etc.?

[Chromanoid]

JNA ist afaik ziemlich langsam. Es ist AFAIK einfacher native Sachen aus Java heraus anzusprechen und zu steuern als umgekehrt. Bei Letzterem weiß ich allerdings nicht woher ich das habe...

Falls du micro-benchmarking machen willst, kann ich http://code.google.com/p/caliper/ empfehlen.

[dot]

Ich würd mal Lua (wurde ja schon genannt), Python, AngelScript und Squirrel in die Runde werfen...

Von Java und .NET würd ich persönlich wohl eher absehen, wenn ich eine light weight Solution will. Ich hab aber auch nicht wirklich viel Erfahrung in dem Gebiet...

[Artificial Mind]

Python mag ja noch etwas verbreitet sein, aber die beiden anderen sagten mir bis jetzt nichts und ich glaube deren Verwendung ist echt gering. Ich glaube das wäre unklug auf so "exotische" Lösungen zu setzen, weil man sich damit viele potentielle Modder vergrault.

@Chromanoid: Wie genau man den Kontrollfluss steuert, ist ja erstmal nebensächlich. Man muss ja auch gucken, woher man den OpenGL Context und den Maus/Tasten-Input bekommt. Außerdem ist zum Entwickeln die AntTweakBar unglaublich praktisch und die will dann ja auch vernünftig angebunden sein.
Ich werde das einfach mal in meinem Prototypen prüfen, wie angenehm die Kommunikation und das Debugging tatsächlich ist. An der eigentlichen Technologieentscheidung sollte das ja nichts ändern.

[dot]

Python mag ja noch etwas verbreitet sein, aber die beiden anderen sagten mir bis jetzt nichts und ich glaube deren Verwendung ist echt gering. Ich glaube das wäre unklug auf so "exotische" Lösungen zu setzen, weil man sich damit viele potentielle Modder vergrault.

Squirrel und AngelScript stammen afaik aus der Feder von Spieleentwicklern und sind daher von vornherein vor allem auf Spieleentwicklung ausgelegt. Über Angel Script bin ich auf gamedev.net schon öfter gestolpert (ich kenn die Sprache überhaupt erst von dort) und nachdem offenbar z.B. Portal 2 und Left 4 Dead 2 Squirrel benutzen, würd ich jetzt mal nicht sagen, dass es sich da um derart exotische Sprachen handelt. Ich hab keine der beiden Sprachen selbst je benutzt. Der Grund, aus dem ich sie hier genannt hab, ist, dass man eben im Zusammenhang mit Spieleentwicklung immer wieder über diese Namen stolpert... ;)

Edit: Was Popularität angeht, ist Lua im Gamingsektor allerdings sicherlich ziemlich weit vorne dabei, noch wesentlich vor Squirrel oder AngelScript...

[Artificial Mind]

Ich habe mich ein wenig an folgendem orientiert, auch wenn das natürlich allgemeine Beliebtheit ist: http://www.tiobe.com/index.php/content/ ... index.html

Egal von welcher Seite du guckst, mit Java (und damit implizit ja auch Scala, Clojure usw.) würden wir wesentlich (ganze Größenordnungen) mehr Modder erreichen. Und anscheinend ist das von der Performance her im Vergleich zu anderen managed/interpreted Sprachen nicht zu toppen.

Es geht ja auch nicht nur um kleinere Scripte sondern auch um komplette Mods, die teilweise echt weitreichend seien können.
Wenn man sich beispielsweise den Aether Mod von Minecraft anguckt (http://www.minecraftforum.net/topic/194 ... i-shockah/), dann ist das schon ziemlich komplex.

Edit: Lua hatten wir auch für unser letztes Projekt benutzt, allerdings möchte man in Lua keine großen Mods schreiben. Aber da Lua tatsächlich relativ beliebt ist, hab ich das ja auch meiner Liste im OP. Trotzdem würde ich behaupten, dass Java immer noch weiter verbreitet ist als Lua, auch unter Spieleprogrammierern.

[dot]

Also den Tiobe Index würd ich jetzt nicht zu ernst nehmen, der ist prinzipiell nicht mehr als das...

Java und .NET sind jedenfalls sicherlich alles andere als ligh weight.

Was "komplette Mods" angeht, würd ich persönlich vermutlich zu C++ greifen, da dir da ja scheinbar eher sowas wie ein komplett eigenständiges und völlig unabhängiges Game vorschwebt. Ich würde generell keine größeren Projekte in einer dynamisch (und am Ende vielleicht sogar noch schwach) typisierten Sprache schreiben wollen, wie Scriptsprachen es oft sind.

[Artificial Mind]

Was "komplette Mods" angeht, würd ich persönlich vermutlich zu C++ greifen, da dir da ja scheinbar eher sowas wie ein komplett eigenständiges und völlig unabhängiges Game vorschwebt.

Du kannst deinen Moddern nicht zumuten, plattformunabhängig einen C++-Mod zu schreiben. Mir schwebt auch nicht vor, dass die Mods selbstständig neue Spiele ergeben, sondern eher wie bei Minecraft kombiniert werden können.
C++ ist außerdem vom Workflow her echt unangenehm zu programmieren. Bei Java können wir tatsächlich den Code Runtime auf Klassen/Funktionsbasis austauschen. Mit C++ wird man bei steigender Projektgröße zwangsläufig unproduktiv, wenn man sich nicht viele Debug Tools oder runtime-changeable Techniken schreibt.

Ich würde generell keine größeren Projekte in einer dynamisch typisierten Sprache schreiben wollen.

Deswegen die Idee, das in einer JVM zu machen.

[dot]

Nun, dann schau dir mal Mono an (afaik basiert z.B. auch Unity auf Mono). Ich würd jedenfalls eine .NET CLR einer JVW vorziehen, da .NET technisch imo in wesentlichen Punkten überlegen ist. Allem voran schon die Tatsache, dass es Value Types kennt, was für die Performance von Dingen wie z.B. Vektorarithmetik entscheident sein könnte, wie du ja selbst schon sagtest. Damit handelst du dir nur eben z.B. wieder Garbage Collection ein. Aber irgendwo wirst du wohl eben Abstriche machen müssen; Performance und Programmieraufwand liegen nunmal leider an zwei ziemlich verschiedene Enden des Spektrums und man kann sich eben nur irgendwo in der Mitte treffen...

Edit: Wie die Unreal Engine 4 mit Kismet zeigt, könnten möglicherweise übrigens bald graphische Programmiersprachen traditionelles Scripting großteils ablösen; zumindest wenn es rein um Produktivität geht...

Edit 2: Hot Swapping lässt sich über dlls/Shared Objects/etc. übrigens auch für Native Code realisieren. Ich hab da grad unlängst irgendwo eine recht eindrucksvolle Implementierung in irgendeiner Engine oder so gesehen, wenn ich es blos finden könnte...

[antisteo]

Was "komplette Mods" angeht, würd ich persönlich vermutlich zu C++ greifen, da dir da ja scheinbar eher sowas wie ein komplett eigenständiges und völlig unabhängiges Game vorschwebt.

Du kannst deinen Moddern nicht zumuten, plattformunabhängig einen C++-Mod zu schreiben. Mir schwebt auch nicht vor, dass die Mods selbstständig neue Spiele ergeben, sondern eher wie bei Minecraft kombiniert werden können.

Da kann JavaScript zum Beispiel auch mit der prototypenbasierten Programmierung punkten. Man betrachte nur, wie gut die Webseiten da draußen zusammenarbeiten, obwohl jedes Social Plugin seinen eigenen Code in den Scope einführt.
Was die Sprache an sich angeht, gibt dir die Wiki (http://de.wikipedia.org/wiki/JavaScript) einen ziemlich guten Überblick, was JavaScript (und nicht die DOM API) ist.

Ich würde generell keine größeren Projekte in einer dynamisch typisierten Sprache schreiben wollen.

[senf]Wenn man die Architektur gut wählt und den Performanceverlust durch Skalierbarkeit (dank managed Code leichter zu erreichen) ausgeglichen wird, warum nicht?[/senf]

[pUnkOuter]

+1 für Angelscript.

[Andre]

Habe ebenfalls zu AngelScript gegriffen. Damals war eigentlich Lua geplant, aber sowol die Sprache, als auch die API gefielen mir nicht. Kann es bis jetzt auch nur weiterempfehlen, ich kenn mich nur mit vielen der anderen Sprachen, die hier schon aufgezählt wurden nicht besonders aus ;)

[Artificial Mind]

Ich habe mir jetzt mal AngelScript etwas genauer angesehen und es scheint tatsächlich relativ gut als Spiele-Scriptsprache zu taugen. Wie steht es mit der Performance? (Auf der Webseite steht JIT, aber wie schnell ist das wirklich?)

[Andre]

Zum JIT-Compiler gibt es mehr hier: http://www.gamedev.net/topic/620390-fir ... available/
Allerdings benutze ich den (noch) nicht und habe trotzdem keinerlei Performanceprobleme. Allerdings beschränkt sich mein Scriptgebrauch im Moment auch eher auf ein paar simplere Testscripts.

[Artificial Mind]

So, ich habe mal AngelScript eingebunden und mir einen "Zauber" gebaut, der zufällig um die angeklickte Version 20 Metallstacheln aus dem Boden wachsen lässt. Sehr coole Sache das.

Die Syntax der Sprache gefällt mir auch echt gut.

[Andre]

Das einzige was mir manchmal ein Bein stellt sind die Pointerzuweisungen, bzw. deren Benutzung bei Ifs. :D

Code: Alles auswählen

@Object = Create(); // <- So soll es sein
Object = Create(); // <- Geht nicht 

Demzufolge muss man auch in einem If @Object benutzen, wenn man es auf "null" prüfen will. Aber man kann sich ja an alles gewöhnen.

[Artificial Mind]

Besser als Speicherlöcher oder Pointer-Gewusel in der Skriptsprache ;)

[Chromanoid]

Ist dir bestimmt auch schon über den Weg gelaufen: http://www.swig.org
Sieht echt interessant aus finde ich, besonders wenn man bedenkt, dass das ganze trotz der uralt aussehenden website scheinbar noch regelmäßig aktualisiert wird. Auf jeden Fall könntest du so deine Kernfunktionalität schon jetzt entwickeln und dann erst später entscheiden welche Scriptsprache/VM du nun nutzen willst. Ich glaube bei Assimp wurde das auch mal benutzt.

[Artificial Mind]

Danke, das sieht in der Tat interessant aus. Wenn man vernünftig kapselt, kann man die Kernfunktionalität wahrscheinlich auch so ohne den Wrapper schreiben, Lua oder AngelScript-Anbindung ist jedenfalls relativ minimalinvasiv. Bei JNI weiß ich das nicht genau.

[Chromanoid]

Ich denke es ist auf jeden Fall einfacher mit SWIG als das mit JNI selbst zu machen. Außerdem hättest du dann auch immer noch Varianten mit Python, C# etc. offen.

[Eike Anderson]

Aber da Lua tatsächlich relativ beliebt ist, hab ich das ja auch meiner Liste im OP. Trotzdem würde ich behaupten, dass Java immer noch weiter verbreitet ist als Lua, auch unter Spieleprogrammierern.

Lua ist eine der meistgenutzten Scriptsprachen in der Spieleentwicklung (siehe auch Marc DeLoura's Game Engine Survey: http://www.gamasutra.com/blogs/MarkDeLo ... esults.php ). Die Anzahl der AAA Spiele, die Lua nutzen (z.B. alle Spiele von Relic) ist recht gross... (Auswahl: http://en.wikipedia.org/wiki/Category:L ... ideo_games )
Ich denke ich liege nicht falsch, wenn ich annehme, dass es wesentlich mehr AA Spiele gibt die Lua verwenden als solche die Java verwenden.

Persoenlich wuerde ich Lua nehmen - der Footprint ist sehr gering (Python dagegen hat einen ziemlichen Overhead).

[kimmi]

+1 AngelScript
+1 Lua

Weil minimaler Eingriff, leichtgewichtig und recht elegant erweiterbar. Ich persönlich mag Lua mehr, weil ich mich halt mit Lua besser auskenne :).

Gruß Kimmi

[Artificial Mind]

Java ist wahrscheinlich echt eher die Kanonenlösung.

Ich hab jetzt ein Semester lang mit Lua arbeiten müssen und es ist zwar nicht schlecht, aber man bekommt schnell Performanceprobleme und die Syntax ist schon etwas gewöhnungsbedürftig.
Bei AngelScript kann sich wahrscheinlich unser Team wesentlich besser einarbeiten. Es wird auch schon von ein paar Leuten verwendet: http://www.angelcode.com/angelscript/users.html

Lua is a solution that can work, but people tend to have a love/hate relationship with it. Using Lua on performance-constrained platforms can definitely be a challenge if you don’t understand the ins and outs of Lua’s memory usage.

Die Registrierung von Klassen in Lua und in AngelScript ist allerdings so ähnlich, dass man wahrscheinlich das so Kapseln kann, dass man entweder beides direkt unterstützt oder es ohne Probleme auswechseln kann.

[Schrompf]

Ich dagegen mag AngelScript mehr, und zwar aus demselben Grund: ich kenne mich damit besser aus. Abgesehen davon halte ich jeder dieser Skriptsprachen für eine gute Weil, aus den schon genannten Gründen: schön gekapselt, einfache Interaktion mit C++, leichtgewichtig, und dank JIT auch ziemlich fix. Das Tempo reicht für Spiellogik allemal, komplexe Spielwelt-Aktionen wie zum Beispiel "gibt mir aus den fünf Millionen Objekten alle im Umkreis von 1m" sollte man aber besser auf Host-Seite zur Verfügung stellen.