höchstlimit für schritte? wenn nicht bei ziel angekommen -> alles verwerfen bis auf zufallszahlen, die schon verwendet wurden.
höchstlimit für schritte? wenn nicht bei ziel angekommen -> alles verwerfen bis auf zufallszahlen, die schon verwendet wurden.
was wenn der in wirklichkeit optimalste weg also die beste lösung mehr schritte erfordert als ich zufälligerweise als höchstlimit eingeben habe? das hat nichst mit berechen sonder mit "würfeln" und zufall zu tun. sowas such ich nicht, es sollte schon eine berechnung sein.
edit: alles andere würde 1. viel zu lange dauern und 2. mit hoher wahrscheinlichkeit würde irgendeinmüll herauskommen wenn ein paar zufällige faktoren wie npcs die sich bewegen oder kleine hindernisse innerhalb der map zusammenkommen.
Edit: noch mal etwas, nehmen wir mal an es gebe gar kein lösung sprich es gebe theoretisch keine verbindung zwischen A und B, dein zufallsscript würde in diesem fall unendlich lang suchen suchen suchen und nichts würde passieren. ein script das es allerdings berechnet und nicht ausprobiert das könnte erechen das keine lösung herauskommt
Kleine info am rande: das ganze ist als pathfinding für eine maussteuerung gedacht, also der held klickt irgendwo und schwubst er läuft dahin. das versuche ich zu realisieren. und zwar relativ perfekt dh. wenn eine verbindung zwischen held und ziel dann soll diese genutz werden allerdings brauche ich dafür ein komplexes pathfinding
Geändert von Mivey (01.01.2009 um 03:53 Uhr)
boah, um die uhrzeit hab ich keinen nerv mir das jetzt alles durchzulesen, vorallem nach deinem umleitungsschild wollte ich eigentlich den thread wieder zu machen, aber was solls, schreibe ich mal eine methode, die evntl noch nich genannt wurde.
an für sich ist es ja kein problem die terrain ID auszulesen, aber was machen, wenn das hinderniss im UPPER LAYER steckt?
dieser frage habe ich mich kürzlich mal gewidmet, und kam zu dem entschluss alle bode tiles auch als nicht passierbar und mit entsprechender ID nochmals auf dem chipset zu platzieren und sie unter den nicht passierbaren dingen zu positionieren. gut, das ging ja so weit auch recht gut, nur umständlich.
da kam mir eine zweite idee, ich setze alle hindernisse im upper layer als events, sprich der upper layer wäre damit hindernis los.
so, jetzt sag man natürlich, das ist doch genau das gleiche, aber weit gefehlt.
WARNUNG: bei dieser methode werden seeeehr viele variabeln drauf gehen.
so, was habe ich eigentlich vor?
ich versuche alle meine hinderniss events in varis zu speichern. d.h. wenn die vari auf 1 steht = hinderniss, wenn auf 0 = passierbar.
dazu erstelle ich mir ein event auf autostart, das bei map betreten aufgerufen wird und mir alle events bis zu einem abbruch event callt
(ich erkläre nicht wie man das macht, sondern nur die methode. ich setze einen gewisse erfahrung einfach mal vorraus)
das abbruch event soll verhindern, das der maker ins leere greift und ein
nicht vorhandenes event aufrfen will, das endet sonst in einem bösen fehler.
jedes event auf der karte muss nun also die seite 1 zum setzen frei haben. gecallt gibt es dann die koords an, und die werden dann für die formel benutz,
die mir berechnet, in welcher vari ID ich speichern möchte.
v = s + ( y * xmax + x)
v = die vari ID
s= der startwert, also die niedrigeste vari ID in der ich speichern möchte
y = y koord des events
xmax = die maximale mapbreite, die ich mit dieser formel berechnen möchte
x = x koord des events
so, nun haben wir also praktisch alle hinderniss events in einer rekonstruirbaren formel gespeichert, und können nun jederzeit wieder darauf zugreifen.
zum pathfinding im allgemeinen kann ich nur den A* algorythmus empfehlen
http://de.wikipedia.org/wiki/A*-Algorithmus
ich wollte euch nur eine andere methode zur feststellung der hindernisse auf der map bieten. ich denke das ist so ziemlich die einfachste methode, und mit dem 500000 vari patch von iwem is das auch sicherlich kein problem xD
ich werde mich auch demnächst nochmal intensiver mit dem A* befassen müssen, dann kann ich genaueres sagen, das was ich bis jetzt beschrieben habe ist graue theorie, also nichts handfestes was ich ausprobiert hätte.
ich gebe keine garantie darauf, das der A* aufm maker umsetzbar ist xD
mfg
EDIT:
ich weiß, ich habe jetzt nicht direkt zu pathfinding beigetragen, aber ich finde das auch ein wichtiges thema.
was mir auch eingefallen ist, das es ja auch bewegliche hindernisse gibt. da würde die "ich blocke im down layer" - methode auch nicht funktionieren, von daher könnte man auch noch eine kleinere liste für die beweglichen events erstellen, und die dann vor jedem pathfinding erneuern lassen. nur eine idee xD
Geändert von DNKpp (01.01.2009 um 04:35 Uhr)
oke dann hab ich also diese formel und was dann? ich meine ok dann hab ich eben für jedes hinderniss eine ID aber wie nützt mir das? also im prinzip müsste es also fragen (durch ein event oder bloß varis) ob zwischen mir und dem ziel ein hinderniss ist. das geht dank dieser formel. aber wie geht es dann drum herum um das hindernis? wie wird der weg berechnet? (sorry um 4 uhr morgens funktioniert mein hirn irgendwie nich)
ja das ist doch das gleiche xD
dann frägst du das feld daneben ab, ob es frei ist oder nicht.
wenn ja, versuch es da lang^^
wenn nicht, geh in die andere richtugn, falls das auch dicht ist, musste einen schritt zurück und da rum probieren^^
so im prinzip ist es ein wege wegstreichen. du hast sagen wir 1000 wege zur verfügung aber nur einer ist der richtige, du gehst die dann alle nach und nach ab.
ich würde dir für ein pathfinding empfehlen, das der bildschirm sich IMMER auf der spielfiegur befindet. somit kann man nicht so weit klicken und die rechenzeiten sind deutlich geringer. das machen auch die kommerziellen spiele so, siehe diablo und sacred und so^^
das hab ich auch so
und es gibt mehr als eine lösung zb. könnte man ja auch im kreis gehen aber ich probiersmal wie du gesagts hast. nur obs dann gleich den kürzesten weg findet weißichnicht.
ließ dir mal die beschreibung zu dem A* algorythmus durch..
auf anhieb den richtigen weg zu finden ist so gut wie UNMÖGLICH!
es werden mehrere versuche gebraucht.
lies dir das mal durch und schnapp dir ein paar tuts zu dem algorythmus, und dann versuch ihn mal nachzubauen. lachsen hat es glaube ich mal gemacht, nur hab ich nie ein script gesehen xD
also wie gesagt, der algorythmus ist dazu da um zu suchen, und nicht dazu sofort den richtigen weg zu erwürfeln^^
mfg
oke ich denk jetz hab ich nen einblick in das thema. naja ist wohl ziemlich kompliziert. müsste herumprobieren.
und im schlimmstem fall scheiss ich auf den ganzen müll und lass den hero einfach zum ziel teleportieren XD
lol, sicher auch ne variante, aber wie gesagt, es ist machbar, und an solchen aufgaben wächst man^^
ach ja, btw frohes neues xD
Ja, es ist machbar, ich habe vor einiger Zeit recht viel damit herumexperimentiert. Für "richtiges" A*-Pathfinding (Lachsen hat dazu auch mal ein Skript geschrieben, welches ich allerdings erst entdeckt hatte, nachdem ich mein eigenes Skript bereits halb fertig hatte :| ) braucht man jedenfalls unheimlich viele Variablen, und solange man nicht einen Weg findet, diese irgendwie "auszulagern" (etwa die ganzen Ergebnisse der verschiedenen Berechnungen mittels einem der vielen Patches in eine Textdatei schreiben) kann man Pathfinding am RM2k(3) eigentlich vergessen. Willst du einigermaßen einfach zu handhabenes, qualitativ hochwertiges Pathfinding, benutze den RMXP, denn dieser ist für technische Spielereien dieser Art meiner Meinung nach dank Rubyweitaus besser geeignet.
Könntest du mir, per PN oder hier im Thread, einen Link zu dem Script von Lachsen geben? Ich würde mir gerne ansehen wie er das Problem bewältigt hat.Zitat
(Lachsen hat dazu auch mal ein Skript geschrieben, welches ich allerdings erst entdeckt hatte, nachdem ich mein eigenes Skript bereits halb fertig hatte)
Abgesehen davon ist der Hero immer auf der Bildschirm mitte dh. der weiteste zurüklegbare wege ist von der mitte zu einem der vier Bildschirm ecken. Das sollte mehr oder weniger realisierbar sein, wie schon gesagt ich müsste herumexperimentieren. Und Varis und wenn nötig abspeichern sind dank Patches kein Problem mehr.
Das Skript sollte hier zu finden sein.
Berechtigungen
Zitieren