Ergebnis 1 bis 8 von 8

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

  1. #1

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

    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.

  2. #2
    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

  3. #3
    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.

  4. #4
    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.

    Geändert von MagicMaker (13.07.2016 um 23:17 Uhr)

  5. #5
    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.

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

    Zitat Zitat
    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

  7. #7
    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!

    Geändert von Owly (14.07.2016 um 00:32 Uhr)

  8. #8
    Der Algorithmus ist minimal anders, von den Wahrscheinlichkeiten her:

    10% Random
    10% Forward
    80% Towards Player

Berechtigungen

  • Neue Themen erstellen: Nein
  • Themen beantworten: Nein
  • Anhänge hochladen: Nein
  • Beiträge bearbeiten: Nein
  •