Dieser Thread wird mir als Projekttagebuch für das Spiel PBall Manager 3 dienen.

Nach dem unglaublichen Erfolg ( ) des Vorgängers PBall Manager 2 war es nur eine frage der Zeit bis es mich wieder zu diesem Thema zieht.

Falls es diesmal, wieder erwarten, Feedback zum PBall Manager 3 gibt, ist hier der passende Thread dafür.

Ziel
Hauptziel ist es ein großes und wohlstrukturiertes Projekt zu erstellen. Ich werde in diesem Tagebuch versuchen klar zu machen wieso ich bestimmte Designentscheidungen getroffen habe.
Nebenbei will ich einen Sportmanager schaffen der mir persönlich Spass macht, weil er wert auf Dinge wie z.B. Stadionausbau legt.

Umfeld
Das Spiel wird mit Java entwickelt. IDE ist Eclipse 3.3 (Europa).
Für die GUI wird in der entgültigen Version OpenGL benutzt. Bis dahin kann es sein, dass eine Entwickler GUI das Programm zieren wird.
Das Spiel soll prinzipiell Plattformunabhängig sein. (Allerdings habe ich bei einem anderen Projekt erleben dürfen wie unter Linux ein "Xlib: unexpected async reply" das Programm torpedierte. Garantieren kann ich also nichts.)

Stand der Arbeiten
+ Projektstruktur (packaging)
+ Zufallswelt (Erstellen einer Initialisierung der Kernkomponenten mit Zufallsdaten)
- Design der Stadionklassen

Download

Noch keiner

_________________
Blog: kevin-fleischer.de und fbaingermany.com

Eine Projektstruktur in Eclipse zu erstellen ist eigentlich sehr simple. Eclipse bietet einen sogenannten "Workspace" an. Dieser enthällt alle Projekte die man gerade bearbeitet. Da man abhängigkeiten zwischen prjekten erstellen kann, bietet es sich an schon auf Projektebene mit der strukturierung zu beginnen.
Man hat dazu folgende Elemente zur Verfügung:

Einführung

Projekte (Java Projekte)
Im Workspace können beliebig viele Projekte liegen welche auch in Abhängigkeitsbeziehung zueinander treten können. --> Ausbildung einer Hierrarchie.

Projekte bestehen wiederum aus...

Source Folder
Jedes Projekt hat mindestens einen Ordner in welchem die eigentlichen Quellcode-Dateien liegen. Es kann aber sehr sinvoll mehrere Source Folder zu verwenden, z.B. um Testcode zu separieren.

Jeder Source Folder enthält wiederum...

Packete
Packete werden benutzt um Quellcodedateien zu bündeln. Anders als in Delphi kann jede Quellcode-Datei nur genau eine (von außen sichtbare und benutzbare) Klasse enthalten. Gehören mehrere Klassen inhaltlich zusammen werden sie üblicherweise im gleichen Packet untergebracht.


1. Idee - Semenatische Struktur

Ich hatte durch die Arbeit am PBM1 und PBM2 bereits ein recht gutes Verständnis davon, welche Entitäten mir im Spiel begegnen werden. Ich konnte sie grob unterteilen in Bau (Gebäude), Verband (Ligen, Nationen), Wirtschaft (Sponsoren, Konten) und Personen (Spieler, Manager). Meine erste Idee war deshalb folgende Gliederung:

Projekte
Es gibt 4 Hauptprojekte PBall3_Bau, PBall3_Verband, PBall3_Wirtschaft, PBall3_Personen. Zusätzlich gibt es ein Projekt PBall3_CoreIF welches die Interaces enthält und später sollte ein Projekt PBall3_Main die Startklassen und Hauptcontroller enthalten.

Die Hierrarchie sollte also sein (von oben nach unten, Projekte weiter oben sind abhängig von drunterliegenden projekten.):

Main
Bau, Verband, Wirtschaft, Personen
CoreIF

Source Folder
Von Anfang an war geplant JUnit tests zu benutzen um die Funktionsfähigkeit einzelner Einheiten zu testen.

Es wurden deshalb 2 Sourcefolder angelegt src\ sowie test\.
Die Packetstruktur in beiden war identisch. Die JUnit-Testklasse welche eine Klasse im Packet a.b.c im eigentlichen Sourceordner src\ testen sollte, lag im test\ Ordner im gleichnamigen Packet a.b.c

Packete
Der Quellcode wurde in den Hauptprojekten (Bau, Verband, ...) folgendermaßen gegliedert (Hier am Beispiel Personen):


Das CoreIF Projekt enthielt ebenfalls eine solche Packetstruktur. Allerdings ohne das Factory-Packet. Dafür aber für jeden Bereich (bau.data, person.data, wirtschaft.data, ...)

Wieso wurde diese Struktur nicht umgesetzt?
Es stellte sich heraus, dass die unterteilung der Projekte probleme macht. Die semantische unterteilung ist zwar gut für die orientierung im Projekt allerdings hat sie ein fundamentales Problem: zyklische Abhängigkeiten zwischen den Projekten.
Eigentlich sollte das CoreIF projekt dies verhindern. Die Controller und Entitys eines Hauptprojektes sollten nur mittels Interfaces mit den Klassen der anderen Hauptprojekte arbeiten. Dabei wurde vergessen, dass zumindest die Factorys zugriff auf die tatsächlichen Klassen benötigen.

Mein erster Reflex war alle Factorys in ein extra Projekt auszulagern, welches in der Hierrachie über den Hauptprojekten lag. Wenn ich nocheinmal drüber nachdenke könnte es sein, dass dies sogar funktionieren könnte(!), allerdings fehlte mir damals noch eine Idee: Damals sollten die Factorys die erstellten Klassen auch verwalten. Falls also jemand ein Team benötigte, sollte er per TeamFactory.getTeam(id) dieses erhalten. Dadurch hätten die Factorys aber von unten erreichbar sein müssen -> zyklus. Dieses Problem könnte ich im zweiten Ansatz durch das "Core" Projekt lösen, welches eine "globale Variable/Klasse" verwaltete über die man zugang zu allen teilen der PBall-Welt erhält.

2. Idee - Syntaktische Struktur

Da die Idee mit dem Code-Projekt erst im laufe der Idee2 kam, wurde Idee1 nicht weiter verfolgt. Die neue Gliederung sah so aus:

Projekte
Es gibt 4 Hauptprojekte PBall3_Factory, PBall3_Data, PBall3_Control, PBall3_GUI. Zusätzlich gibt es ein Projekt PBall3_CoreIF welches die Interaces enthält und später sollte ein Projekt PBall3_Main die Startklassen und Hauptcontroller enthalten. (Auserdem kam noch das Projekt "PBall3_METAPROJEKT" hinzu welches nur dazu dient allgemein genutzte Bibliotheken zur verfügung zu stellen. Es liegt also sogar unter CodeIF)

Außerdem kam wie erwähnt das projekt PBall3_Core hinzu welches die Klasse PBallWeltManager enthielt, welcher wiederum die einzige PBallWelt die existiert (Singleton-Pattern) verwaltet/hält. Außerdem liegt dort noch der Zeitmanager, welcher das Datum im Spiel verwaltet.

Die Hierrarchie änderte ich dabei so (von oben nach unten, Projekte weiter oben sind abhängig von drunterliegenden projekten.):

Main
Factory
Control, Data, GUI
Core
CoreIF
(METAPROJEKT)

Source Folder
Das prinzip der 2 Sourcefolder blieb erhalten. (Funktioniert auch wunderbar.)

Packete
Der Quellcode wurde in den Hauptprojekten (Factory, Control, Data, auch CoreIF) jetzt semeantisch gegliedert (Hier am Beispiel Factory):


Das CoreIF Projekt enthält außerdem noch ein Packet mit Konstanten.

Die Idee2 ist stellt meine momentane Projektstruktur dar.

Idee1 steht senkrecht zu Idee2. Es sind 2 komplett verschiedene Sichtweisen auf das Problem. Falls die Idee1 auch mit dem Code-Projekt zyklische abhängigkeiten enthalten hätte würde dies meine These unterstützen, dass die Projektstruktur sich an den Bedürfnissen der Entwicklung orientieren muss, und nicht am verständniss des Packagings.

Ach ja. Für die nicht Javaner. Die Packetnamen sind in den unterschiedlichen Projekten nicht grundlos gleich. "protected" Eigenschaften sind sichtbar für alle Klassen des selben Packetes. Java ist dabei egal, ob das Packet über mehrere Projekte verteilt ist. Ich kann also mit den Factorys aus dem Factory-Projekt "protected"-Eigenschaften im Data-Projekt setzen. "Fachfremde" Klassen (die in anderen Packeten liegen) können da nicht ran, sondern müssen die "public" Getter und Setter nutzen. Das ist ziemlich praktisch - find ich.

Edit (10.9.07): Nach etliches Abhängigkeits-/Sicht-Problemen beim testen habe ich mich entschlossen die Test nicht per eigenen Sourcefolder Einzubinden. Ich habe vielmehr ein eigenes Subprojekt angelegt welches alle Tests enthält. Die Tests selbst liegen in der selben Packetstrucktur wie die zu testenden Klassen. Das Testprojekt liegt auf der obersten ebene und hat zugriff auf alle anderen Subprojekte. Sichtbarkeitsprobleme gehören damit der Vergangenheit an. ("Einfach ist meistens besser" )

_________________
Blog: kevin-fleischer.de und fbaingermany.com

Nachdem die Projektstruktur festgelegt war, wollte ich das programm soweit bringen, da Basisklassen vorhanden waren und daraus eine Zufallswelt zusammengebaut werden konnte.

Es entstanden Factorys für Personen, Teams, die Verbände, Liegen, Nationen und ein Controller der diese dann in der Richtigen Reihenfolge aufruft.
An dieser Stelle sieht man schon eine Neuerung die es im PBM2 nicht gab: Nationen.

PBM3 wird die Nationalitäten nicht nur auf 3Buchstaben in den Spielereigenschaften beschränken. Jeder Spieler und jedes Team gehören einer Nation an. Jede Nation besitzt wiederum eine Sprache. Durch dieses Konzept sollen später einmal Verständigungsprobleme modeliert werden (wie es bei vielen Fussballmanagern schon üblich ist). Außerdem ist jede Nation einem der 4 Verbände zugeordnet (NEPA, EEPA, SEPA, WEPA). Da die Eigenschaften der Nationen über eine XML Datei eingelesen werden, kann man die Verbands/Liga zusammensetzung prinzipiell dynamisch ändern. Zu diesem Zweck werden später noch Editoren geschrieben.
Was die Nationen sonst noch so können sollen werd ich später mal in einem extra Artikel beschreiben.

Appropos Editoren. Diesmal werden die Spielernamen ebenfalls in Dateien ausgelagert und per Editor erweiterbar gemacht. Man soll dann für jede Nation eine Auswahl von ca. 20 Vor- und Nachnamen haben (so wie es beim PBM2 bereits war). Diesmal kann man aber auch seinen eigenen Namen per Editor hinzufügen. Vielleicht spielt ja (wenns der Zufallsgenerator will) irgendwann einer von euch in der PBall-Welt mit.

Worauf ich etwas stolz bin, ist meine "Factory-Kette" zum erzeugen von verschiedenen Personenarten. Dazu siehe Diagram. Auf den ersten Blick etwas verwirrend. Um es kurz zu erklären. Will man einen Spieler erzeugen nutzt man die Spielerfactory und übergibt ihr bei Aufruf von createInstance ein SpielerFactoryParameter-Objekt. Dieses enthält die Randbedingungen wie z.B. die Position aber auch geerbte Randbedingungen wie z.B. das Alter (geerbt von PersonFactoryParamter). Heraus kommt eine Instanz/Implementation von "Person" - offiziell. Da es aber die Spielerfactory ist, kann man dieses Resultat gefahrlos in eine Instanz vom Typ "Spieler" casten.

Schön finde ich diese Hierachie vorallem deshalb, weil beim codieren nur sehr wenig code benötigt wird. Wenn die Spielerfactory eine eigenständige Factory wäre, so müsste ich dort auch Code hinschreiben den ich bei der Personenfactory schon geschrieben habe - denn jeder Spieler ist auch eine Person. Da die Factorys aber voneinander erben, kann ich per "super.createInstance()" (entspricht in delphi "inherited") ersteinmal die arbeit der Superklassen abwarten und dann jeweils nur noch das neue hinzufügen. Vermutlich machen das die ein oder anderen von euch ähnlich, ich wollte es trotzdem einfach mal erwähnt haben.


Zu guter letzt wurden noch JUnit tests für die meisten Controller und Factorys geschrieben. Für die, welche nicht wissen was Unit-Tests sind:
Bei Unit-Tests schreibt man eine Klasse, welche eine Funktion der zu testenden Klasse aufruft, und die Rückgabewerte mit den vom Programmierer erwarteten Werten vergleicht.
Vorteil ist dieser: Ändert man im programm an irgend einer Stelle etwas kann man sich normaler weise nicht 100% sicher sein, dass es keine Seiteneffekte auf andere Teile des Programms gibt. Durch die Unit-Tests kann man dies prüfen. Man läßt einfach alles Unit-Tests einmal durchlaufen. Wenn alle melden, dass ihre Tests erfolgreich verliefen (und man davon ausgeht, dass alle Controller mit tests ausgestattet waren), kann man sagen: Die Änderung hat keine unerwarteten Probleme verursacht. Java-Programmierer sollten einmal einen Blick auf JUnit werfen. JUnit tests zu schreiben is extrem simple. Und Eclipse unterstützt sogar die grafische Auswertung der JUnit Tests.

_________________
Blog: kevin-fleischer.de und fbaingermany.com

Ich hatte ja schon angedeudet, dass mir der Stadionausbau etwas am Herzen liegt. Ich habe jetzt die Klassen dafür erstellt und auch bisl "ConzeptArt" dazu.

Und zwar möchte ich, dass das Stadion nicht nur hübsch aussieht, sondern es soll eine echte Funktion im Spiel haben. Jetzt könnte man sagen: "Hatte es doch schon. Die Mannschaften spielen drinnen." - ja. Aber ich will mehr. Das Stadion enthält jetzt Container welche mit Geschäften ausgestattet werden können. So trägt das Stadion zur Kostendeckung bei. Geplant sind z.B. Restaurants, Würstchenstände, Getränkeausgaben usw.
Neu wird auch sein, dass manche Zuschauerbelegungen einfluss auf den Unterbau haben. So benötigen Logen nicht nur einen Container, sondern 2. Der hintere ist für den Cateringbereich nötig.

Ich wollte dies im Spiel haben, damit sich die Nutzer beim Stadionbau etwas verwirklichen können. Es soll auch ereignisse geben welche von der Belegung abhängen. Z.B. könnte "Eine bekannte Deutsche OpenGL-Comunity sucht einen Veranstaltungsort. ..." kommen, wenn man Kongressräume im Stadion hat.

Das Prinzip der Container und deren Belegung habe ich einmal in Bild_1 dargestellt. Gemeint ist folgendes:
Die Tribüne (insgesamt gibt es 18, 14Geraden und 4Ecken) bestehen aus Belegungscontainers.
Ein belegungscontainer kann entweder Innenbelegungen oder Zuschauerbelegungen aufnehmen. Alle belegungscontainer werden bei erzeugung der Tribünen angelegt und verknüpft. Sie bleiben aber leer. Es ist aufgabe des Users (bzw. des Zufallsgenerators) sie zu füllen.

Überdachung sind unabhängig von der Belegung. Sie werden direkt an der Tribüne vermerkt.

Es wird (hoffentlich) diesmal auch die Möglichkeit geben, Tribünen als Gästetribünen auszuweisen. Aber das sind alles noch Hirngespinste.

_________________
Blog: kevin-fleischer.de und fbaingermany.com

Der Projektthread wurde leider etwas ignoriert. Ich habe (trotz Diplomarbeit) einiges geschafft, auch wenn es hier nicht so aussieht.

Wie man am Ende des Tutorial_Softwareentwicklung3 lesen kann ist iteratives Vorgehen eine Recht gute Struktur beim programmieren von größern Projekten. Meine erste Iteration war das erstellen der primären Entitäten (Siehe Post "Zufallswelt" und "Design der Stadionklassen"). Als dies fertig war habe ich mit dem nächsten Schritt, der Spielberechnung angefangen. Dieser Schritt läuft noch und ist wohl auch einer der größeren. Hier werden zwar nicht so furchtbar viele neue Klassen entstehen (10-20 sind's schon) aber die paar haben es in sich.
Zur geplanten Spielberechnung werde ich einen extra Post machen.

Meine nächsten Iterationen sehen so aus (Jeder Schritt inkl. Test):

- Spielberechnung I (Grundlegende Berechnung)
- Spielberechnung II (Textausgabe)
- Spielberechnung III (Auswechslungen, Platzverweise, Verletzungen)
- Editoren (Spielereditor, Nationseditor, ...)
- OutGame-Menü
- InGame-Menü
- Kadermenü
- Spielberechnungsmenü

Wenn ich soweit bin werde ich mal was vorzeigen können. Is aber noch ein langer Weg.

_________________
Blog: kevin-fleischer.de und fbaingermany.com

Wie ich bereits erwähnt habe, arbeite ich momentan an der Spielberechnung.

Diese wird diesmal etwas realitätsnaher aber dadurch auch komplexer ausfallen.

Ich bediene mich einer Idee die auch bei der Wettersimulation benutzt wird: Ich unterteile das Spielfeld in Felder (5x5m) und berechne für die (belegten) Felder jeweils was dort passiert.
Momentan ist geplant das Spiel in 4Sek Schritten zu berechnen. Das sind immerhin 80*15 = 1200 Durchläufe pro Spiel. Wenn man bedenkt, dass es 48 Partien pro Spieltag geben wird, ist das schon nicht schlecht. Die Tests werden zeigen ob es so praktikabel ist.

Ihr werdet jetzt bestimmt wissen wollen, wie so ein Spiel berechnet wird. Das ist im Grunde genommen ganz einfach.
In jedem Durchlauf führt zuerst der Ballführer eine Aktion aus, dann seine Mitspieler und dann seine Gegenspieler.
Wurde ein Pass gespielt nehmen alle Spieler auf dem Zielfeld des Passes an der "Annahme" teil. Wer gewinnt entscheidet das Spielergeschick und der Zufallsgenerator.

Die eigentliche Spielberechnungslogik wurde getrennt in "Entscheidungsfindung" (Das übernehmen 2 KIs) und in "Aktionsdurchführung" (das übernimmt der Spielberechnungscontroller).
Die eine KI ist für den Ballführer zuständig, die andere für die restlichen Spieler.

Ich arbeite gerade an der für die "balllosen" Spieler.
Die Ballführer KI ist bereits fertig. Die KI berechnet für die 3 möglichen Aktionen "Schuss", "Pass" und "Dribbling" jeweils den Nutzwert (inkl. einem Fehleinschätzungsfaktor) und nimmt dann die vielversprechendste Aktion.

Damit ihr ein Bild davon habt, welche komplexen Aktionsabläufe möglich sind, habe ich ein Datenflussdiagramm der Ballführer-Aktionen aufgestellt. Dort kann man sehen welche Aktionen wie zustande kommen. (Um die Grafik zu sehen muss man eingeloggt sein.)

Wenn ich die nächste KI fertig habe melde ich mich wieder.

_________________
Blog: kevin-fleischer.de und fbaingermany.com