Für mein erstes Thema hier in diesem Forum habe ich mir gleich mal
etwas ausgedacht, womit ich mich in den letzten Tagen beschäftigt habe.
Gerade erst in der Planung eines Browsergames, überlege ich mir jetzt schon
wie ich später eine gute Übersicht behalte und der Weiterentwicklung nicht
im Wege stehe. Da ist mir natürlich die Meinung von anderen Entwicklern sehr wichtig
Ich würde gerne erfahren wie ihr euer Projekt aufgebaut habt oder für alle
die gerade dabei sind, wie ihr es aufbauen wollt
Mein Gedanke geht dahin, eine Art Framework für das Grundgerüst zu proggen und
durch "Plug-ins" das Spiel zu erweitern. Wäre das eine gute Möglichkeit? Würde gerne
von euch Vor- und Nachteile erfahren (muss dazu sagen das ich mein BG in Java programmieren will)
Habt ihr vielleicht andere Vorgehensweisen, die besser sind?
Schöne Ostergrüße
Sandal Tolk
Projektverwaltung (Architektur) - wie geht ihr vor?
gepostet vor 17 Jahre, 7 Monate von SandalTolk
gepostet vor 17 Jahre, 7 Monate von MrMaxx
Hallo auch ...
Erstmal ist dein Titel ein wenig verfänglich, geht es dir doch mehr um die Architektur.
Bei Projekten in der Grösse von den meisten Browsergames halte ich von solchen Mechanismen, wie du sie beschreibst sehr sehr wenig. Solch ein Aufwand lohnt sich erst ab einer bestimmten Grösse, vor allem weil deine Webanwendung von sichaus meist gut getrennt ist. Meist kann doch ein Surchschlag von HTML-Seite über Servlet zu SessionBean gemacht werden und am ende werden nur sehr wenige Entity Beans abgefragt.
Eigentlich lohnen sich die meisten Ansätze erst bei grösseren Projekten.
Mein Tip ist daher: einfach starten und darauf achten, das du halbwegs sauber programmierst (MVC etc...).
Ich nehme mal an, das du kein in Stein gemeisseltes Designdokument hast, das so gut ausgearbeitet ist, das es unverrückbar niemals wieder geändert werden muss.
Du wirst also garnicht drumherumkommen dein Projekt diveres Male zu refactorn. Das ist auch nicht schlimm, da du vermutlich sowieso allein an deinem Projekt sitzt.
Solange dein Team nur aus sehr wenigen Personen besteht bekommst du mit diesem Ansatz keine Probleme und sparst dir eine Menge Arbeit.
So long ...
Mr.Maxx
EDIT: Das mit den SessionBeans und Entity Beans würde bedeutet, das du die J2EE Palette durchweg benutzt. Ich hab noch keine Erfahrungen mit EJB3.0 sammeln können, kann also nur was zu 2.x sagen und dir 100% abraten.
Erstmal ist dein Titel ein wenig verfänglich, geht es dir doch mehr um die Architektur.
Bei Projekten in der Grösse von den meisten Browsergames halte ich von solchen Mechanismen, wie du sie beschreibst sehr sehr wenig. Solch ein Aufwand lohnt sich erst ab einer bestimmten Grösse, vor allem weil deine Webanwendung von sichaus meist gut getrennt ist. Meist kann doch ein Surchschlag von HTML-Seite über Servlet zu SessionBean gemacht werden und am ende werden nur sehr wenige Entity Beans abgefragt.
Eigentlich lohnen sich die meisten Ansätze erst bei grösseren Projekten.
Mein Tip ist daher: einfach starten und darauf achten, das du halbwegs sauber programmierst (MVC etc...).
Ich nehme mal an, das du kein in Stein gemeisseltes Designdokument hast, das so gut ausgearbeitet ist, das es unverrückbar niemals wieder geändert werden muss.
Du wirst also garnicht drumherumkommen dein Projekt diveres Male zu refactorn. Das ist auch nicht schlimm, da du vermutlich sowieso allein an deinem Projekt sitzt.
Solange dein Team nur aus sehr wenigen Personen besteht bekommst du mit diesem Ansatz keine Probleme und sparst dir eine Menge Arbeit.
So long ...
Mr.Maxx
EDIT: Das mit den SessionBeans und Entity Beans würde bedeutet, das du die J2EE Palette durchweg benutzt. Ich hab noch keine Erfahrungen mit EJB3.0 sammeln können, kann also nur was zu 2.x sagen und dir 100% abraten.
gepostet vor 17 Jahre, 7 Monate von riki1512
EDIT: Das mit den SessionBeans und Entity Beans würde bedeutet, das du die J2EE Palette durchweg benutzt. Ich hab noch keine Erfahrungen mit EJB3.0 sammeln können, kann also nur was zu 2.x sagen und dir 100% abraten.
Das würde ich unterschreiben. EJBs 2.x fand ich schrecklich. Eigentlich sollen sie ja die Arbeit auf Geschäftslogik beschränken, tatsächlich tust du aber alles andere als die Geschäftslogik entwickeln...liegts diesmal am xml, am Application Server, ist es doch ein Runtime-error usw. ? Sollte jetzt aber besser sein.
Nun, ein Framework für das Browsergame aber ist sicherlich kein Fehler. Ich selbst entwickle derzeit ein BG, wobei ich Klassen, die Aspekte mit hohem Wiederverwendungsbedarf behandeln, so abstrakt halte, dass am Ende quasi ein kleines Browsergame-Framework "übrig bleibt".
gepostet vor 17 Jahre, 7 Monate von SandalTolk
Hallo zusammen ^^
erst einmal danke für eure antworten.
Mein Projekt wird derzeit nur von mir geführt und gepflegt, erst wenn ich in der ersten Phase der Programmierung bin, werde ich schaun ob es notwendig ist mir Unterstützung ins Boot zu holen und meine Planung ist, wie du MrMaxx bereits erkannt hast, in der Anfangsphase.
Jeh mehr Arbeit ich mir am Anfang mache, desto besser wirds später hoffentlich laufen - so hoffe ich zumindest
Ich werde mich auf jeden Fall noch einmal hinsetzen und mir das ganze überlegen ob es sich wirklich für mein Projekt lohnt. Da heißt es abwarten und mich weiter in die Materie vertiefen
Vielleicht haben ja andere noch gute Ratschläge wie man so ein Projekt von der Architektur her aufbaut
erst einmal danke für eure antworten.
Mein Projekt wird derzeit nur von mir geführt und gepflegt, erst wenn ich in der ersten Phase der Programmierung bin, werde ich schaun ob es notwendig ist mir Unterstützung ins Boot zu holen und meine Planung ist, wie du MrMaxx bereits erkannt hast, in der Anfangsphase.
Jeh mehr Arbeit ich mir am Anfang mache, desto besser wirds später hoffentlich laufen - so hoffe ich zumindest
Ich werde mich auf jeden Fall noch einmal hinsetzen und mir das ganze überlegen ob es sich wirklich für mein Projekt lohnt. Da heißt es abwarten und mich weiter in die Materie vertiefen
Vielleicht haben ja andere noch gute Ratschläge wie man so ein Projekt von der Architektur her aufbaut
gepostet vor 17 Jahre, 7 Monate von friedenspanzer
Ich als quasi-Anfänger handhabe es ähnlich wie riki1512. Ich habe im Prinzip einfach drauf los programmiert, aber irgendwie darauf geachtet, dass der komplette Code möglichst hohe Wiederverwendbarkeit zeigt. Im Zuge der Entwicklung habe ich z.B. eine kleine Scriptsprache entwickelt, welche ich jetzt in leicht angepasster Form (lediglich die Namen der Funktionen wurden geändert) für ein anderes Projekt verwenden kann.
Das mit den Plug-Ins halte ich prinzipiell für eine relativ gute Idee, wenn du bereits Entwicklungserfahrung hast. Ansonsten würde ich dir davon abraten, denn irgendwann kommst du definitiv an den Punkt, an dem du einfach ALLES in die Tonne treten musst (dieser Punkt kam bei mir schon zweimal. Einmal habe ich versucht ohne OOP auszukommen, weil ich es nicht kannte [^^] und einmal habe ich bei meinem Datenmodell komplett ins Klo gegriffen - außerdem waren Controller, View und Model quasi eins, also wie MrMaxx schon gesagt hat immer schön an MVC halten).
Wo wir schon bei "in die Tonne treten" sind: Wenn du wiederverwertbar codest kannst du dir einige Wiederholarbeit sparen, wenn einige Fragmente deines Codes gar nicht mal so übel sind.
Das mit den Plug-Ins halte ich prinzipiell für eine relativ gute Idee, wenn du bereits Entwicklungserfahrung hast. Ansonsten würde ich dir davon abraten, denn irgendwann kommst du definitiv an den Punkt, an dem du einfach ALLES in die Tonne treten musst (dieser Punkt kam bei mir schon zweimal. Einmal habe ich versucht ohne OOP auszukommen, weil ich es nicht kannte [^^] und einmal habe ich bei meinem Datenmodell komplett ins Klo gegriffen - außerdem waren Controller, View und Model quasi eins, also wie MrMaxx schon gesagt hat immer schön an MVC halten).
Wo wir schon bei "in die Tonne treten" sind: Wenn du wiederverwertbar codest kannst du dir einige Wiederholarbeit sparen, wenn einige Fragmente deines Codes gar nicht mal so übel sind.
gepostet vor 17 Jahre, 7 Monate von RaydenDD
Mal abgesehen von der Art WIE du es aufbaust. Musst du erst mal wissen, wie es funktionieren soll. (In Hinblick auf Updates, Erweiterungen usw.).
Diesbezüglich habe ich zum Teil (nicht alles) sehr schlecht angefangen, sodas Umbauen sehr schmerzhaft werden konnte. Nach diversen schlechten Erfahrungen versuchte ich dann den Code so offen wie möglich zu gestalten ... was dann auf der anderen Seite wieder dazu geführt hat, das ich mich auf Situationen vorbereiten musste, die im normalen Spiel wahrscheinlich niemals auftreten werden.
Im Endeffekt habe ich dann beschlossen einen Mittelweg zu gehen ... etwas OOP, relativ viele Funktionen deren Parameter aber recht eindeutig sind. Zusammenfassen von themenähnlichen Funktionen in einer Klasse.
Alles schön objektorientiert zu machen ist sicher ne lustige Sache, aber man kanns auch übertreiben. Ich mache das Ganze Layout zB in JSP Seiten ... die werden dann zwar auch zu Servlets kompiliert .. lässt sich allerdings sicher schöner Coden als HTML/Javascript und Java in der selben Seite.
Wie gesagt, da das Ganze bei mir ein Hobby-Project ist halte ich es generell einfach in der Architektur (wenn auch teilweise etwas unbersichtlich), aber es ist größtenteils gut Modbar und Ausbaubar, wenn man sich ein bisschen mit dem Code beschäftigt.
Wenn ich Lust habe programmtechnischen Schnickschnak zu machen, dann mach ich das dann lieber in kleinen Teilbereichen im Spiel, die mir besonders Spaß machen .
Diesbezüglich habe ich zum Teil (nicht alles) sehr schlecht angefangen, sodas Umbauen sehr schmerzhaft werden konnte. Nach diversen schlechten Erfahrungen versuchte ich dann den Code so offen wie möglich zu gestalten ... was dann auf der anderen Seite wieder dazu geführt hat, das ich mich auf Situationen vorbereiten musste, die im normalen Spiel wahrscheinlich niemals auftreten werden.
Im Endeffekt habe ich dann beschlossen einen Mittelweg zu gehen ... etwas OOP, relativ viele Funktionen deren Parameter aber recht eindeutig sind. Zusammenfassen von themenähnlichen Funktionen in einer Klasse.
Alles schön objektorientiert zu machen ist sicher ne lustige Sache, aber man kanns auch übertreiben. Ich mache das Ganze Layout zB in JSP Seiten ... die werden dann zwar auch zu Servlets kompiliert .. lässt sich allerdings sicher schöner Coden als HTML/Javascript und Java in der selben Seite.
Wie gesagt, da das Ganze bei mir ein Hobby-Project ist halte ich es generell einfach in der Architektur (wenn auch teilweise etwas unbersichtlich), aber es ist größtenteils gut Modbar und Ausbaubar, wenn man sich ein bisschen mit dem Code beschäftigt.
Wenn ich Lust habe programmtechnischen Schnickschnak zu machen, dann mach ich das dann lieber in kleinen Teilbereichen im Spiel, die mir besonders Spaß machen .
gepostet vor 17 Jahre, 6 Monate von Agmemon
Original von SandalTolk
Mein Gedanke geht dahin, eine Art Framework für das Grundgerüst zu proggen und
durch "Plug-ins" das Spiel zu erweitern. Wäre das eine gute Möglichkeit? Würde gerne
von euch Vor- und Nachteile erfahren (muss dazu sagen das ich mein BG in Java programmieren will)
Ich vermute mal, dass Du PlugIn schreibst, aber was anderes meinst. PlugIns sind Erweiterungen einer Software, ohne den Code der Software anzupassen. Hierzu muss die Anwendung spezielle Schnittstellen zur Verfügung stellen. Das macht aber nur Sinn, wenn man anderen Entwicklern ermöglichen will, eine Anwendung zu erweitern, ohne Ihnen Zugriff auf den Code zu gewähren.
Das was Du brauchst, geht eher in Richtung Design Pattern. Da kommen eigentlich nur zwei Ansätze in Frage, wenn Du Dein Spiel sauber und erweiterbar entwickeln willst: Model-View-Controller Prinzip oder Komponenten basierend.
Beim MVC-Prinzip unterscheidest Du zwischen den Model-Klassen, als deinen Fachklassen und Entitäten, den Controller-Klassen, die die Geschäftslogik und die Kommunikation zwischen View und Modellen enthalten, und den Views, also der Benutzeroberfläche. Durch hinzufügen von neuen Klassen dieser drei Typen, kannst Du Deine Anwendung recht leicht und modular erweitern.