Puzzle 008

Für diesen Beitrag wurde das CBM prg Studio verwendet.
weitersagen ...
Tweet about this on TwitterShare on FacebookShare on Google+Share on LinkedIn

CBM prg Studio
Lauter Lösungen

Im letzten Beitrag haben wir die Möglichkeit zur Bewegung der Puzzleteile eingebaut. Dabei kam es aber zum Problem, dass die Bewegung so schnell vonstattengeht, dass wir häufig zwei Teile gleichzeitig bewegt haben. Wie können wir das Problem jetzt lösen? Wir könnten z. B. eine Verzögerung einbauen, so dass der Spieler die Möglichkeit erhält den Joystick ggf. loszulassen. Ich möchte aber einen anderen Ansatz verfolgen, wir lassen einfach nur einen Schritt zur Zeit zu.

Fügt die unten markierten Zeilen zu  checkinput: hinzu:

Direkt zu Beginn holen wir uns nun die letzte Eingabe ins X-Register. Nach dem Prüfen der aktuellen Eingabe kontrollieren wir ganz zum Schluß, ob die Eingabe sich geändert hat. Dazu vergleichen wir X mit der aktuellen Eingabe, falls sie sich nicht geändert hat, springen wir direkt zum Ende der Routine, anderenfalls verarbeiten wir die Eingabe.
Durch diese Änderung müssen wir jetzt den Joystick jedes mal wieder loslassen oder in eine andere Richtung drücken, damit die Routine auf eine Eingabe reagiert.
Wenn ihr das Programm nun startet, könnt ihr die Puzzleteile endlich bequem bewegen.

 

Das nächste Problem war unsere shuffletiles:-Routine. Dort wurden die Puzzleteile reinzufällig verteilt, dabei kann es spätestens bei größeren Spielfeldern zu unlösbaren Puzzles kommen. Dies müssen wir natürlich verhindern! Also werden wir jetzt das Puzzle aus der gelösten Position per zufälliger ‚virtueller Joystick-Eingaben‚ durcheinanderwürfeln.

Ihr könnt nun die aktuelle Funktion  shuffletiles:  komplett gegen diese ersetzen:

Am Anfang legen wir im X-Register die Anzahl der Schritte fest, die wir fürs Verwürfeln nutzen möchten. Je höher ihr diesen Wert setzt, desto länger dauert das Mischen und um so schwieriger wird es. Da wir X gleich für etwas Anderes benötigen, merken wir uns den Schleifenzähler auf dem Stack.
Dann holen wir uns eine Zufallszahl. Da wir nur die vier Hauptrichtungen des Joysticks verarbeiten, brauchen wir auch nur die unteren beiden BITs. Dann kopieren wir die Zufallszahl aus dem Akku ins Y-Register und füllen den Akku mit dem Wert für den Feuerknopf (%00010000). Um nun an unsere Joystick-Richtung zu gelangen, verschieben wir den Akku um die ermittelte Zufallszahl nach rechts. Schaut ggf. nochmal auf die JOY_...-Konstanten, dann werdet ihr sehen, dass die Richtungen ‚rechts‚ vom Feuerknopf liegen.
Sobald wir unsere zufällige Richtung haben, müssen wir natürlich noch prüfen, ob diese überhaupt erlaubt ist. Dazu laden wir die Position des freien Teils ins X-Register und prüfen mit inputhelper:, ob die Richtung aktuell erlaubt ist. Falls nicht holen wir uns eine neue Richtung, anderenfalls lassen wir die Eingabe bei  performinput: verarbeiten.
Am Ende holen wir unseren Schleifenzähler wieder vom Stack ins X-Register, verringern X und wiederholen alles, bis X=0 ist.

Damit alles korrekt funktioniert, müsst ihr erst noch die Variablen korrekt initialisieren. Dies macht bitte zunächst direkt im Source.
Kontrolliert bitte, ob eure Werte, wiefolgt aussehen:

In  freetilepos: muss eine 8 stehen, unter tileorder: müssen alle Puzzleteile aufsteigend gespeichert sein, so wie es bei der korrekten Lösung aussieht.

Startet ihr das Programm, dann sollten die Puzzleteile nun lösbar verteilt sein. Da wir performinput: verwenden können wir das Mischen sogar verfolgen, es sieht aber noch nicht besonders schick aus (irgendwie fehlen unsere Sprites). Wir müssen in  puzzlemain: nur die Zeile  jsr shuffletiles: vor  jsr loadsprites: verschieben, damit werden die Sprites initialisiert und wir sehen jetzt beim Mischen auch die Sprites. Wer möchte kann dies natürlich abschalten, wenn es für den Spieler nicht sichtbar sein soll oder verlangsamen, damit der Spieler das Mischen besser verfolgen kann.

 

Mir ist bei meinen Tests aufgefallen, dass die ‚Verteilung‚ nicht immer sehr vorteilhaft ist. Das liegt evtl. daran, dass wir in  shuffletiles: sehr schnell Zufallszahlen ermitteln (vgl. Zufallszahlen in Assembler). Ich möchte daher eine eigene Quelle verwenden.
Fügt direkt hinter  main: diese beiden Zeilen ein:

VICRASTERROWPOS ist eine neue Konstante, die ihr oben einfügen könnt, z. B. bei den Sprite-Konstanten:

Wie ihr seht hat sie den Wert $D012, ihr könnt also auch direkt lda $D012 verwenden, falls ihr auf die Konstante verzichten wollt.

Unsere Quelle merken wir uns bei rndSeed:, für die spätere Verwendung. Dafür benötigen wir eine Variable für ein BYTE, fügt diese am Besten hinter calc16Bit: ein.

 

Jetzt müssen wir noch rndTIMER: anpassen. Fügt dort gleich vor dem  rts diese zwei Anweisung ein:

Wir verknüpfen unsere Zufallszahl noch mit unserer Quelle und speichern die eben ermittelte Zufallszahl als neue Quelle.

 

Ein Problem haben wir allerdings immer noch, wir müssen verhindern, dass beim Mischen zufällig ein bereits gelöstest Puzzle herauskommt. Wir benötigen aber sowieso noch eine Routine, die prüft, ob das Puzzle gelöst wurde. Lasst uns die neue Funktion  checkpuzzle:  hinter  puzzlemain: einfügen.

Als Erstes prüfen wir, ob das freie Feld rechts unten steht, nur dann müssen wir überhaupt weiter testen. Wenn das freie Feld sich an der richtigen Position befindet, kontrollieren wir, ob alle anderen Felder aufsteigend sortiert sind. Dazu holen wir uns die Anzahl der restlichen Felder (#$07, da 0 basierend) ins X-Register. Wir kopieren für die Prüfung X in den Akku und vergleichen jetzt ganz einfach, ob an der über X angegebenen Position in tileorder: der selbe Wert wie im X-Register (bzw. Akku) steht. Sind die Werte unterschiedlich brechen wir ab, sonst verringern wir X und prüfen weiter rückwärts bis X = 0 ist. Das letzte Puzzleteil brauchen wir natürlich nicht mehr zu prüfen, wenn das leere Feld korrekt platziert ist und alle anderen Teile auch stimmen, muss zwangläufig das letzte auch an der richtigen Position stehen.
Ist das Puzzle gelöst, gibt die Funktion eine 1 im Akku zurück, sonst eine 0.

 

Damit wir verhindern, dass unser Mischen dem Spieler ein gelöstest Puzzle präsentiert, bauen wir die neue Funktion checkpuzzle: dort gleich mal ein.
Fügt also zu  shuffletiles: vor dem  rts noch diese beiden Zeilen ein:

Jetzt starten wir die Routine einfach noch mal neu, falls das Puzzle gleich gelöst ist.

 

Wer möchte kann die Prüfung, ob das Puzzle gelöst ist ja noch in  checkinput: einbauen. Ändern wir doch einfach mal die Rahmenfarbe, sobald das Puzzle fertig ist. Schreibt einfach folgende Zeilen hinter das  jsr performinput: in checkinput:.

 


Damit sind wir am Ende angelangt. Das Puzzle schreitet langsam voran, aber ein paar Sachen fehlen natürlich noch. Wir sollten den Spieler durch eine Zugbeschränkung oder einen Timer etwas unter Druck setzen. Wenn wir nett sind, könnten wir z. B. noch Punkte fürs Lösen des Puzzles vergeben und wir müssen natürlich auch ein Scheitern des Spielers behandeln.


Start im Java Emulator


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