RPG Klassen konstrukt

Hallo leute,

Ich wollte mal mit euch mal Diskutieren welche Klassen zu einem RPG gehören und wie die von einander abhängen.

Bis jetzt habe ich alle möglichen funktionen und paar klassen zu testzwecken generiert, nun möchte ich die Funktionen in Klassen kapseln und das Ganze vernüftig realisieren.

Das sind so meine überlegungen:

Zunächst habe ich die Klasse World, das soll die Hauptklasse sein, die über Ajax Request aufgerufen werden soll.

Die Klasse world hat folgende Eigenschaften:

Map,Characters,Objects,Enemys,NPCs,Towns

Die Klasse hat Methoden wie displayWorld(), diese Methode soll mir einen JSON Object an mein Document schicken mit anzuzeigenden Maptiles, Spielfiguren,die sich auf dem Selben feld befinden wie meine Figur , Objekte(zb Schatztruhe) , Gegner(irgendwelche Monster) , NPCs und Städte.

Davor wird in der World klasse geprüft ob der Client auch seine Figur ausgewählt hat usw usw..

Das wären so die Grundgedanken für meine World Klasse.

Als nächstes wäre die Map Klasse.

Diese Klasse lädt eine Karten Datei und weis dadurch an welcher X/Y Koordinate sich welcher Tile befindet und weis auch ob ein Tile begehbar ist oder nicht.

Die Klasse Map sollte die Methode setDisplaySize($displayWidth,$displayHeight) besitzen. Anhand der aktuellen x/y position, meines Spielers und der Anzeigegröße, weis ich welche Tiles angezeigt werden sollten.

Zusätzlich wird diese Klasse die Methode getMapTiles() haben um die Tiles an die Klasse world zu übermitteln.

Dann wären 2 Weitere Klassen Player und Character.

Der Player kann sich in Account einloggen, kann sich einen Char erstellen, kann ein Char löschen und kann ihn Auswählen um mit ihm zu spielen.

Der Character hat eigenschaften wie HP,MP,Level usw und kann sich auf der karte bewegen, Enemys angreifen (aufruf der Battle klasse), Items einsammeln, Mit NPC reden(aufruf NPCDialog klasse). Sterben(Denke diese Methode gehört zu Battle klasse, da ich im Kampf sterben kann und nicht auf der Map)?

Das ist vorerst mein Meilenstein.

Ihr kennt euch sicherlich besser aus mit Klassen konstukten wie die Beziehungen zwichen den Klassen aufgebaut werden soll sprich wo könnte man da Interfaces benutzen, Abstrakte klassen, Singletons ,Vererbungen und halt sachen die ich überdenken sollte..

Vllt könnt ihr mir bei der Plannung enorm weiterhlefen;)

LG BlackScorp

Erstmal vermischst du da einiges.

Als erstes wilslt du ein reines Datenmodell (DomainModel/Objektmodel...) erstellen. In diesem bildest du die Reinen Daten und ihre Biziehungen untereinander ab...ohne jegliche Funktionalität!!!!...die hat dort nichts zu suchen.

Hilfreich zum Modellieren ist es hierbei auf UML-Klassendiagramme zurückzugreifen. mit diesem sehr visuellen Modell können andere sehr einfach verstehen, wie deine Datenbasis aussieht. Desweiteren wird das Datenmodell deiner Anwendung häufig (nicht immer) 1:1 in einer Datenbank abgebildet.

Willst du aus Teilen deines Datenmodells z.B. JSON rendern, dann machst du dieses mit Mappern. Diese werden jedoch nicht auf Klassen des Datenmodells selbst implementiert, sondern in seperaten Klassen. Sie erwarten jeweils eine Klasse deines Datenmodells und geben die irgendetwas anderes zurück (XML, JSON, wasauchimmer).

Das ganze fällt dann unter "Seperation of Concerns"...du willst die logischen Aufgabenbereich deiner Anwendung gut voneinander abtrennen.

Was du weiterhin beschreibst sind die einzelnen Anwendungsfälle deiner Anwendung. Auch hier beitet sich an diese einmal strukturiert aufzuschreiben, und zwar so, wie du sie dem User präsentieren willst. Welche Möglichkeiten hat dein Benutzer mit deiner Anwendung zu interagieren, welche Benutzergruppen existieren überhaupt und wie unterscheiden sich die Funktionalitäten, auf die sie zugreifen können. Mal wieder ein Fall für UML-Anwendungsfalldiagramme damit eventuel landere das auch schnell überblicken können.

Ohne auf deine Präsentationsschicht eingehen zu wollen ist es meist so, dass in deiner Serviceschicht (Drei-Schichtenmodell) jeder Anwendungsfall zu genau einer Methode zuzuordnen ist...udn in den meisten Fällen macht deine Serviceschicht einfach nur das folgende: Daten laden per SQL, Daten transformieren per Mapper, Resultat an die Präsentationsschicht zurückgeben. Hier werden wieder einige (zu recht) aufschreien, weil diese Mapper geben nicht oben angesprochenes JSON zurück (damit würde ich meine Serviceschicht an eine ViewTechnologie binden, was man meistens eigentlich nicht will) sondern Sichten auf das Datenmodell.

So long...

Maxx

man.. ich dachte als hobby entwickler brauche ich sowas nicht... na gut dann werde ich mal modelieren.. thx erstmal, ich melde mich noch:D

Brauchen tust du es nicht, aber es spart Zeit und Arbeit. Wenn etwas modellierst kannst es in paar Sekunden umbauen rumschieben umbenennen usw. und hast jederzeit alles im Blick. Wenn gleich mit Quellcode anfängst hast viel mehr Schreibarbeit außenrum, hast alles in verschiedenen Dateien und nicht auf einem Blick, sobald Funktionalitäten usw. drin sind lässt es sich viel schwerer umbauen.

Also erstmal modellieren, Anwendungsfälle durchgehen und wenn alles passt dann anfangen zu entwickeln. Das ist zumindest der Weg den ich in meinen Hobbyprojekten gehe, ich wünschte in der Firma wäre die Zeit für sowas auch da, aber in Firmen wird ja gern mehr Zeit in Bugfixing danach gesteckt als in Planung davor...

Du musst es nicht in aller Tiefe machen, aber als Gedankenstütze in 6 Monaten hilft dir was grafisches auf jeden Fall.

Üblicherweise fängt man mit den Anforderungen an. Diese Analysiert man und findet dabei Kandidaten für Klassen und Funktionen.

Also: Zuerst das _was_, dann das _wie_.