Simons’ Basic/TSB: Farben, Zeichensätze, Sprites & Co.

Zitat von Snoopy

die "Engine" sauber von den "Spielleveldaten" getrennt hättest. Also z.B. dass die Levelinfos in Strings verpackt sind und die Engine daraus die Levels zeichnet und die Verhaltensinfos daraus entnimmt. Dann müsstest du nur jeweils die Strings austauschen, z.B. durch Einlesen der Infos aus einer Datei und die Engine kümmert sich dann selbstständig um das neue Level.

Ja, es ist durchaus erstrebenswert, eine solche universelle Engine zu erschaffen. Allerdings erschweren die doch recht individuellen Auswirkungen eine Umsetzung. Es ist wesentlich einfacher solche Special Events hardzucoden. Es hätte ggf. aber gepasst, die komplette Spiellogik in ein File unterzubringen, wenn man die Level und Texte bzw. so viele Daten wie möglich auslagert, den Code strafft und optimiert.

Sofern sich die levelspezifische Logik nicht wirklich elegant in Strings abbilden (abstrahieren) lässt, baut man sich ja auch nur eine Art "BASIC in Strings", und dafür gibt's einen Begriff: https://en.m.wikipedia.org/wiki/Inner-platform_effect

Delete und Merge hielte ich da für die bessere Option, zumal man so das Spiel sozusagen unbegrenzt groß machen und es perspektivisch auch dynamisch aus z.B. einem CRT "nachladen" lassen kann. Gleichzeitig ist man nicht auf relativ gleichförmige Level festgelegt bzw. kann ziemlich frei entwickeln.

Zitat von Omega

Wenn delete und merge reibungslos (und ohne POKEs) zur Laufzeit funktionieren würden, dann wäre das ein Ansatz. Das hat aber bei mir nicht geklappt.

Ich schau mir das mal an. Du hast ja Engine und Level schon voneinander getrennt. Da wundert es mich, wieso das mit D! und MERGE nicht klappen sollte (wie hier und noch genauer hier beschrieben).

Arndt

Zitat von Omega

Das ist ja voller POKEs.

Wovon der Spieler nichts bemerkt...

Ich stelle gerade fest, dass in Version 2.0 der individuelle Level-Part bei Level 1 in Zeile 3250 beginnt, in Level 2 aber in Zeile 3400. Außerdem hast du im "Engine"-Teil in beiden Programmen nicht immer gleiche Programm-Teile drin. Das ist natürlich dann schon etwas hakelig...

Arndt

Edit: Außerdem hast du in der Engine (in INIT) levelspezifische Aufrufe (Musik usw.), das kann nicht funktionieren!

Siehste, so ist das

So ging es mir nach Joe Gunn, wo ich statt einer Engine jedes Rätsel in allen Facetten hand-gestrickt habe (Position prüfen, Gegenstand prüfen, etc.)

Um wieder gemein zu sein, bei C64Studio kannst du auch BASIC-Dateien per #include zusammenfügen. Da könnte man die Engine auslagern, und die Levels drumherum aufbauen.

Sowas müsste auch mit TSB-Bordmitteln gehen, GoDot guckt doch gerade. Dann ist zumindest ausgeschlossen, dass man Funktionen mehrfach schreibt (und dann gerne mal irgendwo eine Nuance verliert)

Aber hinterher ist man sowieso immer schlauer

Aber vielleicht ist das was für Ghost Canyon (der direkt hinter dem Valley, dann nach 50km an dem lila Kaktus links)

Zitat von Endurion

... an dem lila Kaktus ...

Kaktus ist immer gut!

Eigentlich würde es ja auch reichen, wenn MERGE analog zu LOAD im Programmmodus nach getaner Arbeit das Programm wieder von vorne starten oder gar direkt nach dem MERGE weitermachen würde... (und das Gleiche für D!)

Ob ein MERGE funktionieren würde, dass eingeladene Zeilen wie eine Neueingabe behandelt? Man also einfach existierende überschreibt? Gibt es auch ein DELLINE mit einer Range, so dass man sagen wir Zeile 1000 bis 2000 löschen könnte?

Nichtsdestrotrotz, Variablen sind dann in der Regel futsch, das Programm wird kaum an der aktuellen Stelle weiterlaufen können.

Zitat von Endurion

Nichtsdestrotrotz, Variablen sind dann in der Regel futsch, das Programm wird kaum an der aktuellen Stelle weiterlaufen können.

Die kann man doch aber im Speicher ablegen und danach wieder zuordnen

Bei C geht sowas wie #include, weil der Precompiler das noch vor dem Kompilieren einfach alles zusammenkopiert. BASIC V2 hat aber weder Precompiler noch Compiler. Und vom Sprachdesign her ("alles irgendwie dynamisch zurechtpfuschen") würde merge/delete viel besser zu BASIC V2 passen.

Wann sollte TSB denn ein #include tatsächlich ausführen?

Würde MERGE bei TSB im Programmmodus automatisch wie LOAD das Programm neu starten, bräuchte man die POKEs nicht, siehe #1772.

Ein klein wenig frickelig ist das mit den Variablen behalten schon, weil a) der Speicherplatz evtl. mit Variablen behalten nicht ausreicht (geschenkt, gibt man halt ggf. Out of memory aus), aber vor allem b) Konstantenstrings direkt im Code liegen, die Stringdeskriptoren also potenziell bei MERGE/DELETE ungültig werden bzw. aktualisiert werden müssen.

Wobei das die BASIC-Autoren bei LOAD auch nicht geschert hat und da ggf. Variablen großflächig zu Müll werden.

Zitat von Endurion

Ob ein MERGE funktionieren würde, dass eingeladene Zeilen wie eine Neueingabe behandelt? Man also einfach existierende überschreibt? Gibt es auch ein DELLINE mit einer Range, so dass man sagen wir Zeile 1000 bis 2000 löschen könnte?

DELLINE heißt in TSB D! und landet nach getaner Arbeit (ordnungsgemäß) im Direktmodus. Wenn ich dann aus dem Programm heraus MERGE ausführen will, kann ich das nur mit POKEs in den Tastaturpuffer auslösen. MERGE landet ebenfalls im Direktmodus, startet aber nicht (wie LOAD) das Programm neu, daher die weiteren POKEs in meinem (schon genannten) TSB-Tipp. Natürlich muss man so eine Teilung in Engine und Level vor der Programmiererei planen, es nachher noch nachzurüsten ist unnütz (weil es - des Aufwands wegen - nicht klappen wird).

Dass das Auftrennen geht, zeigen meine Spiele Sokoban, ByPuzz und ByPixx, denn da sind Engine und Level eben getrennt und werden (bei Sokoban noch nicht, da hatte ich die Idee noch nicht) im laufenden Programm eingebunden.

Arndt