Hallo Besucher, der Thread wurde 43k mal aufgerufen und enthält 409 Antworten

letzter Beitrag von xboxown1200 am

Basic Mega65 - Boulder Dash

    Das ist im Prinzip die gleiche Routine.

    Aber da das Array für die Diamanten kleiner ist, als das für die Steine, sind die Diamanten schneller beim fallen. Dafür muss auch noch ein Verzögerung eingebaut werden (abhängig von der Größe des Arrays).

    Habe jetzt noch ein paar Objekte hinzugefügt, damit man auch mal einen echten Level testen kann. Da alle 800 Felder getestet werden, ist die Geschwindigkeit deutlich langsamer als die Engine von TheRealWanderer.

    Zitat von Acorn

    Habe jetzt noch ein paar Objekte hinzugefügt, damit man auch mal einen echten Level testen kann. Da alle 800 Felder getestet werden, ist die Geschwindigkeit deutlich langsamer als die Engine von TheRealWanderer.

    Muss ich mir später gleich anschauen. Bin in letzter Zeit nicht wirklich weiter gekommen, da meine Arbeit mich etwas mehr in Anspruch nimmt.

    Das einzige was ich momentan hinzugefügt habe ist die Explosion, wenn Rockford einen Stein oder Diamanten auf den Kopf fällt.


    Noch eine Frage Acorn :

    Deine Befehlsfolge

    Code
    1. ON PEEK(A+O) GOTO2,2,3,8,13,18,2,2,23,12,1,34,65,66,67,68,22,69,76,83,90,97

    finde ich extrem lang.


    Das Basic 65 hat für solche Fälle eine neue Variante statt "ON n GOTO"

    gibt es den Befehl FGOTO

    Code
    1. a=PEEK(A+O)
    2. FGOTO a

    das macht dein Programm dann etwas übersichtlicher. Finde die Funktion im Basic 65 sehr cool. Das selbe geht natürlich auch mit FGOSUB


    Finde das bis jetzt sehr gut was du da gemacht hast. Dein Explosion finde auch besser wie meine. Muss mal schauen wie du das umgesetzt hast.

    Doch keine so gute Idee. Am Ende ist es ON n GOTO sehr ähnlich. Schade da habe ich zu schnell geschossen ohne darüber nach zu denken. :schande:

    FGOTO hat sogar den Nachteil, das man keine variierende Sprungziele benutzen kann. Der liegende Stein erschlägt keine Gegner, deshalb springt die Routine wieder nach Zeile 2, beim fallenden Stein wird der Gegner erschlagen und springt nach Zeile 35.


    Hier mal die aktuelle Objekt-Liste


    1 = Space -> Zeile 2

    2 = Sand -> Zeile 2

    3 = Stein liegt -> Zeile 3

    4 = Stein fällt -> Zeile 8

    5 = Diamant liegt -> Zeile 13

    6 = Diamant fällt -> Zeile 18

    7 = Stahl -> Zeile 2

    8 = Mauer -> Zeile 2

    9 = Spieler -> Zeile 23

    10 = Flag von Stein unten aufheben -> Zeile 12

    11 = Levelende -> Zeile 1

    12 = Flag von Spieler unten aufheben -> Zeile 34

    13 = Explosion 1 -> Zeile 65

    14 = Explosion 2 -> Zeile 66

    15 = Explosion 3 -> Zeile 67

    16 = Explosion 4 -> Zeile 68

    17 = Flag von Diamant unten aufheben -> Zeile 22

    18 = Glühwurm 1 -> Zeile 69

    19 = Glühwurm 2 -> Zeile 76

    20 = Glühwurm 3 -> Zeile 83

    21 = Glühwurm 4 -> Zeile 90

    22 = Flag Glühwurm 2 unten aufheben -> Zeile 97


    Die Reihenfolge der Objekte ist auch noch nicht optimal, die würde ich nochmal neu sortieren.

    Zum Beispiel würde ich den Sand mit Space tauschen, da dieser häufiger vorkommt, mit der Hoffnung das der erste Sprung bei On Goto schneller ist als der nächste.

    Mit vielen Feldern für die Sprünge kann man auf FGOTO wechseln, das würde ich aber erst machen, wenn das Programm so weit steht. Bei Änderungen wegen Bugs oder verschieben von Zeilen müsste man die Felder sonst von Hand anpassen. Es ist jetzt noch weniger übersichtlich als mit ON GOTO, da man die Sprungziele nicht mehr sieht, dafür aber einen Tick schneller. Und alles, was irgendwie Geschwindigkeit bringt, sollte man auch ausnutzen, denn es gibt mit Level I einen harten Brocken.

    Zitat von Acorn

    Es ist jetzt noch weniger übersichtlich als mit ON GOTO, da man die Sprungziele nicht mehr sieht, ...

    Ob die anzuspringenen Zeilennummern nun beim ON GOSUB stehen oder in der DATA-Zeile ist doch egal? Sehen kannst du sie in beiden Fällen.


    Und wenn z.B. die Sprungziele ab 10000 liegen, dann kannst du problemlos ein RENUMBER machen, solange der Bereich auf 1-9999 eingeschränkt wird. Also z.B. RENUMBER 10,10,1-9999

    Zitat von Acorn

    Mit vielen Feldern für die Sprünge kann man auf FGOTO wechseln, das würde ich aber erst machen, wenn das Programm so weit steht. Bei Änderungen wegen Bugs oder verschieben von Zeilen müsste man die Felder sonst von Hand anpassen. Es ist jetzt noch weniger übersichtlich als mit ON GOTO, da man die Sprungziele nicht mehr sieht, dafür aber einen Tick schneller. Und alles, was irgendwie Geschwindigkeit bringt, sollte man auch ausnutzen, denn es gibt mit Level I einen harten Brocken.

    Wirst du die Zeilen 123 bis 132 später in Datazeilen verpacken.

    Muss gestehen da muss ich mich komplett einarbeiten um das alles nach zu verfolgen.


    Werde aber erst mal die Engine von TheRealWanderer und deine Aufbauroutine soweit fertig machen das man einiger maßen damit spielen kann.

    Dann kann man sie ja mal geseitigtig antretten lassen um zu schauen welche Engine schneller ist. :D

    Sorry Snoopy, das kannste natürlich nicht riechen, das Programm zum Arbeiten sieht so aus. Das Umstellen auf FGOTO kostet später aber kaum Zeit, da man die Sprünge einfach in Datazeilen umwandeln kann, das ist auch viel besser als alles mit DIM O(1)=2 zu definieren. Sobald Drachen mit meiner Engine anfängt, werde ich ihm die den aktuelle Sourcecode geben. Bis dahin werde ich das ein oder andere noch eingebaut haben.



    Zitat von Drachen

    Werde aber erst mal die Engine von TheRealWanderer und deine Aufbauroutine soweit fertig machen das man einiger maßen damit spielen kann.

    In der Engine von TheRealWanderer ist noch ein blöder Bug drin, beim Abrollen der Steine/Diamanten fehlt das Bewegen zur Seite.

    Zitat von Acorn

    In der Engine von TheRealWanderer ist noch ein blöder Bug drin, beim Abrollen der Steine/Diamanten fehlt das Bewegen zur Seite.

    Kannst du das näher erläutern?

    Stehe gerade auf dem Schlauch.

    Achso, ja, das war Absicht, weil ich die Routine nur schnell hingezimmert habe.


    Im Prinzip muss lediglich die Positionen beim verschieben nicht diagonal links (pos+39) oder rechts (pos+41) nach unten gehen, sondern nur nach links oder rechts (+1 bzw -1). Im folgenden Durchlauf greift die normale Routine, bei der die Steine fallen.

    Zitat von Acorn

    Ja so wäre es richtig, auf der Seite Code inComplete gibt es ein paar PDFs zu Boulder Dash.


    In diesen wird das Verhalten der Objekte beschrieben: https://codeincomplete.com/articles/boulderdash-game-logic/

    Wow die Seite kannte ich noch gar nicht. Muss ich mir näher anschauen.

    Klasse Tipp Acron

    Hi Leute

    habe mal wieder viel Zeit gefunden um an unseren Bolder Dash weiter zu machen.

    Als ich so am Coden war für die Explosion für die Diamanten, passiert was sehr eigenartiges mit dem Farbram.

    Also bei ein normalen Explosion mit Rockford ist alles in Ordnung siehe Bild


    Alles Explosionsfelder zeigen sich in einer Farbe, so wie es soll.


    Wenn ich hingegen einen Stein auf einen Butterfly fallen lasse, werde zwar die Diamanten erzeugt, aber die Farben stimmen nicht. Siehe Bild


    Hier mal den Code für die Explosion mit Rockford

    hier hier den Code für "der Stein fällt auf einen Diamanten"

    Wie man sehen kann, ist die Berechnung für das Farbram gleich. Mir scheint so als ob das Programm die Zeile 8530 ignoriert.

    Ich kann mir das nicht erklären.

    Weis einer von euch was eventuell.

    Oder habe ich mal wieder ein seeeeeehhhhhhhhrrrrrr dickes Brett vor dem Kopf.


    Hier mal das Programm bis jetz.

    BD-Mega65-Basic.bas.txt


    Wie immer die Endung txt entfernen.


    Ich prog mal solange weiter. Vielleicht fällt der Groschen bei mir noch. ^^

    Hab gleich mal das mit dem Fallen der Steine geändert (also erst zur Seite und dann runter).


    Das mit den Farben hab ich mir noch nicht angesehen.