spieleprogrammierer.de - Forum und Wiki zur Spieleprogrammierung und Spieleentwicklung

Zeiger, normale Klasseninstanzen oder eben Parameter.

MfG
Check

Naja globale Variablen zu verhindern ist eigentlich gar nicht so schwer. Die werden meistens ja nur aus Faulheit benutzt. Wenn man sein Konzept etwas mehr überarbeitet, dann kommt man schnell auf Ideen, seine Objekte an die Stellen weiter zu reichen, an denen sie gebraucht werden. Dann sagst du, dass Spiele sehr viel Wert auf OOP legen. Da kann ich nur bedingt zustimmen. Die Sache ist die, dass OOP sehr stark verbreitet ist. Es gibt aber genügend andere Ansätze, mit denen man Spiele entwickeln kann. Niemand schreibt mir vor ein Spiel OO zu programmieren. Ich möchte jetzt hier keine Diskussion zum dem Thema losbrechen. Nur darauf hinweisen, dass es auch andere Möglichkeiten gibt. Es spricht erstmal nichts dagegen ein Pong in Haskell zu schreiben oder? (außer einer völlig natürlichen und verständlichen Abneigung funktionaler Sprachen gegenüber ).

So und nun zum eigentlichen Thema Ich spiele immer sehr viel mit meinem Klassendesign herum. Bei dem einen Projekt lös ich noch alles auf die eine Weise und beim nächsten Projekt habe ich wieder andere Flausen im Kopf. Ich denke die wenigsten sind nach einem Projekt 100% mit ihrem Design zufrieden
Aber in etwa habe ich bei jedem Spiel eine Spielzustandsverwaltung in Form von GameStates. Diese implementieren das State-Pattern. Wenn es gewünscht ist, trenne ich die Darstellung auf dem Bildschirm manchmal von der Logik. So kann ich die aktuelle View austauschen, um zum Beispiel die Sicht eines anderen Spielers zu bekommen, oder etwas ganz anderes. Ein Pausescreen wäre dann zum Beispiel auch so eine View. Gleiches gilt zum Teil für die Steuerung/Eingabe. Diese ist teilweise mit in der View, teilweise aber auch in einer eigenständigen Klasse. Je nachdem ob ich die Steuerung unabhängig von der Sicht austauschen können möchte oder nicht. Das wird aber alles je nach Anforderung umgesetzt. Wenn ich keine austauschbare Sicht/Eingabe brauche, ist das alles überflüssig. Meine Welt wird normalerweise auch durch eine extra Klasse dargestellt. Normalerweise werden alle Spielobjekte hier gehalten. Die Welt dient mir quasi wie eine Art Container der Models mit zusätzlichen Funktionen. Spielobjekte werden meistens zusammengefasst. Meistens habe ich eine Parentklasse für alle Renderbaren Objekte und kann diese dann hinterher so zusammenfassen. Das kommt dann aber auch immer stark auf das Projekt an.
Naja so zieht sich das jetzt alles weiter. Ich glaube aber fast dass du darauf nicht hinaus wolltest. Gibt es bestimmte Punkte die dich interessieren?



edit:
Habe noch mal gecheckt. Dir ging es in dem anderen Beitrag ja zum Beispiel um die Getter.
Du solltest normalerweise deine Klasse so aufbauen, dass nichts nach außen geht, was keinen Sinn macht. Vor allem Implementierungsdetails sollten am besten gekapselt werden. Dass heisst, dass der Benutzer nicht sieht was intern abläuft und die Klasse einfach nur benutzen muss. Dadurch schiebst du das Problem auf eine neue Ebene. Die Klasse soll dir ja helfen dass Problem zu lösen. Dann sollte der Benutzer nicht über die gleichen Dinge nachdenken müssen, als wenn er ohne die Klasse arbeiten würde. Wenn du zum Beispiel einen EnemyManager implementiert. Dann sollte den Benutzer nicht interessieren ob dieser intern nun eine Liste, ein Array oder ein Dictionary für die einzelnen Instanzen hält. Der Manager ist ja dafür da, diese Logik zu kapseln und auf ein neues Niveau zu bringen. Deswegen wird dein Manager vermutlich auch keine Methode GetEnemyList() oä bereitstellen. Wenn dein Player jetzt deinen EnemyManager kennen muss, ist das ja erst mal kein Problem. Es spricht ja nichts dagegen. Jetzt müsste man das natürlich etwas genauer betrachten und vielleicht auch Code sehen um zu entscheiden wie sehr dass nun OOP-Richtlinien entspricht. Aber wenn du gut damit fährst, dann behalte es vielleicht erst mal so bei.

Des weiteren evtl. durch Deklaration von friend classen und oder singleton-Klassen, durch letzteres kann man indirekt eine globale Variable definieren und durch Kombination von beiden kann man den zugriff Steuern. (C++)

Mfg Rushh0ur

Singleton ist nicht als Ersatz für globals gedacht Deswegen haben Singletons auch so einen schlechten Ruf.

Das einzige was Singleton und globale Variablen gemeinsam gemeinsam haben ist, dass beide in einem guten Design pratkisch nie vorkommen

Naja es gibt seien Daseinsberechtigung aber das wurde ja hier im Forum schon oft genug diskutiert

Jedem seines, solange man eben klarkommt.

MfG
Check

Ich würde mir mal überlegen, wofür ich diese ganzen Manager brauche. Wenn ich Kollisionen zwischen all diesen Objekten testen will, dann muss ich sie dazu erstmal überhaupt alle kennen. Wirf vielleicht auch einen Blick auf den Double Dispatch Pattern.