Klassen Umsetzungsfrage zu Spiel "Zuul"

[Ion]

Hallo,

ich würde gerne, einfach aus Spaß mal das Spiel "Zuul" programmieren.
Es handelt sich dabei um raumbasiertes Textspiel, sprich vom Prinzip her eigentlich nur Konsolenorientiert. Ich wollte dabei noch ein paar Kleinigkeiten wie verschlossene Räume, Gegenstände(Items) hinzufügen.

Ich bin zwar kein blutiger Anfänger mehr in Sachen Programmierung aber mit der OOP komme ich leider immer noch nicht ganz klar. Wann brauche ich wirklich eine Klasse und wann nicht?

Nun zum konkreten Problem:
Ich habe bei mir an die folgenden Klasse gedacht:
Spiel: Initialisiert das Spiel. Erstellt die Räume, Items etc.
Spieler: Stellt den Spieler mit seinen Informationen dar: Name, wo er sich befindet etc.
Eingabe: Liest die Eingaben und vielleicht noch Hilfe etc.
Raum: Informationen zum aktuellen Raum, Nachbarräume, Items usw.
Item: Informationen zum Item.

Ja, dabei stellen sich mir aber folgende Fragen:

Brauche ich, wenn ich auch verschlossene Räume haben will eine Klasse Tür oder kann man das zum Raum hinzufügen, wobei es ja auch nicht verschlossene Räume geben soll oder vielleicht Türen, die man mit einer Axt zerschlagen kann.

Jetzt habe ich ja die Klasse Item aber wie kann ich dann mehrere Items verwalten, beispielsweise soll der Spieler ja vielleicht eine Schlüssel für einen Raum haben. Ich habe dann gedacht, das man vielleicht eine Hashmap in der Klasse Spieler erstellt oder brauche ich dann noch eine Klasse Items?

Es soll ja auch Befehle geben. Man soll ja in den nächstem Raum gehen können durch eine Eingabe wie: Tür links oder so, brauche ich dann eine Klasse Befehle oder gehört das in die Klasse Spiel?

Reicht das so von der Klassenaufteilung her oder bräuchte ich noch zusätzliche Klassen und wenn ja, warum?

Ich habe auch mal nach einer Lösung gesucht und da das hier gefunden, allerdings ohne meine Ideen, wie eine Tür oder Items.

https://github.com/hrichter/zuul/tr...system/src/de/uni_hamburg/informatik/sep/zuul
Auch wenn ich jetzt nicht unbedingt auf die Lösung dort konzentrieren will verstehe ich nicht, warum er / sie eine Klasse Befehl und eine Klasse Befehlswoerter hat. Würde da nicht nur eine Klasse Befehl reichen?

Danke schon einmal im voraus an alle Antwortenden.

 

[Saheeda]

Hallo Ion,

viele deiner Fragen lassen sich mit "kommt aufs Konzept an" beantworten.

Deine Idee sieht aber schonmal gut aus.

Ich würde nur keine eigene Klasse "Eingabe" bauen, meines Erachtens ließe sich das auch in der Klasse Spiel realisieren, sofern die Eingaben nur aus "links", "rechts", "ja", "nein" bestehen. (als Methode gamehandling o.ä.). Wenn da allerdings noch ein Parser hinzukommt, lohnt sich wiederum eine eigene Klasse.

Wenn die Tür nur die beiden Eigenschaften "offen" und "zu" hat, würde ein boolscher Wert ausreichen, bei so Besonderheiten wie mit der Axt würde es sich hingegen anbieten, eine abstrakte Klasse Tür zu bauen und davon z.B. OrdinaryDoor und SmashableDoor oder so abzuleiten.

Du kannst mehrere Items in einer Liste, Hashmap, Array oder dergleichen verwalten. Eine eigene Items-Klasse ist nicht notwendig.

Bei den Befehlen würde ich wieder schauen, wie umfangreich die werden sollen. Wenn in einem Befehl nur die Info "links" steht, wäre mir die Objekterzeugung im Vergleich zur Verwaltung eines simplen Strings zu doof.

Die Klasse Befehlswoerter aus deinem Beispiel halte ich für keine gute Idee. Er/sie benutzt diese Klasse, um eingegebene Befehle zu validieren. Dazu würde sich beispielsweise ein Enum "Befehl" eher anbieten.

enum Befehl{
	Geradeaus,
	Links,
	Rechts	
}

class KonkreterBefehl{
	Befehl befehl;
	
	public KonkreterBefehl(){
		this.befehl = Befehl.Geradeaus;
	}	
}

 

[Ion]

Das mit dem kommt auf's Konzept an dachte ich mir schon, Mmm ...

Das mit den Befehlen kann ja auch noch beliebig steigen, je nachdem was ich da noch hinzufüge aber bis jetzt würde es nur die Befehle gehe: rechts, links, oben und unten geben und item: xyz nehmen, fallen lassen und vielleicht noch ne Auflistung der Befehle.
Bei einem Parser handelt es sich doch um eine Klasse, die die Eingaben verwaltet und wenn nötig auch ändert oder? Also ungültige Zeichen etc. entfernen usw? Ich denke nicht, das ich sowas einbauen werde. Wenn eine ungültige Eingabe dabei ist kann man diese ja auch einfach ignorieren, ansonsten wäre das ja sowas wie meine gedachte Klasse Eingabe?

Zu der Tür:
Ja, das dachte ich mir ja auch, also das man dann bei der Klasse Raum halt noch eine boolesche Variable verschlossen hinzufügt aber wenn es mehr als ein paar Attribute / Variablen werden, dann bräuchte ich eine Klasse, richtig?
Ein Raum muss ja auch nicht unbedingt eine Tür haben.

Zu den Items:
Das würde dann aber zu dem Spieler gehören oder? Also eine Hashmap items zu der Klasse Spieler hinzufügen?

Zu den Befehlen:
Wäre das dann nicht eher was für den Parser? Hörte sich für mich eigentlich auch eher unnötig an.

 

[Saheeda]

Jein. Ein Parser macht ein bisschen mehr. Wenn du z.B. eine Eingabe hast "Benutze Schlüssel mit Tür", liegt die erstmal als ein großer String vor.
Ein Parser zerlegt ihn dir in seine Bestandteile (und löscht je nach Implementierung auch gleich Sonderzeichen etc. mit raus), sodass du am Ende die Begriffe "Tür" und "Schlüssel" rausfiltern kannst und weißt, was der User eigentlich vorhat.
Sowas zu bauen ist nicht allzu schwer und eine gute Übung. "Kompliziertere" Parser arbeiten dann auch mit Regulären Ausdrücken (Regex).


Zur Tür:
Jap.
Aber überlege dir, wie du eine nicht vorhandene Tür implementierst. Eine Klasse DoorlessRoom? Eine private Variable Door, die bei türlosen Räumen gleich null gesetzt wird?
Bei ersterem brauchst du denke ich eine instanceof-Abfrage in einer enterRoom()-Methode, bei zweiterem musst du z.B. in einer openDoor()-Methode eine null-Prüfung einbauen.

Zu den Items:
Jap.

Zu den Befehlen:
Jap.
Sowas kann im Parser mit eingebaut werden.
Ob dus brauchst oder nicht, musst du selbst entscheiden.