Hey,
Also erstmal nen bisschen weiter ausgeholt damit ihr wisst worum es geht:
Ich arbeite im Moment an einem Roguelike, wobei ich ein ähnliches Spielsystem geplant habe wie DoomRL.
=> Rundenbasiert, Tile-Based und Action orientiert... hey vielleicht sogar Zombies
Mein Hauptproblem z.Z. stellt allerdings im Moment die Map auf der man spielt dar.
Auf Grund von zufallsgenerierten Levels (wie für Roguelikes üblich), bin ich darauf angewiesen meine Grafiken alle irgendwie dynamisch zu erzeugen und darzustellen, d.b. insbesondere ich hab keine Map oder Ähnliches in nem Room schon zur Programmierzeit zusammen gebaut, das geschieht alles zur Laufzeit, inkl. Auswahl der Sprites die dargestellt werden sollen abhängig von der Umgebung jedes einzelnen Tiles der Map.
Ich habe z.Z. 3 Arrays die das Level quasi "beinhalten".
A1. Ein Array welches die Levelstruktur (den Tiletype könnte man sagen) enthält und nur aus "#" und "." besteht. Wobei "#" blockierte Tiles und "." begehbare Tiles sind. Über dieses Array finden dann auch Kollisionschecks bzw. der A* Algorithmus statt.
A2. Ein Array welches eine Ziffer speichert die zusammen mit dem Tiletype (siehe A1) das darzustellenden Sprite angiebt
A3. Ein Array welches speichert welche Tiles schon besucht worden sind, welche noch nicht besucht woren sind und welche gerade von einem Objekt aus eingesehen werden können -> Stichwort Fog of War bzw. Field of Vision
A1,A2,A3 sind also quasi mehrere Layer eines Levels.
Wenn wir uns jetzt vorstellen ich würde eine Levelgröße von 100*100 Tiles (oder auch mehr) generieren, dass sind dann insgesamt 10000 Tiles, da ich auch deren Beziehungen zueinander betrachten muss sind das ganz am Anfang bei Generierung des Levels 10000 Tiles * ihre 8 Nachbarn = 80000 Arrayabfragen, allerdings nur einmalig am Anfang wenn das Level generiert wird. Ungeachtet der Abfragen für Integritätsprüfungen ob z.B. keine Räume in einander überlappen oder Monster mitten in einem Fluss spawnen.
Da ich jetzt natürlich nicht immer die komplette Map darstellen kann (also in jedem Step 10000 Arrayzellen iterieren müsste o.o), beschränke ich mich auf einen 21 * 21 Tiles großen Ausschnitt um den Player herum.
-----------
Mein Problem ist jetzt wie ich anfangen soll das konkret zu implementieren um von Anfang an die Performanz hoch zu halten.
Im Moment lese ich wie gesagt nur einen kleinen Teil des Maparrays (A1) aus (21 x 21 Tiles) und stelle die Grafik mit Sprites dar.
Dabei habe ich folgende 2 Ansätze prototypisch mal ausprobiert und keine Peformance-Probleme festgestellt.
Ansatz 1: Sprites mit verschiedenen Alphawerten zeichnen ->also 21 * 21 = 441 Sprites mit verschiedenen Alphawerten, funktioniert ohne Probleme.
Ansatz 2: Ebenfalls alle 441 Sprites darstellen allerdings normal ohne Alphawert und dann abhängig vom FOV-Array (A3) über die Sprites Rectangles mit ver. Alphawerten legen in der größe eines Tiles legen. Aufwand ist deutlich höher, FPS bleiben aber gleich.
Soweit so toll.
Aber... mein eigentliches Anliegen ist statt Sprites mit mehreren Subimages ein großes Tileset zu benutzen und einmal beim generieren des Levels die Tiles entsprechend von A2 zu setzen.
Bei einem 100*100 Tiles großen Level sind das allerdings dann auch 10000 Tiles die ich in den Raum setzen würde, zwar wie gesagt nur einmalig aber sie wären da und dass obwohl lediglich 441 davon immer zusehen wären d.h. ich hätte ne Overhead von 9559 dargestellten Tiles die allerdings keine Sau sehen kann
Zudem müsste ich dann immer noch wie in Ansatz 2 (dafür hab ich das ausprobiert), meinen Sichtradius mit halbtransparenten Rectangles regeln d.h. zusätzlich nochmal einen Darstellungsaufwand von 441 Rechtecken in unterschiedlicher Opacity.
So wers bis hier hin durchgehalten hat wird sicher gemerkt haben, dass ich noch keine Frage gestellt habe, gell?
Also was ich eigentlich wissen wollte ist:
Was haltet ihr davon? Realisierbar oder Blödsinn?
Hab ich das ganze völlig falsch angegangen?
Und vorallem, hat jemand Erfahrung mit sowas?
Gibts eventuell Techniken um sehr große Tilemaps möglichst effizient darzustellen ohne Zehntausende von Tiles rumliegen zu haben oder auf Sprites auszuweichen?
Eine Überlegung die mir gekommen ist. wozu ich auch gern ne Meinung und/oder Ratschläge hätte:
Was haltet ihr davon wenn ich die Tiles zwar ganz am Anfang bei der Generierung der Map erstelle, dann von der Zeichenfläche einen Snapshot als Background erzeugen und dann alle Tiles wieder lösche.
Macht ein ~ 1600 * 1600 Pixel großer Background Probleme?
Ich müsste dann immer noch, wie in Ansatz 2 beschrieben, meinen Fog of War mit halbtransparenten Rectangles zeichen, wobei ich aber denke dass 441 16*16 große Rechtecke verträglich sind oder?
Auf diese Weise habe ich a) keine Sprites mehr und kann b) ein Tileset verwenden. Fragwürdig ist halt nur der gigantische Background...
Sowas kann man sicher auch irgendwie mit Surfaces machen wobei ich da 0 Ahnung habe und mich damit auch noch nicht ausseinander gesetzt habe, Tipps?
Ok ich denk ich hab genug gesabbelt, vergebt mir meine Ausschweifungen
Wenigstens habt ihr so nen Eindruck davon bekommen mit was für nem Mindfsck ich meinen ersten freien Sommerferientag verbringe :]
Anbei noch ein Screenshot meines Prototypes mit der Implementierung von Ansatz 2, wobei die Tiles die ihr seht keine wirklichen Tiles sind sondern lediglich Sprites die ich zeichne:
Also erstmal nen bisschen weiter ausgeholt damit ihr wisst worum es geht:
Ich arbeite im Moment an einem Roguelike, wobei ich ein ähnliches Spielsystem geplant habe wie DoomRL.
=> Rundenbasiert, Tile-Based und Action orientiert... hey vielleicht sogar Zombies
Mein Hauptproblem z.Z. stellt allerdings im Moment die Map auf der man spielt dar.
Auf Grund von zufallsgenerierten Levels (wie für Roguelikes üblich), bin ich darauf angewiesen meine Grafiken alle irgendwie dynamisch zu erzeugen und darzustellen, d.b. insbesondere ich hab keine Map oder Ähnliches in nem Room schon zur Programmierzeit zusammen gebaut, das geschieht alles zur Laufzeit, inkl. Auswahl der Sprites die dargestellt werden sollen abhängig von der Umgebung jedes einzelnen Tiles der Map.
Ich habe z.Z. 3 Arrays die das Level quasi "beinhalten".
A1. Ein Array welches die Levelstruktur (den Tiletype könnte man sagen) enthält und nur aus "#" und "." besteht. Wobei "#" blockierte Tiles und "." begehbare Tiles sind. Über dieses Array finden dann auch Kollisionschecks bzw. der A* Algorithmus statt.
A2. Ein Array welches eine Ziffer speichert die zusammen mit dem Tiletype (siehe A1) das darzustellenden Sprite angiebt
A3. Ein Array welches speichert welche Tiles schon besucht worden sind, welche noch nicht besucht woren sind und welche gerade von einem Objekt aus eingesehen werden können -> Stichwort Fog of War bzw. Field of Vision
A1,A2,A3 sind also quasi mehrere Layer eines Levels.
Wenn wir uns jetzt vorstellen ich würde eine Levelgröße von 100*100 Tiles (oder auch mehr) generieren, dass sind dann insgesamt 10000 Tiles, da ich auch deren Beziehungen zueinander betrachten muss sind das ganz am Anfang bei Generierung des Levels 10000 Tiles * ihre 8 Nachbarn = 80000 Arrayabfragen, allerdings nur einmalig am Anfang wenn das Level generiert wird. Ungeachtet der Abfragen für Integritätsprüfungen ob z.B. keine Räume in einander überlappen oder Monster mitten in einem Fluss spawnen.
Da ich jetzt natürlich nicht immer die komplette Map darstellen kann (also in jedem Step 10000 Arrayzellen iterieren müsste o.o), beschränke ich mich auf einen 21 * 21 Tiles großen Ausschnitt um den Player herum.
-----------
Mein Problem ist jetzt wie ich anfangen soll das konkret zu implementieren um von Anfang an die Performanz hoch zu halten.
Im Moment lese ich wie gesagt nur einen kleinen Teil des Maparrays (A1) aus (21 x 21 Tiles) und stelle die Grafik mit Sprites dar.
Dabei habe ich folgende 2 Ansätze prototypisch mal ausprobiert und keine Peformance-Probleme festgestellt.
Ansatz 1: Sprites mit verschiedenen Alphawerten zeichnen ->also 21 * 21 = 441 Sprites mit verschiedenen Alphawerten, funktioniert ohne Probleme.
Ansatz 2: Ebenfalls alle 441 Sprites darstellen allerdings normal ohne Alphawert und dann abhängig vom FOV-Array (A3) über die Sprites Rectangles mit ver. Alphawerten legen in der größe eines Tiles legen. Aufwand ist deutlich höher, FPS bleiben aber gleich.
Soweit so toll.
Aber... mein eigentliches Anliegen ist statt Sprites mit mehreren Subimages ein großes Tileset zu benutzen und einmal beim generieren des Levels die Tiles entsprechend von A2 zu setzen.
Bei einem 100*100 Tiles großen Level sind das allerdings dann auch 10000 Tiles die ich in den Raum setzen würde, zwar wie gesagt nur einmalig aber sie wären da und dass obwohl lediglich 441 davon immer zusehen wären d.h. ich hätte ne Overhead von 9559 dargestellten Tiles die allerdings keine Sau sehen kann
Zudem müsste ich dann immer noch wie in Ansatz 2 (dafür hab ich das ausprobiert), meinen Sichtradius mit halbtransparenten Rectangles regeln d.h. zusätzlich nochmal einen Darstellungsaufwand von 441 Rechtecken in unterschiedlicher Opacity.
So wers bis hier hin durchgehalten hat wird sicher gemerkt haben, dass ich noch keine Frage gestellt habe, gell?
Also was ich eigentlich wissen wollte ist:
Was haltet ihr davon? Realisierbar oder Blödsinn?
Hab ich das ganze völlig falsch angegangen?
Und vorallem, hat jemand Erfahrung mit sowas?
Gibts eventuell Techniken um sehr große Tilemaps möglichst effizient darzustellen ohne Zehntausende von Tiles rumliegen zu haben oder auf Sprites auszuweichen?
Eine Überlegung die mir gekommen ist. wozu ich auch gern ne Meinung und/oder Ratschläge hätte:
Was haltet ihr davon wenn ich die Tiles zwar ganz am Anfang bei der Generierung der Map erstelle, dann von der Zeichenfläche einen Snapshot als Background erzeugen und dann alle Tiles wieder lösche.
Macht ein ~ 1600 * 1600 Pixel großer Background Probleme?
Ich müsste dann immer noch, wie in Ansatz 2 beschrieben, meinen Fog of War mit halbtransparenten Rectangles zeichen, wobei ich aber denke dass 441 16*16 große Rechtecke verträglich sind oder?
Auf diese Weise habe ich a) keine Sprites mehr und kann b) ein Tileset verwenden. Fragwürdig ist halt nur der gigantische Background...
Sowas kann man sicher auch irgendwie mit Surfaces machen wobei ich da 0 Ahnung habe und mich damit auch noch nicht ausseinander gesetzt habe, Tipps?
Ok ich denk ich hab genug gesabbelt, vergebt mir meine Ausschweifungen
Wenigstens habt ihr so nen Eindruck davon bekommen mit was für nem Mindfsck ich meinen ersten freien Sommerferientag verbringe :]
Anbei noch ein Screenshot meines Prototypes mit der Implementierung von Ansatz 2, wobei die Tiles die ihr seht keine wirklichen Tiles sind sondern lediglich Sprites die ich zeichne:
