[RPG Maker 2000/2003] Algorithmus hinter "Approach Player" gesucht

[Kelven]

Ich kann mir vorstellen, dass er so ähnlich wie auf dem XP umgesetzt wurde:

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

[Owly]

Hm, der Code passt zum "Movement Command" "Move Toward Player" unter "Set Move Route". Aber "Approach Player" funktioniert anders.

"Move Toward Player" versucht den direkten Weg, aber bleibt an Hindernissen hängen. In dem Code sehe ich auch keine Überprüfung auf Hindernisse.
"Approach Player" geht nicht den direkten Weg. Events mit diesem "Movement Type" überbrücken nicht einfach stumpf Distanz, sondern scheinen einem zufälligen Muster zu folgen, um Hindernisse zu umgehen. Ganz ohne Vorberechnung. Wie gesagt, keine effiziente Methode, aber ich stelle sie mir einfacher vor und wenn es darum geht, ein Event ans Ziel zu führen, ist sie in einer hindernisreichen Umgebung deutlich erfolgreicher.

[MagicMaker]

Die automatisierten Routen bei RPGXP neigen immer dazu, sehr dickköpfig zu sein und brechen den
Schritt ab, wenn die ausgewählte Richtung nicht passierbar ist, statt danach mal auf eine nächstbeste
andere umzuschalten, das Problem seh ich auch hier. So ein Verhalten hat RPG2000 hingegen nicht.

Besonders die Random-Route bei RPGXP kann dafür sorgen, dass ein Event lange irgendwo in einem
schmalen Durchgang festhängt, weil es sich partout immerzu dazu entscheidet, gegen ne Wand zu
laufen und keine Alternativen suchen will.

Man könnts in RPG2000 per Disassembler angucken, wenn man die Stelle im Code kennt, ich geh aber
nicht davon aus, dass dahinter nix allzu Verrücktes steckt und statt spätestens nach zwei Versuchen
(oder einem wie bei Random) einfach aufzuhören, wird noch irgendwas anderes gemacht, damit ne
Figur nicht die ganze Zeit in einer Ecke stehen bleibt, sowas wie noch gelegentliche Schritte in eine
Zufallsrichtung, um mit etwas Glück nem kleinen Hindernis, also nix, das mehr als vielleicht drei
Schritte Umweg bedeutet, zu entgehen.

[Eddy131]

Ich würd vermuten, dass es eine Mischung zwischen direktem Weg zum Spieler und einem Zufallswert ist.

Das Event kann also in alle Richtungen per Zufall gehen, aber die Richtung, die zur Spielfigur führt hat ne Wahrscheinlichkeit von 85% und die anderen drei nur 5% oder etwas in der Art.
Ist simpel und effektiv. Und nachdem, wie die Figuren sich bewegen erscheint mir dass die wahrscheinlichste Methode.

[Kelven]

@Owly
Ich glaub nicht, dass der Algorithmus vom 2K/2K3 wirklich Hindernisse berücksichtigt. Da ist wohl eher eine Menge Zufall mit dabei.

In dem Code sehe ich auch keine Überprüfung auf Hindernisse.

...

Er macht das indirekt über "not moving?".

So ist "approach player" auf dem XP implementiert:

Code:

  def move_type_toward_player
    # Get difference in player coordinates
    sx = @x - $game_player.x
    sy = @y - $game_player.y
    # Get absolute value of difference
    abs_sx = sx > 0 ? sx : -sx
    abs_sy = sy > 0 ? sy : -sy
    # If separated by 20 or more tiles matching up horizontally and vertically
    if sx + sy >= 20
      # Random
      move_random
      return
    end
    # Branch by random numbers 0-5
    case rand(6)
    when 0..3  # Approach player
      move_toward_player
    when 4  # random
      move_random
    when 5  # 1 step forward
      move_forward
    end
  end

[Owly]

Tatsache. Ich habe das switch-Statement nachgebaut und es verhält sich quasi wie "Approach Player". Soo~ simpel hätte ich es dann doch nicht erwartet. Hast du auch den Code zu move_toward_player?

Ich danke euch bis hierhin schonmal!

Edit: Was frag ich denn so dumm. Hast du ja oben schon getan, Kelven. xD Nochmals danke!

[Cherry]

Der Algorithmus ist minimal anders, von den Wahrscheinlichkeiten her:

10% Random
10% Forward
80% Towards Player