Wie lässt sich Auto-Aim implementieren?

[Kelven]

@-KD-
Kein Problem, ich würde es wenn dann nur mit dem XP umsetzen. Neuere Maker hab ich nicht und auf den alten wäre mir das zu doof.

@anti-freak
Ich beherrsche gerade noch so die Grundschulmathematik. xD Ich verstehe grundsätzlich worauf du hinaus willst. Die Steigung bekommt man durch (y2 - y1) / (x2 - x1), oder? Zumindest sagt das Internet das. Nicht ganz klar ist mir, warum man die kleinere Steigung durch die größere teilen muss. Und gehst du bei der Multiplikation mit 16 von den alten Makern aus oder soll damit quasi die Mitte der Tiles getroffen werden? (Beim XP sind die Tiles 32x32 Pixel groß). Die Geschosse wären übrigens unsichtbar, also kann man von einer Größe von einem Pixel ausgehen.

[Grandy]

Ich bin noch mal über die Verfahrensweise drübergegangen, die ich damals angewendet habe, und verstehe selbst nur noch die Hälfte (Hey, das Ding ist sieben, acht Jahre alt) - streckenweise ist es aber auch übertrieben umständlich gehandhabt, was auch daran liegt, dass es eine abgespeckte Version des London-Gothic-Systems ist, das viel mehr Parameter berücksichtigen musste (Entfernung, Körperhaltung, Rückstoß, Zieldauer - hier ein kleiner Gruß an real troll, der daraus in der Allreise ein Lotteriespiel gemacht hat; im Spiel war die sich verändernde Trefferchance ein Zeichen dafür, dass man länger auf den Gegner "anlegt".)
Ein paar Gedanken, die ich mir damals gemacht habe, könnten dir vielleicht etwas Arbeit ersparen:

1. Eine hundertprozentig exakte Berechnung ist m.E. unnötig, da der Spieler die Umgebung aufgrund des "unsichtbaren Projektilsl" und der Pseudo Perspektive des Makers ohnehin anders auffasst, als es realistisch wäre - es sei denn, du planst eine Perspektive direkt von oben ein (was ich übrigens für eine nette Abwechslung hielte - in dem alten DOS-Spiel Dreamweb hats das auch ganz gut funktioniert... und es spart Zeit).
2. Bedenke die bei der Trefferabfrage, dass der Gegner, de am nächsten steht, auch als erstes getroffen wird.
3. Eine Zimmerpalme, die im Weg steht, *kann* ein Hindernis darstellen, muss es aber nicht.
4. Noch was zur hundertprozentig genauen Berechnung - nicht jeder Schuss muss automatisch ein Treffer sein - Ungenauigkeiten bei der Trefferberechnung könnten theoretisch (also aus der Sicht des Spielers) auch darauf zurückzuführen sein, dass der Charakter halt nicht immer 100% trifft - damit hast du ein Feature, ohne dir Arbeit damit machen zu müssen. Angesichts der Tatsache, dass sich die Gegner in einem Action-KS die ganze Zeit bewegen, ist eine genaue Überprüfung, ob du nur geschludert hast, ohnehin kaum möglich.

Btw: Ich habe auch noch ein Spiel in der Pipeline, bei der ein entsprechendes Kampfsystem eingesetzt wird, bin aber noch nicht an dem Punkt angekommen, an dem ich mich damit auseinandersetzen müsste.

[DNKpp]

stimmt, wäre ja die tilegröße der alten maker.

und sehe grade ich habe da einen kleinen denkfehler drin, werd ich mir heute abend dann nochmal anschauen, und berichtigen, aber mit der steigung an sich müsstest du das genauste ergebnis hinbekommen, nur eben noch an die gegebenheiten des makers anpassen.

[Kelven]

@Grandy
Ja, ich hab mich auch schon gefragt, ob es überhaupt nötig ist ganz exakt zu sein. Vielleicht reicht es auch, wenn man gar nicht mit Pixeln, sondern nur mit den Tiles rechnet. Und zwar so:

- man startet entweder mit dem Tile des Spielers oder des Zieles
- dann addiert man die x- und y-Steigung in Tiles, aber nicht auf einen Schlag, sondern man legt quasi eine Bewegungsliste an. Eine Steigung von 3/1 wird z. B. zu [x+1, x+1, x+1, y+1]. Nach jedem Schritt testet man, ob dort ein Hindernis ist oder das Ziel erreicht wurde. Ich hab hier jetzt immer nur +1 geschrieben, aber je nach Lage müsste man natürlich gegebenenfalls subtrahieren.

Keine Ahnung, ob das wirklich funktioniert und wie genau das ist, aber so müsste es sich relativ leicht umsetzen lassen.

[DNKpp]

also aus meiner erfahrung kann ich sagen, das es wesentlich mehr sinn macht, genau zu berechnen, und ne ungenauigkeit per parameter angeben zu lassen, wie schon ungenau zu programmieren. eine kugel fliegt nicht um ecken, und das sollte sie auch nicht in einem game (meine meinung zumindest), deswegen sollte die gerade schon recht exakt berechnet werden, wie weit man dann aber in der berechnung vom eigentlichen zielpunkt abweicht, ist dann eine andere sache.

[Todu]

Kelven: Ich hab mir zwar noch nicht die Zeit genommen, mir das genauer anzuschauen, aber in der Theorie überspringst du praktisch Tiles, die dein Projektil aber passiert. Bei einer Steigung von 3 würde ausgehend vom Mittelpunkt bei Start/Zeil deine Gerade folgende Tiles treffen auf ihrer Flugbahn

Code:

* Start, wird geschnitten
+ Ziel, wird geschnitten
O wird geschnitten
X wird nicht geschnitten

  0 1 2 3 
0 * O X X
1 X X O +

Die Gerade würde genau zwischen 0/1 und 1/2 auf der Ecke in die zweite Zeile rutschen. Bei deiner Überprüfung wie du sie anwenden würdest würdest du prüfen:

Code:

  0 1 2 3 
0 * O O O
1 X X X +

In dem Fall fliegt deine Kugel wie anti-freak schrieb, um Ecken.

Du müsstest tatsächlich irgendwie versuchen eine gerade Linie zu berechnen - auf welche Methode auch immer, ob per Skript oder Events (ich persönlich würd da zu ner Skriptlösung tendieren, aber das liegt daran dass ich damit besser arbeiten kann als mit Events) - und zu testen, welche Tiles die schneidet. (auch wenn ich grad Befürchte, dass dieser Absatz nicht mehr ist , als schon gesagt wurde bisher ~.~, sorry!)