Ich rate doch eher die finger von eigenen Scriptsprachen zu lassen und auf existierende zu gehen.
Lua ist eine sehr einfache und sehr schnelle Scriptsprache. Sie wird in der Spieleindustrie sehr häufig genutzt.
Die anbindung von eigenen Code ist sehr leicht. Ich habe die GUI von X-Dream an Lua angebunden und mein Material System läuft auch über Lua. Ich habe eine Unit geschrieben die durch RTTI vieles von selber macht um eine Schnittstelle zu etablieren.
Wenn Interesse besteht, meien ICQ Nummer hast du ja schon

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

Projekte: https://github.com/tak2004

Ich würde die Finger komplett von Skriptsprachen lassen, den die Zeit der Skriptsprachen nähert sich dem Ende( Das ist nicht nur meine Meinung ).

_________________
Shareholder und Leitender Entwickler bei Pipedream-Games.

Zitat: Siehst du diesen Park da unten? Jeden Tag lernen sich darin Menschen kennen und verlassen einander. Und du hast dein ganzes Leben Zeit darin zu gehen.

Da Skripte bzw. deren Bytecode oft interpretiert werden, kann man sie leicht anhalten und im nächsten Frame oder nach einer gewissen Zeit wieder fortsetzen. Damit kann man Aktionen programmieren, die über mehrere Frames ausgeführt werden und für die man ansonsten einen Automaten benötigen würde.

@SpeedMaster Kannst du mir mal Links zu deinen Bezugsquellen geben ?
Weil meine Erfahrung zeigt, das der Scriptgebrauch eher zu nimmt, als abnimmt.
Aktuelle Engines(Unreal3, Doom3) nutzen Scripts für alles KI, Materials, Events, Interface, Maps selbt vor Animationssystemen wird nicht mehr halt gemacht. Ledeglich die Scriptsprachen selber ändern sich. Ist auch verständlich, weil so kann man sich viel Zeit für den Programmierer sparen und Game Designer können schon viel früher und viel besser in den Game Content eingreifen.
Ausserdem, wenn ein Script wegschmiert ist es kein Problem, das Game weiter fort zu führen. Wenn allerdings die App wegschmiert muss man neustarten und alles muss neugeladen werden und Daten gehen verloren.

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

Projekte: https://github.com/tak2004

Hi,

Ich verstehe natürlich, wenn von sowas abgeraten wird (zu Recht). Ich hab es ja selbst schon geschrieben: Es geht mir weniger darum, das xte Scriptsystem ins Netz zu werfen, sondern mehr um die Erfahrungen, die ich dadurch sammle und weiterverwenden kann. Gerade mit Boliden wie LUA will ich mich nicht messen. Aber man nimmt eben, was man kriegen kann

@SpeedMaster+TAK
Ich glaube ihr redet aneinander vorbei. SpeedMaster hat glaub ich Scriptsprachen wie Python gemeint. Trotzdem stimme ich TAK zu - man denke an Java und .NET. In beiden fällen werden sie afaik immer häufiger verwendet.

gruß

_________________
I'm not the signature, I'm just cleaning the floor...

Derzeitiges Projekt:
FireBlade Particle Engine (Release R2 2009.06.29)

Jepp, ab Java 6 wird Groovy ein offizieller Bestandteil des Java Paketes sein. Das wird sicher sehr interessant

_________________
(\__/)
(='.'=)
(")_(")

Ich meinte Damit Tatsächlich, das die Zeit der Skriptsprachen wie Python, LUA & Co vorbei sind.

In Zukunft wird als Beispiel immer häufiger C# verwendet. Grund dafür ist das der Quellcode genauso wie in Skriptsprachen, nicht vorkompilliert werden muss, da dies zur Laufzeit geschehen kann. Zumal man das ganze auch in Unmanaged Applikationen verwenden kann.
Und das Abschmieren kannst du immer noch Abfangen indem du deinen Code mit try..catch.. ummauerst, das dürfte schneller sein als ein Skriptinterpreter.

_________________
Shareholder und Leitender Entwickler bei Pipedream-Games.

Zitat: Siehst du diesen Park da unten? Jeden Tag lernen sich darin Menschen kennen und verlassen einander. Und du hast dein ganzes Leben Zeit darin zu gehen.

Aber c# ist auch nicht unproblematisch zum Skripten. Man kann zwar relativ leicht eine dynamische Assembly erzeugen, aber wieder entladen. Es gibt keine Möglichkeit Typen wieder zu entfernen, außer wenn die ganze AppDomain entladen wird. Dafür müßte man die Skripte aber in eine zusätzliche AppDomain laden und das bedeutet, dass für die Skriptaufrufe das nicht unbedinngt schnelle Remoting benutzt werden muss.

Ab .net 2.0 gibt es die Klasse DynamicMethod mit der man einzelne Methoden und daraus Delegates erstellen kann, und die automatisch vom GC wieder eingesammelt werden. Da muss man aber die einzelnen Befehle selber angeben. Daher macht eine Skriptsprache speziell für die jeweilige Anwendung die z.B. diese Methoden generiert durchaus Sinn.