spieleprogrammierer.de - Forum und Wiki zur Spieleprogrammierung und Spieleentwicklung

Zitat von »shelley«

Kleine Frage am Rande: Macht es Sinn, das alles in Bibliotheken zu schreiben, auf die das Hauptprogramm zugreifen kann? Oder als .cpp-Dateien?

Letzteres natürlich. Eine Bibliothek stellt ein komplettes nutzbares Modul dar. Ein Item ist kein Modul, denn ein Item allein kann gar nichts.

Zitat von »shelley«

Könnt ihr mir vielleicht ein paar Tipps geben? Wie würdet ihr an die Sache rangehen?

Schritt für Schritt. Fang in der Liste, die Du beschrieben hast, unten an mit der ersten Klasse und bau die Punkte darüber danach dazu. Ein Item hängt von nichts ab. Ein Inventory hängt von Items ab (denn die müssen da ja rein). Ein Shop braucht eigentlich auch nur Items zu kennen. Dass die Items vom Shop in das Inventory kommen, das sollte noch jemand anderes übernehmen - irgendein Controller, der sich um die richtige Bedienung des Shops durch den User kümmert.

Du machst entsprechende Klassen für Item, Slot und Tasche

Item ist eine abstrakte Basisklasse mit virtuellen Funktionen, um z.B. die Art und Geldwert zu bekommen.
Alle anderen Items wie Pistole, Trank, Schwert oder so werden von Item abgeleitet. (am besten erstellst du noch die abstrakte Klasse 'Waffen', die weitere virtuelle Funktionen enthält, um Genauigkeit oder Schaden der jeweiligen zu erhalten).

Die Klasse Slot enthält ein Item (einen Zeiger oder Referenz auf dieses), man kann es durch ein anderes ersetzen oder den Slot leeren.

Die Tasche ist der Container, der alle Items enthält. Man kann Items hinzufügen oder wegnehmen. (Der Slot hält wie gesagt nur eine Referenz auf ein Item, das im Taschen-Objekt enthalten ist).

Wie du das ganze in Dateien auslagerst, ist dir überlassen. Du kannst z.B. alle Items in ein Modul stecken und die Tasche und Slot in ein eigenes.

Wofür soll die Klasse Slot gut sein, wenn sie nur eine Referenz hält?
Und wo siehst Du den Vorteil, wenn er einzelne Klassen in Module auslagert? Nur weil er das tun kann, heißt das nicht, dass er das auch sollte.

War ja nur ein Gedankengang . Mit Modul meinte ich eigentlich eine .hpp+.cpp

Ich würde es sinnvoller finden, wenn die Tasche mehrere Slots, einen "Geldcontainer", sowie die speziellen Körper-Slots hat, die man ja von der normalen Slot-Klasse ableiten und über Check-Funktionen auf bestimmte Items begrenzen kann.

Was tut das Inventory, wenn jemand versucht eine Waffe in es hinein zu tun und zwar in einen Helm-Slot? Es muss doch offenbar auch testen, ob das überhaupt möglich ist. Denn sonst sagt der Slot "geht nicht" und das Inventory tut daraufhin was?

Ableiten muss man da übrigens überhaupt nichts. Jedes Item hat eine Enum, die angibt in welchen Slot-Typ es passt (wahlweise als Flag implementiert) und das Inventory hat viele Slots, die je einen solchen Typ besitzen. Vererbung ist da absolut überflüssig und der Check kann ganz prima vom Inventory gemacht werden. Wofür man jetzt einen "speziellen Körper-Slot" brauchen sollte, ist mir da nicht ersichtlich.

Ganz einfach ausgedrückt: Benutze STL Lists.

Die sind ganz einfach zu nutzen.

Machen wir das ganze für das Inventar:

Struct Item
{
SpezItemID //Das Item
Item Anzahl //Anzahl
Item-Typ //Rüstung, Trank etc.
Preis
}

Klasse für das Inventar.
Members
item[] Rüstung | (soviele Plätze wie Slots dafür) Da das ganze statisch ist ([0] = helm etc.) brauchst du hier noch keine List.
List<struct item> Inventory | Du kannst Items hinzufügen und abziehen. Die Funktionen sind gegeben.
Int Money

Konstruktor für die Init-Items etc.

Funktion AddItem
Wenn Item Existiert:
Wenn Anzahl < MaxAnzahl:
Erhöhe Anzahl
Sonst:
Zu viele Items dieser ID
Sonst Wenn Item nicht Existiert:
Wenn List.Count < MaxSlots:
List.Add(Item)
Sonst:
Inventar Voll

Funktion SubItem
Wenn Item Existiert:
Wenn Anzahl > 0
Anzahl dec.
Sonst :
Lösche Item aus der Liste
Wenn Item nicht Existiert:
Item nicht da.

Funktion Rüste aus
Wenn ItemTyp keine Rüstung:
Fehler
Sonst:
Wenn Feld das Richtige für die Rüstung:
Wenn Feld in Rüstungsarray belegt:
Prüfe ob im Inventar an der Stelle Platz frei wird ( wenn z.B. 8 x Helm da war ist kein Platz, da dann noch 7 Helme da sind)
Wenn Platz:
Tausche Rüstung aus Rüstungsarray mit Rüstung aus Inventar
Wenn nicht:
Soll Rüstung aus Rüstungsarray weggeworfen werden?
Wenn ja:
Rüstung im Rüstungsarray = Rüstung im Inventar
Rüstung im Inventar Anzahl - 1
Sonst:
Kann nichts machen
Wenn nicht Belegt:
Rüstung im Rüstungsarray = Rüstung im Inventar
Rüstung im Inventar Anzahl - 1
Wenn Feld das Falsche:
Tue nichts.
Noch ein paar Funktionen für Usable Items, Geld inc, dec etc.

Die Klasse für Itemverkäufer hat Zugriff auch ein List mit den Items
Bei Interaktionen muss das Inventar des Spielers als Param übergeben werden.
Z.B. Kaufen:
Wird die Funktion AddItem aufgerufen, wenn sie ein Fehler zurückgibt, kann nicht gekauft werden,
Sonst wenn der Verkäufer das Item selber nicht besitzt, Fehler

Sonst wird ein Item aus der Verkäuferliste abgezogen, das Geld aus dem SpielerInventar und schon ists fertig.
Verkauf:
Rufe SubItem-Funktion auf, Prüfe auf Fehler, wenn kein Fehler: Zahle 45%
Wenn Item in der Item-List noch nicht existiert, füge hinzu, sonst ändere Anzahl.

Bums! Aus die maus!
Ist alles noch sehr Schemenhaft umschrieben und nicht alles abgedeckt.
z.B. Einfaches Ablegen der Rüstung
Hinzufügen von Geld, Abziehen von Geld
Das Suchen in der Liste nach nem Item ist auch ein Algorithmus.

Also so einfach ist das Inventar nicht (wenn man es richtig macht), wie man denkt.
Es kann noch sowas wie Haltbarkeit der Rüstung kommen,
Benutzen von Tränken, etc.
Was passiert, wenn ein Gegner klauen kann?

Zitat

Kleine Frage am Rande: Macht es Sinn, das alles in Bibliotheken zu schreiben, auf die das Hauptprogramm zugreifen kann? Oder als .cpp-Dateien?

Ich weiß nicht ob die Frage jetzt darauf abzielt, dass man später dann neue Items in Shop etc. hinzufügen kann ohne jetzt direkt alles neu kompilieren zu müssen. Falls es das aber ist:
Das kann man später dann mit bspw. LUA-Anbindungen machen, was aber fürs erste noch etwas zu fortgeschritten sein dürfte. Für den Anfang ist es vollkommen ausreichend es alles "hart-gecoded"(was ein Wort, hat da jemand was besseres?) in deinen C++-Dateien zu lassen.

@JustJim

ziemlich schwer deine Gedanken zu lesen, am besten mit Einrückungen oder gar im fiktiven Code arbeiten, ich lese mich da echt schwer