Frage zur Umsetzung einer Spielmechanik (Puzzle Boy)

Diese Seite verwendet Cookies. Durch die Nutzung unserer Seite erklären Sie sich damit einverstanden, dass wir Cookies setzen. Weitere Informationen

  • Frage zur Umsetzung einer Spielmechanik (Puzzle Boy)

    Hallo Leute,

    ich versuche mich gerade an einem "Puzzle Boy" bzw. Kwirk Clone.

    Falls ihr das Spiel nicht kennt, hier gibt es ein Video. Ab etwa 7:30 Minuten im Video sieht man die Rotationssteine in Action, mit denen ich Probleme habe.

    youtube.com/watch?v=uNhu0_isbnE

    Ich überlege jetzt seit 2 Tagen, wie ich wohl die türkisen, rotierbaren Steine am einfachsten umsetzen kann. Reicht dafür 1 Objekt oder brauche ich mehrere (z. B. den Rotationsstein + 4 Schalterobjekte in den Ecken). Irgendwie habe ich keine Idee, wie ich das mit möglichst geringem Aufwand umsetzen kann.

    Die Sprites der Rotationssteine haben bei mir 8 Frames, wobei Frame 0,2,4 und 6 jeweils eine Ausgangs- bzw. Endposition darstellen. Frame 1,3,5 und 7 werden nur kurz für die Rotationsanimation genutzt, da sie die Diagonale darstellen.

    Aber wann bzw. wie triggere ich die Rotation am Besten? Bei Berührung des eigentlichen Rotationssteins oder über besser über zusätzliche Trigger-Objekte, die ich in die Eckpunkte setze?

    Wie würdet ihr das lösen? Ich brauche nur einen kurzen Denkanstoß. Ich brauche keinen Code.

    Gruß
    Markus

    Dieser Beitrag wurde bereits 5 mal editiert, zuletzt von Beginner73 ()

  • Ich denke ein Objekt würde reichen. Du könntest mit collision_rectangle(); mehrere Bereiche der Rotationssteine abfragen. Bzw. überall dort, wo eine Berührung eine Rotation auslösen würde. Nach einer Rotation müsstet du die Bereiche wieder neu anordnen, damit sie mit dem Stein übereinstimmen. Ich würde die Berührungspunkte mit lengthdir_x(len, dir); und lengthdir_y(len, dir); platzieren. So könnten sie ganz einfach mitrotieren.

    Gruss

    Belial
    PUTREFACTION ////
    ◇ ALIEN BASTARDS ◇ SLY PITCH ◇ SHOVE MASTER ◇

  • Braucht es denn die gesonderten Berührungspunkte? Oder reicht es abzufragen, dass man sich nicht auf der selben höhe wie der Rotationspunkt befindet. Dann lässt es sich beim gegenlaufen drehen. Die Drehrichtung hängt dann wiederum von der eigenen Position relativ zum Drehpunkt ab.
  • Erst mal vielen Dank für die Anregungen.

    Also ich bin inzwischen ein ganzes Stück weiter. Ich habe nur ein Rotationsobjekt erstellt und frage die Drehrichtung ab, indem ich die Spielerposition und Bewegungsrichtung ins Verhältnis zur Drehachse abfrage. Das dürfte das sein, was TrunX meinte. Triggerobjekte sind nicht nötig.

    Meine Steine drehen sich, wenn Platz ist und werden von anderen Drehsteinen oder verschiebbaren Blöcken blockiert. Soweit so gut.

    Aber es steckt jedoch noch mehr dahinter.

    Jetzt muss ich noch dafür sorgen, dass das Objekt während der Rotation ggf. auch den Spieler "weiterschiebt". Das kann bei manchen Steinen der Fall sein, je nachdem wo ich stehe.
  • Also dieses Konzept schreit nach ds_grid . Das sind quasi 2d arrays. Ein globales ds_grid würde reichen, alle Steine können einen Wert an ihrer Position ablegen.

    GML-Quellcode

    1. //Beispiel für eine Zellengröße von 32 pixeln. wir benutzen modulo um x / y des Objekts zu Gridkoordinaten umzuwandeln
    2. //Wir können ein Parent objekt "parent_stone" erstellen und alle Spielsteine als Childs hinzufügen
    3. //Jeder unterschiedliche Stein bekommt in seinem Create Event eine seperate ID "stone_type"
    4. //Bei Raumstart:
    5. with (parent_stone) {
    6. var xx = (x mod 32);
    7. var yy = (y mod 32);
    8. ds_grid_set(global.game_grid, xx, yy, stone_type);
    9. }


    Bei Veränderungen musst du das ganze erneut aktualisieren oder du sorgst dafür das sich die Objekte die letzte Veränderung merken um sie wieder rückgängig zu machen. Performance sollte bei so einem grid basierten kleinen Spiel allerdings nichts ausmachen. Warum das ganze? Auf diese Weise kannst du das Grid für Kollisionsabfragen nutzen (0 oder -1 etc gleich leer, 1 = stein rot, 2 = stein xyz...) ohne dich mit Pixeln rumschlagen zu müssen. Und das einzige was die Steinobjekte "selber" machen müssen ist ihre Darstellung auf dem Bildschirm.

    tl;dr: Du kannst mit Hilfe eines ds_grids die Kollisionsabfrage von den Objekten entkoppeln und das ist nützlich weil jeder Stein eine klar definierte Position hat bei der man sich nicht mehr um Pixel kümmern muss.
    Für die rotierenden mehrblöckigen Strukturen müssen nur die benachbarten Zellen abgefragt werden.
    132 little bugs in the code. 132 little bugs. Fix a few, set the compiler to stew, 172 little bugs in the code... :vogel: