Spielaufbau bzw. Codeaufbau
-
Namenloser324 schrieb:
Ok, danke und das hat sich bewährt? Bin mir bei sowas nach wie vor unsicher ob sich die objekte selber zeichnen sollten oder es eine renderklasse dafür herangezogen werden sollte
Hat sich bewährt. Du teilst ja die Zeichenfunktionen in allgemeine Zeichenfunktionen(SFMLDrawing) und Objektspezifische Funktionen auf.
Bei ein starren 3D-Objekt dürfte die Draw-Funktion vom ILevelItem nur eine Zeile enthalten:
draw->drawTriangleList(this->dreiecke); //Zeichne jedes Dreieck aus der Liste
Oder: draw->draw3DObjekt(this->_3DObjket); //Das _3DObjekt ist ein Oktree, wo die einzelnen Würfel weitere Unterwürfel oder Dreiecke enthalten
-
Sehr wichtig ist, dass du verschiedene Funktionalität getrennt hältst und möglichst kleine Abhängigkeiten dazwischen hast. Dadurch kannst du gut einzelne Teile ändern, ohne jedes Mal das ganze Projekt anzupassen. Beispiel: Grafik, Benutzereingabe und Spiellogik.
Mach so wenig wie möglich global und vermeide Singletons weitgehend. Am schlimmsten finde ich Manager-Klassen für alles mögliche, die als Singleton "ja objektorientiert" sind. Dadurch hast du in kurzer Zeit wahnsinnig viele Abhängigkeiten, was Wartung und Fehlerbehebung massiv erschwert. Zudem eröffnet sich eine ganze Reihe von weiteren Problemen im Bezug auf Reihenfolge globaler Initialisierung/Zerstörung und Multithreading.
Vererbung hat ebenfalls seine Schattenseiten, eine Alternative ist z.B. component-based design. Auch hier gilt: Schau, dass du die einzelnen Teile möglichst modular halten kannst.
