[Pattern] Übersichtliche Strukturierung beim Spieleprogrammieren

Liebe com,

ich habe nun schon mehrere kleine bis große Spiele begonnen zu programmieren. Bisher hatte ich allerdings immer das Problem, dass ich nach einer bestimmten Nummer von Zeilen einfach vollständig den Überblick verloren habe. Deswegen habe ich auch begonnen mich mit Pattern auseinanderzusetzen.

Meine Frage ist, wie man ein Spiel möglichst strukturieren sollte, sodass man nicht so schnell den Überblick verliert.

Beispiele:
Mein allererstes Spiel was die reinste Katastrophe und hatte nichts mit Grafik zu tun :slight_smile: Das lass ich hier generell mal lieber weg, sonst kommen sofort alle Hater :wink: (falls sich noch jemand im JF dran erinnern kann, irgendjemand [ja, so hieß er wirklich!] hat alle meine Threads zerstört :stuck_out_tongue: )

Mein 2. Spiel war schon etwas komplexer, etwa 5k Zeilen mit Onlinemode sogar über das Internet (aber SEHR buggy). Dabei habe ich kein direktes Pattern genutzt und alle Werte von Einheiten einfach jeweils in ein static Array gepackt (OOP - Was ist das? :smiley: ). Wie man schon sehr schön erkennen kann, hatte das auch nicht viel mit Struktur zu tun, Daten und Grafik waren überall vermischt, Berechnungen über alle Klassen verteilt etc.

Danach kamen ein paar Simulationen und Automaten, an denen ich auch jetzt noch arbeite. Dabei habe ich sehr erfolgreich das MVC-Pattern und Observer genutzt, und diese sind auch noch sehr übersichtlich (bei 1,5k Zeilen geht das noch).

Doch als ich vor etwa 20w mit nem Freund wieder ein Spiel (ein Strategiespiel) begonnen habe (Grafik mit Slick2D), haben wir inzwischen den Überblick verloren. Wir haben auch hier versucht das MVC zu nutzen, allerdings müssen sehr viele Berechnungen und auch die Events in der view ausgewertet werden bzw. wir haben es bisher so implementiert. Inzwischen sind wir bei 10k Zeilen angekokmmen und haben den Überblick verloren. Wir können zwar noch dran Programmieren, aber es ist kaum noch eine Modulation erkennbar und auch das Bugfixen ist kaum möglich, da zum selben Thema in unterschiedlichen Klassen Berechnungen durchgeführt werden müssen.

Deswegen wollte ich jetzt hier mal fragen, wie man (sehr) komplexe Spiele am besten strukturieren sollte bzw. welche Pattern sich am besten eignen, um sowohl besser programmieren zu können ohne die Übersicht zu verlieren, als auch das Bugfixing so einfach wie möglich zu halten. Hat jemand hier Erfahrung mit der Programmierung von komplexen Programmen bzw. Spielen?
Mir geht es hauptsächlich um Strategiespiele o.ä., da ich RPGs eher nicht mag und auch nicht programmieren möchte.

Danke schon im Voraus für eure Vorschläge!

mfg
BH16

Hallo,

es gibt diverse Patterns, aber um eine Klasse von 5000 Zeilen künftig nicht mehr entstehen zu lassen zählt vor allem Erfahrung und OOP. Dabei ist es vollkommen egal, ob es sich um ein Spiel oder etwas anderes handelt. Alles, was irgendwie ein eigenes Objekt im OOP-Sinne ist, sollte auch eines sein. Ich kenne kein besonderes Pattern. Die meisten setzen auf ein solches Wissen bzw. die Umsetzung auf.

Dass das in unterschiedlichen Klassen passieren muss, kann ich mir nicht vorstellen.

Pattern haben nur bedingt etwas mit der Strukturierung einer Applikation zu tun. Der Einsatz eines Pattern kann sich mehr oder weniger auf die Struktur der Applikation auswirken, aber strukturieren muss der Programmierer. Die für solche Zwecke (m.M.) wichtigsten Entwurfsmuster wie MVC, Listener, Observer sind ja scheibar bekannt.
Überlege vorher welche Objekte relevant sind, welche Eigenschaften diese besitzen müssen/sollen und wie diese zusammenhängen. Wenn man dies dann in entsprechenden Klassen abbildet (dabei selbsterklärende Klassen, Methoden- und Variablenbezeichner verwendet) hat man schon eine recht übersichtliche Struktur. Definiere Schnittstellen oder abstrakte Klassen für Objekte, die Gemeinsamkeiten haben, zu einer Gruppe gehören. Programmiere nach Möglichkeit gegen diese Schnittstellen.
Bsp. definiere ein Interface oder abstrakte Klasse Spielfigur, die alle „Wesen“ implementieren bzw. beerben müssen. Dein Model und die View kennen nur dieses Interface und verwalten alle Spielfiguren - egal ob Freund oder Feind - über dieses. Dadurch ist das Spiel um beliebige Charaktere erweiterbar.
Und noch etwas: Vermeide static! Das führt früher oder später zu Fehlern und macht die Applikation schlecht wartbar.

Habt ihr euch mal eine grafische Struktur aufgezeichnet? Hab gehört, das machen wenige Programmierer aber mir hilft das meist auch in dem Moment, an dem ich mir überlege wie ich etwas besser strukturieren könnte. Dann werden neue Klassen generiert, in passende Pakete gepackt und meist siehts dann schon besser aus. Ansonsten auch mal ein Buch darüber schnappen, die “Head First” Reihe ist toll, ob auf Deutsch oder Englisch egal.

Ein Spiel ist am Ende auch nur ein großes Programm.

Genau wie auf jede andere Software kann man mit den SOLID-Prinzipien arbeiten und versuchen möglichst sauberen Code zu schreiben.

Sehr zu empfehlen sind die Bücher “Clean Code” und “Agile Software Development” von Robert C. Martin (Zumindest das erste sollte Pflichtlektüre für jeden Programmierer sein).

Gruß

Plus eins.

Frage dich bei jeder Klasse und Methode, ob sie eine und genau eine klar definierte Aufgabe hat (Single Responsibility Principle), ansonsten refactorn. Wenn du Probleme mit der Initialsierung hast, hilft dir eventuell ein DI-Framework weiter, bei Spielen wohl am besten Guice (da man die Zusatzfeatures von Spring hier normalerweise nicht braucht), das hilft, die einzelnen Teile der Anwendung voneinander zu entkoppeln. Dann solltest du Tests schreiben - zum einen nimmt das die Angst vor Refactorings, zum andern ist Code, der sich schlecht testen lässt, auch ein Warnsignal, dass etwas mit dem Design nicht stimmt.

“Growing Object-Oriented Software, Guided by Tests” find ich persönlich auch recht gut. Geht dann auch schon in die Richtung Test-Driven Development (TDD) und ein Stückchen weiter mit Akzeptanz-Tests (ATDD). Und da wird man auch merken, dass sich bei dieser Art zu entwickeln bestimmte Patterns einfach “lohnen”. Man macht das irgendwann automatisch, weil man seinen Code so auch testen kann. Und man lernt die logischen Einheiten überschaubar zu halten. Hat mir jedenfalls ganz gut geholfen.