Javascript 2D Engine programmieren

[ActiviT]

Hallo Selfler!

Ich möchte versuchen in Javascript eine Spiele-Engine (natürlich in 2D) zu programmieren. Ich kenne mich mit Javascript relativ gut aus (ich hoffe, dass es für eine Engine reicht), weiß aber nicht genug, wie ich an das Problem herangehen soll.

Die Engine soll ein 2D Spiel darstellen können. Und zwar aus der Vogelperskeptive (senkrecht von oben) wie bei vielen alten Spielen. Leider habe ich nur wenige Vorstellungen, wie man eine Engine überhaupt angeht. Es werden Spielfiguren, Objekte und Gebäude ja aus Polygonen (meist Dreiecken) "gebaut". Das lässt sich in Javascript relativ leicht realisieren. Schwieriger wird es mit den Grafiken, die muss man irgendwie passend erstellen und darüberlegen. Effekte werden wohl auch schwer machbar sein, zumindest nicht performant.

Was mir aber noch mehr Kopfzerbrechen bereitet, ist die Kollisionsberechnung. Wie geht sowas? Ich habe mal gegoogelt, aber meist nur extrem komplizierte 3D Engines für Java oder C++ gefunden. Selbst Wikipedia gibt kaum Informationen her und hat nur eine große Liste von kostenlosen und kommerziellen Engines.

Ich kann mir eine Kollisions-Engine eigentlich nur so vorstellen, dass sie bei jeder Bewegung berechnet, ob ein Teil eines Objekts nach der Bewegung von der Position her mit dem Teil eines anderen Objekts übereinstimmt und diese Bewegung dann nur beschränkt zulassen. Das ist aber mit Sicherheit sehr sehr rechenaufwendig, weil ich bei _jeder_ Bewegung (also im Prinzip alle paar Millisekunden für dutzende Objekte) jede mögliche Kollision abfragen müsste. Ist soetwas mit Javascript überhaupt möglich?

Vielleicht kennt sich ja jemand damit aus und kann mir ein bisschen Lektüre empfehlen und mein Vorhaben in Bezug darauf, ob es überhaupt realisitisch ist, einschätzen.

Vielen Danke!

[Delfried]

Tag,
ich kenne mich zwar net aus, und bin mir auch net sicher wie du sowas realisieren willst, aber wegen dem Kollisionsproblem:
Wie wärs wenn du das ganze in Sektoren einteilst.
Und dann befindet sich jede Figur in einem Sektor...
Die Figur A befindet sich im Sektor Alpha. Und zwar auf Feld x: 3 y: 3.
Jetzt überprüfst du ob dieses Feld (3|3) ein Randfeld ist, indem Fall mal einfach keins. Nun musst du nur noch die Daten wohinschicken und es wird eifach mit allen anderen Charackteren überprüft. Ist es am Rand eines Sektors, z. Bsp. Feld (1|1) von Sektor Alpha, dann überprüfst du was anliegt, und lässt die umliegenden Felder des Sektors Beta (angenommen der heißt so) überprüfen.
So musst du nie alles überprüfen sondern schaust nur wer sich in der nähe im Sektor aufhält und falls es wer ist, dann ziehste daraus die Konsequenzen und baust eine Sperre oder so.
Aber i-wie kann ich mir net vorstellen wie man mit JS eine richtige Engine programmieren will, abgesehen davon das du was Serverseitiges bäruchtes, wenn ich das richtige verstehe.
Gruß, Delfried

[ActiviT]

Tag,
ich kenne mich zwar net aus, und bin mir auch net sicher wie du sowas realisieren willst, aber wegen dem Kollisionsproblem:
Wie wärs wenn du das ganze in Sektoren einteilst.
Und dann befindet sich jede Figur in einem Sektor...
Die Figur A befindet sich im Sektor Alpha. Und zwar auf Feld x: 3 y: 3.
Jetzt überprüfst du ob dieses Feld (3|3) ein Randfeld ist, indem Fall mal einfach keins. Nun musst du nur noch die Daten wohinschicken und es wird eifach mit allen anderen Charackteren überprüft. Ist es am Rand eines Sektors, z. Bsp. Feld (1|1) von Sektor Alpha, dann überprüfst du was anliegt, und lässt die umliegenden Felder des Sektors Beta (angenommen der heißt so) überprüfen.

Das wäre möglich. Das Problem ist aber, dass das ganze etwas... ähm... steinzeitlich ist. Soll heißen, dass man damit kein vernünftiges Spiel programmieren kann. Und die Objekte könnten sich nur alle X Pixel bewegen. Es sei denn, man sagt, dass ein Feld ein Pixel ist. Allerdings ist das dann mit Sicherheit zu Speicher- und CPU hungrig. Wie machen das denn andere Engines?

Aber i-wie kann ich mir net vorstellen wie man mit JS eine richtige Engine programmieren will, abgesehen davon das du was Serverseitiges bäruchtes, wenn ich das richtige verstehe.

Wieso etwas Serverseitiges?

[Mav]

Hallo

Es werden Spielfiguren, Objekte und Gebäude ja aus Polygonen (meist Dreiecken) "gebaut".

Ich würde sagen du denkst an dieser Stelle viel zu kompliziert: Wozu brauchst du denn hier bitte Dreiecke zum Erstellen deiner Spielfiguren? Hast du nie einen NES oder Atari oder sowas gehabt? Kann mich beim besten Willen nicht daran erinnern dort jemals einen Objekt gesehen zu haben, dass aus vielen kleinen Dreiecken bestand -> das kam erst mit der 3D Programmierung. Viele einzelne Grafiken sind in diesem Fall die Lösung.

Was mir aber noch mehr Kopfzerbrechen bereitet, ist die Kollisionsberechnung.

Kollisionsberechnung ist in 2D auch nicht besonders schwierig. Bei 3D Spielen werden typischerweise Quader oder Kugeln als Kolisionsbox verwendet. Bei 2D wären das somit dann Rechtecke oder Kreise. Die Formeln für die Berechnung lassen sich damit dann auch recht einfach selbst herleiten. Wenn dir Kreise und Rechtecke nicht reichen, kannst du das ganze natürlich auch auf belibige Polygone ausweiten; dadurch steigt aber natürlich auch der Aufwand für deine Formel.

Ich kann mir eine Kollisions-Engine eigentlich nur so vorstellen, dass sie bei jeder Bewegung berechnet, ob ein Teil eines Objekts nach der Bewegung von der Position her mit dem Teil eines anderen Objekts übereinstimmt und diese Bewegung dann nur beschränkt zulassen. Das ist aber mit Sicherheit sehr sehr rechenaufwendig, weil ich bei _jeder_ Bewegung (also im Prinzip alle paar Millisekunden für dutzende Objekte) jede mögliche Kollision abfragen müsste. Ist soetwas mit Javascript überhaupt möglich?

Du musst natürlich nur die Objekte überprüfen, die sich auch wirklich geändert haben in Ihrer Position.

Hoffe, dass ich dich damit ein wenig in die "richtige" Richtung gelenkt habe.

[ActiviT]

Hallo

Es werden Spielfiguren, Objekte und Gebäude ja aus Polygonen (meist Dreiecken) "gebaut".

Ich würde sagen du denkst an dieser Stelle viel zu kompliziert: Wozu brauchst du denn hier bitte Dreiecke zum Erstellen deiner Spielfiguren?

Wegen der Kollisionsengine. Ich muss ja eine Fläche haben, mit deren Hilfe ich Kollisionen abfragen kann. Die Grafiken sind davon natürlich mehr oder weniger unabhängig.

Hast du nie einen NES oder Atari oder sowas gehabt?

Doch klar, daher kommt überhaupt erst meine Motiviation. ;)

Kann mich beim besten Willen nicht daran erinnern dort jemals einen Objekt gesehen zu haben, dass aus vielen kleinen Dreiecken bestand -> das kam erst mit der 3D Programmierung. Viele einzelne Grafiken sind in diesem Fall die Lösung.

Nunja, beispielsweise Zelda A Link To The Past auf dem SNES. Dort spielt man eben Link (den Protagonist) und wenn man dicht an eine Wand läuft, ist ein Teil seiner Kleidung über der Wand. Das sieht auch realistisch aus. D.h. die Teile, aus denen er besteht (Kugeln, Polygone, whatever) sind kleiner als die Grafik.

Was mir aber noch mehr Kopfzerbrechen bereitet, ist die Kollisionsberechnung.

Kollisionsberechnung ist in 2D auch nicht besonders schwierig. Bei 3D Spielen werden typischerweise Quader oder Kugeln als Kolisionsbox verwendet. Bei 2D wären das somit dann Rechtecke oder Kreise. Die Formeln für die Berechnung lassen sich damit dann auch recht einfach selbst herleiten.

Gibt es dazu irgendwelche Links? Ich finde absolut nichts. Oder irgendwelche Lektüre in Papyrus-Form?
Ich vermute einfach mal, dass dabei Schnittmengen von Körpern berechnet werden und man auf das jeweilige Ergebnis reagieren müsste. Das könnte ich mir wahrscheinlich schon selber herleiten, aber ich habe angst, dass ich vieles kompliziert mache und ein eventuelles Spiel nachher nur noch auf einem Core2Duo mit XXX GHz spielbar ist.

Ich kann mir eine Kollisions-Engine eigentlich nur so vorstellen, dass sie bei jeder Bewegung berechnet, ob ein Teil eines Objekts nach der Bewegung von der Position her mit dem Teil eines anderen Objekts übereinstimmt und diese Bewegung dann nur beschränkt zulassen. Das ist aber mit Sicherheit sehr sehr rechenaufwendig, weil ich bei _jeder_ Bewegung (also im Prinzip alle paar Millisekunden für dutzende Objekte) jede mögliche Kollision abfragen müsste. Ist soetwas mit Javascript überhaupt möglich?

Du musst natürlich nur die Objekte überprüfen, die sich auch wirklich geändert haben in Ihrer Position.

Das mit der KI wird auch noch so eine Sache...

Hoffe, dass ich dich damit ein wenig in die "richtige" Richtung gelenkt habe.

Ja. Danke ;)

[peterS.]

gruss ActiviT,

Was mir aber noch mehr Kopfzerbrechen bereitet, ist die Kollisionsberechnung. Wie geht sowas?
Ich habe mal gegoogelt, ...

ich auch: »javascript 2D engine collision« ...

... aber meist nur extrem komplizierte 3D Engines für Java oder C++ gefunden.

... und bin mit dem ersten treffer auf »Javascript 2D Game Engine« gelandet, was fuer mich
nach kurzer lektuere hinsichtlich Deiner anforderungen sehr vielversprechend aussieht.

die physik-engine gibt es mittlerweile in einer canvas-faehigen variante.
ein aelteres beispiel *leided* natuerlich noch unter divitis.

da die beispiele nahelegen, dass grundlegende reale-welt-probleme, wie beschleunigung
und kollision zufriedenstellend geloest wurden, solltest Du dich als anregung durch den
quellcode der 2D-engines kaempfen.
vielleicht schreibst Du diesen dann ja um, denn sprachkonzeptionell sind die engines
alles andere als zufriedenstellend geloest.

viel spass - peterS. - [e-mail]

[ActiviT]

»» gruss ActiviT,

Hi

Was mir aber noch mehr Kopfzerbrechen bereitet, ist die Kollisionsberechnung. Wie geht sowas?
Ich habe mal gegoogelt, ...

ich auch: »javascript 2D engine collision« ...

Verflucht sei Google...

... und bin mit dem ersten treffer auf »Javascript 2D Game Engine« gelandet, was fuer mich
nach kurzer lektuere hinsichtlich Deiner anforderungen sehr vielversprechend aussieht.

Allerdings. Der Quelltext ist zwar etwas... naja... unübersichtlich ist untertrieben. Aber zumindest kann man ihm den Code für Kollisionen entnehmen.

die physik-engine gibt es mittlerweile in einer canvas-faehigen variante.

ein aelteres beispiel *leided* natuerlich noch unter divitis.

da die beispiele nahelegen, dass grundlegende reale-welt-probleme, wie beschleunigung
und kollision zufriedenstellend geloest wurden, solltest Du dich als anregung durch den
quellcode der 2D-engines kaempfen.
vielleicht schreibst Du diesen dann ja um, denn sprachkonzeptionell sind die engines
alles andere als zufriedenstellend geloest.

Das werde ich tun. Allerdings habe ich da doch noch eine Frage.
Bei Luke (dein Link) läuft die Engine so, dass alle X Sekunden ein "Durchlauf" geschieht. D.h. alle X Sekunden bewegen sich die Körper. Es kommt aber zu Probleme, wenn man die Framesrate herunterstellt (nur ein Durchlauf alle 2 Sekunden z.B.). Wenn man dann nämlich zwei Körper aufeinander zufliegen lässt (mit sehr hoher Geschwindigkeit), fliegen Sie durcheinander durch. Denn die Engine berechnet Kollisionen, indem sie berechnet, ob es nach einem Durchlauf Kollisionen gibt, was sie tut, indem sie guckt, ob zwei Körper sich überlagern. Aber man betrachte folgendes:

OOO                                         OOO
OOO ->                                   <- OOO
OOO                                         OOO

Das hier sind zwei Körper. Sie fliegen aufeinander zu...

OOO                               OOO
     OOO ->                         <- OOO
     OOO                               OOO

OOO                     OOO
          OOO ->               <- OOO
          OOO                     OOO

OOO           OOO
               OOO ->     <- OOO
               OOO           OOO

OOO OOO
                    OOO OOO
                    OOO OOO

OOO   OOO
                <- OOO   OOO ->
                   OOO   OOO

Weil jedes Objekt insgesamt 5 Einheiten zurücklegt, jedes Element aber nur 3 Einheiten breit ist, crashen sie gar nicht, weil sie sich zu keinem von der Engine erfassen Zeitpunkt überlappen. Wie kann man soetwas verhindern?

[Daniel Thoma]

Hallo ActiviT,

Weil jedes Objekt insgesamt 5 Einheiten zurücklegt, jedes Element aber nur 3 Einheiten breit ist, crashen sie gar nicht, weil sie sich zu keinem von der Engine erfassen Zeitpunkt überlappen. Wie kann man soetwas verhindern?

Ich weiß nicht, wie das tatsächlich gemacht wird. Aber ich würde versuchen, die nicht Zustände auf Kollisionen zu checken sondern Kollisionen voraus zu berechnen.
Sprich, du hast zusätzlich zur Positionsinformation noch Information darüber, in welche Richtung sich die Objekte bewegen für einen bestimmten Zeithorizont. Dann kannst Du durch Berechnen von Schnittpunkten bestimmen, wann das nächste Objekt kollidiert und den Verlauf der Simulation entsprechend anpassen.
Um zu simulieren, muss man meist diskretisieren, also unterschiedbare Zustände berechnen und nicht irgend etwas kontinuierliches. Wenn man das zu fein macht, wird man nicht mehr fertig, wenn man es zu grob macht, verpasst man eben Ereignisse. Die Idee ist nun, die Zustände einfach immer da hin zu packen, wo ein Ereignis passieren wird. Also musst Du eben berechnen, wann die Objekte kollidieren würden (bzw ein anderes Ereignis auftritt, dass die Bewegung der Objekte verändert). Dann berechnest Du genau diesen Zustand.
Das ist eine durchaus übliche Simmulationstechnik, ob auch Spieles so arbeiten, weiß ich allerdings nicht. Bei einer 2D-Welt und linearen Bewegungsabschnitten stelle ich mir das noch relativ einfach vor. In 3D und bei Bewegungen auf irgendwelchen Kurven ist die Schnittpunktberechnung schon recht aufwendig, vielleicht zu aufwendig um praktikabel zu sein.

Grüße

Daniel

[Daniel Thoma]

Noch eine Anmerkung: hast Du folgendes mal gelesen:
< http://en.wikipedia.org/wiki/Collision_detection>
Die deutsche Fassung ist wirklich nicht sehr umfangreich, aber da wird genau mein Ansatz beschrieben als alternative zu dem von Dir beschriebenen.
Der Ansatz, Kollisionen zu erkennen, hat eben gerade diesen Nachteil, dass man keine exakte Lösung findet, wenn man zu ungenau Rechnet evtl. sogar Kollisionen verpasst. Dafür ist er aber einfacher zu implementieren (im Allgemeinen).
In diesem einfachen Fall (2D) und Bewegungen auf linearen Bahnen ist die Kollisionsprognose vermutlich einfach genug machbar. Du musst nur die Bewegunsbahnen bzw deren Ränder schneiden und dann noch ausrechnen, ob die Objekte gleichzeit diesen Schnittbereich erreichen. Bei konstanten Geschwindigkeiten oder konstanten Beschleunigungen (was für solche Spiele sicher reichen sollte) kann man das auch noch alles geschlossen ausrechnen.
Das ist natürlich auch noch recht aufwendig umzusetzen, aber einfach ist das Problem eben nicht ;-)

[ActiviT]

Noch eine Anmerkung: hast Du folgendes mal gelesen:
http://en.wikipedia.org/wiki/Collision_detection

Jetzt schon. Danke!

Die deutsche Fassung ist wirklich nicht sehr umfangreich, aber da wird genau mein Ansatz beschrieben als alternative zu dem von Dir beschriebenen.
Der Ansatz, Kollisionen zu erkennen, hat eben gerade diesen Nachteil, dass man keine exakte Lösung findet, wenn man zu ungenau Rechnet evtl. sogar Kollisionen verpasst. Dafür ist er aber einfacher zu implementieren (im Allgemeinen).

Ja und anscheinend performanter. Zitat: "Almost all games use a posteriori collision detection, and collisions are often resolved using very simple rules".
Ich werde mich deshalb (und weil es für mich logischer erscheint) diese Technik verwenden.

Außerdem habe ich für alle (die das hier auch lesen) einen ganz guten Link gefunden: http://www.harveycartel.org/metanet/tutorials/tutorialA.html

[Daniel Thoma]

Hallo ActiviT,

Ja und anscheinend performanter. Zitat: "Almost all games use a posteriori collision detection, and collisions are often resolved using very simple rules".

Zu gut Deutsch: Die meisten pfuschen einfach rum ;-)
Aber gut, für Spiele wird das wohl taugen. Da steht aber in dem was Du verlinkt hast auch, dass die eben einfach vermeiden, dass sich Objekte zu schnell bewegen um die Kollision so zu erkennen, bzw wenn sie das tun, dann berechnet man für dieses Objekt extra mehr Zustände.
Ich bin nicht sicher, ob das für einfachen 2D-Kram wirklich einfacher zu implementieren ist. Aber funktionieren wird es sicher auch. Wird halt wahrscheinlich nicht auf eine saubere Lösung hinauslaufen, sondern darauf, dass man ne Menge regeln bastelt, mit denen das dann schon hinkommt.

Grüße

Daniel

[ActiviT]

Hallo ActiviT,

Weil jedes Objekt insgesamt 5 Einheiten zurücklegt, jedes Element aber nur 3 Einheiten breit ist, crashen sie gar nicht, weil sie sich zu keinem von der Engine erfassen Zeitpunkt überlappen. Wie kann man soetwas verhindern?

Ich weiß nicht, wie das tatsächlich gemacht wird. Aber ich würde versuchen, die nicht Zustände auf Kollisionen zu checken sondern Kollisionen voraus zu berechnen.
Sprich, du hast zusätzlich zur Positionsinformation noch Information darüber, in welche Richtung sich die Objekte bewegen für einen bestimmten Zeithorizont. Dann kannst Du durch Berechnen von Schnittpunkten bestimmen, wann das nächste Objekt kollidiert und den Verlauf der Simulation entsprechend anpassen.

Aber ich kann doch gar nicht wissen, wann eine Kollision stattfinden wird. Es kann doch passieren, dass eine Kugel A 10 Wegeinheiten zurückgelegt. Eigentlich würde Kugel A die Kugel B gar nicht treffen. Nun kommt aber Kugel C ins Spiel, die Kugel B in ihrer Richtung verändert. Innerhalb desselben Zeitabschnitts, kracht Kugel B also gegen Kugel A, obwohl es in einem Schleifendurchlauf vorher noch gar nicht so ausgesehen hat.

Um zu simulieren, muss man meist diskretisieren, also unterschiedbare Zustände berechnen und nicht irgend etwas kontinuierliches. Wenn man das zu fein macht, wird man nicht mehr fertig, wenn man es zu grob macht, verpasst man eben Ereignisse. Die Idee ist nun, die Zustände einfach immer da hin zu packen, wo ein Ereignis passieren wird. Also musst Du eben berechnen, wann die Objekte kollidieren würden (bzw ein anderes Ereignis auftritt, dass die Bewegung der Objekte verändert). Dann berechnest Du genau diesen Zustand.
Das ist eine durchaus übliche Simmulationstechnik, ob auch Spieles so arbeiten, weiß ich allerdings nicht. Bei einer 2D-Welt und linearen Bewegungsabschnitten stelle ich mir das noch relativ einfach vor.

Lineare Bewegungsabschnitte?

In 3D und bei Bewegungen auf irgendwelchen Kurven ist die Schnittpunktberechnung schon recht aufwendig, vielleicht zu aufwendig um praktikabel zu sein.

Elliptische Kurven kann es bei mir doch genauso geben. Da müsste ich ja alles vorberechnen.

[Daniel Thoma]

Hallo ActiviT,

Aber ich kann doch gar nicht wissen, wann eine Kollision stattfinden wird. Es kann doch passieren, dass eine Kugel A 10 Wegeinheiten zurückgelegt. Eigentlich würde Kugel A die Kugel B gar nicht treffen. Nun kommt aber Kugel C ins Spiel, die Kugel B in ihrer Richtung verändert.

Kugel C kommt ja nicht aus dem nichts, die hatte vorher schon eine Geschwindigkeit und eine Richtung. Du würdest also berechnen, dass das nächste Ereignis ist, dass Kugel C Kugel B trifft. Nun würdest Du diesen Zeitpunkt ausrechnen. Danach würdest Du feststellen, dass jetzt als nächstes Kugel B Kugel A trifft usw.
Du kannst nicht alle Kollisionen voraus berechnen, sondern nur die nächste, das reicht aber um zu wissen, dass Du keine Kollisionen "bersiehst".

Innerhalb desselben Zeitabschnitts, kracht Kugel B also gegen Kugel A, obwohl es in einem Schleifendurchlauf vorher noch gar nicht so ausgesehen hat.

Eben das ist der Punkt, es gibt keine fixen Zeitabschnitte in diesem Ansatz. Der Zeitabschnitt wird immer so gewählt, dass er gerade bis zur nächsten Kollision reicht.

Elliptische Kurven kann es bei mir doch genauso geben. Da müsste ich ja alles vorberechnen.

Nuja irgendwann brauchst Du dann natürlich Numerik, um die Schnittpunkte der Bahnen zu berechnen. Aber bist Du Dir sicher, dass Du so etwas brauchst. Willst Du irgendwie angedrehte Kugeln simulieren? ;-)
Aber auch für nahezu beliebige Kurven dürfte das machbar sein. Du musst eben die Bahnen der Kugeln berechnen können (so oder so), diese Bahnen schneiden (geht mit numerischen Verfahren problemlos, so hässlich werden die Kurven sowieso nicht sein) und dann berechnen, ob sich die Kugeln irgendwo zur gleichen Zeit auf dem Schnittbereich der Bahnen befinden (auch kein Problem). Um das zu machen brauchst Du aber wirklich erstmal ziemlich Grundlagen in Mathematik und Numerik.

Für Dein Spieleszenario brauchst Du das aber eigentlich alles nicht. Spielfiguren laufen ja eigentlich immer nur gerade aus (Ausnahme wohl Rennspiele). Das mag nicht so erscheinen, wenn man sehr oft die Richtung ändert, aber die Prognose funktioniert natürlich nur bis zu dieser Richtungsänderung. So bald eine KI oder ein Benutzer irgend welche Ereignisse auslöst (z.B. Richtungsänderung) musst Du natürlich den Systemzustand für dieses Ereignis berechnen.

Grüße

Daniel

[ActiviT]

Hallo ActiviT,

Aber ich kann doch gar nicht wissen, wann eine Kollision stattfinden wird. Es kann doch passieren, dass eine Kugel A 10 Wegeinheiten zurückgelegt. Eigentlich würde Kugel A die Kugel B gar nicht treffen. Nun kommt aber Kugel C ins Spiel, die Kugel B in ihrer Richtung verändert.
Kugel C kommt ja nicht aus dem nichts, die hatte vorher schon eine Geschwindigkeit und eine Richtung. Du würdest also berechnen, dass das nächste Ereignis ist, dass Kugel C Kugel B trifft. Nun würdest Du diesen Zeitpunkt ausrechnen. Danach würdest Du feststellen, dass jetzt als nächstes Kugel B Kugel A trifft usw.
Du kannst nicht alle Kollisionen voraus berechnen, sondern nur die nächste, das reicht aber um zu wissen, dass Du keine Kollisionen "bersiehst".

Innerhalb desselben Zeitabschnitts, kracht Kugel B also gegen Kugel A, obwohl es in einem Schleifendurchlauf vorher noch gar nicht so ausgesehen hat.
Eben das ist der Punkt, es gibt keine fixen Zeitabschnitte in diesem Ansatz. Der Zeitabschnitt wird immer so gewählt, dass er gerade bis zur nächsten Kollision reicht.

Aha, jetzt verstehe ich das. D.h. ich gucke, welche Kollision als nächstest stattfindet, berechne was passiert und lasse dann die Zeit bis zu diesem Zeitpunkt vergehen (also bis die Objekte sich treffen). Danach gucke ich wieder, welche Kollision als nächstes stattfindet usw. Ist das jetzt richtig oder immer noch nicht?

Elliptische Kurven kann es bei mir doch genauso geben. Da müsste ich ja alles vorberechnen.
Nuja irgendwann brauchst Du dann natürlich Numerik, um die Schnittpunkte der Bahnen zu berechnen. Aber bist Du Dir sicher, dass Du so etwas brauchst.

Naja, wenn ich Objekte habe, die andere anziehen (z.B. Planeten o.ä.), werde ich wohl nicht drumherum kommen. Reicht da der Mathe LK in der Oberstufe aus? :)

Für Dein Spieleszenario brauchst Du das aber eigentlich alles nicht. Spielfiguren laufen ja eigentlich immer nur gerade aus (Ausnahme wohl Rennspiele).

Aber was ist, wenn der böse Endgegner einen Magneten hat, um den Held in einen Lavasee zu ziehen? Das muss ich ja irgendwie berechnen! ;)

[Don P]

Hallo,

Weil jedes Objekt insgesamt 5 Einheiten zurücklegt, jedes Element aber nur 3 Einheiten breit ist, crashen sie gar nicht, weil sie sich zu keinem von der Engine erfassen Zeitpunkt überlappen. Wie kann man soetwas verhindern?

Nicht, dass ich mich besonders auskennen würde, aber ich würde es auch so anfangen, wie von Daniel beschrieben. Wenn ein Objekt sich pro Runde 5 Einheiten weiter bewegt, dann muss es, sofort nachdem es am Zug war – also schon *vor* seiner der nächsten Bewegung – die 5 nächsten Einheiten als besetzt markieren. Falls diese bereits als besetzt markiert sind (von einem anderen Objekt) kann es seine Bewegung eben nicht fortsetzen, denn es würde zur Kollision kommen.

Gruß, Don P

[Vinzenz Mai]

Hallo Don P,

Wenn ein Objekt sich pro Runde 5 Einheiten weiter bewegt, dann muss es, sofort nachdem es am Zug war – also schon *vor* seiner der nächsten Bewegung – die 5 nächsten Einheiten als besetzt markieren. Falls diese bereits als besetzt markiert sind (von einem anderen Objekt) kann es seine Bewegung eben nicht fortsetzen, denn es würde zur Kollision kommen.

das, denke ich, ist wieder zu grob gerechnet. Die beiden Objekte könnten immer noch aneinander vorbeikommen.

Beispiel:
Objekt 1 überquert Einheit A als erstes Feld seiner Bewegung in der Zeiteinheit, Objekt 2 erreicht dieses Feld als letztes Feld seiner Bewegung in der gleichen Zeiteinheit. Das könnte doch genügen, um aneinander vorbeizukommen, Dein Vorgehen würde jedoch eine Kollision ermitteln.

Freundliche Grüße

Vinzenz