Akzeptiere ich auch, hatte Dir ja noch 'ne PM geschrieben gestern
Also wegen der Skriptsprache. Da gibt es natürlich viele Ansätze, wichtig ist auf jeden Fall, daß Du Dich von Anfang an nicht in eine Sackgasse begibst, sondern daß Du möglichst all das später abdecken kannst, was noch in Dein Spiel so reinkommen wird (und das weiß man ja oftmals nicht so genau, wenn man am Anfang steht).
Eine Möglichkeit wäre nun, ale Funktionalitäten für die Charaktere (und vielleicht auch für Gegenstände) in hübsche, klare Procedures zu packen. Somit hast Du schonmal den Vorteil, daß Du bestimmte Dinge in Deiner Skriptsprache 1:1 nachbilden kannst. Beispielsweise steht in Deiner Skriptsprache der Befehl "LoseLife", dann hast Du bestenfalls auch eine Procedure namens LoseLife, und kannst diese direkt aufrufen. Hierbei kannst Du natürlich auch perfekt Parameter übergeben.
Mit Variablen kannst Du natürlich auch arbeiten, allerdings wird das dann natürlich etwas komplizierter. Eine ganz simple, aber auch relative beschränkte Methode ist, jedem Objekt z.B. 20 Longs zu spendieren (als Array z.B.), die Du über Deine Skriptsprache setzen kannst. Zum Beispiel über einen Befehl wie "Set Var1 = 99". Natürlich könntest Du dann auch Aliase einbauen, sodaß Du tatsächlich "Set Energie = 99" eingeben kannst (wobei Energie ein schlechtes Beispiel ist, weil das eine so generelle Eigenschaft ist, daß Du da besser "native" Funktionalitäten einbaust anstatt dafür Variablen zu nehmen.
Wenn Dir das mit den 20 Variablen nicht reicht oder zu "unsauber" ist, kannst Du natürlich auch jedesmal Speicher allozieren, z.B. indem Du eine LinkedList benutzt. Diese muß dann natürlich mit einer Structure arbeiten, die sowohl Namen als auch Wert speichert. Um es performanter zu machen, sollte natürlich kein Name sondern eine Nummer vergeben werden, und der Name sollte nur in der Skriptsprache auftauchen (zur besseren Benutzbarkeit) und vor dem Spielstart entsprechend in eine fortlaufende Nummer konvertiert werden.
Letztendlich solltest Du dann eine Liste aller Befehle haben, sodaß Du diese komplett abarbeiten kannst. Oft ist es auch wichtig, daß Du in Deiner Skriptsprache Schleifen oder "Gotos" drin hast, daher solltest Du das Skript nicht live parsen, sondern bereits alles schön fertig im RAM haben und dort dann auslesen.
Allgemein noch ein Wort zur Performance: Natürlich empfiehlt es sich, das Skript hinterher nicht als Klartext in den Dateien zu haben, sondern jeden Befehl durch eine Zahl zu ersetzen (da reicht ja dann 1 Byte für 256 Befehle) und dahinter dann die entsprechenden Werte. Natürlich mußt Du Dir dafür dann einen kleinen Compiler schreiben. Ist aber bei einem größeren Projekt dann auf jeden Fall von Vorteil. Natürlich kannst Du dann den Skript-Compiler auch direkt noch in Dein Spiel einbauen, sodaß Du weiterhin mit Klartext-Skripten arbeiten kannst, die dann aber vor dem Spielstart direkt kompiliert werden und von nun an im RAM in Zahlen vorliegen. Damit ersparst Du Dir das lästige "von Hand kompilieren". Später kannst Du das dann ja auch wieder entfernen bzw. den Compiler dazu bringen, daß er erkennt, ob Du mit Klartext oder mit "Bytecode" arbeitest, somit kannst Du dann beim finalen Release die fertig kompilierten Skripte anbieten, um Cheatern das Leben schwerer zu machen (falls das in Deinem Interesse liegt).
Ich hab mal für eine Adventure-Engine eine Skriptsprache für jeden Raum erstellt, das war so 'ne Art Assembler, wurde dann hinterher auch in einen Bytecode umgesetzt. War benutzbar aber auch nicht perfekt durchdacht. Also wie schon gesagt, vorher auf jeden Fall gut planen und strukturieren, wissen was rein muß und was nicht, und dafür sorgen, daß es jederzeit gut erweiterbar bleibt.
