Jump and Run - Umsetzung?

[Deadline]

Guten Abend liebe ZFX'ler!
In der letzten Zeit nehme ich mir C++ mal wieder vor und bin auch schon mit Heiko Kalista's Buch "C++ für Spieleprogrammierer" durch und habe alle Beispiele sowieso das Beispielspiel (nettes wort :P) mal nachprogrammiert und erweitert. Nachdem ich das allerdings getan habe, bin ich seit einiger Zeit am experimentieren, wie es mit den nächsten Spielen weiter gehen könnte. Und nach einigen kleinen Pong's etc) bin ich auf die Idee gekommen mal ein Jump and Run zu programmieren.
Dann habe ich mir einfach mal ein paar Dinge durch den Kopf gehen lassen wie man das "Problem" der Map lösen könnte:
a) Man erstellt ganz viele Rechtecke, die man als Boden auslegt und die anschließend auf Kollision mit dem Spieler prüft
b) Man hat eventuell ein Bild wo eine Kollisionslinie mit einer bestimmten Farbe eingezeichnet ist und diese Linie wird später im Spiel einfach mit "dem Boden" ersetzt
c) Man hat Einzelne Eckpunkte die miteinander verbunden werden und sozusagen demselben Prinzip einer Kollisionslinie oder eben "Boden" folgen wie b)
Wie die Umsetzung davon allerdings funktionieren könnte - davon habe ich absolut keine Ahnung :(

Abgesehen von diesem Problem bin ich noch nicht ganz dahinter gekommen wie es funktionieren wird den Bildschirm zu bewegen bzw. eine Art Kamera zu haben.
Selbstverständlich freue ich mich sehr über Buchlinks, allerdings helfen mir vielleicht Tutorial oder ähnliches mehr weiter, denn ich möchte mir vieles eben selbst erarbeiten um einfach mal ein bisschen ins Problemlösende Denken richtig einzusteigen ;)

Es tut mir Leid wenn das jetzt irgendwie nervig oder sonstiges ist, aber ich stehe hier im Moment nunmal auf dem Schlauch. :roll:
Danke im Voraus! :)

[pUnkOuter]

Die meisten Jump&Runs sind ja sowieso aus Tiles (Kacheln) zusammengesetzt, und da speicherst du neben der Grafik halt auch noch, ob es Luft, "feste Materie", Wasser, Lava oder was auch immer ist.

[TheBenji]

Grundlegend kannst du deine "Karte" in einem 2 Dimensionalen Array ablegen (oder so).
Da kommen dann Elemente rein, z.b. 1 für "Luft", 2 für "Blöcke", ...

Jetzt kannst du mit ner forschleife durch das array durch gehen und die entsprechenden Grafiken (Tiles) zeichnen.

Um jetzt zu scrollen fang die forschleife einfach mit einem höheren wert an durchzulaufen ;)

Bzgl. der kollision kannst du die spielerposition ja auch einfach mit dem array abgleichen um zu schauen ob das geht oder nicht^^

[sfxon]

Es gibt tausend Ansätze zum Erstellen von Jump'N'Runs. Das hängt dann letztendlich davon ab, was alles möglich sein soll und wie die Spielmechanik funktionieren wird..

Ich würde es folgendermaßen angehen.

1. Eine Spielwelt in Abschnitte (Boxen) aufteilen.
2. In den Abschnitten die Objekte anlegen.
->das wiederum auf mindestens 3 Ebenen: Hintergrund - Spielfläche - Vordergrund

Der Ansatz hat mehrere Vorteile.
-Die Kollisionserkennung muss nur auf Objekte getestet werden, welche sich in der aktuellen Box befinden.
(bzw. in 2 Boxen, bei Wechsel von einer zur nächsten..)
-Durch die Abgrenzung wird das Debuggen imho einfacher.
-Es müssen nur Dinge animiert und bewegt werden, welche sich in den angezeigten Boxen befinden.
-Man könnte das auf die Spitze treiben, und die Spielwelt immer dynamisch nachladen.. (und nicht mehr benötigte Teile aus dem Speicher freigeben..)

Was jetzt noch gar nicht erwähnt wurde, sind weitere Grundlagen wie:
-Physik-Engine (vereinfacht - aber immerhin möchte man ja springen - also -> Bewegungslehre)
-Kollisionserkennung (möglichst Pixelgenau - bspw. durch Schwarz/Weiß Kollisionsgrafiken)
-Blokadefreie Eingabe

[dowhilefor]

Ich sitze auch gerade an einem Jump'n Run allerdings mit einem sehr straffen Zeitplan. Deswegen habe ich mir gewisse Dinge einfach gemacht, bspw. benutze ich Box2d( bzw. Farseer da ich C# benutze ) für die Physik. Kann ich nur empfehlen, je nach dem was du wie machen möchtest kann es zwar einfacher sein sich die Physik die man braucht selber zu schreiben, wenns dagegen um Ergebnisse geht ist eine fertige Physik Engine nicht schlecht.

[Deadline]

Als erstes Mal: Danke für die ganzen Ideen und Hilfestellung!
Dann werde ich wohl mal das altbewährte "Weiterprobieren" betreiben =)

[Chromanoid]

Wenn du mal was Neues (im Sinne von neuer Programmiersprache/Plattform) ausprobieren willst, kannst du dir auch mal Flixel oder FlashPunk anschauen. Das sind zwei Flashengines für Oldschool 2D Spiele mit Augenmerk auf "platformer" und "jump'n runs". Bei Flixel wird für Kollisionserkennung ein Quadtree und Tilemaps benutzt. Überlappt der Spieler einen Tilemap-Abschnitt wird das entsprechende Tilemap-Objekt nach Kollisionsauflösung gefragt. Alle anderen Objekte besitzen i.d.R. eine rechteckige Bounding Box, die dann für die Kollisionserkennung direkt verwendet wird. Bei Box2D muss man glaube ich etwas basteln bis man ein Oldschool Jump'n Run Feeling hinbekommt. Physikengines sind ja nicht unbedingt auf sowas ausgelegt.

Falls dich der Flixel-Code interessiert:
Hier wird ein "overlap"-Test mit dem Quadtree und beliebigen Objektgruppen durchgeführt: https://github.com/AdamAtomic/flixel/bl ... xG.as#L944
Die collide-Funktion ruft die overlap-Funktion auf (mit einer Callback/Collision-Response-Funktion für Überlappungen, die die Objekte anhand der X und Y Achse separiert (sofern möglich)): https://github.com/AdamAtomic/flixel/bl ... xG.as#L973
Der Quadtree Code: https://github.com/AdamAtomic/flixel/bl ... uadTree.as
Die "Collision-Response" Funktion für das Separieren: https://github.com/AdamAtomic/flixel/bl ... ct.as#L955
Bei Kollisionen mit Tilemaps wird overlapsWithCallback von der Tilemap aufgerufen: https://github.com/AdamAtomic/flixel/bl ... ap.as#L898
Diese Funktion berechnet die möglichen Tiles, die mit dem Objekt kollidieren können (das ist ja bei Grids recht einfach) und führt bei Überlappung die übergebene Collision-Response-Funktion aus. Im Normalfall ist das die gleiche wie bei den normalen Objekten. Es wird einfach jew. ein temporäres "Tile-Objekt", welches für das überlappende Tile steht, erstellt/benutzt und damit dann die "separate"-Funktion bzw. übergebene Collision-Response-Funktion aufgerufen, als würde es sich um ein normales Objekt handeln.

Letzteren Kniff, überlappende Kacheln einer Tilemap nur temporär für Kollisionen als normales Objekt sozusagen als Platzhalter zu erstellen, finde ich recht elegant. Normalerweise sollte ein einziges temporäres Platzhalterobjekt ausreichen, welches dann für jede Kachelüberlappung angepasst und wiederverwendet wird.