Einige Fragen zu Jump'n Run und Collision Detection sowie Tileengines
-
Ok Parallax Scrolling wird auch noch verwendet stimmt! Danke
-
Ich bin mir noch ein wenig unsicher, was die Kollisionserkennung mit der Welt angeht, allerdings denke ich, dass es das beste sein wird, hierfür eine extra Tilemap mit sehr kleinen Tiles (vielleicht 8x8). Das Problem hierbei ist, dass ich auch Levelabschnitte habe, bei denen der Spieler schräg nach oben laufen kann, oder sogar in einer vertikalen Kurve. Dann würde der Spieler ja ständig 8px nach oben bzw. unten Springen. Was für andere Methode zur Kollisionserkennung in Jump'n Runs gibt es noch? Was verwendet bspw. Sonic the Hedhedog?
Lg Ishildur
-
Zur Grafikschnittstelle schickst du die Farbinformationen der Tiles und intern behältst du eine enstprechende Schwarz/Weiß-Tile. Schwarz ist dann nix und weiß, das ist was. (Also Bit gesetzt oder nicht.) Damit kannst du dann einfach deine pixelgenaue Kollisionserkennung bauen.
-
Hmmm, aber wie merke ich nun, ob ich die Figur im Falle einer erkannten Kollision nach oben, "auf das Terrain" oder zurück "vor das Terrain" bewegen muss? Dies hängt natürlich vom Grad der Steigung ab, aber eben, wie implementieren das die Profis?
-
Für Kollisionsabfragen auf quadratische Tiles und sogenannte Slopes (45°-Dreiecke) ist folgendes Tutorial relativ hilfreich (ich hab damit selber gute Erfahrungen gemacht): http://jnrdev.72dpiarmy.com/
Mit anderen Steigungen und pixelgenauen Abfragen kenne ich mich leider nicht so aus...
Edit: Ich hab selber auch mal ein Jump'n'Run programmiert. Das war noch mit SDL, und ich hatte auch eine Auflösung von 640*480 Pixeln. Die Tile-Grösse betrug bei mir 32 Pixel, das geht eigentlich gut. Wenn dir 32 Pixel nicht passen, würde ich allerdings eher zu kleineren Grössen raten, noch grösser schränkt meiner Ansicht nach das Spiel zu stark ein.
-
Wenn du fertige Algorithmen sehen möchtest, dann lade dir doch die Sourcen von Supertux oder so. Dafür ist Freie Software schließlich da.
-
Ich hab mal 'ne Engine angefangen für solche "ungeraden" Tiles, da habe ich es so gemacht, daß meine Tiles zwar quadratisch sind, aber es zusätzlich eine Art "Maske" gibt, die bestimmt, wo man tatsächlich langläuft.
D.h. meine Bitmap war z.B. aufgebaut:
#### #### #### #### ==== ==== ==== ====Der obere Bereich ist die rein optische Version des Tiles. Unten drunter ist dann nur ein reines S/W-Bild, bei dem die Farbe schwarz quasi all das bestimmt, was als "Hindernis" bzw. als Boden gilt, und alles weiße war dann eben "Luft". Nun habe ich beim Laden der Tiles einfach von allen 4 Seiten (okay ich hab es bisher nur von oben gemacht, aber wenn ich jetzt dran weiter machen würde, würd ich irgendwann alle 4 Seiten machen
) abgetastet, wie weit ich gehen kann bis ich auf einen schwarzen Pixel treffe. Diese Werte merke ich mir in einem Array, d.h. wenn mein Tile 64x64 Pixel hat, dann habe ich für jede Seite nochmal ein Array mit je 64 Werten. Diese bestimmen dann einfach wie gesagt den Abstand vom "quadratischen Rand" bis zum ersten schwarzen Pixel.Nun zeigst Du die Tiles ganz normal an, benutzt aber für Kollisionen bzw. fürs "Hängenbleiben" einer Figur die Daten aus den einzelnen Arrays.
Das ist ziemlich praktisch, da Du damit nicht einfach nur 45° Slopes machst, sondern Du kannst richtig kurvige Tiles machen.
-
Ach ja, das mit den Pflanzen, die im Vordergrund sind, wird einfach über Layer realisiert. Du könntest z.B. Deine Map einfach 2x speichern, einmal der hintere Layer (also mit allen Tiles), und einmal der vordere Layer, bei dem dann z.B. die Pflanzen oder sonstige Dinge drin sind. Beides können stinknormale Tilemaps sein.
Nun zeichnest Du einfach erst den hinteren Layer, dann die Figuren, und zum Schluß die Pflanzen, und schon hast Du das Ergebnis so wie Du es haben willst
-
gehen wir doch noch einmal ganz zurück, zum aller ersten Donkey kong, da verwenden die wahrscheinlich sowas wie Geraden, die Beschreiben, wo man laufen kann, und wo nicht. Die Kollisionserkennung ist auch recht rudimentär, Da man den Sprung sowiso nicht viel beeinflussen kann, weiß der Computer schon zum Zeit des Absprungs wo er landen wird (Schnittpunkt der Bewegungsbahn und so). Vieleicht schaust du dir sas spiel mal an, ich finde das ist so alt, da kann man noch die Technit erkennen, in der das Gemacht wurde, Aber ein tutorial hab ich jetzt nicht sorry. Übrigens ich würde nicht zu tiles tendieren, die zu klein sind, dann wird das mit der Kollisionsabfrage grauenhaft.
-
Man kann ja auch ohne weiters variable Tile-Grössen verwenden, und/oder komplett frei positionierte (und grosse) "Flecken". Ein Grid verwendet man dann bloss dazu damit man weiss was evtl. auf dem Schirm sein könnte, bzw. um Kandidaten für die Kollisionserkennung zu ermitteln (bzw. genauer: die Anzahl der Kandidaten die man prüfen muss klein zu halten).
Mehrere Ebenen sind - solange die Grafikkarte schnell genug ist, was heute kein Problem darstellen sollte - trivial, einfach mehrere Tile-Maps (oder andere Maps) übereinander legen - wurde ja schon erwähnt.
Was "schräge" Tiles etc. angeht wurden auch schon 2 gute Techniken erwähnt, also entweder eine "Maske" für die Tiles mit abspeichern, oder für bestimmte Tile-Typen extra Code schreiben (45°, 30°, ...).
Am Besten aber einfach mal anfangen und ausprobieren.
-
da man sowas eh nicht hardcoden wuerde, muss man sich garnicht auf eine tilegroesse festlegen, das kann man je nach anforderung immer aendern.
