Collab: Entwicklung eines TSB-Puzznic-Klons

Es gibt 1.089 Antworten in diesem Thema, welches 110.365 mal aufgerufen wurde. Der letzte Beitrag (1. November 2024 um 23:56) ist von Omega.

  • EgonOlsen71: Woher soll man solche Dinge wissen? Und wenn's nicht läuft. Wie kann man dann herausfinden, woran es gelegen hat?

    Das muss man halt irgendwie geschickt eingrenzen. In dem Fall habe ich den Emulator auf 20% Speed gestellt und geschaut, was da passiert. Er hat einfach die Blöcke gelöscht, anstatt sie nach unten zu schieben, also war klar, dass an der Stelle irgendwas schief war. Der Rest war Ausprobieren. Im Zweifelsfall bastelt man sich einfache Testfälle für sowas.

    Bitte melde dich an, um diesen Link zu sehen.

    Bitte melde dich an, um diesen Link zu sehen.

    Bitte melde dich an, um diesen Link zu sehen.

    Einmal editiert, zuletzt von EgonOlsen71 (14. Februar 2024 um 11:12)

  • Omega: Wenn EgonOlsen71 es mit compiliertem Basic hinkriegt, ist es auch ok. Ich mache langsamere Schritte, als ich dachte, weil es schon länger her ist, dass ich was mit Assembler gemacht habe.

    Okay. Kein Problem. Ich hoffe es macht dir nichts aus, wenn wir parallel nach alternativen Lösungen suchen.

    Das muss man halt irgendwie geschickt eingrenzen. ... Er hat einfach die Blöcke gelöscht, anstatt sie nach unten zu schieben, also war klar, dass an der Stelle irgendwas schief war.

    Das klingt ehrlich gesagt ziemlich kompliziert. Ich bin eher so der Typ, der einen Error in Zeile 12345 braucht, um was zu raffen. (Meistens raff ich's dann immer noch nicht. :))

  • Ich hab EgonOlsen71 s PRG jetzt nach TSB gewandelt und hier den Quelltext im C64Studio-Format auch drin. Rechts oben sind zwei Zahlen. Sie verdeutlichen, wie das Programm funktioniert. Sind sie weiß, ist die Fallenlassen-Phase im Gange, die wird immer von unten nach oben durchgezogen. "16" heißt, dass wir uns gerade in der achten Kachelzeile befinden, die darüberliegenden werden noch behandelt. Wobei "5" eine Optimierung meinerseits anzeigt. Es bedeutet, dass die oberen 5 Kachelzeilen nichts mehr enthalten, also von Programm übergangen werden. Die Bewegungsphase wird so oft durchgeführt, bis sich nichts mehr bewegt hat.

    Danach tritt die Check-die-Nachbarn-Phase ein. Sie wird mit grünen Ziffern dargestellt. Findet das Programm solche Nachbarschaften, blinken die Zahlen jeweils orange auf. Gleichzeitig verschwinden dann die Nachbarteile scheinbar, sie werden markiert (auf schwarz umgefärbt). Ist der Checklauf durch, werden die markierten Nachbarschaftler tatsächlich gelöscht. In diesem Durchgang, der von oben nach unten verläuft, sind die Ziffern rot. Danach folgt wieder die weiße Fallenlass-Phase, die Check-Phase, ggf. die Löschphase und wieder von vorn. Wenn sich überhaupt nichts mehr rührt, wird das Spielfeld neu aufgebaut.

    Bitte melde dich an, um diesen Anhang zu sehen. (In der Aktionsphase, das gelbe Kreuz rechts muss noch fallen)

    Zum Aufbau des Feldes hab ich MAP verwendet, ebenso für die Generierung der Symbole. Da aber die Verwaltung der Positionen nicht über ein das Spielfeld repräsentierendes Array erfolgt, sondern über den Bildschirm selbst ("wo ist nichts, da kann ich hin!") bewege ich die Symbole mit dem Bitte melde dich an, um diesen Link zu sehen.. Die Schwarzfärbung mit FCOL und die Löschungen mit FCHR. Bei einem Spielfeld-Array wäre ich weiterhin mit MAP vorgegangen.

    Das Ganze ist (auch wegen des vielen GePEEKes) schnarchlangsam. Aber es zeigt halt, wie es funktioniert. Deshalb also hier der Programmcode:

    Am Anfang lädt das PRG den MAP-Befehl und Omega s Zeichensatz, deshalb die Zeile 1. Die wartet auf einen Tastendruck. In der Zeit kann man schön die richtige Disk mit den benötigten Sachen einlegen. Nur nicht vergessen, dann irgendeine Taste zu drücken.

    So. Das nur zur Verdeutlichung. Gute Nacht!

    Arndt

    GoDot C64 Image Processing
    Bitte melde dich an, um diesen Link zu sehen. - Bitte melde dich an, um diesen Link zu sehen. - Bitte melde dich an, um diesen Link zu sehen.
    Bitte melde dich an, um diesen Link zu sehen. - Bitte melde dich an, um diesen Link zu sehen. - Bitte melde dich an, um diesen Link zu sehen.

  • GoDot: Vielen Dank für die Mühe. Ehrlich gesagt habe ich Schwierigkeiten, das Programm zu verstehen. Kann man das so ändern/reduzieren, dass folgendes passiert:

    1.) Die benachbarten Paare werden aufgelöst (es kann pro Durchlauf maximal 3 geben).

    2.) Die anderen Teile fallen von oben in die Lücken, die durch das Auflösen enstanden sind.

    3.) Es wird die Anzahl der aufgelösten Teile ermittelt und gemerkt.

    4.) Ende: Die Kontrolle wird wieder an den Spieler zurückgegeben.

    Übrigens: Bei dem Spiel handelt es sich nicht um einen Falling-Block-Puzzler a la Tetris/Columns. Bei Puzznic sind die Spielsteine schon von Anfang an auf dem Bildschirm und es kommen keine neuen dazu. Das Ziel ist, sie aufzulösen. Dann hat man gewonnen.

  • EgonOlsen71 s Programm ist eine Machbarkeitsstudie. Meine Version bildet sie nur in TSB ab. Alles andere musst du vorgeben. Es geht, heißt das bis jetzt.

    Arndt

    GoDot C64 Image Processing
    Bitte melde dich an, um diesen Link zu sehen. - Bitte melde dich an, um diesen Link zu sehen. - Bitte melde dich an, um diesen Link zu sehen.
    Bitte melde dich an, um diesen Link zu sehen. - Bitte melde dich an, um diesen Link zu sehen. - Bitte melde dich an, um diesen Link zu sehen.

  • Ich hab gerade keinen Zugriff, aber einfach die #-Kommentare löschen, dann müsste es laufen. Das Tempo ist unterirdisch, das liegt aber auch an der gewählten Positionsverwaltung und an der Menge der Bewegungen. Wenn es nur um eine einzige Bewegung geht, sieht das ganz anders aus.


    Arndt

    GoDot C64 Image Processing
    Bitte melde dich an, um diesen Link zu sehen. - Bitte melde dich an, um diesen Link zu sehen. - Bitte melde dich an, um diesen Link zu sehen.
    Bitte melde dich an, um diesen Link zu sehen. - Bitte melde dich an, um diesen Link zu sehen. - Bitte melde dich an, um diesen Link zu sehen.

  • Ich habe meinen Ansatz weiterentwickelt und versuche hier mal zu beschreiben, was da genau passieren soll wenn es fertig ist.

    Geladen und gestartet wird so:

    Code
    load"tsb.neo",8,8
    sys32777
    load"demonblock006"
    run

    Was ich schon habe:

    Der Spieler steuert mit dem Joystick in Port 2 den Cursor. Wenn man auf einem Spielstein steht, drückt man den Feuerknopf. Der Cursor färbt sich grün und man hält den Spielstein fest. Durch Links- und Rechtsdrücken wird der Spielstein bewegt.

    Es gibt zwei Arten einen Spielzug abzuschließen:

    1.) Indem man den Feuerknopf noch ein zweites Mal drückt (man lässt den Spielstein los und der Cursor färbt sich wieder weiß).

    2.) Wenn der Spielstein keinen Boden unter den Füßen hat (man lässt ihn dann automatisch los und er fällt runter).

    Was ich brauche:

    Ein Programm, das erkennt wenn sich Spielsteine gleicher Farbe berühren. Diese werden dann vom Spielfeld entfernt (außer bei Glasblöcken). Wenn sich über den aufgelösten Spielsteinen noch andere Spielsteine befunden haben, dann rutschen diese nach unten nach. Dies kann ggf. erneute Paarbildung verursachen. Wenn keine Paarbildung/Auflösung mehr möglich ist, ist das Unterprogramm zuende.

    Ich habe hier zur Veranschaulichung mal zwei Bilder angefügt. Betrachten wir "Zug 1". Das türkisfarbene Quadrat wird ein Feld nach links gezogen und es fällt runter. Dadurch bildet sich unten eine Dreierkombination aus türkisfarbenen Quadraten. Diese werden aufgelöst. Dann rutschen die drei Teile (auf die die grünen Pfeile zeigen) nach. Dadurch bildet sich eine neue Kombination aus den beiden grauen Kreuzen. Diese müssen auch aufgelöst werden und das Herz und die Raute rutschen nach. Dann ist der Spielzug vorbei und der Spieler ist wieder dran.

    Der neue Programmcode/SYS-Befehl soll in die Prozedur zugausf eingefügt werden zwischen Zeile 2250 und 2260.

    Wer mir ein entsprechendes Unterprogramm abliefern kann, wird im Titelbild gebührend erwähnt und von mir zum "Coder-of-the-Year" nominiert. Außerdem winken Ruhm und Ehre, ewige Vollkommenheit und Schönheit. Einsendeschluss ist der 20.02.2024. Der Rechtsweg ist ausgeschlossen.

    Bitte melde dich an, um diesen Anhang zu sehen.    Bitte melde dich an, um diesen Anhang zu sehen.

    Bitte melde dich an, um diesen Anhang zu sehen.

  • Geladen und gestartet wird so:

    Cooles Spiel! :thumbsup:

    Bitte melde dich an, um diesen Anhang zu sehen.

    Nur zwei kleine Kritikpunkte:

    - wechselnde Levels wären etwas abwechslungsreicher

    - wenn sich gleiche Steine, die sich berühren, auflösen würden, dann würde das das Spiel ungemein bereichern!

    :weg:

  • Nur zwei kleine Kritikpunkte:


    - wechselnde Levels wären etwas abwechslungsreicher

    - wenn sich gleiche Steine, die sich berühren, auflösen würden, dann würde das das Spiel ungemein bereichern!

    Klasse wäre es, wenn es Glassteine gäbe, die sich dann nicht auflösen! Hach, ich habe einfach großartige Ideen :saint:, vielleicht sollte ich Spieledesigner werden.

    ────────────────────────────────────────────────────────────
    Bitte melde dich an, um diesen Link zu sehen. - Bitte melde dich an, um diesen Link zu sehen.
    ────────────────────────────────────────────────────────────

  • Löscht ein Stein einen gleichen auch beim Vorüberfliegen nach unten oder nur dann, wenn er unten angekommen und liegen geblieben ist?

    Ich frage natürlich für einen Freund, der sich für die Programmierung interessiert. :whistling:

  • Löscht ein Stein einen gleichen auch beim Vorüberfliegen nach unten oder nur dann, wenn er unten angekommen und liegen geblieben ist?

    Der Stein, den man zuletzt gezogen hat, fällt erst runter bis er unten auf ein beliebiges Hindernis stößt (das kann auch ein gleicher Stein sein). Dann soll eine (bisher noch nicht existierende) Prüfroutine in Aktion treten und gleiche Spielsteine, die sich gegenseitig horizontal oder vertikal (nicht diagonal) berühren, suchen und vom Spielfeld löschen. Dabei soll gespeichert werden, wieviele Teile gelöscht wurden, z.B. in der Variable x. Wenn x=0 ist, dann ist alles erledigt und der Spieler übernimmt wieder die Kontrolle. Wenn x>0 ist, dann soll eine Routine ausgeführt werden, die die (durch das Paare-Auflösen) entstandenen Lücken aufräumt. Danach wird wieder das Auflösen ausgeführt, solange bis x=0 ist.

    Also grob schematisch dargestellt so

    Code
    Wiederhole
       [PaareAuflösen] (Rückgabe: x=Anzahl der aufgelösten Steine)
       wenn x>0 dann [LückenAufräumen]
    Bis x=0
  • EgonOlsen71 hat die Paare markiert (damit er alle erfassen kann) und erst dann aufgelöst (das wollte ich mit meinem TSB-Port verdeutlichen, hast du ihn ans Laufen gekriegt? Wenn ja, siehst du dort genau das). Wenn du einfach nur zählst, was ein Paar (oder ein Triplett oder so) ist, dann verlierst du wahrscheinlich den Überblick.

    Und nochmal, wenn das Spielfeld nicht nur auf dem Bildschirm, sondern auch in einem Array gehalten würde, wären die Suchen per PEEK sicherlich wesentlich weniger zeitaufwändig.

    Arndt

    PS: Ich hab deine Lösung zum MOBCOL-Befehl entdeckt, hehe... :D

    GoDot C64 Image Processing
    Bitte melde dich an, um diesen Link zu sehen. - Bitte melde dich an, um diesen Link zu sehen. - Bitte melde dich an, um diesen Link zu sehen.
    Bitte melde dich an, um diesen Link zu sehen. - Bitte melde dich an, um diesen Link zu sehen. - Bitte melde dich an, um diesen Link zu sehen.

  • das wollte ich mit meinem TSB-Port verdeutlichen, hast du ihn ans Laufen gekriegt?

    Nein. Da tut sich bei mir nix. Ich hatte sowieso gehofft, dass mir jemand eine genau passende Lösung anfertigt und ich die dann ins Programm einbaue und so tue, als hätte ich es komplett selbst geschrieben. Wenn nicht, bin ich erstmal aufgeschmissen.

    Und nochmal, wenn das Spielfeld nicht nur auf dem Bildschirm, sondern auch in einem Array gehalten würde, wären die Suchen per PEEK sicherlich wesentlich weniger zeitaufwändig.

    Hmmm. Man weiß es nicht. Ich bezweifle allerdings, das es insgesamt schneller geht wenn man die Daten zusätzlich zum Bildschirm auch noch im Array speichert.

  • Und nochmal, wenn das Spielfeld nicht nur auf dem Bildschirm, sondern auch in einem Array gehalten würde, wären die Suchen per PEEK sicherlich wesentlich weniger zeitaufwändig.

    Habe ich auch schon gedacht. Aber dann muss man das Array wiederum aktualisieren, wenn Steine fallen und/oder verschwinden. Ich bin nicht ganz sicher, ob das den Vorteil nicht wieder auffrisst...:?:

    Bitte melde dich an, um diesen Link zu sehen.

    Bitte melde dich an, um diesen Link zu sehen.

    Bitte melde dich an, um diesen Link zu sehen.

  • Ich hatte sowieso gehofft, dass mir jemand eine genau passende Lösung anfertigt und ich die dann ins Programm einbaue und so tue, als hätte ich es komplett selbst geschrieben.

    Das klingt sehr verlockend! :thumbsup: