Komplexe Evente

[Rusk]

Guten Abend erstmals,
mein Problem sind diesmal Evente, welche mit einem AKS zu tun haben.
Folgendes will ich ausprobieren:
Ein Event (zb. ein Partymitglied) soll ein anderes Event (zb. Gegner) angreifen, falls er in dessen Radius kommt.
Umgekehrt soll auch das der Gegner machen.
Das mit dem Radius bekomme ich schon hin, aber wie soll ich das hinkriegen, dass eines der Evente sich zum anderen Event hinbewegt und diesen angreift oder sonst etwas mit ihm anstellt?
Einen Move - Befehl für derartiges gibt es ja nicht, nur für den Helden.
Meine Idee wäre es mit den berühmten X und Y Koordinaten zu machen,
aber mein Gedankenvermögen reicht dafür nicht ganz aus.
Und da ja sich im Atelier so kluge Köpfe tummeln, ersuche ich eure Hilfe und Ratschläge.
Vielleicht bringt mich ja der eine oder andere schon auf die Lösung ...

MfG Deamonic

[niR-kun]

Einen Move - Befehl für derartiges gibt es ja nicht, nur für den Helden.

...

Doch das geht, einfach in dem du die x- und y-Koordinate des Gegner-Events und des Mitglied-Events vergleichst und dann einfach diese bewegst. Da du das mit dem Radius ja schon gemacht hast, dürfte das nicht so schwer sein.

Falls du das Demoprojekt von Inelukis Tastenpatch hast, da kannst dir ja mal das ganze Anschauen (Map0020:Maussteuerung - Event0003:NPC-Bewegung) oder das Nachlaufen bei VD2 (auf so gut wie jeder Map). Das Prinzip ist immer das selbe - Vergleich der x- und y-Koordinaten und Event bewegen.

[Supermike]

Doch das geht, einfach in dem du die x- und y-Koordinate des Gegner-Events und des Mitglied-Events vergleichst und dann einfach diese bewegst. Da du das mit dem Radius ja schon gemacht hast, dürfte das nicht so schwer sein.

...

Natürlich ist das einfach! Das Problem an der Sache ist nur, dass die Events dumm wie stroh sind und wenn sie gegen etwas knallen auch da stecken bleiben, weil sie einfach keine ahnung haben wie sie "drumherum" müssen.
Insbesondere bei grösseren unpassierbaren Gebieten.

[Kelven]

Die einfachste (und für Makerspiele eigentlich schon ausreichende) Möglichkeit ist das gute alte step toward hero.

Im XP wurde das so implementiert:

Code:

def move_toward_player
    # Get difference in player coordinates
    sx = @x - $game_player.x
    sy = @y - $game_player.y
    # If coordinates are equal
    if sx == 0 and sy == 0
      return
    end
    # Get absolute value of difference
    abs_sx = sx.abs
    abs_sy = sy.abs
    # If horizontal and vertical distances are equal
    if abs_sx == abs_sy
      # Increase one of them randomly by 1
      rand(2) == 0 ? abs_sx += 1 : abs_sy += 1
    end
    # If horizontal distance is longer
    if abs_sx > abs_sy
      # Move towards player, prioritize left and right directions
      sx > 0 ? move_left : move_right
      if not moving? and sy != 0
        sy > 0 ? move_up : move_down
      end
    # If vertical distance is longer
    else
      # Move towards player, prioritize up and down directions
      sy > 0 ? move_up : move_down
      if not moving? and sx != 0
        sx > 0 ? move_left : move_right
      end
    end
  end
end

Das musst du dann nur in Makercode umschreiben.

[natix]

Wenn du was anderes willst als einen Step towards Hero dann stehst du vor einem Problem weil es nicht wirklich einfach ist einem Event beizubringen Hindernisse zu erkennen und drumherum laufen zu lassen. Es gab mal ein Path Finding Skript für den Maker in dem man einem Event sagen konnte wo es hinlaufen sollte und es fand von selbst aus einem Labyrinth heraus. Problem war an dem Skript das es nicht wirklich zu verstehen war und hunderte von Variablen nutzte. (Wenn ich es richtig in Erinnerung habe)

Wenn du ein Event ein anderem folgen lassen willst, dann speicherst du die Koordinaten der beiden Events in Variablen, vergleichst diese miteinander und bewegst das Event dann je nachdem in welchem Verhältnis die Variablen voneinander abweichen. Eigentlich schnell gemacht, wie schon gesagt, aber das Problem mit den Hindernissen bleibt bestehen. Aber ich denke bei so etwas wie einem AKS ist das auch weniger schlimm, weil da ja eigentlich sowieso alles und jeder in Bewegung ist und sich schnell eine neue Route um das Hinderniss herum auftut.

[Rusk]

Danke für eure hilfreichen Antworten, werde mich mal hinsetzen und das in Ruhe ausprobieren.

[Dhan]

Eine erweiterte Möglichkeit eines einfachen "nehme kürzeste Luftlinie"-Systems wäre es, zu speichern, was die letzten Koords des Events waren und was die 2 zuletzt gelaufenen Richtungen waren und wenn sich die Koords nicht verändern, versucht das Event es einfach mit einer anderen Richtung (solange diese nicht entgegengesetzt ist)
Hilft nicht, wenn das Event in ein U reinläuft, wohl aber, wenn bloß ein einziges Feld im Weg ist

Komplexeres Pathfinding ist auf dem 2k jedenfalls Quatsch, es sei denn, du willst extrem viel Variablen aufwenden um Objekte mit Zeigern zu simulieren (und sowat wie Breadth First Search auf Tiles als Objekten zu machen und dabei den Search zur Entfernungsmarkierung verwenden) - und es kann dann sein, dass der Maker für sowas schlichtweg zu langsam ist