DGL
https://delphigl.com/forum/

@FBScript
https://delphigl.com/forum/viewtopic.php?f=14&t=5941		 Seite 1 von 1
Autor:  TAK2004 [ Mi Sep 13, 2006 11:02 ]
Betreff des Beitrags:  @FBScript
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 :wink:
Autor:  Speedmaster [ Mi Sep 13, 2006 12:24 ]
Betreff des Beitrags: 
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 ).
Autor:  LarsMiddendorf [ Mi Sep 13, 2006 12:48 ]
Betreff des Beitrags: 
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.
Autor:  TAK2004 [ Mi Sep 13, 2006 14:01 ]
Betreff des Beitrags: 
@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.
Autor:  Kyro [ Mi Sep 13, 2006 15:39 ]
Betreff des Beitrags: 
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ß
Autor:  Evil-Devil [ Mi Sep 13, 2006 17:11 ]
Betreff des Beitrags: 
Kyro hat geschrieben:
Trotzdem stimme ich TAK zu - man denke an Java und .NET. In beiden fällen werden sie afaik immer häufiger verwendet.

Jepp, ab Java 6 wird Groovy ein offizieller Bestandteil des Java Paketes sein. Das wird sicher sehr interessant :)
Autor:  Speedmaster [ Do Sep 14, 2006 10:56 ]
Betreff des Beitrags: 
Kyro hat geschrieben:
@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ß


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.
Autor:  LarsMiddendorf [ Do Sep 14, 2006 16:19 ]
Betreff des Beitrags: 
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.
Seite 1 von 1 Alle Zeiten sind UTC + 1 Stunde
Powered by phpBB® Forum Software © phpBB Group
https://www.phpbb.com/