PureBoard

UPDATE

- Klammerproblem weg
- Verbesserte Abfrage der Schlüsselwörter
- For To Next Schleife
- Debuggerausgabe als HTML (eigentlich nur für mich, damit cih weiß was mein Programm macht^^)
- Netter Nebeneffekt, auch Umlaute können ihn Variablen enthalten sein :-P
IncludeFile

Interessant wäre auch ein kleiner Compiler dazu, der alles in Bytecode
compiliert, was ja viel einfacher und schneller zu handhaben wäre.

Dann bräuchtest du natürlich zwei Teile. Einen Compiler und einen
Interpreter. Also erstmal nur als Vorschlag sehen.

aber würde das im Endeffekt nicht ehr langsammer sein, denn zur zeit ist es ja so, oder ist es so gedacht, das dieser ScriptCode irgendwo in einer Datei rumliegt, und sich die EXE, immer wieder "neu" einließt und abarbeitet, das heißt er ist nicht unbedingt fest.

Wenn ich nun dieses Script compiliere und dann erst Ausführe, dann geht das compiliere zwar schneller, wäre dann abe fest, für eine bestimmte Zeit.
Wenn sich nun was ändert/(änder soll) dann müsste neu compiliert werden, was dann langsammer wäre.

Aber du hast ja geschrieben, es ist nur ein Vorschlag, ich werde mich erst mal weilter mit der stabilisierung des Syntax befassen...

Naja also daß sich der Code "live" ändert wird wohl nur in den wenigsten Fällen vorkommen, aber in solch einem Fall müßte man halt einfach die Möglichkeit haben, von vorneherein die Bytecode-Funktion auszuschalten.

Ansonsten ist die Idee natürlich schon die bessere, weil's eben schneller bei der Ausführung wäre. Und je nachdem, wie komplex der Bytecode ist, kann es sogar sein, daß die Programmierung für Dich irgendwann angenehmer und einfacher wird, weil Du z.B. nicht für jede Art von Schleife neuen Code erstellen mußt, sondern einfach z.B. For- und While- und Repeat-Schleifen (oder was auch immer noch dazukommen mag) eh auf den gleichen Bytecode abgebildet bzw. kompiliert werden.

Meiner Meinung nach wäre das Endergebnis folgendermaßen am besten:
- eine DIC_RunBytecode()-Funktion, der Du einfach den Pointer auf ein im Speicher befindliches kompiliertes Skript übergibst
- eine DIC_RunString()-Funktion, der Du einen String übergibst, der wahlweise live ausgeführt oder erst kompiliert wird (ist dann aber doppelter Aufwand, daher würd ich sofort kompilieren)
- eine DIC_LoadScript()-Funktion, die eine Datei öffnet und daraus das Skript liest. Ist es als Sourcecode vorhanden, wird es sofort in Bytecode kompiliert und in einer zweiten Datei abgelegt, ansonsten wird einfach nur der Bytecode eingelesen

Bei größeren Projekten werden die Skripte eh meist in externen Dateien abgelegt. Somit kannst Du Deine Skripte direkt ändern, aber sie werden bei jedem Laden direkt kompiliert. Später kannst Du diesen kompilierten Bytecode ja auch wieder direkt in Deinen Programm-Sourcecode einbinden über einen Data-Block oder ähnliches, wenn Du unbedingt eine EXE haben willst, die alles beinhaltet.

Wenn Du oft DIC_RunString() verwenden willst, und die Kompilierzeiten Dich nerven, dann würde ich einfach noch zusätzlich eine DIC_CompileString()-Funktion bauen, dann kannst Du das Kompilieren in der Initialisierungs-Phase Deines Programms/Spiels machen, das dauert ja auch nicht besonders lang. Dann fällt ein Stück Bytecode dabei raus, welches Du im eigentlichen Spielverlauf dann immer schön effizient und schnell mit DIC_RunBytecode() starten kannst.

super Projekt,
ich hoffe du bleibst dran.

Hab 2 Projekte (Anwendungen, keine Spiele) die das gut brauchen könnten.


..aber ist das für eine KI in einem Spiel dann nicht etwas zu lahm?
Ich habs noch nicht ausprobiert aber wenn man viele Gegner(typen) hat, und das Programm dann jedesmal alles durchlaufen muss, fürchte ich, dass die Performance stark sinkt, im vergleich zu der fest "eingebauten" Ki. Und in Spielen steht und fällt ja grad alles mit der Performance

naja das gute ist ja, das das Script bis auf die Schnittstellen, wo die VARWerte ausgetauscht werden, komplett eigenständig laufen kann, also auch in einem Thread.

Wenn ich jetzt ein Spiel habe mit 1000 Eiheiten und 4Teams, dann wird nicht jede einheit eine eigenes Script bekommen, aber die 4KIs (Teams) können das locker machen.

Aber ich stimme dir Zu, das alleine die Umwandlung von Termen schon relativ zu fertig kompilierten sachen lange braucht, trotzdem, die Zeit im Beispiel Script konnte ich nicht messen,also kleiner 1ms

SirCus hat geschrieben:..aber ist das für eine KI in einem Spiel dann nicht etwas zu lahm?
Ich habs noch nicht ausprobiert aber wenn man viele Gegner(typen) hat, und das Programm dann jedesmal alles durchlaufen muss, fürchte ich, dass die Performance stark sinkt, im vergleich zu der fest "eingebauten" Ki. Und in Spielen steht und fällt ja grad alles mit der Performance

Sogar Maniac Mansion (von 1987) war schon komplett geskriptet
Also Skripte sind ein fester Bestandteil eines jeden Spiels, da würd ich mir keine Sorgen machen. Viele benutzen Lua und in letzter Zeit wird auch oft Python eingesetzt. Und wieder andere benutzen ihre eigene Skriptsprache.
In den Skripten wird ja auch nix hochkompliziertes gemacht, sondern meist werden ein paar Dinge berechnet und dann Entscheidungen getroffen. Die meiste Zeit verbringt Dein Spiel i.d.R. mit dem Rendern der Grafiken, und das wird natürlich nicht in Skripte ausgelagert, sondern da programmiert man sich eine Engine, die das alles so optimal wie möglich macht. Aber die paar Skripte, die fallen nicht sonderlich ins Gewicht, vorausgesetzt, man setzt sie richtig ein.

Natürlich sollte man eine Skriptsprache verwenden, die in Bytecode kompilieren kann, da dieser natürlich deutlich schneller ausgeführt wird als wenn erst immer alles live übersetzt werden muß.