Falls jemand eine Meinung hat, die er zum Projekt äußern will. Bitte hier rein.

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

Ja ich habe eine Meinung zu dem Thema.

Zunächst einmal begrüße ich es das es eine Fortsetzung von PBall Manager 2 geben wird. Mir hat das Spiel bis auf die Fehler die den SPielspass drückten gefallen und ich hab immerhin 17 Saisons gespielt ^^ Soviel dazu...

@Struktur: Wieso machst du dir das Leben unnötig schwer und verzweigst alles in Unterprojekte? Dadurch können viel mehr Fehler bei den Abhängigkeiten auftreten. Ich empfehle dir die jeweiligen Bereiche in entsprechende Packages zu packen innerhalb des Projektes. Zb. wie folgt.

• BPM3
  
  • Core
    
    • IO
  • GUI
  • Input
  • Game
    
    • Bau
    • etc
  • Tests

Die Factories packst du in ihre jeweiligen Packages, zb. die Factories zum Bauen kommt ins Bau Package und GUI ins GUI Package. Damit erhält man eine einfache und verständliche Projektstruktur. Im Idealfall wissen die jeweiligen Packages nicht voneinander, aber das geht nur bei geschlossenen Subsystemen

_________________
(\__/)
(='.'=)
(")_(")

Endlich! Das Beispiel zu dem Tutorial
Leider kann man am Anfang nicht so viel sagen. Es ist dein Aufbau der Diagramme.
Ich muss sagen, dass ich nicht weiss wie du genau deine Diagramme ausarbeitest, aber wenn es elektronisch ist fände ich Bilder sehr interessant. Falls nicht: Ein Scanner in deiner Nähe?

_________________
Steppity,✲steppity,✴step,❆step,✳step!
❆ ❄ ❄ ❄ ❅ ❄ ❆ ❄ ❅ ❄ ❅ ❄ ❅ ❄ ❄
❅ ☃ ❄ ❄ ❄ ❅ ❄ ❄ ❄ ❅ ❄ ☃ ❄ ❆ ❄ ❄

Hmmm... alles in ein Projekt zu packen wäre tatsächlich eine Lösung die ich mir aus unerfindlichen Gründen noch gar nicht überlegt habe.

In meiner Praktikumsfirma und auch bei Projekten an der Uni, bestand das gesamtprojekt immer aus mehreren Javaprojekten. (In der Firma >50 Stück. Die aber jeweils Eclipseplugins waren.) Da hab ich noch gar nicht drüber nachgedacht...

Eventuell schmeiß ich alles nochmal um und mach ein 3. Einprojektdesign. Muss mal drüber anchdenken.

@Diagramme: Werd mal was machen.

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

@Plugin Projekte: Das hat auch seinen Sinn. Das wäre für ein Projekt zu unübersichtlich und es wäre sehr schwer das zu deployen.

@Struktur: Überleg dir zunächst welche Bereiche evtl häufiger Änderungen erfahrne könnten und ob es sich lohnen würde die mit in das Hauptprojekt zu setzen, allerdings kann man auch aus den Packages die in einem Projekt exisiteren mehrere JARs exportieren. Hierbei helfen ANT bzw. MAVEN sehr gut.

_________________
(\__/)
(='.'=)
(")_(")

Das mit den jar-Erstellung war mir auch in den Sinn als Contra-Argument gekommen. Aber ich glaube auch, dass es leicht möglich ist bestimmte Packete eines Projektes in ein gesondertes jar zu exportieren.

Ich mach mir nochmal gedanken dazu. Hab auch gerade nochmal jemanden zu dem Thema befragt der es wissen sollte (is SW-Architekt). Mal sehn ob er da ein Totschlägerargument hat.


Edit: Mir viele noch eines ein. Trennung von Oberfläche und Inhalt. Die UIs (Swing, OpenGL, Console) werden in jeweils eigene Projekte ausgelagert. Im Hauptprojekt liegen die Interfaces und die Factorys. Diesen Teilt man zur Laufzeit erst mit welche Klassen sie laden sollen (per ClassLoader). So könnte man durch eine Config-Datei zwischen verschiedenen UIs einfach umschalten.

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

Warum so furchtbar umständlich. Ein gutes Design ist einfach und elegant.

Da fällt mir nur ein:

You Ain't Gonna Need It
http://de.wikipedia.org/wiki/YAGNI
KISS-Prinzip
http://de.wikipedia.org/wiki/KISS-Prinzip

Premature Generalization

http://blogs.msdn.com/ericgu/archive/20 ... 87962.aspx

Singletons sind auch nicht unproblematisch,denn sie verursachen eine starke Bindung und werden häufig mißbraucht um eine statische Klasse "schöner" aussehen zu lassen. Die eine Instanz erkauft man mit dem großen Nachteil der globalen Verfügbarkeit.

Wieso großer nachteil? Die globale Verfügbarkeit ermöglicht es mir erst die Ganze PBall-Welt an einem Punkt zu verwalten ohne sie überall durchzuschleifen.
Und wieso erzwingt ein Singleton eine globale Verfügbarkeit. Dies ist nur der Fall wenn alles in einem Projekt liegt. In meinem Fall ist die projektstruktur oben drüber auch eine "Sichtbegrenzung".



Damit bin ich dann wohl offiziell an dem Punkt wo Sascha (tafka Son of Satan) schon vor einigen Jahren war. Du warst damals vielleicht noch nicht hier im Forum, deshalb lies bitte diesen Thread und ziehe Schlüsse: viewtopic.php?t=3213

Es ärgert mich schon, wenn man gar kein Feedback bekommt.


Öhm... also so war das nicht gedacht. Ich gehe nicht zu 100% nach dem RUP vor. Aber auch nicht ganz weit weg davon.

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

Nur weil ich den Thread nicht kannte, bedeutet das nicht das ich da nicht schon im Forum war. Kein Feedback zu erhalten ist zwar immer schade, aber jeder bezieht seine Motivation aus verschiedenen Dingen. Feedback ist nicht alles.

Und zum Mitglied seit, das steht doch unter dem Avatar

_________________
(\__/)
(='.'=)
(")_(")

Wieso muss bei dir eigentlich alles aus einer Fabrik kommen? z.B. bei deinen Spielern sehe ich den Vorteil nicht. Bei der Gui mag das ja noch sinnvoll sein, damit man das darunterliegende system austauschen kann, aber selbst das ist in einem hobbyprojekt wohl meist übertrieben. Ich habe häufig den Eindruck, dass Javaprogrammierer zum übertriebenen Einsatz von Designpatterns neigen.

_________________

@Evil-Devil: Ich seh gerade. Du bist 1 Jahr(!) länger dabei als ich. Sorry. Aber der Thread is trotzdem DGL-Pflichtlektüre.

@The-Winner: Ich sach mal so. Falls ich irgendwann mal was an meinen Personen ändern will weiß ich wo. Oder falls ich irgendwann mal eine komplett neue Implementation von "Spieler" schreiben will/muss, brauch ich sie nur dort einzusetzen, und das ganze Programm nutzt sie. Außerdem kann man Fabriken auch benutzen wenn man Klassen befüllen will, die verschiedene Interfaces implementieren. Z.B. Die Klasse 1 implementiert die IFs A,B,C und D, die Klasse 2 die IFs A und E. Dann erstell ich die Klasse 1 (von mir aus auch in ner Factory) und dann leite ich die an die einzelnen Factorys für A,B,C,D weiter damit dort ein Inititalzustand gesetzt wird. Das kann z.B. praktisch sein, wenn man irgendwann feststellt, dass der Initialzustand für alle Implementationen des IF A geändert werden müssen.

Du hast aber recht. Man könnte nach dem YAGNI-Prinzip (siehe Beitrag von Lars) das auch weglassen. Ich komm damit aber sehr gut zu recht.


PS:
Bei mir kommt noch hinzu, dass die Factorys Klassen aus dem Projekt DATA mit welchen aus dem Projekt CONTROL verbinden. Ohne die Factory wäre das nicht möglich, da es keine Abhängigkeit zwischen den Beiden Projekten gibt.

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

So. Habe soeben von dem SW-Architekten erfahren welche Leitlinien man so nehmen sollte, und warum.

1. Wieso Teilprojekte?
==============
1. Sie lassen sich leichter deployen (installieren/aktualisieren)
2. Sie Sorgen für eine gesteigerte Wiederverwendbarkeit (wenn die Projekte richtig aufgeteilt wurden)

2. Welche Gliederung?
==============
Meine synthaktische Gliederung (also nach Schichten) fand er nicht so gut. Er sagte, dass dadurch zu viele Schnittstellen zwischen den Projekten bestehen (da hat er recht). Er würde die semantische Gliederung bevorzugen. In meinem Fall Projekte mit den Namen Person, Bau, Wirtschaft, Verband.
Diese Projekte wären dann auch leichter wiederverwendbar (in meinem Fall nicht so wichtig) aber auch beim Diployment wären die Bestandteile der Componenten beieinander. (Wenn man was im Stadionbereich ändert und ein Update veröffentlicht, muss man nur das Bauprojekt frisch deployen.)

Ich werde deshalb das projekt nochmal umstruturieren. Dies geht dank Refactoring recht leicht. Trotzdem hoffe ich das ich das jetzt zum letzten mal mache.

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

Das Umstrukturieren schlug fehl. Ich bin wieder dort wo ich vorher war und werd dabei auch bleiben. Wiederverwendbarkeit ist für das Projekt nicht wichtig. Wichtiger ist Wartbarkeit (das war bei PBM2 eine echte Katastrophe!).

Ich hab aber noch ein schmankerl, das werde ich gleich im projektthread mal posten.

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

Die Stadionskizzen sowie das Konzept mit den Containern sieht schonmal interessant aus und sollte für abwechslungsreiche Settings sorgen. Und das Spiel ist ja auch nicht an ne reale Sportart gebunden, da könntest evtl. einige exotischere Dinge machen oder gar verschiedene Spielfeldarten. Muss ja nicht so extrem sein wie bei Mutant League Football, aber es muss ja nicht immer einfacher Rasen oder Sandplatz sein.

Arbeitest du eigentlich allein an dem Projekt, oder gibts nen externen Grafiker oder so?

_________________
www.SaschaWillems.de | GitHub | Twitter | GPU Datenbanken (Vulkan, GL, GLES)

Nein. Bin allein. Es gäbe da zwar noch jemanden den ich fragen könnte, aber der ist eher weniger ein Spieleprogrammierer. Und Grafiker ist erst recht keiner da.
Ich hab allerdings schon ne ziemlich Coole Idee für das Oberflächen-Design. Ich versuche etwas luftiges zu machen. Nich so brachial wie bei z.B. "Anstoss 4". Mein Design hab ich "NeoZen" genannt. Hoffentlich siehts auch so aus.

Das ding mit dem Spielfeld... das ist so verrückt daran hatte ich noch gar nicht gedacht. Ich glaube aber nicht, dass ich das einbauen kann. Ich will diesmal eine reale Spielberechnung einbauen (plane diese gerade) welche ähnlich funktioniert wie Klimamodelle. Das heißt ich berechne für verschiedene Teile des Spielfelds was da passiert (konkret nur für die wo Spieler stehen). Da wäre es natürlich blöd, wenn es unterschiedliche Spielfeldformen gäbe. Das würde auch die KI komplizieren welche den Spielern "Spielintelligenz" geben soll.
Außerdem sollte bei PBall der Ball den Boden nicht berühren (Siehe Regelwerk im Anhang der Bedienungsanleitung von PBM2). Somit ist der Untergrund fast egal.

Aber du hast recht wegen den verrückten Ideen. Ich sollte ruhig das ein oder andere Verrückte Detail einbauen. z.B. bei der gestaltung des Vereinsgeländes könnte man bestimmt was mit Gebäuden machen, oder bei den Tribünenbelegungen. Falls du (und die geneigten Leser) also lustige Ideen haben. Einfach reinschreiben.

Wenn ich an die Gestaltung der Inhalte Denke könnts mir gleich wieder vergehen. Die ganzen Gebäude gehören ja auch irgendwie gemodellt.... Naja... mal sehn was wird.

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