Kurz vor Weihnachten ist mir der Durchbruch gelungen!

Mein Sorgenkind, der BBScript-Parser, hat das gesamte Projekt bis zuletzt furchtbar hinaus gezögert. Was habe ich nicht alles für Ansätze ausprobiert und wieder verworfen:

- Code per String-Manipulation von BBScript in JavaScript-Syntax umwandeln (das war Anfang 2018 und ging gründlich schief)
- alles selbst schreiben (Lexer und Parser)
- formale Grammatik entwickeln und einen Parser-Generator benutzen

Zuletzt hatte ich meine Hoffnungen in einen Parser-Generator namens tsPEG gesteckt. Dieser funktionierte bei kleinen Grammatiken sehr gut, hat aber bei umfangreichen Regeln (BBScript hat > 700 Befehle) große Probleme und arbeitet nicht zuverlässig.

Mit leichter Verzweiflung - angesichts der vielen Zeit, die für meine Parsing-Ansätze schon draufgegangen ist - habe ich eine Problemanalyse unternommen. Dabei sind mir folgende Dinge aufgefallen, die das Thema kompliziert machen:

- ich habe zu wenig Erfahrung im Umgang mit eigenen Parsern bzw. Parser-Generatoren
- die BBScript-Syntax ist zu komplex, um einfache Regeln zu definieren

Während dem oberen Punkt nur durch Ausprobieren und das Sammeln von Erfahrungen begegnet werden kann, kann man auf den unteren Punkt effektiv reagieren: Die BBScript-Syntax muss einfacher werden. Oder besser gesagt, es sollten zunächst einmal Grundstrukturen wie das Ausführen von (simplen) Befehlen und das Zuweisen globaler Variablen funktionieren.

Der neue Parser besteht nun aus Regeln, die per Pattern-Matching erkennen, worum es sich bei der aktuell geparsten Codezeile handelt. Im Moment werden nur Befehle und Variablendeklarationen unterstützt. Außerdem müssen Parameter direkt ihre finalen Werte enthalten und dürfen keine Ausdrücke sein:

Code: [AUSKLAPPEN] [EINKLAPPEN]

Nach und nach werden weitere Strukturen im Parser implementiert. So lassen sich derzeit etwa Befehle nur ohne das Setzen von Klammern aufrufen. Für Klammerung wird später ein interner Stack gepflegt, um die Verschachtelung auf allen Ebenen korrekt beizubehalten.

Im Oktober 2019 hatte ich folgendes Versprechen geäußert: "Im Jahre 2020 wird definitiv eine Alpha-Version von BBScript veröffentlicht, die online nutzbar ist."

Bis zuletzt hatte ich befürchtet, dass ich mich damit zu weit aus dem Fenster gelehnt hatte. Zwar gibt es in der Tat ein paar kleine Code-Beispiele auf der Homepage www.blitzbasicscript.com , aber diese sind allesamt hardgecoded. Da ich nun aber einen funktionierenden Weg gefunden habe, selbst Code in einem simplen Textfeld zu schreiben und diesen zur Laufzeit zu parsen und zu interpretieren, bin ich optimistisch, dass ich eine kleine Testversion davon noch vor Jahresende auf der Homepage veröffentlichen kann. (Oder falls das nicht klappt, zumindest im Januar )

Natürlich sind noch längst nicht alle Befehle unter der Haube implementiert, und auch das Verwenden von Datenstrukturen wie Schleifen oder If-Blöcken klappt noch nicht. Dennoch, für ein paar kleine Sound- und Grafikdemos reicht der aktuelle Stand bereits aus. Sobald der Code-Editor online ist, könnt ihr ja mal ein paar der folgenden Befehle ausprobieren:

BlitzBasic: [AUSKLAPPEN] [EINKLAPPEN]

Graphics
Cls
ClsColor
Color
Rect
Oval
Line
Plot
Text
CreateCamera
CreateCube
CreateCylinder
CreateCone
CreateSphere
PositionEntity
RotateEntity
Sqr
Sin
Cos
; ...

Ich wünsche euch allen ein fröhliches Weihnachtsfest und einen guten Rutsch ins neue Jahr 2021!

Seit Anfang September habe ich einen kleinen Root-Server gemietet, auf dem ich beliebige Software installieren kann. Bislang war der Tech Stack von BbScript sehr überschaubar:

- Frontend: Angular 10 mit Bulma
- Backend: PHP und MySQL

Es war insbesondere lästig, alle Interfaces und Klassen quasi doppelt zu implementieren, einmal in TypeScript und einmal in PHP. Da MySQL eine relationale Datenbank ist, musste ich für die Befehlsdokumentation alle Parameter von Befehlen per Fremdschlüsselreferenz zuordnen - furchtbar. Zudem hatte ich keinerlei Backend-Framework eingesetzt, weshalb das Ding allmählich zu explodieren drohte

Kurzum: All diese Probleme haben sich nun (zumindest theoretisch) auf einen Schlag erledigt. Jetzt kann ich überall in BbScript genau die Technologien einsetzen, welche am besten zusammen passen. Momentan sind das:

- Mono-Repository: nrwl/nx

- Frontend
Framework: Angular 10
Design: Bulma, Theme „Superhero“
Unit Tests: Jest

- Backend
Framework: NestJS
Datenbank: Apache CouchDB
Datenbank-Interface: PouchDB

- Programmiersprache
Parser-Generator: tsPEG
3D-Engine: babylon.js

On top gibt es noch einige Verbesserungsmöglichkeiten, die der Root-Server mit sich bringt:

- Plesk als Web Hosting Tool
- unbegrenzte Wildcard-Zertifikate für alle Domains dank Let's Encrypt
- Cronjobs und Git Hooks, um eine automatisierte CI-Pipeline zu bauen

Parser-Generator
Nachdem ich ja schon mehrmals erwähnt hatte, dass der Parser mir Kopfschmerzen bereitet, habe ich nun den Tipp von @DAK von Anfang März beherzigt und nach Parser-Generatoren für TypeScript gesucht. Dabei bin ich auf tsPEG gestoßen und finde das Tool sehr praktisch für meine Zwecke. Der Entwickler (EoinDavey) ist auch sehr aktiv und hat schon auf mehrere Feature-Vorschläge von mir reagiert

Im Prinzip läuft das so ab: Man schreibt eine formale Grammatik auf (vergleichbar mit EBNF) und definiert darin Regeln, welche der Parser abarbeitet. Wichtig zu beachten ist, dass es einen unendlichen Lookahead gibt. Dieser ist zugleich Fluch und Segen: Man kann damit kontextsensitive Grammatiken verfassen, darf allerdings innerhalb einer Produktionsregel diese nicht rekursiv aufrufen, da der erzeugte Parser sonst in eine Endlosschleife gerät, bis es zum Stack Overflow kommt.

Bislang sind grundlegende Datenstrukturen schon als Regeln formuliert (Bedingungen, Schleifen, Zuweisungen etc.) - die ersten Entwürfe für eine Grammatik habe ich immerhin schon vor fast einem Jahr entwickelt. Eine mittelgroße Herausforderung werden jedoch die ganzen BbScript-Befehle sein: Entweder man betrachtet diese als Symbole und wertet sie erst im Interpreter aus, oder aber man schreibt die alle in die Grammatik rein mit ihren dazugehörigen Parametern. Letzteres hätte den Vorteil, dass der Parser direkt schon erkennt, welche Befehle zu viele oder zu wenige Parameter haben und bereits vor der Programmausführung einen Fehler werfen könnte.

http://blitzbasicscript.com

Nach intensiven Arbeiten in den letzten Wochen ist nun die BlitzBasicScript-Website in neuem Gewand online. Als Theme benutze ich nun Bulma Superhero, da es zu kompliziert wurde, alle Designs selbst zu definieren.

Momentan ist der Inhalt recht überschaubar, weil alle unfertigen Features vorerst deaktiviert sind (Login, Tutorials, Dokumentation usw.). Die Online-IDE zum Code schreiben ist noch in der Entwicklung, darum kann man noch nicht aktiv eigenen Code eingeben. Es gibt aber schon einige Codebeispiele, die in den nächsten Tagen und Wochen erweitert werden und zeigen, was BBScript mittlerweile so alles kann:

2D-Grafiken und Zeichenbefehle ausführen
3D-Objekte erstellen und positionieren
Sounds abspielen
Mathematische Funktionen und Stringbefehle

Aktueller Zustand und die nächsten Schritte
Es sind bereits ca. 250 Befehle aus BlitzBasic / Blitz3D implementiert. Dateizugriffe auf die BlitzBasicScript-Cloud funktionieren rudimentär; nur die Anwendungen der ganzen Read- und Write-Befehle braucht noch etwas Zeit, weil ich erstmal verstehen muss, wie diese Binärdaten geschrieben werden...

Ace ist zwar ein schöner Online-Code-Editor, aber für meine Zwecke zu beschränkt. Es soll später möglich sein, per Mausklick auf einzelne Befehle im Code in die Online-Dokumentation zu springen, bzw. zu den Funktions- und Type-Implementierungen bei der Verwendung eben jener. Deshalb bastele ich (zugegeben, zum wiederholten Male) an einer eigenen IDE. Folgende Features wird sie später haben:

Autocomplete
Syntax Highlighting (schon implementiert)
Copy/Paste
Undo/Redo
verschiedene Themes
Code-Navigation (siehe oben)

...und dann ist da ja noch der leidige Parser. Das Ding beschäftigt mich schon seit Monaten und stellt mit Abstand den schwierigsten Teil dar. Die eigentliche Herausforderung ist es, verschachtelte Aufrufe korrekt zu analysieren und in abstrakte Syntax umzuwandeln. Damit werde ich noch gut zu tun haben bis Ende des Jahres.

Nichts desto trotz, es geht gerade richtig gut voran und ich bin hoch motiviert, den Befehlsumfang Stück für Stück zu erweitern und allmählich in Richtung eines benutzbaren Systems zu gelangen

BlitzBasicScript bekommt eine Grammatik

Seit über einem Jahr habe ich schon diverse Konzepte entwickelt, wie eine Grammatik für BlitzBasicScript aussehen kann. Diese ist notwendig, damit Programmierkonstrukte wie Ausdrücke, Befehlsaufrufe und Schlüsselwörter korrekt in abstrakte Syntax umgewandelt und zur Laufzeit interpretiert werden können.

Bisher lagen meine Überlegungen nur in Textform vor, was auf Dauer mühselig zu lesen und zu verstehen ist, wenn man ein paar Wochen etwas anderes gemacht hat. Darum habe ich nun eine kleine Präsentation mit LibreOffice angelegt, wo die Sprachkonstrukte als Diagramm visualisiert sind (Sobald die Diagramme fertig sind, werde ich sie hier als PDF verlinken, damit ihr sie euch anschauen könnt ). Einige der wichtigsten Grammatikregeln umfassen folgende Elemente:

- Befehlsaufrufe
- Variablenzuweisung (und -definition)
- Funktionen
- Typen
- Labels
- Bedingungen
- Schleifen

Ein kleines Beispiel: Eine BBScript-Funktion beginnt mit dem Schlüsselwort Function, gefolgt von einem beliebigen Funktionsnamen und einer öffnenden Klammer. Dann gibt es zwei Varianten:

- keine Funktionsparameter vorhanden: schließende Klammer, fertig
- mind. 1 Parameter: Name des Parameters, optionale Default-Wert-Definition (Gleichheitszeichen gefolgt von einem String / Zahl / Boolean), anschließend entweder ein Komma und weitere Parameter-Definition oder schließende Klammer, fertig

Um die Arbeit für den Parser etwas zu erleichtern, werde ich vor der eigentlichen Sematik-Analyse die Lexer-Tokens in Gruppen einteilen. Dadurch werden z. B. Funktionen, Types oder Schleifen gleich "im Stück" vorverarbeitet und man muss keinen riesigen Stack verwalten, auf den immer mehr Zustände gepusht werden. Natürlich werde ich trotzdem nicht um einen Stack herumkommen, denn Codeblöcke können natürlich auch verschachtelt sein (z. B. mehrere Schleifen ineinander).

Das ganze hat den großen Vorteil, dass man Syntaxfehler relativ leicht erkennen kann. Wenn z. B. eine Funktions- oder Typbeschreibung nicht abgeschlossen wird (fehlendes End Function / End Type), oder ungültige Blöcke miteinander verschachtelt werden (z. B. eine Funktion innerhalb einer Funktion), so werden diese Fehler schon bei der Vorverarbeitung erkannt.

Und was macht eigentlich der Interpreter?
Parallel zu meinen Arbeiten an der Grammatik entwickle ich bereits eine abstrakte Syntax für die ganzen BBScript-Konstrukte. Für jede Art von Syntaxblock gibt es ein Objekt, in welchem die relevanten Informationen abgespeichert werden, damit das ganze zur Laufzeit ausgeführt und berechnet werden kann.

Auch hier ein kurzes Beispiel: Angenommen, der Interpreter soll eine globale Variable erstellen und ihr einen Wert zuweisen.

BlitzBasic: [AUSKLAPPEN] [EINKLAPPEN]

Global variable = "Hello World!"

Der Parser analysiert die Sematik dieser Codezeile und erzeugt ein Objekt mit folgenden Attributen:

- Variablenname: variable
- Wert: <Ausdruck> <string> "Hello World!"

Der Interpreter kommt

Endlich tut sich was unter der Haube von BlitzBasicScript auf dem Weg zur Spieleentwicklung im Browser

Nach mehreren (gescheiterten) Versuchen habe ich heute den Interpreter angelegt und begonnen, die wesentliche Logik zu implementieren. Zur Erinnerung: Damit der BBScript-Code zur Laufzeit dynamisch ausgeführt werden kann (mit Variablen, Funktionsaufrufen etc.), benötigen wir eine abstrakte Syntax, um die Statements semantisch zu beschreiben und aus dieser Syntax während der Programmausführung die eigentlichen Operationen aufrufen.

Der Programmcode von BBScript besteht im Wesentlichen aus Codeblöcken, Funktionen und Typedefinitionen. Ein Codeblock ist entweder ein einzelnes Statement (z. B. Zuweisung, Befehls- oder Funktionsaufruf etc.) oder eine "Gruppe" mit komplexerer Logik, etwa ein If-Block oder eine Schleife.

Die einfachste Form von Statements sind CommandStatements, also Befehlsaufrufe. Jedes CommandStatement besteht aus folgenden Elementen:

- Befehlsname (z. B. Graphics3D, DrawImage oder Tan)
- einem Array von Parametern

Bisher habe ich in meiner vereinfachten Parser-Implementierung angenommen, dass jeder Parameter ein statischer Wert sein muss (Zahl oder String). Das widerspiegelt natürlich nicht die Realität; deshalb werden die einzelnen Parameter nun als Ausdrücke (Expressions) aufgefasst. Eine Expression kann ein statischer Wert sein, der Wert einer Variablen, ein Funktions- oder Befehlsaufruf bzw. ein mathematischer Ausdruck, der diese ganzen Elemente durch Operatoren verknüpft.

Der Interpreter besitzt eine eigene Methode, um die Parameter-Ausdrücke von Befehlsaufrufen zur Laufzeit auszuwerten. Der gesamte Vorgang muss Asynchronität berücksichtigen, denn ein Parameter kann durchaus einen weiteren Befehlsaufruf enthalten, der seinerseits asynchron arbeitet. Hier sind drei Beispiele:

BlitzBasic: [AUSKLAPPEN] [EINKLAPPEN]

EntityTexture(cube, LoadTexture("gfx/texture.png"))  ; zweiter Parameter von EntityTexture ist ein asynchroner Aufruf
Text 0, 0, ReadLine(stream)  ; ReadLine lädt in BBScript asynchron
PlaySound LoadSound("sfx/sound.wav")  ; gleiches Prinzip wie zuvor

Wie ihr seht, ergeben sich ziemlich viele tricky Zustände, wenn man nicht alle Befehle schön synchron abarbeiten kann wie in BlitzBasic


Promises statt Observables

Die Befehlsaufrufe werden ab sofort nicht mehr als Observables behandelt, sondern mithilfe von Promises. Im Rahmen eines internen Vortrags bei meiner Arbeit hatte ich mich näher mit beiden Konzepten beschäftigt und festgestellt, dass Promises für den Anwendungsfall "Befehle abarbeiten" besser geeignet sind. Während ein Promise ein Objekt verkörpert, das zu einem späteren Zeitpunkt einen Wert zurückliefert, handelt es sich bei einem Observable um einen richtigen Stream, über den Events gefeuert werden können. Das ist sehr praktisch im Umfeld reaktiver Programmierung, aber für "einfache" Befehlsaufrufe sollte nicht pro Befehl jedes Mal ein neuer Stream eröffnet werden müssen. Dazu kommt, dass Observable-Streams zunächst aktiviert werden müssen (per sogenannter Subscription), was bei Promises entfällt.

Kurz zusammengefasst, wird die Abarbeitung von Befehlsaufrufen in Zukunft wesentlich leichter und sauberer zu implementieren sein.

Eine erste Alpha-Website des Projekts BlitzBasicScript ist nun fertig und kann besucht werden unter: https://blitzbasicscript.com/



Auf der Landing Page erfahrt ihr die grundlegenden Features der Scriptsprache, welche umgesetzt werden sollen.
Im Bereich "Lexer" könnt ihr BlitzBasic(-Script)-Code eingeben und euch dann die Tokens anzeigen lassen, in welche der Code bislang zerlegt wird. Nach einem Bugfix vor einigen Tagen (\r-Zeichen wurden versehentlich als Teil des Codes interpretiert) gehe ich nun davon aus, dass der Lexer vollständig umgesetzt ist und es damit keine Probleme mehr geben sollte.
Im Menü "Befehle" findet ihr die einzelnen Kommandos von BBScript in ihren entsprechenden Kategorien. Das Schema orientiert sich stark an der BlitzForum Online-Hilfe (vielen Dank an alle die fleißigen Menschen, die das hier mal aufgeschrieben haben!).

Bitte beachtet, dass die Befehlsdokumentation noch nicht vollständig ist (bei vielen Kommandos fehlen noch Parameter) und es noch keine Codebeispiele gibt. Diese werden erst im Laufe der Zeit hinzukommen.

Wer schon mal ein funktionierendes BBScript-Schnipselchen ausprobieren möchte, kann zum Beispiel den folgenden Code kopieren, dann im "Befehle"-Menü auf der Website einen Befehl auswählen und den kopierten Code in den Editor einfügen und auf "Starten" klicken:

Code: [AUSKLAPPEN] [EINKLAPPEN]

Okay, das ist zugegebenermaßen noch sehr langweilig . Aber zumindest reicht es als Beweis dafür, dass es jetzt prinzipiell möglich ist, BBScript-Code zu schreiben und daraus einen ausführbaren Web-Code zu generieren.

Die weiteren Aussichten
Bevor ich an der Website weiter arbeite, widme ich mich in den nächsten Wochen intensiv dem Parser. Dieser kann momentan nur sehr rudimentäre Statements verarbeiten und unterstützt noch keinerlei Datenstrukturen (nicht einmal das Erstellen von Variablen).

Mein bisheriger Ansatz bei der Generierung des Ziel-Codes war falsch. Ich wollte fertige Funktionsaufrufe generieren und in einem Array speichern, um dann zur Laufzeit des Spiels die Funktionen einfach nur nacheinander abzuarbeiten. Dabei habe ich übersehen, dass die Parameter, mit denen die Funktionen aufgerufen werden sollen, sich ja dynamisch ändern können und ich sie nicht "statisch" in den Zielcode pressen kann. Somit muss meine Game-Engine also während der Laufzeit erst die ganzen Ausdrücke berechnen (zb. 2 + x - y * Pi kann nicht von vornherein berechnet werden, weil man die Werte von x und y vor der Programmausführung noch gar nicht kennt).

Ich werde nun Schritt für Schritt den Parser so umbauen und erweitern, dass er für verschiedene Programmstrukturen den entsprechenden Ziel-Code als "abstraktes Syntax-Objekt" (JSON) generiert. Die Reihenfolge soll ungefähr so aussehen:

- Konstanten (sehr simpel, da nur Zahlen, Strings oder Wahrheitswerte möglich sind)
- Befehlsaufrufe (können verschachtelt sein)
- Globale Variablen definieren
- Schleifen

Damit werde ich bis Ostern sicherlich gut zu tun haben. Und wenn die abstrakte Syntax dann hinreichend gut umgesetzt ist, widme ich mich wieder der eigentlichen Programmausführung sowie der Implementierung der rund 700 restlichen Befehle...

Willkommen zurück!

In den vergangenen zwei Jahren habe ich viel Zeit damit verbracht, mir alle Raffinessen von BBScript zu überlegen und mich in dutzenden Ideen zu verlieren. Was dabei herausgekommen ist: Ein halbfertiger Lexer, ein halbfertiges Parser-Konzept, eine halbfertige Website und eine halbfertige Umsetzung einiger rudimentärer Befehle. Seltsam - kam im letzten Satz zufällig das Wort "halbfertig" vor?

Kurzum, das Projekt ist irgendwie aus dem Ruder gelaufen, weil es zu viele offene Baustellen gab (und immer noch gibt) und nichts richtig fertig wurde, was auf Dauer die Motivation schmälert. Deshalb habe ich mir für 2020 überlegt, erstmal kleine Brötchen zu backen und überhaupt etwas Sichtbares auf die Beine zu stellen, mit dem sich weiterarbeiten lässt:

Eine kleine Website
Während der Entwicklung von BBScript genügt es, einige grundlegende Funktionen anzubieten, damit sich die Nutzer erstmal einen Überblick verschaffen können, worum es eigentlich geht. Zu diesem Zweck habe ich nochmal ein neues Webprojekt aufgesetzt mit nur drei Seiten: Info, Lexer und Befehle. Man kann sich also informieren, was BBScript ist (bzw. werden soll) und welche Fähigkeiten es mitbringt. Außerdem lässt sich BBScript-Code (bzw. alter BlitzBasic-Code) in einem Editor eintippen, welcher in Echtzeit gelext wird und man bekommt die entsprechenden Tokens angezeigt. (Hier wird es eine Funktion geben, mit der man Feedback-Reports mit einem Buttonklick absenden kann - das ist für mich hilfreich, um eventuell noch vorhandene Fehler im Lexer schneller zu identifizieren). Zu guter Letzt kann man sich die Befehlsdatenbank schon einmal ansehen und in einem Live-Editor Codebeispiele anschauen und ausführen. Die Datenbank ist noch sehr unvollständig und es wird einige Zeit dauern, bis ein brauchbarer Umfang erreicht sein wird.

Der Parser funktioniert endlich
Hurra! Wie lange hat es gedauert, endlich die zwei Welten - BBScript-Code und Game-Engine - miteinander verbinden zu können. Bislang konnte man zwar schon den Code lexen, sowie die Command-Funktionen der Engine aufrufen; aber einen BBscript-Befehl einzutippen und daraus automatisch den zugehörigen Befehl in der Engine anzusprechen, klappte einfach nicht. Mein Parser-Konzept ist überaus umfangreich und so komplex, dass es mir unmöglich schien es auf einen Schlag umzusetzen. Stattdessen werde ich inkrementell daran arbeiten und habe zunächst die Möglichkeit eingebaut, Befehle mit primitiven Parametern (Zahl, String oder Boolean) zu erkennen und daraus Gamecode zu erzeugen, welcher ausgeführt werden kann.

Ausblick
Die vorläufige Website wird voraussichtlich Ende Januar online gehen. Sie ist noch nicht vollständig für Mobilgeräte optimiert, wird aber im Laufe der Zeit verbessert und die Befehlsdatenbank wird täglich erweitert. Parallel dazu werden kontinuierlich weitere Befehle innerhalb der Game-Engine umgesetzt und getestet.

Bevor man allerdings komplexe Programme mit Variablen, Schleifen, Bedingungen usw. schreiben und testen kann, wird noch einige Zeit ins Land gehen. Dazu wird es nämlich nötig sein, den Parser komplexe Strukturen erkennen zu lassen und diese korrekt mit JavaScript-Mitteln in ein browserfähiges Spiel umzusetzen. Dieser Teil ist zwar auch schon seit letztem Jahr umfangreich durchdacht und geplant, aber es muss noch sorgfältig implementiert und getestet werden.

...und schon wieder sind genau 110 Tage vergangen seit dem letzten Worklog-Eintrag. Leider bin ich seitdem kein bisschen mit der Entwicklung von BBScript weiter gekommen.

Das liegt vor allem daran, dass ich im Sommer eine Trennung und einen Wohnungsumzug auf meiner Todo-Liste hatte und entsprechend privat beschäftigt war. Dafür habe ich seit Oktober nun einen DSL-100-Glasfaseranschluss, was für die Entwicklung einer Online-Game-Engine nur praktisch ist zum Ressourcen laden.

Ab heute geht's also endlich weiter mit dem Projekt. Zunächst versuche ich, die Website endlich rund zu bekommen, auch wenn sich das insgesamt schwieriger gestaltet als anfänglich gedacht. Der Teufel steckt einfach im Detail und der Funktionsumfang der "Website" ist eben doch etwas umfangreich:

- Authentifizierung mit Registrierung und Login / Logout
- (kleines) Blog-System mit Lazy Loading, um Beiträge zu laden
- interaktive IDE mit Dateibaum, Editor, Projekteinstellungen u. v. m.
- übersichtliche Dokumentation, bestehend aus Tutorials, Schlüsselwörtern, Befehlen und weiteren Hilfsmitteln

Danach gibt es noch genügend Baustellen, an denen ich mich in den nächsten Monaten durchbeißen werde:
- Parser implementieren (!)
- Beispielprojekte aufsetzen und testen
- Assets bereitstellen (Sounds, Musik, Tiles, 3D-Objekte etc.)
- Dokumentation und Tutorials aufbereiten
- Werbung machen für BBScript, damit das auch genutzt wird

Zu guter Letzt möchte ich ein Versprechen machen: Im Jahre 2020 wird definitiv eine Alpha-Version von BBScript veröffentlicht, die online nutzbar ist.

Wahnsinn, wie schnell die Zeit verfliegt! Jetzt ist es bereits 110 Tage her, dass ich zuletzt über den Fortschritt von BlitzBasicScript berichtet habe. Nun denn, Zeit für ein Update:

Website (Angular 8)
Die Website www.blitzbasicscript.com befindet sich nach wie vor in der Entwicklung und wird allmählich "nutzbar", sowohl im Desktop-Modus als auch auf Mobilgeräten. Es fehlen allerdings immer noch viele wichtige Dinge, wie z. B. automatisiertes Anzeigen neuer DevBlog-Beiträge, Login / Logout sowie das Laden und Speichern von Dokumenten in der BBScript Cloud. Außerdem habe ich ein Major Version Update von Angular durchgeführt, sodass jetzt die neueste Version 8 genutzt wird. Mit etwas Glück wird im August eine erste Version live zu sehen sein (gut Ding will Weile haben).



Update auf BabylonJS 4
Hurra, endlich ist BabylonJS 4 da! Das Update war glücklicherweise nicht besonders komplex, nur ein paar Klassen-Import-Statements mussten aktualisiert werden. Wer Lust hat, sich einen Überblick über die neueste Version dieser Browser-Game-Engine verschaffen möchte, schaue sich am besten auf der offiziellen Seite um.

Online-IDE mit Ace
Nach mehreren Versuchen, eine eigene Online-IDE als separates Modul zu entwickeln, habe ich irgendwann beschlossen, die Zeit lieber in die eigentliche Sprachentwicklung zu stecken und stattdessen Ace als Grundlage zu nutzen. Ace bietet wichtige Features wie Auto-Completion, Syntax Highlighting, Copy-Pasting, Undo-Redo, verschiedene UI-Themes usw. Zunächst habe ich sämtliche von BBScript unterstützten Schlüsselwörter und Befehle in eine eigene Syntax-Datei gepackt (basierend auf der Syntax von VBScript) und diese ließ sich - nach einigem Herumprobieren - auch einbinden. Jetzt wird also der BBScript-Code schon mal hübsch formatiert angezeigt.

Nein, das Projekt BlitzBasicScript ist nicht - wie meine zwei vorherigen Worklogs - bereits wieder eingeschlafen. Nur passiert momentan viel "unter der Haube" und dauert seine Zeit, weshalb es nicht wirklich viel Neues zu zeigen gibt.

Momentan arbeite ich primär an der BBScript-Website. Diese soll komplett responsive werden, wie man sich anhand dieser Mockup-Screen-PDF's bereits anschauen kann:
Desktop-Ansicht
Mobile Ansicht

Des weiteren gibt es schon seit geraumer Zeit eine Art "Language API" für BBScript, unter welcher die Schlüsselwörter und Befehle via REST abgefragt werden können. Der ursprüngliche Gedanke dabei war, dass ich nicht zweimal den gleichen Code schreiben muss, einmal für die Dokumentation und einmal für den Parser. Mittlerweile weiß ich nicht, ob das Konzept noch klappen wird, aber verwerfen kann ich es zur Not später immer noch .

http://api.blitzbasicscript.com/keywords
http://api.blitzbasicscript.com/commands