spieleprogrammierer.de - Forum und Wiki zur Spieleprogrammierung und Spieleentwicklung

Guten Tag

Ich lerne nun seit 1-2 Monaten C++ und arbeite mich gerade in die SFML ein (Version 2.0 RC).

Zurzeit versuche ich eine kleine Engine zu "bauen", angefangen mit der Grafik. Im Endeffekt will ich ein Tilelevel mit verschiedenen Layern darstellen
(mein Ziel). Dazu habe ich mich schon ein wenig im Internet eingelesen und habe mir nun folgende Gedanken dazu gemacht:

cImageManager
- enthält eine verkettete Liste, in der die Images verwaltet werden
- Funktionen zum Laden von Images

cTile
- konvertiert ein Image in ein Spriteobjekt
- dieses Spriteobjekt kann wird dann letztendlich auch auf dem Bildschirm erscheinen und kann manipuliert werden (z.B. Position)

cMap
- kümmert sich darum, dass aus einer XML-Datei die Leveldateien ausgelesen werden und angezeigt werden (mit TileIDs, usw.)

cCamera
- eine Kamera (Vogelperspektive), mit der dann auch bspw. Scrolling verwirklicht werden wird


Hierbei geht es vorerst nur um die Grafik. Da ich mich vonvornherein um einen guten, effizienten Stil bemühen möchte, würde ich gerne eure
Meinung für diese Vorgehensweise hören.
Habe ich mir da zu umständliche Gedanken gemacht, geht es einfacher, etc. ?

Ihr sollt mir natürlich nicht sagen, wie man die einzelnen Klassen verwirklichen kann. Teilweise habe ich damit schon angefangen und ich denke
größtenteils kann ich das alleine schaffen. Mir geht es halt nur darum, dass sich das Ganze auch am Ende lohnt und ich dann nicht wieder alles
umwerfen muss, aus diesem Grund würde ich gerne eure Meinung hören.

Guten Abend

Zitat von »Schrompf«

Ich kenne mich mit SFML nicht so aus, aber es erscheint mir als Verschwendung, ein Sprite-Objekt für jede einzelne Grafik zu erstellen, die ich irgendwo auf dem Bildschirm zeichnen will. Gibt es nicht auch eine direktere Zeichenmethode? So nach dem Motto "Zeichne mir DIESE Grafik an DIESE Stelle".

Design-Vorschlag: Lass die Karte sich nicht selbst zeichnen, sondern beschränke ihre Funktion auf das Laden, evtl. Speichern und die Bereitstellung der Kartendaten. Erfinde stattdessen eine zusätzliche Klasse MapRenderer mit einer Funktion DrawMap( const cMap& map, const cCamera& camera), die das Zeichnen übernimmt.

Stil-Vorschlag: lass das "c" vor Klassennamen weg. Klassennamen und Typen schreibt man groß, Instanzen klein, fertig.

Performance-Vorschlag: speichere alle Tiles nicht in einer verketteten Liste, sondern in einem Array - std::vector ist Dein Freund. Der Vector bietet schenllen Zugriff auf beliebige Elemente im Container (zum Googlen: konstante Komplexität), während man bei einer Liste immer von vorn loszählen müsste, wenn man ein Element aus der Mitte haben will (Lineare Komplexität). Da eine TileMap nunmal auf Platte aus Indizes von Tiles besteht, kannst Du dann mit den Indizes direkt in das Tile-Array greifen.

Im Grunde genommen kann man es so machen, wie du gesagt hast. Aber in dem Fall ist es keine Verschwendung, denn man kann mit der SFML nur Texturen oder Bilder laden, aber wenn man bspw. ein Image anzeigen will, dauert dies länger und ist intensiver, als wenn man ein Sprite-Objekt nutzen würde, da es weniger Informationen enthält und sozusagen extra dafür gemacht wurde.
So gesehen lädt man bei Tilebased-Maps ja eigentlich hinterher sowieso keine einzelnen Tiles, sondern Tilesets und clippt die dann, soweit ich weiß.

Über deinen Design-Vorschlag habe ich mal nachgedacht und mir zusätzlich das hier zurate gezogen: http://www.sdltutorials.com/sdl-maps
Hier ist die Map komplett in einer Klasse zusammengefasst, zusätzlich gibt es noch die Klassen Area (Teilbereich der Map, der gerendert wird), Camera, Tile (repräsentiert ein Tile mit bestimmten Informationen wie z.B. begehbar oder nicht). Die Tiles werden so wie ich das sehen kann auch hier in einem Vektor behandelt, also so wie du es auch vorgeschlagen hast.
Dieser Aufbau ist ja eigentlich ähnlich, bloß dass man noch eine Klasse RenderMap entwerfen könnte und evtl. zusätzlich einen ImageManager (das Problem ist, wenn man ein Image in ein Sprite konvertiert, wird KEINE Kopie, wenn das Image gelöscht wird, wird das Sprite nichts mehr anzeigen).
Wie wäre diese Alternative zum Aufbau?

Zitat von »Jonathan_Klein«

Ohne die genauen Implementationsdetails zu kennen, ist es ein wenig schwer zu sagen, ob die Klassenaufteilung Sinn macht. Ansich sieht es aber ok aus.
Sich um einen guten Stil zu bemühen ist immer gut, allerdings braucht man da letztendlich sehr viel Erfahrung. Wenn du nach 10 Jahren programmieren feststellst, dass der Entwurf den du vor 2 Jahren gemacht hast Müll ist, ist das normal. Man lernt eben immer dazu.

Wegen verketteter Listen: Es ist halt immer die Frage, wie du es genau benutzen möchtest. Wenn du Beispielsweise eine bestimmte Datei öffnen willst, könnte auch eine std::map sinnvoll sein, da du dort schnell sehen kannst, ob du sie schon geladen hast. Mach dich am besten ein wenig vertraut damit, was es so für Container gibt und welche Vor- und Nachteile diese haben.

Alles klar. Ja das glaube ich dir. Erfahrung ist natürlich das A und O, aber man kann ja bestimmten Sachen von vornherein aus dem Weg gehen.
Stimmt Maps wären auch noch eine Alternative, danke für den Vorschlag. Da muss ich wohl nochmal drüber nachdenken, was das effizienteste ist.