ich komme persönlich aus der PHP Ecke und da gibt es ja das sehr bekannte MVC Pattern um Ausgabe und Logik zu trennen. Nun würde ich gerne zum Lernen ein kleines Spiel programmieren (nicht für andere, keinen WoW Killer etc, ich kenne das Gerede). Dafür setze ich denke ich mal auf Code::Blocks mit SMFL. Nun habe ich zwei kleine Fragen:

1. Macht es Sinn für 2D Ausgabe etc SMFL zu nutzen? (Die Empfehlung habe ich zwar hier im Forum gelesen, aber man weiß nie.) Reicht Code::Blocks als professionelle IDE oder muss ich mich später zwangsläufig mit Visual C++/Eclipse anfreunden?

2. Und wichtigstes, wie sollte ich das MVC Pattern in C++ umsetzen? Mir widerstrebt der Gedanke jedem renderbaren Objekt eine Render Methode zu geben und einen Sprite als Membervariable? Ich würde lieber einen "Rendermanager" schreiben, an dem sich renderbare Objekte registrieren. Der würde dann den Objekttyp rausfinden, nach einem Interface die Position erfragen und das Objekt rendern. Was denkt ihr ist sinnvoller? Ich würde ja den Manager bevorzugen, habe aber kurioserweise total oft diese Render Schleife gesehen und brauche da ein wenig Input.

Gruß

1. Macht es Sinn für 2D Ausgabe etc SMFL zu nutzen? (Die Empfehlung habe ich zwar hier im Forum gelesen, aber man weiß nie.) Reicht Code::Blocks als professionelle IDE oder muss ich mich später zwangsläufig mit Visual C++/Eclipse anfreunden?

Definitiv. SFML bietet sehr viel, was du für 2D-Grafik brauchst. Schwierig wirds höchstens, wenn du native GUIs nachbilden willst, da gibts geeignetere Frameworks. Auch Code::Blocks sollte eigentlich kein Problem sein, ich kenne die IDE allerdings nicht. Programmiere jedoch so, dass du keine Probleme bei einem möglichen Wechsel hättest (halte dich soweit möglich an den C++-Standard).

rhanarion schrieb:

2. Und wichtigstes, wie sollte ich das MVC Pattern in C++ umsetzen? Mir widerstrebt der Gedanke jedem renderbaren Objekt eine Render Methode zu geben und einen Sprite als Membervariable? Ich würde lieber einen "Rendermanager" schreiben, an dem sich renderbare Objekte registrieren. Der würde dann den Objekttyp rausfinden, nach einem Interface die Position erfragen und das Objekt rendern. Was denkt ihr ist sinnvoller? Ich würde ja den Manager bevorzugen, habe aber kurioserweise total oft diese Render Schleife gesehen und brauche da ein wenig Input.

Bei SFML handhaben es (leider) recht viele Leute so, dass Grafik und Logik nicht getrennt wird, wahrscheinlich auch weil es in den Tutorials so gezeigt wird und sich viele Spiele-/Grafikprogrammierer gar nie gross mit objektorientiertem Design und gewissen Teilen von C++ befassen. Teilweise ist es sogar so schlimm, dass zwar recht gute Spiele entstehen, aber grausamer Code mit undefiniertem Verhalten und sonstigen Frickeleien dahintersteckt (im Allgemeinen, nicht auf SFML bezogen).

Ich benutze auch SFML und habe mir die gleichen Fragen gestellt. Ich verwende allerdings nicht knallhart MVC, sondern so eine Art Zwischenlösung: Für Logikobjekte (bei mir sind das oft Elemente in Spielen, wie z.B. Gegner) habe ich autonome Klassen, die nichts von SFML wissen, sondern nur Logikdaten enthalten. Dann gibt es eine GraphicManager -Klasse, welche sozusagen die Schnittstelle zu SFML darstellt. Sie besitzt eine Draw() -Memberfunktion, welche für die einzelnen Logikobjekte überladen ist und diese selbstständig zeichnet.

Diese Klasse ist allerdings nur für Grafik zuständig. Für die Verwaltung der Logik habe ich eine separate Klasse, welche die einzelnen Logikobjekte in Containern besitzt. Deren Memberfunktion Output() ist für sämtliche Ausgaben zuständig, unter anderem werden die einzelnen Objekte an den GraphicManager zum Zeichnen übergeben.

Das ist mein momentaner Ansatz, du kannst aber auch etwas stärker mit MVC arbeiten. Ich bin mit gewissen Teilen auch noch nicht ganz glücklich, z.B. Event-Handling mache ich immer noch mehr oder weniger in einer switch -Abfrage (d.h. Stati werden dann gesetzt, die später für bestimmte Aktionen gelesen werden; es ist schon nicht so, dass ich einen gigantischen switch -Block habe). Aber Logik und Grafik sind meines Erachtens recht gut getrennt, ich kann auch ohne viel Aufwand einzelne Teile verändern.

Ich hoffe, ich konnte dir ein paar Ideen geben.

Ich denke ich werde es erstmal so lösen, dass jedes Objekt was "gezeichnet werden möchte" sich an einer Managerklasse registriert und diese Managerklasse dann bei jedem Render-Durchlauf durch eine Liste der registrierten Objekte iteriert, eine überladene Draw Methode mit einer Referenz auf das zu zeichnende Objekt aufruft und dann je nach Objekttyp sich Positione etc holt damit es das Objekt rendern kann.

Das klingt relativ flexibel (Ausgabedetails je Objekt in einer Methode zusammengefasst, mit einem "drawable" Interface oder so sicher noch weiter zu abstrahieren) und einfach zu implementieren :).

Trotzdem wird aber an der Update-Schleife meist festgehalten, oder? Ich frage nur weil ich die Render-Schleife ja grade wegabstrahiere und nur noch durch einen Methodenaufruf der Managerklasse ersetzen will.

Ich denke ich werde es erstmal so lösen, dass jedes Objekt was "gezeichnet werden möchte" sich an einer Managerklasse registriert und diese Managerklasse dann bei jedem Render-Durchlauf durch eine Liste der registrierten Objekte iteriert, eine überladene Draw Methode mit einer Referenz auf das zu zeichnende Objekt aufruft und dann je nach Objekttyp sich Positione etc holt damit es das Objekt rendern kann.

Das ist auch eine Möglichkeit, allerdings bringt sie das Problem des Konsistenz-Haltens mit sich. Die Zeiger müssen ständig gültig sein; wenn ein Objekt zerstört wird, muss es abgemeldet werden. Das wäre ja noch kein grosses Problem, jedoch können STL-Container (welche die Logikelemente verwalten) intern Reallokationen durchführen, was sämtliche Zeiger in der GraphicManager -Klasse ungültig macht. Da musst du ständig aufpassen, es kann auch zu sehr hässlichen Fehlern kommen. Ich finde ausserdem, es verletzt die Trennung von Grafik und Logik nicht, einzelne Objekte zum Zeichnen zu übergeben. Die übergebende Logikklasse muss schliesslich so oder so nichts über Grafikdetails wissen.

rhanarion schrieb:

Trotzdem wird aber an der Update-Schleife meist festgehalten, oder? Ich frage nur weil ich die Render-Schleife ja grade wegabstrahiere und nur noch durch einen Methodenaufruf der Managerklasse ersetzen will.

Ja, ich habe eine Updateschleife. Du kannst natürlich auch das in eine separate Logikklasse auslagern, die Frage ist lediglich, ob es dir einen wirklichen Vorteil verschafft.

Das ist auch der Grund, wieso ich nicht voreilig aufteile. Ich bin nicht einer, für den das Vorhandensein von mehr Klassen automatisch ein besseres Design impliziert. Ich überlege mir, ob ich tatsächlich etwas gewinne (und nicht nur theoretische Abstraktion, ohne die Wartung genauso gut oder sogar besser möglich ist).