Script: Unterschied zwischen den Versionen
K (Einige Rechtschreibfehler behoben.) |
|||
| (Eine dazwischenliegende Version von einem anderen Benutzer wird nicht angezeigt) | |||
| Zeile 1: | Zeile 1: | ||
| − | {{Unvollständig|Rechtschreibung und Grammatik | + | {{Unvollständig|Rechtschreibung und Grammatik sowie ein Inhaltscheck fehlen.}} |
=Scriptsprache= | =Scriptsprache= | ||
==Allgemein== | ==Allgemein== | ||
Ein Script ist eine Folge von Befehlen, Bedingungen und Variablenoperationen. | Ein Script ist eine Folge von Befehlen, Bedingungen und Variablenoperationen. | ||
Die Scripte werden zur Laufzeit verarbeitet und ausgeführt, hierbei existiert in der Regel ein sogenannter Bytecode. | Die Scripte werden zur Laufzeit verarbeitet und ausgeführt, hierbei existiert in der Regel ein sogenannter Bytecode. | ||
| − | Der Bytecode entspricht einer bestimmten Operation auf der Virtuellen | + | Der Bytecode entspricht einer bestimmten Operation auf der Virtuellen Maschine. Eine virtuelle Maschine ist dabei das System, welches den Bytecode in den passenden CPU Code umwandelt. Die virtuelle Maschine wird oft um Fähigkeiten, wie z.B. Garbage Collection, Laufzeitcodeoptimierung, Speicheroptimierung, Modulsysteme und so weiter, erweitert. So kann man ein Programm schreiben, welches ohne Änderungen auf jedem erdenktlichen System läuft. Dazu muss man für die Zielplatform eine virtuelle Maschine zur Verfügung haben und entsprechende Hardware. Wenn ein Script 64MB Speicher braucht, dann kann man es nicht auf ein 32MB-System laufen. |
| − | Eine | ||
| − | Die | ||
| − | So kann man ein Programm schreiben, welches ohne | ||
| − | Dazu muss man für die Zielplatform eine | ||
| − | Wenn ein Script 64MB Speicher braucht, dann kann man es nicht auf ein 32MB System laufen. | ||
==Verwendungszweck== | ==Verwendungszweck== | ||
| − | Scriptsprachen werden oft für nicht | + | Scriptsprachen werden oft für nicht zeitkritische Aufgaben verwendet, wie z.B. GUI, Kontrollskripte oder KI. Java, Lua oder C# können den Quellcode schon vorcompilieren und liefern dann nur noch den optimierten Bytecode. Der Vorteil liegt auf der Hand, der Ladeprozess ist kürzer und der Code wird schneller ausgeführt. Die Scriptsprachen sind vom Funktionsumfang, Geschwindigkeit und Syntax unterschiedlich. |
| − | Java, Lua oder C# können den Quellcode schon vorcompilieren und liefern dann nur noch den optimierten Bytecode. | ||
| − | Der Vorteil liegt auf der Hand, der Ladeprozess ist kürzer und der Code wird schneller ausgeführt. | ||
| − | Die Scriptsprachen sind vom Funktionsumfang, Geschwindigkeit und Syntax unterschiedlich. | ||
Im Bereich Spieleentwicklung und Grafikentwicklung sind Scripte sehr Nützliche Helfer. | Im Bereich Spieleentwicklung und Grafikentwicklung sind Scripte sehr Nützliche Helfer. | ||
| Zeile 21: | Zeile 13: | ||
Man spart Zeit und kann diese Arbeit dann auch einen Grafiker übergeben, da keine Programmierfähigkeiten mehr von nöten sind. | Man spart Zeit und kann diese Arbeit dann auch einen Grafiker übergeben, da keine Programmierfähigkeiten mehr von nöten sind. | ||
Um solch ein System zu realisieren, braucht man eine Scriptsprache, UI Format(z.B. XML) und natürlich eine Schnittstelle zur eigenen UI. | Um solch ein System zu realisieren, braucht man eine Scriptsprache, UI Format(z.B. XML) und natürlich eine Schnittstelle zur eigenen UI. | ||
| − | Je nach Scriptsprache kann man | + | Je nach Scriptsprache kann man objektorientierten oder prozeduralen Code verwenden. |
| − | C# z.B. kann C++ Klassen verstehen, wenn man aber ein generisches System haben will, sollte man das Lua Konzept mal näher betrachten. | + | C# z.B. kann C++ Klassen verstehen, wenn man aber ein generisches System haben will, sollte man das Lua-Konzept mal näher betrachten. |
| − | Hierbei werden die, durch dll/so | + | Hierbei werden die, durch dll/so standartdisierten Funktionen unterstützt, die von allen Hochsprachen verstanden werden und Metatables verwendet. |
Metatables bieten die Möglichkeit, Klassen aus jeder Hochsprache an Lua zu verbinden. | Metatables bieten die Möglichkeit, Klassen aus jeder Hochsprache an Lua zu verbinden. | ||
Dabei besitzt jede Variable von Lua eine Metatabelle, in der setter,getter und andere grundlegende Operationen überladen werden können. | Dabei besitzt jede Variable von Lua eine Metatabelle, in der setter,getter und andere grundlegende Operationen überladen werden können. | ||
==Performance und nützliche Tipps== | ==Performance und nützliche Tipps== | ||
| − | In der Spieleindustrie ist Lua eine sehr verbreitete Scriptsprache, da sie | + | In der Spieleindustrie ist Lua eine sehr verbreitete Scriptsprache, da sie flexibel, schnell, leicht verständlich, der Code offen ist und frei zur Verfügung steht. Die höchste Geschwindigkeit und Sicherheit kann man durch statisches Mappen der Hochsprachenfunktionen auf die Scriptfunktionen erreichen. |
| − | Die höchste Geschwindigkeit und Sicherheit kann man durch statisches | + | Etwas langsamer (beim Start), unsicherer, aber fehlertolleranter ist das Mappen der Funktionen beim Programmstart. |
| − | Etwas langsamer(beim Start), unsicherer aber | + | Hierbei kann man ein Propertysystem verwenden, welches z.B. bei Delphi oder C# die RTTI-Daten verwendet. |
| − | Hierbei kann man ein Propertysystem verwenden, welches z.B. bei Delphi oder C# die RTTI Daten verwendet. | + | Die langsamste, unsicherste, aber für Fehler unanfälligste Variante ist das Mappen zur Laufzeit. |
| − | Die langsamste, unsicherste aber Fehler unanfälligste Variante ist das zur Laufzeit | + | Dabei werden anhand von z.B. RTTI oder Propertydaten die Daten konvertiert und an die richtigen Funktionen weitergeleitet. |
| − | Dabei werden anhand von z.B. RTTI oder Propertydaten die Daten konvertiert und an die richtigen Funktionen | ||
| − | Die erste Lösung ist z.B. bei KI Scripten ein absolutes | + | Die erste Lösung ist z.B. bei KI Scripten ein absolutes Muss. |
| − | Wenn man Scripte braucht und sich die Funktionalität aber öfters erweitert oder verändert, dann sollte man die | + | Wenn man Scripte braucht und sich die Funktionalität aber öfters erweitert oder verändert, dann sollte man die zweite Lösung verwenden. |
Dieser Fall kann z.B. bei Ladescripten auftreten, wie z.B. Materials. | Dieser Fall kann z.B. bei Ladescripten auftreten, wie z.B. Materials. | ||
| − | Wenn man GUI entwickelt, dann sollte man die letzte Variante wählen, da man hier nicht Zeit sondern Fehlertolleranz höher | + | Wenn man GUI entwickelt, dann sollte man die letzte Variante wählen, da man hier nicht Zeit sondern Fehlertolleranz höher priorisiert. |
| − | Eine weitere Performancefalle ist das | + | Eine weitere Performancefalle ist das Ausführen von zuviel Code auf der Scriptseite. |
| − | In den Scripten sollten man eine Handvoll von Befehlen zur | + | In den Scripten sollten man eine Handvoll von Befehlen zur Verfügung haben und die Möglichkeit, Entscheidungen zu treffen. |
| − | Ein Script delegiert die Arbeit aber macht selber keine, so ruft es z.B. eine Funktion(IsPlayerInView(" | + | Ein Script delegiert die Arbeit, aber macht selber keine, so ruft es z.B. eine Funktion(IsPlayerInView("Heinz")) auf, fragt noch nach Informationen(GetHealthOfPlayer("Heinz")) und verwendet diese Informationen(if (a && b){dosomething();}) um eine Entscheidung zu treffen und somit eine weitere Funktion(DoEmotion(shout,"Medic!!!");) aufzurufen. |
| − | Die ganze | + | Die ganze Funktionalität liegt also im Script, aber die Implementierung liegt auf Seiten der Hochsprache. |
| − | Dinge, die ohne Probleme auf der Scriptseite gemacht werden können sind | + | Dinge, die ohne Probleme auf der Scriptseite gemacht werden können, sind Funktionsaufrufe, logische und einfache mathematische Operationen. |
==Nützliche Features== | ==Nützliche Features== | ||
Ein wichtiger Aspekt bei Scriptsprachen ist die Sicherheit. | Ein wichtiger Aspekt bei Scriptsprachen ist die Sicherheit. | ||
| − | Es ist in der Regel erwünscht, dass man bei einem Fehler im Script nicht die ganze Anwendung mit in den | + | Es ist in der Regel erwünscht, dass man bei einem Fehler im Script nicht die ganze Anwendung mit in den Tod reisst und deswegen werden Maßnahmen getroffen. |
| − | So kann man z.B. das | + | So kann man z.B. das Erstellen und Verändern von Speicher unterbinden, allerdings braucht man auch Variablen in einer Scriptumgebung und deswegen ist es häufig so gelöst, dass man einen festen Speicher für die VM reserviert und in diesem kann die VM ihre Operationen und Variablen verarbeiten. |
Geht der reservierte Speicher zu neige, dann wird z.B. der Speicherbereich defragmentiert und von nicht mehr genutzten Daten gesäubert. | Geht der reservierte Speicher zu neige, dann wird z.B. der Speicherbereich defragmentiert und von nicht mehr genutzten Daten gesäubert. | ||
| − | Einige Scriptsprachen reservieren dann auch mehr Speicher und rennen dann eventuell in den | + | Einige Scriptsprachen reservieren dann auch mehr Speicher und rennen dann eventuell in den Tod, wenn nicht mehr genügend Speicher verfügbar ist. |
| − | Eine fixe Speicherbegrenzung hat viele Vorteile, man kann zu | + | Eine fixe Speicherbegrenzung hat viele Vorteile, man kann zu mobilen und Embedded Geräten kompatibel bleiben, der Speicherverbrauch ist leichter zurückzuverfolgen, Fehler im Script können leichter entdeckt werden,... . |
Zur Sicherheit gehört aber auch die Fehlertolleranz, so sollte eine Scriptsprache nicht Probleme mit verschiedenen Typen haben. | Zur Sicherheit gehört aber auch die Fehlertolleranz, so sollte eine Scriptsprache nicht Probleme mit verschiedenen Typen haben. | ||
| − | Einige Scriptsprachen sind deshalb typenlos und erlauben das | + | Einige Scriptsprachen sind deshalb typenlos und erlauben das Speichern von Daten, egal welchen Typs, in eine Variable. |
| − | Ideal sind Optimierung an der | + | Ideal sind Optimierung an der virtuellen Maschine, in Hinsicht auf Konvertierung und Geschwindigkeit. |
| − | So ist es besser | + | So ist es besser Arrays für Zeichenketten zu verwenden und nicht terminierte Zeichenketten, float statt int für Zahlen zu verwenden(sind auf PC schneller und reduziert die Anzahl an Konvertierungsroutinen) oder Erkennung von statischen, mathematischen Operationen (Warnung ausgeben, vielleicht kann der User da was optimieren und die VM noch ein Cache für den Wert anlegen). |
| − | Eine Scriptsprache sollte auch einfach sein, da man diese oft Personen zur | + | Eine Scriptsprache sollte auch einfach sein, da man diese oft Personen zur Verfügung stellt, die keine Programmiererfahrung haben (z.B. Level-Designer). |
| − | Hier sollte man dem | + | Hier sollte man dem Benutzer soviel wie möglich abnehmen und z.B. Typenkonvertierung verstecken und auf eine einfache Syntax bauen. |
==Links== | ==Links== | ||
| + | *[[Tutorial_Scriptsprachen_Teil_1]] (DGL Tutorial hier im Wiki) | ||
| + | *[[Tutorial_Scriptsprachen_Teil_2]] (DGL Tutorial hier im Wiki) | ||
*[http://wiki.delphigl.com/index.php/Tutorial_Scripting_mit_JvInterpreterProgram Scripting mit JvInterpreter] | *[http://wiki.delphigl.com/index.php/Tutorial_Scripting_mit_JvInterpreterProgram Scripting mit JvInterpreter] | ||
| − | |||
| − | |||
*[http://www.lua.org/ LUA Website] | *[http://www.lua.org/ LUA Website] | ||
*[http://www.somedude.net/gamemonkey/ GameMonkey Website] | *[http://www.somedude.net/gamemonkey/ GameMonkey Website] | ||
Aktuelle Version vom 10. August 2008, 18:16 Uhr
(Mehr Informationen/weitere Artikel) Rechtschreibung und Grammatik sowie ein Inhaltscheck fehlen. |
 |
Inhaltsverzeichnis
Scriptsprache
Allgemein
Ein Script ist eine Folge von Befehlen, Bedingungen und Variablenoperationen. Die Scripte werden zur Laufzeit verarbeitet und ausgeführt, hierbei existiert in der Regel ein sogenannter Bytecode. Der Bytecode entspricht einer bestimmten Operation auf der Virtuellen Maschine. Eine virtuelle Maschine ist dabei das System, welches den Bytecode in den passenden CPU Code umwandelt. Die virtuelle Maschine wird oft um Fähigkeiten, wie z.B. Garbage Collection, Laufzeitcodeoptimierung, Speicheroptimierung, Modulsysteme und so weiter, erweitert. So kann man ein Programm schreiben, welches ohne Änderungen auf jedem erdenktlichen System läuft. Dazu muss man für die Zielplatform eine virtuelle Maschine zur Verfügung haben und entsprechende Hardware. Wenn ein Script 64MB Speicher braucht, dann kann man es nicht auf ein 32MB-System laufen.
Verwendungszweck
Scriptsprachen werden oft für nicht zeitkritische Aufgaben verwendet, wie z.B. GUI, Kontrollskripte oder KI. Java, Lua oder C# können den Quellcode schon vorcompilieren und liefern dann nur noch den optimierten Bytecode. Der Vorteil liegt auf der Hand, der Ladeprozess ist kürzer und der Code wird schneller ausgeführt. Die Scriptsprachen sind vom Funktionsumfang, Geschwindigkeit und Syntax unterschiedlich.
Im Bereich Spieleentwicklung und Grafikentwicklung sind Scripte sehr Nützliche Helfer. So kann man z.B. die ganze UI durch ein Script laden und mit dem Programm verbinden, ohne das Programm selber immer wieder neu zu compilieren. Man spart Zeit und kann diese Arbeit dann auch einen Grafiker übergeben, da keine Programmierfähigkeiten mehr von nöten sind. Um solch ein System zu realisieren, braucht man eine Scriptsprache, UI Format(z.B. XML) und natürlich eine Schnittstelle zur eigenen UI. Je nach Scriptsprache kann man objektorientierten oder prozeduralen Code verwenden. C# z.B. kann C++ Klassen verstehen, wenn man aber ein generisches System haben will, sollte man das Lua-Konzept mal näher betrachten. Hierbei werden die, durch dll/so standartdisierten Funktionen unterstützt, die von allen Hochsprachen verstanden werden und Metatables verwendet. Metatables bieten die Möglichkeit, Klassen aus jeder Hochsprache an Lua zu verbinden. Dabei besitzt jede Variable von Lua eine Metatabelle, in der setter,getter und andere grundlegende Operationen überladen werden können.
Performance und nützliche Tipps
In der Spieleindustrie ist Lua eine sehr verbreitete Scriptsprache, da sie flexibel, schnell, leicht verständlich, der Code offen ist und frei zur Verfügung steht. Die höchste Geschwindigkeit und Sicherheit kann man durch statisches Mappen der Hochsprachenfunktionen auf die Scriptfunktionen erreichen. Etwas langsamer (beim Start), unsicherer, aber fehlertolleranter ist das Mappen der Funktionen beim Programmstart. Hierbei kann man ein Propertysystem verwenden, welches z.B. bei Delphi oder C# die RTTI-Daten verwendet. Die langsamste, unsicherste, aber für Fehler unanfälligste Variante ist das Mappen zur Laufzeit. Dabei werden anhand von z.B. RTTI oder Propertydaten die Daten konvertiert und an die richtigen Funktionen weitergeleitet.
Die erste Lösung ist z.B. bei KI Scripten ein absolutes Muss. Wenn man Scripte braucht und sich die Funktionalität aber öfters erweitert oder verändert, dann sollte man die zweite Lösung verwenden. Dieser Fall kann z.B. bei Ladescripten auftreten, wie z.B. Materials. Wenn man GUI entwickelt, dann sollte man die letzte Variante wählen, da man hier nicht Zeit sondern Fehlertolleranz höher priorisiert.
Eine weitere Performancefalle ist das Ausführen von zuviel Code auf der Scriptseite. In den Scripten sollten man eine Handvoll von Befehlen zur Verfügung haben und die Möglichkeit, Entscheidungen zu treffen. Ein Script delegiert die Arbeit, aber macht selber keine, so ruft es z.B. eine Funktion(IsPlayerInView("Heinz")) auf, fragt noch nach Informationen(GetHealthOfPlayer("Heinz")) und verwendet diese Informationen(if (a && b){dosomething();}) um eine Entscheidung zu treffen und somit eine weitere Funktion(DoEmotion(shout,"Medic!!!");) aufzurufen. Die ganze Funktionalität liegt also im Script, aber die Implementierung liegt auf Seiten der Hochsprache. Dinge, die ohne Probleme auf der Scriptseite gemacht werden können, sind Funktionsaufrufe, logische und einfache mathematische Operationen.
Nützliche Features
Ein wichtiger Aspekt bei Scriptsprachen ist die Sicherheit. Es ist in der Regel erwünscht, dass man bei einem Fehler im Script nicht die ganze Anwendung mit in den Tod reisst und deswegen werden Maßnahmen getroffen. So kann man z.B. das Erstellen und Verändern von Speicher unterbinden, allerdings braucht man auch Variablen in einer Scriptumgebung und deswegen ist es häufig so gelöst, dass man einen festen Speicher für die VM reserviert und in diesem kann die VM ihre Operationen und Variablen verarbeiten. Geht der reservierte Speicher zu neige, dann wird z.B. der Speicherbereich defragmentiert und von nicht mehr genutzten Daten gesäubert. Einige Scriptsprachen reservieren dann auch mehr Speicher und rennen dann eventuell in den Tod, wenn nicht mehr genügend Speicher verfügbar ist. Eine fixe Speicherbegrenzung hat viele Vorteile, man kann zu mobilen und Embedded Geräten kompatibel bleiben, der Speicherverbrauch ist leichter zurückzuverfolgen, Fehler im Script können leichter entdeckt werden,... . Zur Sicherheit gehört aber auch die Fehlertolleranz, so sollte eine Scriptsprache nicht Probleme mit verschiedenen Typen haben. Einige Scriptsprachen sind deshalb typenlos und erlauben das Speichern von Daten, egal welchen Typs, in eine Variable. Ideal sind Optimierung an der virtuellen Maschine, in Hinsicht auf Konvertierung und Geschwindigkeit. So ist es besser Arrays für Zeichenketten zu verwenden und nicht terminierte Zeichenketten, float statt int für Zahlen zu verwenden(sind auf PC schneller und reduziert die Anzahl an Konvertierungsroutinen) oder Erkennung von statischen, mathematischen Operationen (Warnung ausgeben, vielleicht kann der User da was optimieren und die VM noch ein Cache für den Wert anlegen).
Eine Scriptsprache sollte auch einfach sein, da man diese oft Personen zur Verfügung stellt, die keine Programmiererfahrung haben (z.B. Level-Designer). Hier sollte man dem Benutzer soviel wie möglich abnehmen und z.B. Typenkonvertierung verstecken und auf eine einfache Syntax bauen.
Links
- Tutorial_Scriptsprachen_Teil_1 (DGL Tutorial hier im Wiki)
- Tutorial_Scriptsprachen_Teil_2 (DGL Tutorial hier im Wiki)
- Scripting mit JvInterpreter
- LUA Website
- GameMonkey Website
