Puzzle 007

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 StudioEndlich selber puzzeln

Nun wird es langsam Zeit für etwas Interaktivität bei unserem Puzzle, wir kümmern uns um die Eingabe. Der Spieler soll nun ja mit dem Joystick das Puzzle lösen und schon müssen wir wieder eine schwerwiegende 😉 Entscheidung treffen:

 

Wie ‚versteht‚ der Spieler das Puzzle?

Ihr kennt unser Schiebepuzzle bestimmt auch aus dem CBM prg Studio, dort allerdings etwas größer.

Schiebepuzzle aus dem prg Studio
Schiebepuzzle aus dem prg Studio

Hier ist es relativ intuitiv zu verstehen, dass man auf das Teil klickt, dass man bewegen möchte. Ebenso, wie man bei einem ‚echten‚ Schiebepuzzle ein Teil mit seinen Fingern in die Lücke verschiebt.

Unlösbares 15'er Spiel!
Unlösbares 15‘er Spiel!

Das obige Puzzle ist übrigens (wie vom ‚Erfinder‚ ursprünglich vorgesehen) nicht lösbar! Für unser Spiel ist das natürlich undenkbar, wir müssen darauf achten ein lösbares Ausgangsbild zu erzeugen! Darum werden wir uns aber erst im nächsten Beitrag kümmern, hier wollen wir zunächst die Teile mit dem Joystick bewegen und da haben wir unser Problem.

Puzzleteil oder leeres Feld mit dem Joystick bewegen?
Leeres Feld oder Puzzleteil mit dem Joystick bewegen?

Ist man mit dem ‚echten‚ Puzzle vertraut, wird man das Puzzleteil bewegen wollen. Wenn man es allerdings nicht kennt, könnte man auch meinen, man ‘steuert‚ das leere Feld, das sticht schließlich so schön heraus. Bevor wir jetzt mit Kanonen auf Spatzen schießen und das einstellbar machen, treffen wir einfach die Entscheidung und drücken dem Spieler unsere Sichtweise auf.

Ich habe mich für das Bewegen des jeweiligen Puzzleteils, so wie beim realem Spiel entschieden.

 

Für unsere Eingabe brauchen wir noch einige Hilfsvariablen. Fügt also zu den Variablen, am Besten hinter calc16Bit:, noch folgendes hinzu:

In  freetilepos: merken wir uns die Position des freien Feldes, damit wir nicht immer nach dem $FF suchen müssen. Wir betrachten für unsere Bewegung immer das freie Feld und machen daran fest welche Bewegungen erlaubt sind. Die erlaubten Richtungen packen wir in die Hilfstabelle inputhelper:. Dort findet ihr für jede Position des freien Feldes binär die erlaubten Richtungen. Schaut dafür evtl. noch mal auf die Konstanten JOY_..., dann werdet ihr sehen, dass wenn das freie Feld sich oben links befindet nur RAUF und LINKS erlaubt ist (denkt daran, dass wir die Puzzleteile bewegen und nicht das freie Feld). Der Aufbau der Tabelle ist analog zu tileorder: .

 

Dann kümmern wir uns mal um die Eingabe, zunächst fragen wir den Joystick ab. Fügt die folgende Routine am Besten direkt hinter  puzzlemain: ein.

Gleich zu Anfang von checkinput:  springen wir in unsere bereits vorhandene Routine  joystickinput: zum Auslesen des Joystickstatus. Das Ergebnis steht wieder im Akku und wird auch unter inputstate:  gespeichert. Als nächste nehmen wir eine kleine Anpassung am Joystickstatus vor. Die benötigten Register $DC00 (CIA1_A / Joy-2) & $DC01 (CIA1_B / Joy-1) sind low aktiv, d. h. die BITs stehen auf 1, wenn der Joystick nicht betätigt wird und wechseln auf 0, wenn eine Richtung gedrückt ist. Da dies etwas unbequem ist, kehren wir das mit einem  eor einfach um, nach dem wir zur Sicherheit die oberen drei BITs ausgeblendet haben. Ist das Ergebnis null, dann wird der Joystick gerade nicht benutzt und wir brauchen nichts weiter zu prüfen, sonst merken wir uns den ‚korrigierten‚ Zustand wieder in  inputstate:. Als nächstes wollen wir sichergehen, dass nur eine Richtung gedrückt wurde. Dazu verschieben wir den Akku-Inhalt (dort steht auch die korrigierte Eingabe) solange nach rechts, bis wir eine 1 im Carry-Flag haben (eine muss vorhanden sein, sonst würden wir diese Zeile nicht erreichen s. o.). Da  lsr auch das Zero-Flag beeinflusst, können wir dann mit einem  bne prüfen ob der Rest Null ist (also keine weitere Richtung vorliegt). Wenn nur wenn eine einzelne Richtung vorliegt holen wir uns die Position des freien Feldes von freetilepos: ins X-Reg., um damit aus der Tabelle  inputhelper: die erlaubten Richtungen zu holen. Diese prüfen wir dann mit der aktuellen Eingabe und nur wenn die aktuelle Richtung wirklich erlaubt ist, springen wir zur Verarbeitung nach performinput:.

Jetzt müssen wir noch unsere Eingabe in die Tat umsetzen. Dies machen wir in der Funktion performinput:, die wir einfach hinter die Funktion von eben schreiben.

Wir verschieben den Akku-Inhalt nach rechts und kontrollieren das Carry-Flag. Wenn dort eine 1 auftaucht wurde der Joystick RAUF gedrückt und wir ‚verarbeiten‚ oben, wenn eine 0 im C-Flag steht springen wir zur Prüfung für RUNTER. Werft ggf. nochmal einen Blick auf die Tastaturmatrix und dort natürlich speziell auf die Joysticks, falls ihr mit der bitweisen Prüfung hadert. Wir schauen uns jetzt mal an, was passiert, wenn der Joystick RAUF gedrückt wurde, in unserem Beispiel steht das freie Feld in der Mitte (also auf Position 5). Wenn wir RAUF gedrückt haben, müssen wir jetzt also das Puzzleteil unter dem freien Feld finden. Dazu holen wir uns die  freetilepos:  in den Akku und addieren einfach zur Position des freien Feldes 3, das könnt ihr ganz einfach abzählen. Für den Zugriff auf tileorder: kopieren wir den Wert dann ins Y-Register. Nun merken wir uns das Puzzelteil im X-Register, überschreiben es dann in  tileorder: mit $FF und holen uns das gemerkte Teil von X in den Akku. Das speichern wir dann an der alten Position des freien Feldes, darauf greifen wir mit  tileorder:-3 zu (da im Y-Reg. die neue Position steht, müssen wir ja wieder drei Felder zurück) und legen dort das Puzzleteil wieder ab. Im Y-Register steht ja die neue Position des freien Feldes, die speichern wir natürlich noch unter  freetilepos: ab. Zum Schluß springen wir dann zum Refresh. Dort zeichnen wir einfach alles neu. Das ist hier OK, aber bei aufwendigeren Szenen sollten wir uns darauf beschränken nur das zu zeichnen, was sich wirklich geändert hat.
Die anderen Richtungen funktionieren ähnlich, die überspringe ich daher bei der Erklärung.

Wir sind nun fast durch, aber damit  freetilepos: zu Beginn richtig initialisiert ist, sollten wir vor das  rts  in shuffletiles:  noch einige Zeilen hinzufügen.

Wir durchsuchen hier  tileorder:  nach dem $FF und merken uns die Position in  freetilepos:.

 

Endlich ist es geschafft. Übersetzt das Programm und startet es… Ooops, ganz wie gewünscht klappt es noch nicht, wir sind aber nah dran. Ihr habt ja recht, nah dran ist ein Dessousladen bei dem die Schaufensterscheibe vergessen wurde. Es bewegt sich mehr als gewünscht, wer möchte kann ja mal versuchen es in den Griff zu bekommen. Ich werde meine Lösung im nächsten Beitrag zeigen.


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

2 Gedanken zu „Puzzle 007“

  1. Hallo,
    Der Build zeigt 2 Probleme an:
    Invalid Address Mode „sta tileorder:+3,y“
    Invalid Address Mode „sta tileorder:+1,y“
    Eine Idee wo die herkommen? Danke. 🙂

Schreibe einen Kommentar


Beachtet bitte, dass ich eure Kommentare erst manuell freigegeben muß, bevor sie auf der Seite erscheinen! Da ich nicht pausenlos am Rechner sitze, kann es schon mal etwas dauern, bis ein Kommentar für alle sichtbar ist.

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

Protected by WP Anti Spam