Einführung in die Sprache

Warum eine eigene Sprache?

Zunächst einmal zur Frage, warum ich eigentlich eine eigene Skriptsprache implementiert habe, wo es doch bereits zahlreiche freie Skriptsprachen gibt, die besser dokumentiert sind, schneller interpretiert werden und zudem zum Teil auch einfach in eigene Projekte eingebunden werden können? - Darauf gibt es nicht nur eine Antwort:

Zunächst einmal, war für Vorlage nie ein Interpreter geplant. Es sollte nur ein Zugvorlagengenerator werden, der es ermöglicht, ohne in den Normalreport zu schauen, seinen Zug zu erstellen. Dies ist der Grund für den Namen und auch dafür, das es mehr Features für die Zugvorlagen-Erzeugung gubt, als für die Computerreport-Erzeugung. Nach Betrachtung des Perl-Generators von Georg Edelmayer, kam die Idee auf, einfache kleine Befehle einzubauen um simple Automatisierungen zu ermöglichen. So wurden dann #after, #next, #forever, #every implementiert. Mit den Befehlen kam dann der Wunsch die Parameter der darin angegebenen Eressea-Befehle von Report-Daten abhängig zu machen. Kurzerhand wurde ein Expression-Parser eingebaut, ein paar Report-Objekte abgebildet und so konnte Vorlage Ausdrücke. Von da war es dann nur ein kleiner Schritt zu einer eigenen Sprache, da die Mechanismen nun schon alle vorhanden waren.

Zum anderen war natürlich schon früh mit dem Einbauen der Befehle die Frage aufgekommen ob nicht eine fertige Skriptsprache einfacher wäre. Allein der Aufwand eine eigene Sprache leidlich Fehlerfrei zu erstellen zwang diese Frage auf die Tagesordnung. Aber es gab dann einige Gründe die diesen Weg nicht so attraktiv erscheinen liessen wie eine komplett eigene Sprache:

• Atlantis-Ableger haben eine wenig computerfreundliche Spielsprache. Die Befehle sind durch Zeilemumbruche getrennt und die Argumente durch Leerzeichen. Das bedeutete, das eine eingebettete fremde Sprache nicht mit den Atlantis-Befehlen mischbar war, da die üblichen Skriptsprachen Leerzeichen an den meisten Stellen ignorieren, diese also keine Funktion erfüllen.
• Fast alle Sprachen haben heute das Semikolon mit einer Fuktion belegt, in der Regel zum Trennen oder Abschliessen von Befehlen. Das Semikolon darf aber in den Zügen nicht verwendet werden, da es im Spiel einen Komentar einleitet und alles ab dem ersten Semikolon einer Zeile abgeschnitten wird.
• Perl ist nach meiner Meinung zu groß und für Einsteiger zu kompliziert um in so einem Projekt verwendet zuwerden.
• Python erfordert kosmetische Klimmzüge um das notwendige Einrücken von Schachtelungen stabil über den Server zu retten.
• Tcl ist prinzipbedingt eher langsam (auch wenn im Moment schneller als der Vorlage-Interpreter).
• Allen betrachteten (auch Lua oder C-Interpretern) ist gemein, das sie nicht mit den PBEM-Befehlen gemischt werden können. Es ist sicher nicht Jedermanns Sache, aber die Möglichkeit Spiel-Befehle ohne irgendwelche Say-, Emit- oder Print-Befehle verwenden zu können, stellt ein wichtiges Design-Kriterium dar, mit der Hoffnung den Zugang auch Nichtcodern zu erleichtern.

Die Komponenten

Die Skriptsprache von Vorlage kann in drei Komponenten eingeteilt werden. Diese haben unterschiedliche Regeln und ein Verständnis ihrer Besonderheiten ist sicherlich notwendig um vollen Nutzen aus Vorlage zu ziehen.

Die die drei Bereiche sind:

Metabefehls-Syntax

Dieser Abschnitt erklärt die Verwendung und Mischung von Metabefehlen und den normalen Befehlen eines PBEMs.

Metabefehls-Ausdrücke

Dieser Abschnitt befasst sich mit Ausdrücken um, Werte für Variable oder Parameter für Befehle zu berechnen.

Reguläre Ausdrücke

In diesem Abschnitt wird auf die von  Perl entliehenen Ausdrücke zum Mustervergleich eingegangen, die für einige Text-Funktionen in Vorlage verwendet werden.

vordefinierte Variablen

Diese Seite beschreibt die Variablen die der Interpreter schon erzeugt.