spieleprogrammierer.de - Forum und Wiki zur Spieleprogrammierung und Spieleentwicklung

Ich habe dieses Problem sooft gehabt, dass ich zu folgender Architektur gegangen bin:

1) Ich habe eine Game-Klasse. Diese hat auch einen InputManager (wobei ich einfach ein Keyboard und Mouse-Objekt bereistelle), und auch den RessourcenManager.
2) Jedes Objekt erbt von GameObject und muss eine obligatorische Verbindung zum Game haben. Dadurch es auf den RessourcenManager oder InputObjekte zugreifen (Ressourcen laden, auf Eingaben reagieren, ...).

Zusätzlich habe ich das Problem, dass teilweise GameObjects von anderen benötigt werden. Ich habe den Weg eingeschlagen, Objekte im Game Global registrieren zu können:



andere GameObjekt-Instanzen können über eine Analoge GetGlobalObject()-Methode sich die Instanz holen.

Dadurch habe ich mittlerweile eine sehr robuste Architektur, die solche "ich brauche X" auf ein minimum begrenzen.

Hmm verstehe ehrlich gesagt nicht so ganz, wo genau das Problem liegt. Nehmen wir an, du klickst eine Einheit an. Du speicherst die Position und lässt den ObjectManager nach der Einheit suchen, die auf dieser Position (bzw. innerhalb eines gewissen Radius davon) sich befindet. Diese kannst du dann manipulieren.
Was ich persölnlich machen würde ist, selektierte Einheiten in einen eigenen Container zu setzen. Deine Anwendung findet diese dann schneller und du kannst auch mehrere Einheiten ganz einfach auswählen, indem du halt jede Einheit in diesen Container setzt. Dann könntest du z.B. folgendermaßen die auf verschiedene Mausklicks reagieren:

- Es befinden sich Einheiten im Container -> Bewege Einheiten
- Es befinden sich Gebäude im Container -> Setze Sammelpunkte
- Es befinden sich Einheiten im Container und auf der geklickten Position ist ein Gegner -> Greife Gegner an

Da InputManager und ObjectManager beide Teile der Gameklasse sind, kann diese entsprechend das ganze steuern: Der InputManager sagt, es wurde auf Position xy geklickt, die Gameklasse geht dann zum ObjectManager und sucht sich die entsprechenden Einheiten an der Position raus und bestimmt die Aktion nach oben genannten Schema.

Den Ansatz von TrommBomml mag ich ehrlich gesagt gar nicht. Ein Objekt steuert sich immer selbst und alles ist global, aber nur scheinbar hübsch verpackt? Irgendwie sehr dezentral, sehr chaotisch und noch schlechter zu warten oder zu verstehen als globale Variablen, denn Referenzen und Call-Hierarchien lassen sich damit überhaupt nicht mehr bestimmen.

Ich bin immer noch der Fan von Controllern. Der Vorteil ist dabei auch, dass es für das "GameObject" (ich hasse dieses nichts-sagende Wort) egal ist, wie der Input gemappt wird oder woher er stammt. Mouse, Joystick, Tastatur, Tastenbelegung, Touch-Screen, Beschleunigungs-Sensor? Total egal. Der Controller mappt das und gibt dem Objekt seine Befehle. Dabei braucht kein Objekt irgendwelche anderen globalen Objekte zu kennen oder sich selbst um Dinge zu kümmern, die es eigentlich nichts angeht (eine Spielfigur kennt meiner Meinung nach logisch gesehen so etwas wie Maus oder Touch-Screen nicht - auch ein Raumschiff kennt so etwas nicht - wieso also den Code so aufbauen?).

Zitat von »BlueCobold«

Den Ansatz von TrommBomml mag ich ehrlich gesagt gar nicht. Ein Objekt steuert sich immer selbst und alles ist global, aber nur scheinbar hübsch verpackt? Irgendwie sehr dezentral, sehr chaotisch und noch schlechter zu warten oder zu verstehen als globale Variablen, denn Referenzen und Call-Hierarchien lassen sich damit überhaupt nicht mehr bestimmen.

Ich glaube du bist ein bisschen allergisch, was global angeht oder? Ausserdem glaube ich, dass du meinen Ansatz nicht ganz verstanden hast. Jedes Objekt ist sogar sehr selbstständig, weil es als einzigen Kontext das Game benötigt und darüber zentral an alle wichtigen Teile des Spiels kommt: Ressourcen, RenderContext, Einstellungen, Auflösung des Viewports, GraphicsDevice, Input etc. Ich fand das letztendlich besser, als immer die Update-Methoden unterschiedlich zu parametrisieren, weil z.B. das Level den Player kennen muss oder ein Player Projetile abfeuert, die mit dem Level und Figuren kollidieren usw.
Für mich hat das einfach ziemlich saubere Trennung bewirkt und den Code stark vereinfacht. Globale Objekte sind einfach nur im Game bekannte GameObjects. Das sind nicht alle, sondern nur eine Hand voll. Dadurch hat man sehr einheitliche Schnittstellen für jedes GameObject, was ich sehr leserlich finde.

Zitat von »BlueCobold«

Ich bin immer noch der Fan von Controllern. Der Vorteil ist dabei auch, dass es für das "GameObject" (ich hasse dieses nichts-sagende Wort) egal ist, wie der Input gemappt wird oder woher er stammt. Mouse, Joystick, Tastatur, Tastenbelegung, Touch-Screen, Beschleunigungs-Sensor? Total egal. Der Controller mappt das und gibt dem Objekt seine Befehle. Dabei braucht kein Objekt irgendwelche anderen globalen Objekte zu kennen oder sich selbst um Dinge zu kümmern, die es eigentlich nichts angeht (eine Spielfigur kennt meiner Meinung nach logisch gesehen so etwas wie Maus oder Touch-Screen nicht - auch ein Raumschiff kennt so etwas nicht - wieso also den Code so aufbauen?).

Interessanter Ansatz. Mich würde eine konkrete Implementierung zum Vergleich interessieren. Gerade, was Kollisionen und deren reaktion angeht, wäre interessant zu wissen, wie das aussehen würde. Ich empfinde es spannenderweise genau anders herum gut, wenn die einzelnen Spielelemente alles selbst behandeln, was für sie von Interesse ist. Sonst hatte ich die Erfahrung, dass sich die öffentlichen Schnittstellen der Objekte einfach enorm vergrößert, was ich gar nicht gut finde. Dafür nehme ich gerne ein paar globale Einzelkämpfer in Kauf.