Blickrichtungen in Tile-Based Map

[Yoghurt]

Bei 2D ist das so eine Sachen. Da kann man den Blickwinkel bzw. die Perspektive nicht einfach ändern, weil alle Grafiken in einer bestimmten Perspektive erstellt werden müssen. Außerdem müsste man wahrscheinlich auch Sachen wie die Kollisionserkennung und generell die Spielphysik umschreiben.
Die Umstellung der Perspektive wäre also sehr viel Aufwand. Deshalb sollte man die (bei 2D zumindest) schon vorher festlegen.

[Glocke]

Bei 2D ist das so eine Sachen. Da kann man den Blickwinkel bzw. die Perspektive nicht einfach ändern, weil alle Grafiken in einer bestimmten Perspektive erstellt werden müssen. Außerdem müsste man wahrscheinlich auch Sachen wie die Kollisionserkennung und generell die Spielphysik umschreiben.
Die Umstellung der Perspektive wäre also sehr viel Aufwand. Deshalb sollte man die (bei 2D zumindest) schon vorher festlegen.

Also mit der schwenkbaren Kamera das würde sich auf 3D beziehen - damit werde ich unter Verwendung von 2D wahrscheinlich nicht glücklich

Gute 3D-Modelle zu erstellen ist halt viel aufwändiger als gute Sprites.
Und die Darstellung von 3D Grafik ist natürlich auch aufwändiger und komplexer wie bei 2D bzw. 2,5D.

Das ist so das Problem, was ich bei 3D hätte

Bei C&C Tiberiumkonflikt werden sicherlich massig Sprites verwendet. Aber wie organisiere ich die? Also wie gesagt: bisher habe ich die 8 Blickrichtungen verwendet. Wie Xin schon gesagt hat reichen die nicht aus, wenn ich z.B. auf ein Feld (was in x-Richtung 1 und in y-Richtung 2 Felder entfernt ist) schießen will. Bisher habe ich ein Frameset verwendet (8 Zeilen, jede für eine Richtung und dann spaltenweise die einzelnen Frames für die entsprechende Blickrichtung) und habe die einzelnen Frames mit Hilfe des int-Wertes der Blickrichtung (wie gesagt: die Blickrichtungen sind Zeilenweise im Frameset angeordnet) dann beim blitten erfasst. Nur fehlt mir der prinzipielle Ansatz, wie ich das nun mache.

Zusammenfassung:
Die Variante 3D mit OpenGL (unter Verwendung von SDL) wäre die optisch schönste Version. Meine Sprites werden mir von einem Kumpel gerendert (--> Blender). Prinzipiell wäre es ja kein Problem die Modelle zu exportieren und mit OpenGL zu rendern. Dazu stellt sich mir die Frage, der Geschwindigkeit. Ich entwickle das ganze auf einem Netbook - und dort soll es (auch) flüssig laufen.

Die Variante 2D mit reinem SDL wäre vom Aufwand her die schönste Version. Allerdings fehlt mir da der Ansatz bzgl. der richtigen Verwaltung der Blickrichtungen.

LG Glocke

[Xin]

Bei 2D ist das so eine Sachen. Da kann man den Blickwinkel bzw. die Perspektive nicht einfach ändern, weil alle Grafiken in einer bestimmten Perspektive erstellt werden müssen. Außerdem müsste man wahrscheinlich auch Sachen wie die Kollisionserkennung und generell die Spielphysik umschreiben.
Die Umstellung der Perspektive wäre also sehr viel Aufwand. Deshalb sollte man die (bei 2D zumindest) schon vorher festlegen.

Also mit der schwenkbaren Kamera das würde sich auf 3D beziehen - damit werde ich unter Verwendung von 2D wahrscheinlich nicht glücklich

Gute 3D-Modelle zu erstellen ist halt viel aufwändiger als gute Sprites.
Und die Darstellung von 3D Grafik ist natürlich auch aufwändiger und komplexer wie bei 2D bzw. 2,5D.

Das ist so das Problem, was ich bei 3D hätte

Du kannst mit OpenGL eine Draufsicht realisieren. Was Du als Sprite hast, ist einfach ein Viereck, dass Du auf auf die Karte legst. Bei orthogonaler Ansicht ist das quasi 2D. Dem Viereck gibst Du nun eine Textur mit, eben die Grafik, die das Sprite darstellen soll. Du kannst das Viereck über die Grafikkarte drehen und bewegen.

Möchtest Du später andere Perspektiven, musst Du das Viereck mit der Textur durch ein 3D-Model austauschen.

[Glocke]

Du kannst mit OpenGL eine Draufsicht realisieren. Was Du als Sprite hast, ist einfach ein Viereck, dass Du auf auf die Karte legst. Bei orthogonaler Ansicht ist das quasi 2D. Dem Viereck gibst Du nun eine Textur mit, eben die Grafik, die das Sprite darstellen soll. Du kannst das Viereck über die Grafikkarte drehen und bewegen.

Naja den Sprite möchte ich nicht im 2D-Sinne verwenden und als Textur draufzeichnen. Sonst habe ich das wieder das gleiche Problem wie bisher: dass ich für jeden Frame der Drehung des Geschützturms einen neuen Sprite brauche. Ich habe da eher an das 3D-Modell gedacht.
Die "Landschaft" (was bisher isometrisch gekachelt ist), würde ich aber dennoch mit Vierecken und "Tile-Textur" realisieren.

[Xin]

Naja den Sprite möchte ich nicht im 2D-Sinne verwenden und als Textur draufzeichnen.

Nimm den Panzer und den Geschützturm als zwei Vierecke. Unten drehst Du den Panzer passend, oben drüber drehst Du den Geschützturm nach belieben. Dann reicht eine (ausreichend aufgelöste) Textur, die passend drehst.

Die "Landschaft" (was bisher isometrisch gekachelt ist), würde ich aber dennoch mit Vierecken und "Tile-Textur" realisieren.

Hindert Dich ja auch keiner dran. Je Kachel ein Viereck.

[Yoghurt]

Bei C&C Tiberiumkonflikt werden sicherlich massig Sprites verwendet. Aber wie organisiere ich die? Also wie gesagt: bisher habe ich die 8 Blickrichtungen verwendet. Wie Xin schon gesagt hat reichen die nicht aus, wenn ich z.B. auf ein Feld (was in x-Richtung 1 und in y-Richtung 2 Felder entfernt ist) schießen will. Bisher habe ich ein Frameset verwendet (8 Zeilen, jede für eine Richtung und dann spaltenweise die einzelnen Frames für die entsprechende Blickrichtung) und habe die einzelnen Frames mit Hilfe des int-Wertes der Blickrichtung (wie gesagt: die Blickrichtungen sind Zeilenweise im Frameset angeordnet) dann beim blitten erfasst. Nur fehlt mir der prinzipielle Ansatz, wie ich das nun mache.

Wenn du sowas wie C&C Tiberiumkonflikt, realisieren möchtest kommst du meiner Meinung nach auch mit 2D ans Ziel.
Ein Geschützturm schaut von oben immer gleich aus egal wie du ihn drehst. Du musst ihn eben nur drehen. D. h. du hast nur ein Sprite, das du aber je nach Blickrichtung anders rotierst.
Tipp: In der Lib SDL_gfx gibts eine Funktion die "rotozoomSurface" oder so ähnlich heißt. Mit der kannst du sprites rotieren.

[Glocke]

Nimm den Panzer und den Geschützturm als zwei Vierecke. Unten drehst Du den Panzer passend, oben drüber drehst Du den Geschützturm nach belieben. Dann reicht eine (ausreichend aufgelöste) Textur, die passend drehst.

Mein Problem ist, dass - wenn ich einen vorgerenderten Sprite drehe - die räumliche Komponente dann kaputtgeht.

Als Beispiel habe ich mal den grünen Panzer von http://www.reinerstilesets.de/de/2d-gra ... -vehicles/ genommen:



Das Original ist vorgerendert mit "Blick" nach Unten (linker Teil). Das "Ziel" ist vorgerendet (3D Modell um 11,25° gedreht, rechter Teil). Drehe ich nun das Original um 11,25° erhalte ich das mittlere Bild. Wenn ich das auf den Panzer draufzeichne, ist der Turm schief

Btw 11,25° weil für den Panzer 32 verschiedene Richtungen vorgerendert sind und 360°32 = 11,25°.

Wenn du sowas wie C&C Tiberiumkonflikt, realisieren möchtest kommst du meiner Meinung nach auch mit 2D ans Ziel.

Btw war Tiberiumkonflikt nur ein Beispiel. Tiberian Sun ist für die Optik eher eine Messlatte für mich.

Ein Geschützturm schaut von oben immer gleich aus egal wie du ihn drehst. Du musst ihn eben nur drehen. D. h. du hast nur ein Sprite, das du aber je nach Blickrichtung anders rotierst.
Tipp: In der Lib SDL_gfx gibts eine Funktion die "rotozoomSurface" oder so ähnlich heißt. Mit der kannst du sprites rotieren.

Die einzige Lösung die mir einfällt (btw gerade aufm heimweg gekommen xD) wäre, für zig Blickrichtungen vorgerendert die Bilder zu laden. Im Endeffekt ist es auch so bei dem Panzer (siehe Link), wie ich eben festgestellt habe
Nehmen wir einmal ein ganz anderes Spielgenre: Rollenspiele. Auch da sind die Bewegungen mit 8 Blickrichtungen recht abrupt. Wenn ich dort 32 Blickrichtungen verwende und eine Bewegungsanimation 8 Frames lang ist, muss ich allein für die Bewegung dieser Figur 256 Frames erstellen. Lässt sich garantiert automatisieren, sicher kein großes Problem. Jetzt spinnen wir mal noch andere Dinge dazu wie "Stand"-Animation (quasi idle), bei der die Figur vllt. leicht wankt über 8 Frames - zusätzlich noch eine Angriffs-Animation und eine Sterben-Animation - und gehen wir mal jedesmal von 8 Frames aus. Dann sind das für eine Figur 1024 Einzelbilder.

Bin ich da nicht besser dran, wenn ich direkt 3D Modelle im Spiel rendern lasse? Btw wurde das bei "Pool of Radiance 2: Ruins of Myth Drannor" (da es wahrscheinlich kaum einer kennt: http://www.mobygames.com/images/shots/l ... t-this.jpg: 3D-Modelle die auf einen vorgerenderten Hintergrund gezeichnet werden.

LG Glocke

[darksider3]

Hä?
Du hast den Boden(Viereck eins). Dann hast du einen Grünen Panzer, dessen Boden du dem boden in deinem Spiel anpasst, wenn ich das jetzt richtig "rendere"

[Glocke]

Hä?
Du hast den Boden(Viereck eins). Dann hast du einen Grünen Panzer, dessen Boden du dem boden in deinem Spiel anpasst, wenn ich das jetzt richtig "rendere"

Ich versuche seit gestern Abend dein Post zu verstehen

Ja der Boden ist ein Viereck Den Boden des Panzers der Tile anpassen? Meinst du bzgl. Größe?

[Yoghurt]

Hä?
Du hast den Boden(Viereck eins). Dann hast du einen Grünen Panzer, dessen Boden du dem boden in deinem Spiel anpasst, wenn ich das jetzt richtig "rendere"

Ich versuche seit gestern Abend dein Post zu verstehen

Ja der Boden ist ein Viereck Den Boden des Panzers der Tile anpassen? Meinst du bzgl. Größe?

Ich vermute er meint damit, dass du den Hintergrund (Boden des Panzers ) der Panzer Grafik so wie die darunterliegende Grafik gestaltest (Boden in deinem Spiel). Das würde aber bedeuten, dass du für jeden Hintergrund die Panzer-Grafik ändern musst.
Am besten macht man das, indem man entweder Grafiken in einem Format mit Alpha-Kanal (Alpha-Blending) benutzt oder indem man einen Color-Key (Farbschlüssel) setzt. Setzt man den Color-Key zum Beispiel auf RGB: FF00FF dann werden Pixel mit genau dieser Farbe nicht angezeigt (sind also transparent).

Das hat allerdings nicht wirklich etwas mit deinem Problem in diesem Thread zu tun und ich vermute diese Techniken um eine Transparenz in den Grafiken zu erzeugen sind dir bereits geläufig.