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

[Owly]

Huhu!

Weiß jemand, welcher Algorithmus hinter der "Approach Player"-Option des "Movement Type" eines Events steckt? Effizient ist die sicher nicht, aber wahrscheinlich viel schlanker als Lösungen wie A* oder Dijkstra, die den idealen Pfad vorberechnen.

[Kelven]

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



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:



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