Vorlage DokumentationEinfuehrung
Allgemeines
   Aufruf
   Einleitung
   Installation
   Konfiguration
   Syntax
Einführung
   MetabefehlsAusdruecke
   MetabefehlsSyntax
   RegulaereAusdruecke
   VordefinierteVariablen
Funktionen
   abs()
   after()
   and()
   antoi()
   before()
   ceil()
   change()
   close()
   crop()
   equals()
   exp()
   flatten()
   float()
   floor()
   int()
   isnothing()
   itoan()
   length()
   log()
   log10()
   match()
   not()
   open()
   or()
   random()
   read()
   readline()
   sign()
   status()
   statustext()
   substr()
   system()
   time()
   tolower()
   toupper()
   typeof()
   write()
   writeline()
   xname()
   xor()
Metabefehle
   #after
   #array
   #break
   #call
   #config
   #const
   #debug
   #default
   #dict
   #else
   #every
   #forever
   #func
   #if
   #ifregion
   #ifunit
   #include
   #input
   #message
   #next
   #notrace
   #proc
   #return
   #sort
   #table
   #tag
   #trace
   #var
   #while
Rückruf-Prozeduren
   CalcUnitCapacities
   CreateRegionHeader
   CreateUnitHeader
   EndRegion
   EndUnit
   OnBuilding
   OnExit
   OnInit
   OnRegion
   OnShip
   OnUnit
   OutputLineFilter
Report-Objekte
   building
   grenze
   partei
   preise
   races
   region
   report
   ship
   things
   unit
Anhang
   Danksagungen
   SkriptDebugger
   VorlageFAQ

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.
Revision 06 Jan 2005

Page design, graphics and contents (c) copyright 1999-2004
by S.Schümann and contributing authors