Hallo,

ich habe vor in einem Spiel eine Scriptsprache zu verwenden, aber ich will vorher wissen, ob man das in meinem Fall überhaupt so tun kann.

Ich will den Script nicht zum laden oder sowas benutzen, sondern während dem Spiel zwischen den einzelnen Frames. Es soll keine Komplexe Funktion sein,
sondern nur ein paar If-Abfragen und mehrere Funktionen innherhalb meines Programms aufrufen. Also nicht mehr als 10 Zeilen. Während einem Loop würden dann
auch nicht mehr als 4-5 von diesen Scripten ausgeführt werden.

Ich habe noch nie mit Scriptsprachen gearbeitet und weiß deshalb nicht, ob sie so schnell sind, dass es nicht zu Rucklern kommen kann.
Daher meine Frage: Ist eine - und wenn ja welche - Scriptsprache geeignet für mein Problem?

Markus

Das hängt davon ab was das für Funktionen sind, wieviele, ob du Daten aus der Anwendung brauchst, welche, auf welchem Wege.

Lua ist sehr sehr schnell, das Interface zur Anwendung ist auch sehr gut, wenn du also nicht gerade ein Partikelsystem mit steuern willst *hust*, bist du damit wohl ganz gut beraten.
Schau dich doch mal auf http://www.lua.org um.

Gruß Lord Horazont

_________________
If you find any deadlinks, please send me a notification – Wenn du tote Links findest, sende mir eine Benachrichtigung.
current projects: ManiacLab; aioxmpp
zombofant network • my photostream
„Writing code is like writing poetry“ - source unknown

„Give a man a fish, and you feed him for a day. Teach a man to fish and you feed him for a lifetime. “ ~ A Chinese Proverb

Hallo,

nein, ich möchte keine Partikelengine damit steuern , sondern ein paar Events auslösen.
Danke für den Link, ich schau mir das mal an!

Markus

Skripte werden in sehr vielen Spielen benutzt. Besonders in First Persion Shootern sind Skiptsprachen sehr weit verbreitet (ich meine für KI). Far Cry setzt auch auf LUA. Die ganze Unreal Tournament (selbst der erste Teil) benutzt Skripte. Und da solche Spiele zum Promoten eine Engine gedacht sind werden auch die Lizenznehmer der Engine auf die Skripte setzen. Sacred 2 (Rollenspiel) benutzt glaube ich auch LUA. Das sind aber nur ein paar Beispiele.

Die Skripte werden häufig in einer Art Bytecode übersetzt. Der lässt sich wesentlich schneller ausführen als wie wenn man einen Text dauerhaft parsen müsste. Keine Ahnung ob LUA das auch so macht. Kann ich mir gut vorstellen.


Auf heutigen Systemen sollten aber selbst größere Skripte kein Problem mehr darstellen. Im Zweifel genügt es aufwändige Berechnungen in einen extra Thread auszulagern. Damit würdest du dann Mehrkern Prozessoren besser ausnutzen. Und diese sind stark auf dem Vormarsch. Aber so weit (Threads) müsste man gar nicht mal gehen. Wenn man sich klar macht, dass die GPU auch nur eine Art zusätzlicher Kern ist.

Kleines Beispiel. Du hast verschiedene Dinge die gezeichnet werden müssen. Dies geschieht mittels VertexBufferObjects. Nach dem Zeichnen der VBOs rufst du SwapBuffers auf um das gezeichnete auf den Schirm zu bringen. Nach SwapBuffers würden dann deine Skripte laufen. Das wäre zu mindest der klassische und naheliegenste Weg. Aber so würde man den Vorteil einer seperaten PU verspielen. Moderne GPUs arbeiten überwiegend asynchron. Die Befehle werden irgendwo zwischen gepuffert und dann abgearbeitet wenn die GPU Zeit hat. SwapBuffers (und andere Operationen) erzwingt ein Leeren dieses Befehlspuffers. Was daraus resultiert, dass die CPU so lange warten musst bis die GPU fertig ist. Wirklich schnell ist man, wenn man kaum aufeinander warten muss.

Wenn deine Grafikkarte also noch ein paar (zehn oder hundert) tausend Dreiecke zu zeichnen hätte, dann könntest du auf der CPU andere Dinge machen. Und erst danach dann SwapBuffers aufrufen. Also wenn deine Modele groß genug und die Skripte nicht zu groß sind und du sie vor SwapBuffers ausführst (fürs nächste Frame), dann denke ich besteht die Chance, dass die Skriptausführung sich gar nicht oder nur kaum in den FPS wieder spiegelt. Das kommt aber sehr stark auf die Operationen an die du machst. Nicht SwapBuffers wartet auf die Abarbeitung aller Befehle.

Das sind allerdings nur ein paar Ansätze wie man die Abläufe optimieren könnte. Bin wohl etwas vom Thema abgewichen. Ob so etwas überhaupt nötig wird hängt sehr stark von der Komplexibilität deines Spieles ab. Da würde ich auch spontan erst mal behaupten, dass du gar nichts optimieren müsstest sondern es einfach mal ausprobierst. Und wenn du meinst, dass es zu langsam wird, dann kannst du immer noch optimieren.

Wo schon Lua erwähnt wurde werde ich das gleich aufgreifen.
Erstmal eine Scriptsprache ist in erster linie so schnell, wie das Verständnis, des Benutzer, über diese.
Was bei Scriptsprachen in der Spielewelt gemacht wird ist etwas anderes wie z.B. bei einer Software.
Erstmal ist ein Spiel anders aufgebaut und hat andere Ansprüche.
Man sollte bei einer Scriptsprache, die in Verbindung mit endlosen Renderschleifen arbeitet aufjedenfall soviel wie möglich auf Funktionsaufrufe setzen.
Ein Funktionsaufruf ist extrem nahe der ausführungszeit jeder noch so hoch optimierten Sprache.
Denn es passiert nicht mehr als ein push und ein call.
Bei Performanten Anwendungen wird also ein komplexer Code hinter einer Funktion versteckt und diese der Scriptsprache bekannt gemacht.
So dass in der Scriptsprache nicht mehr passiert als, Funktion aufrufen, entscheidung treffen, anhand von gegebenen Werten und wieder eine Funktion aufrufen.
Was nicht rein gehört sind Berechnungen, wertezuweisungen(wie z.B. a=mystr+"test"+inttostr(mynumber) sollten in die Programmiersprache verlagert werden ), komplexere Funktionen.
LUA gehört zu einer der schnellsten Scriptsprachen, besser gesagt sie ist die schnellste, stabilste Scriptsprache, wenn es um längere ausführung geht.
LUA hat wie andere Scriptsprachen auch ein Parser, benutzt eigene Variablentypen und einiges mehr aber durch den Aufbau hat es den anderen Scriptsprachen einiges vorraus. So kann LUA zur laufzeit optimieren, ein integrierte Routine erstellt ein zugriffsranking und optimiert dementsprechend den Bytecode zur laufzeit weiter. LUA setzt auf Tabellen, alles in LUA ist eine Tabelle, was es leicht zu verstehen macht, eine Metatabelle an jeden Objekt erlaubt das Verhalten zu verändern z.B. was passiert, wenn man dem Objekt etwas zuweisen will, ein Element in der Tabelle aufrufen will und so weiter.
LUA setzt auf einfachheit und besitzt nur die Datentypen NULL,NUMBER,BOOLEAN,STRING,OBJECT.
Die meist genutzte Scriptsprache in der Spieleindustrie ist LUA, wenn keine eigene eingesetzt wird, dann ist es in der Regel LUA oder scriptmonkey.
FarCry, Garry's Mod, World of Warcraft und viele mehr nutzen LUA, weil es klein, schnell , robust, leicht modifizierbar und vorallem eine sehr freizügige Lizenz hat.
Viele neue Titel die für PC und XBox360 kommen setzen mitlerweile auf C# als Scriptsprache, auch wenn C# eine Hochsprache mit einen JIT compiler ist.
Denn C# kann durch managed/unmanaged code mit C++ kommunizieren und direkt auf die Klassen zugreifen ohne noch wrapper oder irgendwas anderes zu brauchen.
Titel die auch auf PS3 oder anderen Systemen erscheinen haben diese Möglichkeit nicht.
Eine sehr bekannte Scriptsprache ist z.B. die UE3 Scriptsprache, welche Objekt Orientiert ist und ein starker ableger von der C# Syntax ist.
Allerdings ist diese ziemlich lahm und hat in z.B. schleifentest bis zu 10mal langsamer abgeschnitten als z.B. LUA.
Noch dazu ist diese sehr speicherhungrig, da durch die OO einiges an Metadaten anfällt.

Um zur Frage zurück zu kehren, ich würde dir LUA empfehlen und mach genau das, was du geschrieben hast, funktionen aufrufen und ein paar ifs, denn berechnugnen sind böse. Du kannst je nach einsatz mehrere LUA Sessions aufmachen und z.B. in ein Thread packen, dass sie parallel weiter laufen, ohne auf das rendern warten zu müssen(für z.B. KI,Statusabfragen).
Praktisch ist LUA auch für Materialssystem oder für Startup Scripte(neue hardware da, dann mache x) und Konfigurationsscripte(feature xy gibt es nicht, weiche auf yz aus, a wird supported also verwende besser Setting a).

_________________
"Wer die Freiheit aufgibt um Sicherheit zu gewinnen, der wird am Ende beides verlieren"
Benjamin Franklin

Projekte: https://github.com/tak2004