Projekt PBM2
Inhaltsverzeichnis
Kurzbeschreibung
Im Spiel PBall Manager 2 übernimmt man die Funktion des Managers und Trainers eines PBall Vereins.
PBall selbst ist eine fiktive Ballsportart welche an Fußball angelehnt ist, im Gegensatz zu diesem aber mit Hand und Fuß gespielt wird.
Der Spieler übernimmt bei Spielbeginn einen von 96 Vereinen aus 8 Ligen die aufgeteilt sind auf 4 Regionen (Mitte-West, Süd, Nord und Ost).
Als Trainer hat er die Kontrolle über den Sportlichen Sektor (Training, Aufstellung, Taktik) und als Manager ist er verantwortlich für den wirtschaftlichen Teil des Vereins (Spielertransfers, Stadion und Vereinsgelände, Finanzen). Überwacht wird der Spieler nur vom Vereinspräsidenten der zu Beginn einer jeden Saison 2 Aufgaben stellt, die erfüllt werden müssen. Werden diese Aufgaben nicht gelöst und hat der Spieler nicht anderweitige Erfolge vorzuweisen hat, ist der Trainerstuhl alles andere als sicher.
Höhepunkt einer jeden Saison ist der Liga-Meister-Pokal. In ihm treten die besten 8 Teams aus den 4 Regionen gegeneinander an, um das beste Team zu bestimmen. Neben Ruhm und Ehre wartet natürlich auch eine gehörige Portion Geld auf den Sieger.
Mehr Screenshots und das Spiel selbst findet ihr unter
http://www-user.tu-chemnitz.de/~flke/PBM2.php
Projektentwicklung
Vorgeschichte
Als ich mit meinem Studium begann traf ich in den ersten Wochen auf einen Komiliotonen der ständig auf seinem (grafikfähigen) Taschenrechner rumtippte. Es stellte sich heraus, dass er ein Spiel für diesen schrieb. Das faszinierte mich und brachte mich auf die Idee selbst so etwas zu machen. Da mich das Genre "Sportmanager" interessierte (Ich war stolzer Besitzer von Anstoss2 und Anstoss3) sollte es ein solcher werden.
Ich konnte Michael Bomsdorf (das war besagter Taschenrechnerprogrammierer) von einer Zusammenarbeit überzeugen. Als Programmiersprache verwendeten wir Turbo Pascal 7, da diese Sprache auch während des Studiums benutzt wurde und wir zum Schluss kamen, dass der Taschenrechner wohl doch nicht so ne tolle Plattform war.
Nach wenigen Wochen stand der erste Prototyp des PBall Managers. Das Spiel verfügte über eine spartanische ASCII Textausgabe die sich auch nach mehreren Verbesserungen gehalten hatte.
Wir kamen recht gut voran, doch nach ca. einem halben Jahr schlief das Projekt wieder ein. Nach mehreren Monaten Pause grub ich das Spiel wieder aus und schrieb es fertig. Der PBall Manager (DOS) war fertig.
Der 2. Teil
Im 4. Semester stand ein Softwarepraktikum auf meinem Stundenplan. Wir konnten uns eigene Themen suchen. Da ich schon seit längerem über eine neue Version des PBM nachdachte und mittlerweile die ersten Schritte in Sachen OpenGL gegangen war schlug ich vor, den PBM2 zu schreiben. Mit im Boot war wiederum Michael sowie 3 weitere Komiliotonen. Aufgrund der Teamgröße bildete ich mir ein, dass das Projekt recht schnell über die Bühne gehen würde. Leider entpuppte sich das Softwarepraktikum als "Dokumentationspraktikum" (Zum damaligen Zeitpunkt hatte ich noch nicht den Hauch einer Ahnung wie echtes Softwaredesign funktioniert und war extrem genervt von Dokumentation und Pflichtenheft. Ich wollte einfach coden.).
Meine Komiliotonen konzentrierten sich in der folge nur noch auf das was gemacht werden musste. Da ich der einzige war der wirklich am Projekt arbeitete (Michael steuerte zumindest anfangs noch etwas Code bei), blieb die Dokumentation wiederum an mir hängen. Ich hatte die Nase ziemlich voll. Vor allem als Michael sich über ein Semester hinweg nicht mehr meldete.
Die folge war, dass ich das Projekt selbst fertig stellte. (Neben den gesamten Grafiken und Modellen sind 97% des Codes (44412 Zeilen davon ~12000 Zeilen Typ- und Klassendefinitionen) von mir.).
Postmortem
Ich kann nicht behaupten, dass es gar keine Struktur gibt. Aber schön ist der Code auf keinen Fall.
Das Spiel wurde einfach hingeschrieben. Es gab die Überlegung, die Menüs als Klassenhierarchie zu erstellen. Dies hatte zur folge, dass es zumindest in Ansätzen ein UI-Framework gibt. Allerdings ist dieses sehr primitiv und erlaubt zum Beispiel nicht, dass Menüs verschoben werden, oder minimiert bzw. geschlossen.
Alle GUI-Komponenten sind ebenfalls Klassen. Die Formulare besitzen eine Klickauswertung und finden somit heraus was vom Klick getroffen wurde. Da hört der Luxus aber auch schon auf.
Das Spiel ist folgendermaßen gegliedert:
- UMain
- Stellte die OpenGL-Oberfläche zur Verfügung und initialisierte diese. Außerdem steht hier die Renderschleife.
- UTypes
- Enthält alle Typen, Konstanten und Klassendefinitionen. (12000 Zeilen!)
- UOptions
- Kümmert sich um Speichern und Laden. Dieser Teil stammt zum Großteil von Michael.
- UTextureLoader
- Wurde im nachhinein eingebaut um nicht alle Texturen zu Beginn zu laden.
- UGLText
- Diese Unit sorgt für die Textausgabe und wurde ebenfalls von Michael geschrieben.
- USteuerung
- Enthält Beschreibungen was bei einem Klick auf Button XYZ im Menü ABC gemacht werden soll.
- UWochenstart
- Diese Unit sorgte für den Wochenablauf
- Menüs und Ligapokal
- Alle Menüs besitzen eine eigene Unit in der ihr Verhalten definiert ist.
- UEngine
- Enthält alles was sonst nicht zuordenbar war.
Wie ihr seht: Besonders toll isses nicht.
Der Ablauf war eigentlich bereits Grundsätzlich falsch, denn ich fing einfach an zu programmieren ohne mir überhaupt Gedanken zu machen, was ich im Verlauf der Programmierung an Klassen benötigen könnte.
Abgesehen davon ging alles recht viel versprechend los. Ich wollte meinen Komiliotonen eine Plattform bieten von wo aus sie selbst Code beisteuern konnten. Zu diesem Zweck schrieb ich eine Art Blase. Die GUI existierte bereits und ein erstes Menü hatte ich als Vorlage eingebaut. Logik war keine da.
Im zweiten Schritt erstellte ich die Klassen für die Spieler und Teams. Ich wusste ungefähr (vom PBM1) was die Spieler ausmacht. Mein nächstes Ziel war eine Spielwelt generieren zu können. Das hieß, alle Spieler sollten erstellt werden können und in Teams organisiert werden. Die Teams selbst sollten in Ligen organisiert werden, und die Transferliste sollte mit ein paar Spielern gefüllt werden. Von da ab wurde sehr unplanmäßig weiter programmiert. Hier mal ein Menü, da mal eine Klasse, dort eine Klasse verändert. Folge war "The Big Mess". Es war wirklich furchtbar etwas zu debuggen. Schon alleine aufgrund der langen Startzeiten. Denn zu diesem Zeitpunkt wurden alle Spielgrafiken noch am Spielstart geladen. Mit der Folge, dass ein Start ca. 30 Sekunden lang dauerte.
Immer wieder vielen mir neue Features ein und sogar solche Basiseigenschaften wie die der Spieler wurden später redisigned. Dazu kam der Ärger über Michael der sich zu diesem Zeitpunkt nicht mehr meldete, und ich vergebens auf eventuellen Code von seiner Seite wartete.
Extrem viel Zeit verschlang das Design der Grafiken. Mit den Menüs kam ich noch sehr zügig voran (sie waren bereits innerhalb der ersten 2 Wochen fertig). Doch schließlich mussten noch 96(!) Teamwappen erfunden und gezeichnet werden. Dies war sehr anstrengend und langwierig. (An solch einem Punkt weiß man was 1 oder 2 Grafiker im Team wert sind.)
Unerklärliche und nicht reproduzierbare Fehler verschönerten mir viele Monate der Arbeit. Ich begann damit den Code genauer zu dokumentieren. Ich hatte zwar von Anfang an, eine kleine Beschreibung an den Beginn einer jeden Funktion gestellt, doch hatte ich viele Verhaltensweisen im Spiel durch Zahlen codiert und diese nicht dokumentiert. Dies holte ich nun nach.
Zwischenzeitlich versuchte ich die Spielberechnung (die in ihrer ursprünglichen Form von Michael stammte) die von Anfang an nicht sehr übersichtlich war, durch Änderungen meinerseits aber endgültig verkompliziert wurde, neu zu schreiben. Ich wollte hin zu einer echten Spielberechnung, welche die Ballposition und die Positionen der Spieler Minutengenau berechnete.
Nach 2500 Zeilen Code (die man natürlich nicht testen konnte) stieß ich auf Konzeptionelle Probleme und brach die arbeiten daran ab. Dieser Punkt war sehr frustrierend, denn enorm viele Arbeitsstunden waren umsonst. An diesem Punkt merkte ich zum zweiten mal (Nach dem Fitz in der gesamten Klassenstruktur bzw. Programmaufbau) das ich alles hätte besser Planen müssen.
Die Spielberechnung ließ mich aber nicht los. Denn es fielen einfach zu wenig Tore (im Vergleich zur original Spielberechnung des PBM1). Ich balancierte das Spiel über Wochen hinweg aus. Als es dann ging, viel mir ein, dass Verletzungen (und damit verbunden Auswechslungen) dem Spiel gut tun würden. Das Gegenteil war für den Code der Fall.
Jetzt hatte ich das Große Glück, dass durch die Umbaumaßnahmen in sporadischen Fällen Fehler in der Spielberechnung auftraten. Das hatte zumindest etwas gutes: Es wurden endlich Exceptionhandler eingebaut. Um korrekt zu sein: Die Gesamte Spielberechnung wurde in Unterprogramme aufgegliedert und alle wurden mit Exceptionhandler ausgerüstet, die im Fehlerfall aussagekräftige Fehlermeldungen produzierten.
Nachdem das Spiel soweit fertig war, wurden 5 Versionen zum test freigegeben bevor, nach 2 Jahren Programmierzeit, das Spiel abgeschlossen wurde.
Ich habe nicht durchgehend am Spiel gearbeitet, aber bei 2 Jahren Arbeitszeit verliert man schon mal die Geduld.
Lehren
Die deutlichste Lehre für mich war: "Du kannst zwar programmieren, aber von Softwaredesign hast du keine Ahnung!"
Aus diesem Grunde (und durch den Glücklichen Zufall, dass ich jemanden kennen lernte der mehr Ahnung hatte) habe ich mich mit dem Thema "Softwaredesign" auseinander gesetzt. Die Ergebnisse könnt ihr in der Tutorialsektion sehen.
Was hätte anders laufen müssen:
- Vorausschauende Planung
- Durch eine genauere Planung und mehr Erfahrung hätte ich das Klassenkonzept anders anlegen können.
- GUI-Design
- Die Planung der GUI hätte von anfangs an getrennt erfolgen sollen. Die GUI war nicht nur schlecht Design, sie war außerdem noch unflexibel, hatte wenige Features und war vor allem durchsetzt mit Daten. Das führt zum nächsten Punkt:
- Trennung von Daten, Logik und GUI
- Das Prinzip von Model - View - Controller bzw. Boundary - Control - Entity war mir damals noch unbekannt. Es hätte vieles Einfacher gemacht. Vieeeles!
- Ordentliche Dokumentation
- Dokumentation in Form von Diagrammen wäre beim finden von Fehlern sehr hilfreich gewesen, und hätte sicherlich bei der Implementation einige Irrwege vermieden. Außerdem war es echt schwierig sich in fremden Code einzuarbeiten, ohne entsprechende Doku.
- Teamzusammenstellung
- Traf auf dieses Projekt zwar nicht so sehr zu, da es ursprünglich für die Uni war, aber man sollte sich ein fähiges Team zusammen suchen. Grafiker können einem enorm entlasten, denn Grafiken zu erstellen kostet viel Zeit.
Um es zusammenzufassen: Wenn ich eine neue Version des PBM schreiben würde, würde ich die Finger erstmal vom Code lassen, und einen genauen Schlachtplan zurecht legen wann, was und wie ich etwas machen könnte. Einfach los schreiben mag bei weniger als 2000 Zeilen klappen, bei mehr wird's schnell Mist. Wichtig ist vorallem die Zuständigkeitsverteilung. Klassen die Zuviel können sind eine echte Belastung. Viele kleine Controller kann man leichter verstehen, da sie einen recht begrenzten Zweck erfüllen.
Kevin Fleischer aka Flash
