logo 'RMGlow' by ryg :: rmarchiv.de is brought to you with love.
logo 'RMGlow' by ryg :: rmarchiv.de is brought to you with love.
In der Vergangenheit habe ich bereits zwei Arten von Schuss-KS entwickelt, die technisch unterschiedlich funktionieren. Ich würde gerne eine dritte perfektionierte Art entwickeln, die im Grunde auf der zweiten basiert, aber dabei dessen größte Schwäche ausmerzt, was zwar basierend auf der ersten Art vermutlich leichter zu bewerkstelligen wäre, diese aber wiederum ihre ganz eigenen Probleme mit sich bringt, weswegen ich die zweite Art überhaupt erst entwickelt habe. Aber erstmal zur Erklärung, was ich mit erster und zweiter Art meine.
Erste Art von Schuss-KS (klassisch): Diese kommt in Makerspielen am häufigsten zum Einsatz. Es wird die Position der Spielfigur ermittelt und bei Abgabe eines Schusses das Projektil-Event abhängig von der Blickrichtung +/- 1 X/Y Tile vor die Spielfigur plaziert und direkt danach der Blickrichtung der Spielfigur nach bewegt (abgefeuert). Wenn sich dabei die Projektil- und Gegnerkoordinaten überschneiden, ist das der Trigger für den gewünschten Effekt. (Schaden, Animation, etc)
Der Haken: Es kommt häufig vor, dass der Gegner, obwohl er augenscheinlich vom Projektil getroffen wurde, keinen Schaden erleidet. Ich kann mir das nur so erklären, dass ein Event beim Übertritt in ein anderes Tile sofort dessen Koordinaten annimmt, während die Grafik des Events noch so und so lange hinterhertrödelt; was dann so aussieht, als ob man durch den Gegner hindurch danneben geschossen hat und die Technik dahinter buggt. Ist dem so? Jedenfalls, um dieses Problem zu beseitigen, hatte ich eine neue Art von Schuss-KS entwickelt, das ohne Projektil-Events auskommt.
Zweite Art von Schuss-KS (ohne Projektil): Bei Abgabe eines Schusses entlang der X-Achse (links/rechts) wird ermittelt, ob Spielfigur und Gegner die gleiche Y-Koordinate teilen. Bei Abgabe eines Schusses entlang der Y-Achse (hoch/runter) wird ermittelt, ob Spielfigur und Gegner die gleiche X-Koordinate teilen. Das muss allerdings noch weiter spezifiziert werden, damit aus der Schuss-Gerade eine Schuss-Halbgerade wird; also nur den Bereich auf der Schuss-Achse in Blickrichtung der Spielfigur betrifft. Sonst würde man Gegner auch mit dem Rücken zugewandt abknallen können. Hierbei wird berechnet, ob die X respektive Y Koordinate der Spielfigur, welche nicht deckungsgleich mit der des Gegner ist, einen größeren oder kleineren Zahlenwert hat als jene Koordinate des Gegners. Teilen sich beispielsweise Spielfigur und Gegner die selbe Y-Koordinate, dann ist der X-Koordinatenwert des Gegners zwangsläufig entweder kleiner ODER größer als der der Spielfigur; kleiner wenn sich der Gegner relativ zur Spielfigur links auf der Map befindet und größer, wenn rechts. Wenn also der Fall auftritt, dass man nach links schießt und die Gegner X-Koordinate jedoch größer ist (Gegner befindet sich relativ zur Spielfigur rechts auf der Map), bedeutet das, man schießt in die entgegengesetzte Richtung und nicht zum Gegner gewandt. Ist die Blickrichtung allerdings nach rechts UND die X-Koordinate des Gegners ist größer als die der Spielfigur, dann befindet sich der Gegner in der Schusslinie, und erst dann wird der Effekt getriggert. Die Werte müssen natürlich für jede weitere Fallunterscheidung logisch zueinander abgeglichen werden mit dem Hintergrund, dass sich der Koordinaten Ursprung einer Map oben links befindet; also eine invertierte Y-Achse hat, verglichen mit normalen Graphen, die man so aus der Schule kennt, bei denen sich der Ursprung unten links befindet.
Der Vorteil: Gegner innerhalb der Schusslinie werden instant vom Schuss erfasst, ohne dass sich dabei ein sichtbares Projektil durch die Luft bewegt und ggf. nicht trifft. Dadurch wird der Darstellungsfehler aus der ersten Schuss-KS Art, welche auf Event-Projektile zurückgreift, negiert. Wenn man bedenkt, dass der Sichtbereich auf einer Map nicht viel größer sein dürfte als vielleicht 300m², übertragen auf eine entsprechende Realdarstellung und Projektile mit einer enormen Geschwindigkeit durch die Luft fliegen, sodass 15-20 Meter in nur wenigen Millisekunden zurückgelegt werden, was für das blanke Auge gar nicht sichtbar ist, erscheint mir das realistisch.
Der Haken: Hindernisse werden dabei nicht berücksichtigt und das ist die weiter oben angesprochene Schwäche der zweiten Schuss-KS Art. Mir ist nicht klar, wie man auf elegante Weise die zweite Schuss-KS Art modifizieren könnte, damit man nicht durch Hindernisse wie etwa Häuser, Autos o.Ä., welche sich zwischen Spielfigur und Gegner befinden, schießen kann. Dies aber zu bewerkstelligen wäre das angestrebte Ziel bzw. die dritte und perfektionierte Form eines Schuss-KS.
Eine erste, jedoch unpraktikable Lösungsidee: Die Außenränder jeglicher Hindernisse auf der Map werden mit Events abgedeckt. Danach fließt in die Schussrichtungsberechnung die Fallunterscheidung mit ein, ob der Koordinatenwert eines dieser Hindernismarkierungsevents irgendwo ZWISCHEN denen von Spielfigur und Gegner liegt. Das Problem: man müsste die abgleichenden Fallunterscheidungen für wirklich jedes einzelne Hindernisevent machen und davon würde es je nach Map enorm viele geben. Ich hege starke Zweifel, ob das überhaupt praktikabel ist und das die Performance mitmacht.
An die Technikfreaks: Wenn ihr anhand der Beschreibung das Funktionsprinzip des zweiten Schuss-KS verstanden habt, wie würdet ihr das Problem mit den Hindernissen in Angriff nehmen? Und zwar auf eine praktikable Art und Weise, auf die ich leider nicht von selbst komme.
Der Thread ist zwar schon zwei Jahre alt, aber bei der Aktivität heutiger Makercommunities ist eine Antwort in diesem Zeitraum ja noch relativ flott.
Eine wirklich elegante, vollautomatische Lösung gibt es meines Erachtens nicht. Du müsstest schon alle Felder überprüfen, die sich auf der Schusslinie zwischen Held und Gegner befinden. Dabei würde ich zwei Arten von Abfragen kombinieren: Terrain-IDs und Events.
Wenn du jedes Feld in Schusslinie überprüfst, kannst du erstmal die Terrain-ID abfragen. Wenn das Terrain ein Hindernis darstellt (z.B. eine Wand), wird der Schuss abgebrochen. Das funktioniert nur für Lower Tiles, weil man für Upper Tiles keine Terrains definieren kann. Deswegen muss noch eine weitere Abfrage dazu.
Bei Hindernissen, die im Upper Layer oder Event Layer liegen, wirst du um Events nicht herumkommen. Ich würde auf solchen Hindernissen ein Event platzieren, das auf der ersten Seite nichts weiter tut als den Switch "HINDERNIS" einzuschalten. Die erste Seite sollte nur über den "Call Event"-Befehl aufrufbar sein. Auf der zweiten Seite würde ich definieren, was von dem Event während des Spiels sichtbar sein soll, also die Grafik etc.
Wenn ein Feld beim Abfragen der Schusslinie nicht durch das Terrain als Hindernis identifiziert wurde, wird das auf dem Feld befindliche Event aufgerufen (erst "Get Event ID" mit den aktuellen Koordinaten, dann "Call Event" mit der Event ID und Page No. = 1). Ist der Switch "HINDERNIS" nach dem Aufruf aktiv, wird der Schuss abgebrochen.
Ist zwar sehr umständlich, aber so ist das beim Makern. Wenn wir nicht masochistisch veranlagt wären, hätten wir ja schon längst die Engine gewechselt.
Wow. Danke für die interessante Ausführung! Hätte nicht gedacht, dass da irgendwann mal noch jemand drauf eingeht. ^^
Wenn wir nicht masochistisch veranlagt wären, hätten wir ja schon längst die Engine gewechselt.
Das hat mMn nichts mit Masochismus zu tun. Viel eher ist es eine wesentlich größere Hürde sich bei der Spielentwicklung erst in eine neue Engine reinfuchsen zu müssen, ehe man mit dem Projekt auf einen grünen Zweig kommt, als dafür auf eine bereits vertraute zurückzugreifen, mit der man schneller Ergebnisse erzielt, auch wenn man dafür technische Abstriche in Kauf nehmen muss. Vor allem wenn sich die Motivation von Anfang an in Grenzen hält.
Der Thread ist zwar schon zwei Jahre alt, aber bei der Aktivität heutiger Makercommunities ist eine Antwort in diesem Zeitraum ja noch relativ flott.
Das macht überhaupt nichts. Ist ja nicht so, als hätten Threads ein Verfalldatum. Das schöne an Internetforen ist, dass die Themen dort im Gegensatz zu jenen in Messager Kanälen nicht so schnell in der Versenkung verschwinden und man jederzeit auf alles worauf man Lust hat eingehen kann, ohne dass sich individuelle Themen dabei in die Quere kommen. Ich stelle mir das wie eine 2-dimensionale Ebene vor, in welcher der 1-dimensionale Zeitstrang nicht unbedingt in einer geraden Linie verlaufen muss, sondern auch die Möglichkeit hat eine Kurve nach links oder rechts einzuschlagen, um sich so mit einem vergangenen Zeitpunkt in der bereits zurückgelegten Strecke zu überkreuzen.