Allgemeine Frage zur Spiele-Programmierung

[ui_3k1]

Hey,

ich arbeite mich derzeit in die Spiele-Programmierung ein und bin jetzt bei libgdx hängen geblieben.
Zu meiner Frage:
Ich versuche mir das Verständnis für dieses Thema vor allem durch Beispielcode anzueignen und dabei ist mir aufgefallen, dass die Programmierstiele derart auseinander gehen, dass es mir mittlerweile schwer fällt eine "zielführende" Methode heraus zu suchen.

Allgemein gesagt, empfinde ich es auf den ersten Blick als unsinnvoll massenhaft Logik in einer Klasse -zusammenzuführen- um sie dann später mittels eines einzigen Funktionsaufrufs abrufen zu können.
Ich denke mir, dass es doch sinnvoller sein müsste, die Logik in einzelne Klassen zu verteilen und diese dann in der game-loop einzeln aufzurufen. Allein schon der Lesbarkeit des Codes und der eventuellen Wartung...

Warum erstellt man beispielsweise eine WorldRenderer-Methode, wenn es ohne diese genauso gut funktionieren würde?

Oder ist mein Gedanke ein Trugschluss?

 

[amfa]

Ich glaube deine Frage lässt sich nicht so eindeutig beantworten.
Generell sollten Klassen möglichst nur eine Funktion haben, aber diese Funktion kann durchaus durch sehr viele Methoden ausgeführt werden.

Mit einer Funktion meine ich, dass nicht eine Klasse für Sound, AI und Grafik zuständig sein soll.

Und es kann durchaus richtig sein im GameLoop nur eine einzige Methode aufzurufen.
Ist auch durchaus logisch der Gameloop soll halt jedes mal die Weltzeichen (WorldRenderer).

Ich baue Methoden halt meist so, dass von "vorne" gesehen alles möglichst sehr einfach aussieht, das heißt es werden möglichst wenig Methoden nach Aussen (public) gemacht.
Aber so generell ist das schwierig zu beantworten.
Andere Klassen sollten meiner Meinung nach möglichst einfache Methoden aufrufen und sich gar nicht um Details kümmern müssen.
Weil dann kannst du später innerhalb der Klasse Änderungen machen und dein "Aussenrum" braucht nicht geändert werden.

 

[ui_3k1]

Okay, vielen Dank schon mal für den Hinweis.
Ich glaube meine Frage war nicht so günstig gestellt.

Was mir irgendwie noch Kopfzerbrechen bereitet ist, die Logik sinnvoll zu trennen.
Konkret in meinem aktuellen Fall:
Ich habe eine Player Klasse, die den Spieler darstellen soll. Allerdings habe ich es noch nicht hinbekommen die einzelnen "Bauelemente" des Spielers zu kapseln.
Sprich, derzeit beinhaltet der Spieler:
-Position
-Textur´u. Animation
-Steuerung.
Mit der Folge, dass ich jetzt das Problem habe, dass wenn ich über den InputProcessor zurück ins Hauptmenü will, diese Methode aus der Player Klasse nicht fehlerfrei aufgerufen werden kann. (Darstellung erfolgt über eine Klasse "GameScreen")

Will ich jetzt zB die drei oben aufgeführten "Mechanismen" kapseln, funktioniert gar nichts mehr. :-/

Ich habe wie gesagt schon viele Tutorials durchgelesen / durchgearbeitet, aber habe absolut nicht das Gefühl, dass ich wirklich durchgestiegen bin. Gibts irgendein Tutorial / Buch, was zu empfehlen ist? Ich glaube mir ist in diesem Fall absolut nicht geholfen, wenn ich alle 2 Tage das Lehrmaterial wechsle...

 

[amfa]

Literatur kann ich dir leider nicht empfehlen.

Aber die Steuerung z.B. würde ich so auf anhieb nicht in die Spieler Klasse packen.

Vereinfacht kann man sich ja erst mal ein Schachspiel vorstellen.
Die Figur hat zwar eine Positionseigenschaft, aber die Steuerung passiert von ausserhalb (der Spieler nimmt die Figur in die Hand und bewegt sie.)
Was dann sinnvoll wäre, die erlaubten Züge von der Spielfigur selber berechnen zu lassen. Sonst müsste man in der "Spieler" Klasse sehr viele Abfragen machen ob ein zug legal ist.
Da du ja vermutlich kein Schachspiel baust musst du das ganze halt irgendwie auf dein Problem übertragen.

 

[ui_3k1]

Das Beispiel ist gut, jedenfalls kann ich mir da so grob einen Code vorstellen was im Hintergrund geprüft werden könnte... Mal sehen, ob ich mit dem Gedanken weiterkomme.
Danke noch mal

 

[amfa]

Es hilft halt oft sich den Sachverhalt erst mal sehr stark vereinfacht vorzustellen.

So baue ich dann auch meine methoden,
Spieler hätte dann um bei dem beispiel zu bleiben eine "bewegeFigur(Figur, Zielposition)" Methode.
In dieser methode musst du dann z.B. prüfen ob die Figur diesen zug machen darf.
Quasi:
if (Figur.holeErlaubteZüge().contains(Zielposition)).

Hier fällt mir jetzt auf, dass es sinnvoll wäre, wenn das Schachbrett wüsste welche Figur auf welchem feld steht, daher wäre es in dem beispiel wohl besser, wenn nicht die Figur ihre Position kennt, sondern das Schachbrett

Denn das muss ich noch fragen ob an der Zielpostion nicht schon eine andere Figur steht, die dann geschlagen wird.
Entweder kennen dann beide die Position (finde ich jetzt etwas unschön) oder die
holeErlaubteZüge() methode bekommt noch die aktuelle Position als Parameter übergeben.

if (Figur.holeErlaubteZüge(Schachbrett.getAktuellePosition).contains(Zielposition)) {
    // erlaubter zug
    if schachbrett.figurAufPosition(zielposition)
       removeFigur(Zielposition)
schachbrett.setzteFigur(Figur, Zielposition)
}

So gehe ich meisten daran, Quasi von aussen, welche groben befehle brauche ich (lässt sich gut in einem Interface schon mal schreiben) und dann überlege ich was genau diese Methode ausführen muss und welche informationen sie dafür braucht.