Projekt PBM2 - Versionsgeschichte

Flash: Bild mit Stadion hinzugefügt. Beide Bilder als Thumbs eingefügt.

2007-09-19T09:25:12Z

Bild mit Stadion hinzugefügt. Beide Bilder als Thumbs eingefügt.

Flash: /* Kurzbeschreibung */

2007-08-01T21:03:25Z

‎Kurzbeschreibung

Flash: /* Postmortem */

2007-02-11T22:00:56Z

‎Postmortem

Flash: /* Kurzbeschreibung */

2007-02-11T21:54:52Z

‎Kurzbeschreibung

Flash: /* Postmortem */

2006-04-24T09:25:08Z

‎Postmortem

Flash: Komiliotonen

2006-04-23T17:08:37Z

Komiliotonen

Flash: Bilder eingebaut

2006-04-23T17:07:00Z

Bilder eingebaut

Änderungen zeigen

I0n0s: Komolitionen->Komiliotonen ;) + Rechtschreibfehler

2006-04-23T17:03:07Z

Komolitionen->Komiliotonen ;) + Rechtschreibfehler

Flash: Postmortem zum PBall Manager

2006-04-23T16:48:38Z

Postmortem zum PBall Manager

Neue Seite

==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 angeleht ist, im Gegensatz zu diesem aber mit Hand und Fuss 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ößt und hat der Spieler nicht anderweitige Erfolge vorzuweisen 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.

==Projektentwicklung==

===Vorgeschichte===
Als ich mit meinem Studium begann traf ich in den ersten Wochen auf einen Komolitonen 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. Semster 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 sowei 3 weitere Komolitonen. 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 Pflichtenhaft. Ich wollte einfach ''coden''.).

Meine Komolionen 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. Vorallem 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 Klassenhierrarchie 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 Click 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 vielversprechend los. Ich wollte meinen Komolitonen eine Plattform bieten von wo aus sie selbst Code beisteuern konnten. Zu diesem Zweck schrieb ich eine Art Blase. Die GUI exisitierte 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 entgü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 vielen einfach zu wenig Tore (im Vergleich zur orginal 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 tuhen 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 schonmal 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 [[Tutorial|Tutorialsektion]] sehen.

Was hätte anders laufen müssen:

;Vorausschauende Planung: Durch eine genauere Planung und mehr Erfahung hätte ich das Klassenkonzept anders anlegen können.
;GUI-Design: Die Planung der GUI hätte von anfang an getrennt erfolgen sollen. Die GUI war nicht nur schlecht design, sie war außerdem noch unflexibel, hatte wenige Features und war vorallem durchsetzt mit Daten. Das führt zum nächsten Punkt:
;Trennung von Daten, Logik und GUI: Das Prinzip von ''Model - View - Controller'' bzw. ''Boundary - Controll - Entity'' war mir damals noch unbekannt. Es hätte vieles Einfacher gemacht. Vieeeles!
;Ordentliche Dokumentation: Dokumenation 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 losschreiben mag bei weniger als 2000 Zeilen klappen, bei mehr wirds schnell Mist.

'''Kevin Fleischer''' aka Flash

[[DGL_Projekte|Zurück in die Projekte-Ecke]]

@@ Zeile 1: / Zeile 1: @@
 ==Kurzbeschreibung==
-[[Bild:PBM2_Kdr.jpg|right]]
+[[Bild:PBM2_Kdr.jpg|thumb|right|Das Kadermenü in dem man die Mannschaft aufstellen kann.]]
 Im Spiel '''PBall Manager 2''' übernimmt man die Funktion des Managers und Trainers eines PBall Vereins.
@@ Zeile 106: / Zeile 107: @@
-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.
+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.

@@ Zeile 13: / Zeile 13: @@
 Mehr Screenshots und das Spiel selbst findet ihr unter
-'''http://www-user.tu-chemnitz.de/~flke/PBM2.htm'''
+'''http://www-user.tu-chemnitz.de/~flke/PBM2.php'''
 ==Projektentwicklung==

← Nächstältere Version		Version vom 11. Februar 2007, 22:00 Uhr
Zeile 87:		Zeile 87:


−	Nachdem das Spiel soweit fertig war, wurden 5 Versionen zum test freigegeben bevor, nach 2 Jahren Programmierzeit das Spiel abgeschlossen wurde.	+	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.		Ich habe nicht durchgehend am Spiel gearbeitet, aber bei 2 Jahren Arbeitszeit verliert man schon mal die Geduld.

@@ Zeile 7: / Zeile 7: @@
 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 ist der Trainerstuhl alles andere als sicher.
+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.
@@ Zeile 14: / Zeile 14: @@
 Mehr Screenshots und das Spiel selbst findet ihr unter
 '''http://www-user.tu-chemnitz.de/~flke/PBM2.htm'''
 ==Projektentwicklung==

@@ Zeile 83: / Zeile 83: @@
-Die Spielberechnung ließ mich aber nicht los. Denn es vielen 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.
+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.
@@ Zeile 91: / Zeile 91: @@
 Ich habe nicht durchgehend am Spiel gearbeitet, aber bei 2 Jahren Arbeitszeit verliert man schon mal die Geduld.
 ===Lehren===

@@ Zeile 20: / Zeile 20: @@
 ===Vorgeschichte===
 <div align = "right" style = "float: right; padding-left: 20px;"> http://www-user.tu-chemnitz.de/~flke/Images/Thumb_PBM.jpg </div>
-Als ich mit meinem Studium begann traf ich in den ersten Wochen auf einen Komolitonen der ständig auf seinem (grafikfähigen) Taschenrechner rumtippte.
+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.
@@ Zeile 32: / Zeile 32: @@
 ===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 Komolitonen. Aufgrund der Teamgröße bildete ich mir ein, dass das Projekt recht schnell über die Bühne gehen würde.
+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 Komolitonen 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.
+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.).
@@ Zeile 63: / Zeile 63: @@
 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 Komolitonen 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.
+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.

@@ Zeile 14: / Zeile 14: @@
 ===Vorgeschichte===
-Als ich mit meinem Studium begann traf ich in den ersten Wochen auf einen Komolitonen der ständig auf seinem (grafikfähigen) Taschenrechner rumtippte.
+Als ich mit meinem Studium begann traf ich in den ersten Wochen auf einen Komilitonen 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.
@@ Zeile 26: / Zeile 26: @@
 ===Der 2. Teil===
 Im 4. Semster 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 sowei 3 weitere Komolitonen. Aufgrund der Teamgröße bildete ich mir ein, dass das Projekt recht schnell über die Bühne gehen würde.
+Mit im Boot war wiederum Michael sowei 3 weitere Komilitonen. 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 Pflichtenhaft. Ich wollte einfach ''coden''.).
-Meine Komolionen 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. Vorallem als Michael sich über ein Semester hinweg nicht mehr meldete.
+Meine Komilitonen 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. Vorallem 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.).
+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.).
@@ Zeile 37: / Zeile 37: @@
 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 Klassenhierrarchie 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.
+Das Spiel wurde ''einfach hingeschrieben''. Es gab die Überlegung, die Menüs als Klassenhierrarchie 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.
@@ Zeile 55: / Zeile 55: @@
-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.
+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 vielversprechend los. Ich wollte meinen Komolitonen eine Plattform bieten von wo aus sie selbst Code beisteuern konnten. Zu diesem Zweck schrieb ich eine Art Blase. Die GUI exisitierte bereits und ein erstes Menü hatte ich als Vorlage eingebaut. Logik war keine da.
+Abgesehen davon ging alles recht vielversprechend los. Ich wollte meinen Komilitonen eine Plattform bieten von wo aus sie selbst Code beisteuern konnten. Zu diesem Zweck schrieb ich eine Art Blase. Die GUI exisitierte 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.
@@ Zeile 72: / Zeile 72: @@
-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 entgültig verkompliziert wurde, neu zu schreiben. Ich wollte hin zu einer echten Spielberechnung, welche die Ballposition und die Positionen der Spieler Minutengenau berechnete.
+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 entgü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.
+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 vielen einfach zu wenig Tore (im Vergleich zur orginal 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 tuhen würden. Das Gegenteil war für den Code der Fall.
+Die Spielberechnung ließ mich aber nicht los. Denn es fielen einfach zu wenig Tore (im Vergleich zur orginal 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 tuhen 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.
+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.
+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 schonmal die Geduld.
+Ich habe nicht durchgehend am Spiel gearbeitet, aber bei 2 Jahren Arbeitszeit verliert man schonmal die Geduld.
@@ Zeile 90: / Zeile 90: @@
 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 [[Tutorial|Tutorialsektion]] sehen.
+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 [[Tutorial|Tutorialsektion]] sehen.
 Was hätte anders laufen müssen:
 ;Vorausschauende Planung: Durch eine genauere Planung und mehr Erfahung hätte ich das Klassenkonzept anders anlegen können.
-;GUI-Design: Die Planung der GUI hätte von anfang an getrennt erfolgen sollen. Die GUI war nicht nur schlecht design, sie war außerdem noch unflexibel, hatte wenige Features und war vorallem durchsetzt mit Daten. Das führt zum nächsten Punkt:
+;GUI-Design: Die Planung der GUI hätte von Anfang an getrennt erfolgen sollen. Die GUI war nicht nur schlecht Design, sie war außerdem noch unflexibel, hatte wenige Features und war vorallem durchsetzt mit Daten. Das führt zum nächsten Punkt:
 ;Trennung von Daten, Logik und GUI: Das Prinzip von ''Model - View - Controller'' bzw. ''Boundary - Controll - Entity'' war mir damals noch unbekannt. Es hätte vieles Einfacher gemacht. Vieeeles!
-;Ordentliche Dokumentation: Dokumenation 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.
+;Ordentliche Dokumentation: Dokumenation 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.