Fahrt 004

weitersagen ...
Tweet about this on TwitterShare on FacebookShare on Google+Share on LinkedIn

C64 Studio
Für eine spielbare Strecke sorgen

Bei ‚Fahrt 003‚ haben wir zwar unsere Strecke bis zur Basis der Volour per Zufallsgenerator erstellt, aber es kann durchaus passieren, dass diese unspielbar ist. Darum wollen wir uns als Erstes kümmern und setzen das Projekt aus dem letzten Beitrag fort.

 

Der erste Bildschrim
Im letzten Beispiel habt ihr euch evtl. über den folgenden Code-Ausschnitt etwas gewundert.

Warum erst eine !byte-Anweisung? Ein einzelnes !fill hätte doch gereicht, es wurde eh alles ab roadtobase mit der zufälligen Strecke überschrieben. Sicher, aber nun verwenden wir diese erste Zeile, die zufällig Platz für acht Tiles (also einen Bildschirm) bietet, um den Start immer einheitlich zu gestalten. Ändert diesen Block zunächst einmal so ab…

Die Fahrt beginnt so immer mit dem selben Bildschirm, erst ab  roadtobase_rnd wir es zufällig. Außerdem habe ich noch die  !fill-Anweisung auf 81 erhöht. Somit kommen wir auf eine Strecke, die insg. 11 Bildschirme ‚lang‚ ist.

Sucht nun noch die Funktion initroad und ändert die Zeile sta roadtobase,X ;Zahl in die Tabelle eintragen einfach in sta roadtobase_rnd,X.

Schon läßt sich das Programm starten und ihr seht zukünftig immer den selben Startbildschirm.

Der immer gleiche Startbildschirm
Der immer gleiche Startbildschirm

Ihr könnt die ersten Tiles für den Startbildschirm natürlich beliebig wählen oder auch nur vier oder fünf Tiles vorgeben und den Rest des ersten Bildschirms schon zufällig füllen lassen. Ich denke aber es ist fair, dem Spieler etwas (wenn auch nur sehr wenig) Zeit zu geben, sich mit der Steuerung anzufreunden.

 

Das kann man (und Frau) schaffen!
Nun wollen wir noch dafür sorgen, dass die zufällig erstellte Strecke wirklich spielbar ist. Durch unseren bisherigen Ansatz, alles absolut zufällig zu gestalten, kann es durchaus zu folgender Strecke kommen.

Kein Durchkommen
Kein Durchkommen

Da der Rover später max. eine Tilebreite überspringen kann, ist dieser Abschnitt unmöglich zu spielen. Der nächste sichere ‚Landeplatz‚ wäre das Tile mit dem Schutthaufen, wenn man diesen vorher zerstört. Wie aber eben erwähnt, kann der Rover nie soweit springen.

Laßt uns daher folgende Regel fürs Erstellen definieren:

  • Nach einem Abgrund (egel ob sanft oder steil) muss immer ein gerades Stück oder ein Schutthaufen folgen.

Der Schutthaufen läßt sich auf eine beliebige Distanz abschießen und wird so wieder zu einem geraden Teilstück, auf dem der Rover landen / fahren kann.

Überarbeiten wir also unsere Routine zum Erstellen der Strecke. Für eine einfache Prüfung, sind unsere Tiles leider nicht in der richtigen Reihenfolge. Kopiert die Daten von tile_4 (dem Schutthaufen) an die zweite Stelle…

Dies hat den Vorteil, dass die sehr ähnlichen Tiles (gerade Strecke und Schutthaufen, der ja durch Beschuss zur geraden Strecke wird) direkt über die Nr. 0 und 1 angesprochen werden können. Somit können wir über eine einfache boolesche Operation für die Erstellung unserer korrekten Strecke bis zur Basis sorgen.
Möchtet ihr, dass auf dem Startbildschirm weiterhin ein steiler Abgrund erschein, dann müsst ihr, nach dieser Umstellung, bei roadtobase in der ersten !byte-Anweisung die 2 gegen eine 3 tauschen.

Begebt euch jetzt bitte zur Funktion initroad und ändert den Anfang, wo wir die Strecke erstellen, folgendermaßen.

Zu Beginn speichern wir auf der Zero-Page einen Filter, mit dem wir unsere Strecke (zumindest theoretisch, wie wir gleich noch sehen werden) spielbar machen. Nun ‚bereinigen‚ wir die ermittelte Zufallszahl mit dem neuen Filter. Durch die oben erfolgte Umstellung der Tiles, haben die sicheren Bauteile nun die Nr. 0 (gerade Strecke) und 1 (Schutthaufen, sicher nach Beschuß). Also können wir durch einfaches Ausblenden aller BITs, bis auf BIT-0 immer ein sicheres Tile erreichen, sonst sind alle vier Tiles möglich. Jetzt müssen wir in der Schleife nur noch dafür sorgen, dass nach einem Abgrund direkt ein sicheres Tile folgt. Die Abgründe haben nun ja die Nr. 2 (sanft) und 3 (steil), sie können somit also über BIT-1 an- und abgeschaltet werden. Über das eor #%00000010 erreichen wir genau dies. Da sichere Tiles immer möglich sein sollen, aktivieren wir diese zusätzlich über das  ora und speichern den neuen Filter unter  ZP_LOOPHELP.

Schon ist unsere Strecke schaffbar, wenn auch noch äußerst schwer!

 

‚Kontrollfahrt‚
Nun kann ich natürlich viel behaupten, wir wollen aber mit eigenen Augen sehen, dass die Strecke ab jetzt schaffbar ist. Dazu könnten wir das Programm so ändern, dass wir nach jedem Erstellen einen anderen Bildschirm der Strecke sehen. Das ist mir aber zu nervig, lasst uns die Strecke doch automatisch Tile für Tile durchscrollen.

Es gibt jetzt also noch nicht das demnächst folgende Soft-Scrolling, sondern ein sehr ruckeliges. Wir werden nun unser Programm so ändern, dass wir eine Routine haben, die ab einen gegebenen Start-Tile immer acht komplette Tiles auf den Bildschirm bringt. Somit können wir durch Erhöhung dieses Start-Tiles eine Art von Scrolling erreichen. Legt erstmal diese beiden Konstanten an.

In  ZP_FIRSTTILE merken wir uns das erste sichtbare Zeichen. Ab diesem werden also die nächsten acht Tiles für die komplette Bildschirmbreite gezeichnet. ZP_NEXTTILE verwenden wir beim Zeichnen und zeigt immer auf das nächste Tile, das ausgegeben werden soll.
Jetzt ‚lösen‚ wir noch das Zeichnen aus initroad heraus. Sucht dort die Zeilen

und fügt direkt dahinter diese zwei Zeilen ein:

Wir behalten das Initialisieren der Farben noch in initroad, setzen danach direkt ZP_FIRSTTILE zur Sicherheit zurück auf 0 und verlassen die Funktion anschließend.

Den nun herausgelösten Rest, der fürs Zeichnen verantwortlich ist, wandeln wir in eine neuen Funktion drawroad um.

Der Funktion wird im X-Register das erste sichtbare Tile für die Ausgabe übergeben. Wir speichern diesen Wert direkt bei  ZP_NEXTTILE. Das Y-Register dient wieder als Schleifenzähler für die acht durchläufe und gibt die Position des Tiles auf dem Bildschirm an. Dann holen wir uns die Tile-Nr. in den Akku und springen damit, wie bisher zu, drawtile. Danach erhöhen wir  ZP_NEXTTILE um eins und laden den neuen Wert wieder ins X-Register. Diese wiederholen wir, bis alle acht Tiles (siehe Y-Reg.) gezeichnet wurden.

Jetzt brauchen wir noch eine kleine Scroll-Routine, die fügen wir am Ende von main, zwischen den beiden gelb markierten Zeilen, ein.

Wir holen also das erste sichtbare Tile von  ZP_FIRSTTILE ins X-Register und springen damit zur neuen Funktion  drawroad. Damit das Scrolling am Ende der Strecke (wird durch eine negative Tile-Nr. hier $FF gekennzeichnet) stoppt, holen wir nach dem Zeichnen ZP_NEXTTILE (zeigt automatisch aufs ‘neunte‚ Tile für die Ausgabe) ins X-Register und kontrollieren, ob das Tile negativ (= Ende der Strecke) ist. Falls ja, springen wir zur Endlosschleife, sonst erhöhen wir  ZP_FIRSTTILE, damit unser Ausgabe beim nächsten Durchlauf um ein Tile weiter bewegt wird. Damit wir überhaupt etwas erkennen können, müssen wir eine Verzögerung einbauen. Wir warten einfach X-mal bis der Rasterstrahl den kompletten Bildschirm abgegrast hat (bei PAL geschieht dies bekanntlich 50-Mal in der Sekunde). Dazu laden wir das X-Reg. mit der gewünschten Anzahl und warten dann, bis die Rasterzeile 250 erreicht wurde. Sind wir in der gesuchten Zeile, dann verringern wir das X-Register und warten gleich nochmal, bis X den Wert Null erreicht. Erst danach zeichnen wir die Tiles erneut.

Jetzt könnt ihr euch das Ergebnis im Java-Emulator ansehen und das Projekt herunterladen.


Ihr solltet feststellen, dass wir tatsächlich keine unspielbaren Passagen mehr haben. Aber der Schwierigkeitsgrad ist wohl übertrieben hoch! Es gibt kaum Verschnaufpausen!! Darum werden wir uns Später noch kümmern müssen. Ich möchte aber damit fortfahren, das Scrolling zu verbessern.


Schrott!!Naja...Geht so...Ganz gut...SUPER! (4 Bewertungen | Ø 5,00 von 5 | 100,00%)

Loading...


 

<<< zurück | weiter >>>

 

weitersagen ...
Tweet about this on TwitterShare on FacebookShare on Google+Share on LinkedIn

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.

Protected by WP Anti Spam