spieleprogrammierer.de - Forum und Wiki zur Spieleprogrammierung und Spieleentwicklung

UML nutzt man eher zur Dokumentation. Für Planung meist nur sehr grob um Komponenten zu identifizieren und grobe Kommunikation zu planen. Details wie Klassen und Methoden nutzt man in der Praxis nicht. Zumindest nicht bei uns. Detailplanung nennt sich Wasserfall-Modell und funktioniert nicht.

GameMode klingt für mich ehrlich gesagt nach einem Enum. Dass alle Deine Objekte darauf zugreifen, klingt für mich schon mal sehr falsch. Das hast Du ja bereits selbst erkannt.

Zitat von »birdfreeyahoo«

GameMode ist ein actor und mein gamemode ist ein gamemode. Er sitzt auf dem server und kontrolliert das spiel. Ich kann einen pointer eig von überall abrufen und über ihn weitere pointer holen oder so. Das geht immer.
Jedoch caste ich den pointer immer in meinen gamemode ( er ist polymorph). In der annahme es isr immer diese unterklasse funktionieren die objekte und obwohl das so ist ist es irgendwie schmutzig.

Was hindert dich denn daran die Abhängigkeiten (Pointer) bei der Erzeugung eines Gameobjekts direkt im Konstruktor mitzugeben und dann den Gamemode als fixe Abhängigkeit rauszulassen? Damit wären die Objekte nicht nur von deinem speziellen Gamemode unabhängig sondern von jeglicher Art Gamemode.

Um Gottklassen zu vermeiden, würde ich vielleicht andere Programmierkonzepte verwenden.
Sehr beliebt, übersichtlich und oft verwendet: Component + Entity. Oder Entity System.
Wird auch von Unity, Waveengine und vielen weiteren verwendet.

UML wird in unserem Unternehmen meist direkt aus dem Code generiert. (Für Besprechungen, Dokumentationen oder rein zur Übersichtlichkeit)
Sich jedoch vor dem Programmieren ein Konzept zurecht zu legen, kann sicherlich nicht schaden.

Was ist eine Entity mit sehr vielen Komponenten, wenn nicht eine Gott-Klasse? Nur weil ich sie über ein gemeinsames Interface zusammengefasst in einen Array/Liste werfe statt sie einzeln fest in der Klasse zu deklarieren, ändert sich eigentlich gar nichts. Das ist eine scheinbare Verbesserung, die aber eigentlich nicht wirklich eine ist. Ähnlich dem "Ich verwende keine globalen Objekte, ich verwende Singletons"-Trugschluss.

Zitat von »BlueCobold«

Was ist eine Entity mit sehr vielen Komponenten, wenn nicht eine Gott-Klasse? Nur weil ich sie über ein gemeinsames Interface zusammengefasst in einen Array/Liste werfe statt sie einzeln fest in der Klasse zu deklarieren, ändert sich eigentlich gar nichts. Das ist eine scheinbare Verbesserung, die aber eigentlich nicht wirklich eine ist. Ähnlich dem "Ich verwende keine globalen Objekte, ich verwende Singletons"-Trugschluss.

So kann man das auch sehen. Nur sind die Komponenten unabhängig, eigenständig und benötigen keine "Gottklasse" für Datenmanipulation. (Bzw. gibt es nicht nur eine Gottklasse, sondern eben Count(Entity) viele) Auch können die Komponenten klar abstrahiert und wiederverwendet werden. Gottklasse vs Entity verliert bereits bei der Übersichtlichkeit. Auch wenn es sich um eine scheinbare Verbesserung handelt, habe ich das Gefühl von CleanCode und weniger Angst vor Antipattern.

Zitat von »birdfreeyahoo«

Das ist component-basiert jedoch hat GameMode als abstrakter Actor keine. Ich habe genauer darüber nachgedacht und herausgefunden dass ich alles unabhängig lösen kann. Es gibt diverse Sachen die einen anderen Platz haben sollten.
Da hab ich wohl GameMode als Gottklasse missbraucht was im Singleplayer durchaus funktioniert.

Wenn ihr das nicht plant, wie macht ihr das dann? Einfach drauflosprogrammieren d.h. system und details kurz vor der implementierung überlegen?

Überlegen was ich erreichen will. Realisierungsmöglichkeiten gedanklich auflisten. (API's, Frameworks)
Gedanklich bereits grobe Klassen zusammenstellen, ihre Aggregate und Schnittstellen ermitteln.
Dann programmieren. Während dem Programmieren versuche ich bereits zu optimieren. Google, nimm Bücher zur Hand etc.
Nach ein paar Tagen/Wochen/Monaten (regelmäßig) überfliegen und refactorn. (Man lernt schließlich nie aus)

Zitat von »Toemsel«

Bzw. gibt es nicht nur eine Gottklasse, sondern eben Count(Entity) viele

Wo siehst Du da jetzt einen Unterschied? Ob ich nun Ball, Spieler, Monster als einzelne Klassen habe und jedes davon hat mehrere Animationen, mehrere Sounds, mehrere KIs/Controller, mehrere Physik-Bodies oder alle haben nur eine unbestimmte Menge von Komponenten, die im Detail auch wieder Animation, Sound, KI/Controller und Physik-Body heißen, macht doch null Unterschied. Das Einzige, wofür so ein Komponenten-System wirklich gut ist, ist Scripting. Wenn jemand von außen beliebig viele Komponenten an irgendein "Ding" anfügen kann um damit zu machen, was er will, ohne dass es dafür eine neue Klasse bräuchte. Den Vorteil kannst Du im Normalfall aber gar nicht ausreizen.

Zitat von »Toemsel«

Auch können die Komponenten klar abstrahiert und wiederverwendet werden.

Und wo genau ist da der Unterschied zum klassischen OOP-Ansatz Deiner Meinung nach? Auch dort können Komponenten wiederverwendet werden und sind klar abstrahiert.

Zitat von »Toemsel«

Gottklasse vs Entity verliert bereits bei der Übersichtlichkeit.

Eine Entity ist nebenbei bemerkt kein spezielles Wort für eine Klasse, die einen Komponenten-Ansatz verwendet. Ich behaupte eben, dass so eine Klasse mit Komponenten-Ansatz eine Gottklasse ist und zusätzlich sogar durch fehlende Kontrollierbarkeit ihrer eigenen Komponenten viel ihrer Zuständigkeit an andere Stellen nach *außen* abgibt, was abstrakt betrachtet eigentlich mal ein schlechter Ansatz ist, weil sie sich nicht mehr um ihre eigenen Daten kümmert, sondern jemand anders, was sie teilweise zu einem reinen Gott-Datenhalter degradiert, statt zu einer logisch in sich geschlossenen Klasse.

Wie ich schon sagte, ein Komponenten-Ansatz ist noch immer ein Haufen Komposition wie bei klassischer OOP-Entwicklung, die eine Gott-Klasse schön aussehen lässt, weil statt 20 einzelner Attribute in der Klasse eine Liste von Komponenten verwendet wird. Allerdings bringt dieses Vorgehen sehr viele Probleme mit sich wie etwa double-dispatch-Unmöglichkeiten, dynamische Typprüfungen zur Laufzeit, wilde typunsichere Casts, dynamische (langsame) Auflösung/Suche der richtigen Komponente aus der Liste, etc, etc. All diese Nachteile nimmt man in Kauf für einen einzigen großen Vorteil: Es kann nach der Kompilierung entschieden werden welche Komponenten ein Spiel-Objekt genau bekommt. Solange man diesen Vorteil nicht ausreizen kann, ist man meiner Meinung nach mit so einem System ordentlich in die Kacke getreten. In Unity wird sogar empfohlen sich viele der Komponenten nur einmal zurückgeben zu lassen und zu cachen. Das ist dann erst mal Unsinn. Klar ist das massiv schneller, genau deswegen soll man es ja machen, aber ich habe damit effektiv eine Gottklasse, die zu jeder ihrer Komponenten in der Component-List auch noch zusätzlich eine Property für das Caching der jeweiligen Komponente hat. Das tut doch weh, schon wenn man drüber nachdenkt.