Collab: Entwicklung eines TSB-Puzznic-Klons

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

  • Snoopy: Das gibt es aber nicht wirklich, oder? :gruebel

    Falls doch: Wo kann ich mir das runterladen?

    Nicht ganz, ich habe mir "künstlerische Freiheiten" im Cover erlaubt. :D

    Aber das Buch gibt es tatsächlich von Data Becker:

    Bitte melde dich an, um diesen Link zu sehen.

  • Ich bastle an einer Lösung in TSBneo. Spiele von Omega sind schon seit Jahrhunderten BASIC-pur und das soll auch so bleiben! :D

    Bitte melde dich an, um diesen Link zu sehen.

    Ist aber erst der Anfang, aber ich bleibe da dran und will ausloten, was geht.

    Leider muss ich nun was machen, wofür ich Geld bekomme für Brot und Wasser für die Familie. Die Bezahlung ist bei Omega wirklich unterirdisch! ;(

    Eine Frage noch zum Verständnis: So ein Bildschirm, wie ich ihn mir gebastelt habe, kann eigentlich nicht sein? Oder dürfen auf dem Screen auch gleiche Steine nebeneinanderliegen ohne sich aufzulösen? Also erst, wenn ein zusätzlicher gleicher Stein dazukommt?

  • Ich bastle an einer Lösung in TSBneo.

    Sehr gut. Ich bin gespannt, was du austüftelst.

    Ist aber erst der Anfang, aber ich bleibe da dran und will ausloten, was geht.

    Hast du auch meinen Hinweis aus Bitte melde dich an, um diesen Link zu sehen. berücksichtigt? Ich bezweifle, dass man das Spielprinzip richtig umsetzen kann, wenn man nicht jedes einzelne Feld überprüft. Aber ich lasse mich gerne überraschen.

    Die Bezahlung ist bei Omega wirklich unterirdisch! ;(

    Ich verspreche dir, dass nach deinem Tod 72 tanzende Jungfrauen im Paradies auf dich warten. Klingt doch gut, oder? :emojiSmiley-133::emojiSmiley-133::emojiSmiley-133::emojiSmiley-133::emojiSmiley-133::emojiSmiley-133::emojiSmiley-133::emojiSmiley-133::emojiSmiley-133::emojiSmiley-133::emojiSmiley-133::emojiSmiley-133::emojiSmiley-133::emojiSmiley-133::emojiSmiley-133::emojiSmiley-133::emojiSmiley-133::emojiSmiley-133::emojiSmiley-133::emojiSmiley-133::emojiSmiley-133::emojiSmiley-133::emojiSmiley-133::emojiSmiley-133::emojiSmiley-133::emojiSmiley-133::emojiSmiley-133::emojiSmiley-133::emojiSmiley-133::emojiSmiley-133::emojiSmiley-133::emojiSmiley-133::emojiSmiley-133::emojiSmiley-133::emojiSmiley-133::emojiSmiley-133:

    So ein Bildschirm, wie ich ihn mir gebastelt habe, kann eigentlich nicht sein?

    Bei so einem Bildschirm müssten sich direkt beim Levelstart einige Blöcke auflösen und einige runterfallen. Das kommt aber in meinen Leveldesigns so nicht vor. Grundsätzlich kann man sagen: Alle Spielsteine haben von Anfang an eine feste Position und werden erst vom Spieler bewegt. Zumindest bei den Entwürfen, die ich gemacht habe.

    PS.: Beim mehrmaligen Betrachten deines mp4-Videos kommt mir der Verdacht, dass du hier versuchst den "Flood Fill"-Algorhitmus zu verwenden. Gute Idee, eigentlich. Aber bedenke: Bitte melde dich an, um diesen Link zu sehen.. Und das langsame "Fallen"-Problem ist damit auch nicht abgedeckt.

  • Ich verspreche dir, dass nach deinem Tod 72 tanzende Jungfrauen im Paradies auf dich warten. Klingt doch gut, oder?

    Kommen die mit 72 Schwiegermütter? :gruebel

    Bei so einem Bildschirm müssten sich direkt beim Levelstart einige Blöcke auflösen und einige runterfallen. Das kommt aber in meinen Leveldesigns so nicht vor. Grundsätzlich kann man sagen: Alle Spielsteine haben von Anfang an eine feste Position und werden erst vom Spieler bewegt. Zumindest bei den Entwürfen, die ich gemacht habe.

    Also bei einem Level sind beim Start niemals zwei gleiche Steine, die sich auflösen würden, benachbart zu finden?

    Sorry, wenn ich vielleicht blöd frage, aber ich will ja gerne alle möglichen Fälle berücksichtigen, aber nach Möglichkeit alle unmöglichen Fälle aussparen. ;)

  • Heureka! Ich glaube ich habe die Lösung gefunden. Der C64 schickt das aktuelle Spielfeld per Akustikkoppler an einen Raspberry Pi. Der führt dann die Berechnungen auf dem Spielfeld durch und sendet die Spielfelddaten wieder zurück an den C64. Der braucht das dann nur noch darzustellen. Genial! Ich ruf' sofort beim Patentamt an. :tel:

  • Und das langsame "Fallen"-Problem ist damit auch nicht abgedeckt.

    Was war denn das für ein Problem? Die Steine fallen in deiner Version doch schon runter. :gruebel

    Merkt man eigentlich arg, dass ich das zugrundeliegende Spielprinzip nicht so gut kenne? :whistling:

  • Heureka! Ich glaube ich habe die Lösung gefunden. Der C64 schickt das aktuelle Spielfeld per Akustikkoppler an einen Raspberry Pi. Der führt dann die Berechnungen auf dem Spielfeld durch und sendet die Spielfelddaten wieder zurück an den C64. Der braucht das dann nur noch darzustellen. Genial! Ich ruf' sofort beim Patentamt an. :tel:

    Mit dem WiC64 tatsächlich kein Problem...:D

    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.

  • Was war denn das für ein Problem? Die Steine fallen in deiner Version doch schon runter. :gruebel

    Wenn du einen Stein fallen lässt, dann bilden sich dadurch möglicherweise Paare. Und diese Paare werden aufgelöst. Und die Steine, die sich über den aufgelösen Steinen befunden haben, müssen nach unten nachrutschen. Weil kein Stein in der Luft schweben darf.

    Außerdem musst du berücksichtigen, dass, wenn du einen Stein aus einem Stapel herausziehst, rutscht der ganze Stapel um ein Feld nach unten. Und es bilden sich möglicherweise irgendwo Paare. Und wenn die sich auflösen, rutscht etwas nach- und es könnten sich wieder Paare bilden. Und die lösen sich auf und wieder rutscht etwas nach.

    Ja. Tückisch, tükisch. Ich glaube, dieses Spiel hat der Teufel höchstpersönlich entworfen.

  • Wenn du einen Stein fallen lässt, dann bilden sich dadurch möglicherweise Paare. Und diese Paare werden aufgelöst. Und die Steine, die sich über den aufgelösen Steinen befunden haben, müssen nach unten nachrutschen. Weil kein Stein in der Luft schweben darf.


    Außerdem musst du berücksichtigen, dass, wenn du einen Stein aus einem Stapel herausziehst, rutscht der ganze Stapel um ein Feld nach unten. Und es bilden sich möglicherweise irgendwo Paare. Und wenn die sich auflösen, rutscht etwas nach- und es könnten sich wieder Paare bilden. Und die lösen sich auf und wieder rutscht etwas nach.

    Ah, vielen Dank! :thumbup:

    Alles im Allem eine wohl höchst rutschige Angelegenheit! :)

  • Alles im Allem eine wohl höchst rutschige Angelegenheit! :)

    Ja. Das war ja der Grund, wieso mein Proof of Concept immer den gesamten Bereich durchgegangen ist, bis sich nichts mehr änderte. Das ist langsam(er), aber es erledigt all diese Fälle automatisch.

    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.

  • Alles im Allem eine wohl höchst rutschige Angelegenheit! :)

    Eigentlich ist das relativ leicht lösbar. In VB oder auf dem Mega65 (oder einer anderen schnellen Kiste) ist das ein Klacks. Da würde man jedes Feld durchprüfen und dann entsprechende Vertauschungen oder Auflösungen vornehmen. Aber in C64-Basic ist es eine Tortur. Weil das (mehrfache) durchscannen aller Felder bis Weihnachten dauert.

    Den von EgonOlsen71 vorgeschlagenen Compiler zu benutzen, ist auf den ersten Blick super. Aber problematisch wenn man TSB beibehalten will. Man hat in TSB nämlich nur einen einzigen Bereich, in dem man knapp 1KB zusammenhängend unterbringen kann. Der Rest ist Kleckerkram. Da passt so ein großes kompiliertes Programm nicht rein. Wenn der Quellcode mehr als eine Bildschirmseite in Anspruch nimmt, dann wird's schon eng.

    Und Assembler lernen? Naja. Ich schätze mal, da lohnt sich das Aufwand-zu-Nutzen Verhältnis nicht.

    Ich weigere mich im Moment noch aufzugeben. Aber viele Optionen bleiben nicht. Wenn kein edler Ritter in glänzender Rüstung kommt und einen <1KB großen MS-Code zum Fallen und Auflösen der Teile zur Verfügung stellt, dann war's das wohl.

  • Was wäre mit "ohne TSB"...? Klar, mehr POKEs und Gefummel, keine schönen Prozeduren usw. Aber wir reden hier ja nicht über das neueste AAA-Spiel. Das kann man in normalem BASIC V2 schon machen. Dann wäre wieder Platz für kompilierte Teile.

    Das Problem bei der Ritter-Lösung ist meiner Ansicht nach, dass der Ritter den Drachen nie genau so erschlagen wird, wie du das brauchst. Dann muss er entweder immer wieder neu antreten oder du müsstest eben doch kämpfen (also Assembler...) lernen und dann bist du wieder am Anfang...wäre ja schon gut, wenn du eine Lösung hättest, die du komplett selber pflegen kannst.

    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.

  • Ähm,

    Warum schaut ihr euch nicht den Quellcode vom Boulder Dash an. Da gibt es eine Routine fürs Fallen.

    Und auch ein Kaskade Überprüfung, wenn z.B. eine Stein in einen Meer voller Schmetterlinge fällt und diese sich dann in Diamanten verwandel.

    Und die Diamanten weiterfallen und wieder einen Schmetterling trifft usw.

    Den Source Code habe irgenwann mal im Netz gefunden. Es ist der Code von BD I, BD II und BD

    Er wurde sehr gut aufgearbeitet und man ihn gut verstehen.

  • Aber problematisch wenn man TSB beibehalten will. Man hat in TSB nämlich nur einen einzigen Bereich, in dem man knapp 1KB zusammenhängend unterbringen kann.

    Nein, der Heap ist ideal für sowas! Du positionierst dein kompiliertes PRG ans Ende des Heap, sagst Basic, wo dein Kompilat anfängt (damit es nicht von Strings beschädigt wird), und alles läuft! Genau so hab ich Bitte melde dich an, um diesen Link zu sehen. eingebunden, das hat 1613 Bytes und intern ein paar kleine Pufferbereiche (passt letztlich in sieben Pages) und läuft an $7900. Der Basic-Speicher wird nur um rund 1700 Bytes kleiner (aber um mehr als in einen Bildschirm passt).

    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.

  • Was wäre mit "ohne TSB"...? Klar, mehr POKEs und Gefummel, keine schönen Prozeduren usw. Aber wir reden hier ja nicht über das neueste AAA-Spiel. Das kann man in normalem BASIC V2 schon machen. Dann wäre wieder Platz für kompilierte Teile.

    Ja, da hast du wohl recht. Dann würde ich dazu tendieren, einen richtigen Compiler zu benutzen und nicht den Micro-Compiler. Der gibt einem nämlich auch Rätsel auf. Aber da wir alle an TSB hängen, ist das keine Option.

    ...wäre ja schon gut, wenn du eine Lösung hättest, die du komplett selber pflegen kannst.

    Hmm. Viele Köche verderben den Brei und so. Ja, ja. Stimmt ebenfalls.

    Nein, der Heap ist ideal für sowas!

    Und kannst du mir mal genau (für Doofe) erklären, wie das geht?

    Mit so einer Angabe wie:

    Bitte melde dich an, um diesen Anhang zu sehen.

    kann ich nämlich Null anfangen. Ich wüsste noch nicht einmal, wo ich das MS-Programm hinladen soll.

    Warum schaut ihr euch nicht den Quellcode vom Boulder Dash an.

    Ich schau mir den nicht an, weil ich kein Assembler kapiere.

  • Neuer Denkansatz:

    Das TSB-Programm manipuliert, ohne Ausgabe auf dem Bildschirm, nur einen Speicherbereich von 12 mal 12 Bytes. Die eigentliche Bildschirmdarstellung wird dann durch eine relativ einfache Assemblerroutine generiert, indem aus den 12x12 Bytes 24x24 Zeichen erstellt werden, inklusive Farbram-Manipulation.

    Vorteil: Die gesammte Spielelogik bleibt weiterhin in Basic wartbar.

  • Eigentlich ist das relativ leicht lösbar. In VB oder auf dem Mega65 (oder einer anderen schnellen Kiste) ist das ein Klacks. Da würde man jedes Feld durchprüfen und dann entsprechende Vertauschungen oder Auflösungen vornehmen. Aber in C64-Basic ist es eine Tortur. Weil das (mehrfache) durchscannen aller Felder bis Weihnachten dauert.

    Ich sehe es in C64-(TSB)-BASIC eher als Herausforderung. VB ist viel zu modern und MEGA65 sagt mir überhaupt nix. :whistling:

    Es müssen ja nicht alle Felder überprüft werden, das macht man halt dann, wenn man genug Leistung unterm Hintern hat. Die hat der C64 in BASIC/TSB nun mal nicht. Aber das ist ja auch der Reiz dieser alten Kiste.

    Wenn ein Stein fällt und eventuell eine längere Kettenreaktion hinter sich herzieht, dann gibt es das Spielprinzip auch her, dass man dem Rutsch- und Löschtreiben auch mal 2 bis 3 Sekunden zusehen kann. In der Regel wird es eh kürzer sein. Da wird niemand meckern und wenn es einem doch zu lang ist, kann er auch kurz aufs Klo gehen. ;)

  • Und kannst du mir mal genau (für Doofe) erklären, wie das geht?

    Mit so einer Angabe wie:

    Bitte melde dich an, um diesen Anhang zu sehen.

    kann ich nämlich Null anfangen. Ich wüsste noch nicht einmal, wo ich das MS-Programm hinladen soll.

    Dem Bitte melde dich an, um diesen Link zu sehen. folgen und lesen! =O Müsste dir sehr bekannt vorkommen! :P

    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.