Inventar Systeme

Ich überlege gerade, wie Spiele wie Diablo 3 wohl das Inventar implementiert haben. Meine erste Idee war so etwas wie

struct inventory_slot
{
  item* i;
};

Eventuell noch mit einem "stack" Zähler. Aber wie geht es jetzt weiter? Die erste Frage ist, wie sieht die item Klasse aus? Ich tendiere zu einer virtuellen Methode use() und vielleicht noch draw_description(). Allerdings müsste man jetzt ja wissen, wann man das Item nach dem "Benutzen" löschen soll, und wann nicht. Eventuell übergibt man der use Methode gleich genug, um das selbst zu regeln. Wobei das schon fast wieder komisch wirkt. Und draw()? Scheint mir auch unschön, sollte man das nicht trennen? Aber von außen zeichnen geht ja nicht, weil der genaue Typ garnicht bekannt ist. Und das größte Problem: Wenn man das ganze so machen will, dass ein Item mehrere Slots besetzen kann (wie bei Diablo eben), funktioniert das System so eigentlich überhaupt nicht mehr. Irgendwelche Ideen?

Mechanics

Was willst du jetzt hören? Ich vermute mal, das Inventar ist eine der einfachsten Komponenten des Spiels überhaupt. Wie das konkret gelöst ist, wird dir niemand sagen könnnen, kommt auf deren Architektur an. Da gibts sicher hunderte Möglichkeiten. Ich finde deine konkreten Überlegungen recht sinnlos. Außer es interessiert dich wirklich, die Architektur einer möglichen Inventarverwaltung zu entwerfen. Dann musst du dich halt hinsetzen und das ganze durchdenken. Wenn dir was nicht gefällt oder nicht klar ist, überleg weiter. Wenn du erstmal ein insgesamt schlüssiges Konzept hast, dann ist es ja schon mal gut. Ob mans noch optimieren kann ist eine andere Frage, das kann man fast immer. Aber so spontan so konkrete Fragen zu stellen macht keinen Sinn.

Ich will nicht wissen wie genau die das in Diablo 3 gemacht haben, ich schrieb ja auch "Spiele _wie_ Diablo 3". Und seit wann kann eine Frage zu konkret sein.. hä.. also irgendwie verwirrt ihr mich. Man darf keine allgemeinen Fragen stellen, jetzt auch keine konkreten mehr.. was denn nun? Also letztlich hat wohl niemand eine Antwort darauf, wie man sowas machen könnte, obwohl das ja ziemlich leicht ist. Äh.. was?

Mechanics schrieb:

Was willst du jetzt hören?

Irgendeine Idee, wie man soetwas implementieren könnte. Am besten noch eine Gute. Ob das jetzt auf meinen Gedanken aufbaut oder was völlig anderes ist, ist mir egal.

Mechanics

lüffl schrieb:

Man darf keine allgemeinen Fragen stellen, jetzt auch keine konkreten mehr..

Richtig Deine Frage ist zu konkret, weil du nur ganz konkrete Teilaspekte eines unbekannten Systems herausgreifst und irgendwas dazu fragst. Da man das Gesamtsystem nicht kennt, macht die Beantwortung der konkreten Fragen (draw_description oder deine inventory_slot Klasse) keinen Sinn.
Du willst also einen Gesamtentwurf. Deswegen habe ich ja vorgeschlagen, dass du den selber machst und komplett durchdenkst. Die Alternative wäre, dass es jemand für dich macht. Entweder hat sich schon jemand hier Gedanken dazu gemacht und so einen Entwurf erstellt, oder es wird dir niemand die Frage direkt beantworten können. Ich kann mir durchaus vorstellen, dass sich paar Leute hier schon Gedanken dazu gemacht haben, aber bisher hat ja keiner geantwortet.
Um vielleicht paar deiner konkreten Fragen zu beantworten. Ja, Darstellung und Logik sollte man auf jeden Fall trennen. Wie man das macht ist widerum eine andere Frage. Die Item Klasse könnte z.B. die benötigten Informationen in Form von passiven Daten zur Verfügung stellen, z.B. Preview Image als Bitmap, oder description als Text. Dann gibt es eine Renderer Klasse, die das darstellt.
Eine virtuelle use Funktion ist auch nicht verkehrt. Dann könnte das Item z.B. Events haben, und ein möglicher Event wäre z.B. dass das Item aufgebraucht wurde und somit aus dem Inventar verschwindet, weil sich das Inventar mit den Events der Items verbindet.
Wieviel Slots ein Item braucht könnte man auch als Eigenschaft des Items zur Verfügung stellen. z.B. Anzahl der Slots und Layout. Oder man trennt es wiederum und zu jedem Item gibt es noch ein zusätzliches Objekt, dass die für die Darstellung benötigten Informationen bereitstellt.
Kann man alles sicherlich auch anders/besser machen, hab das nur ganz spontan hingeschrieben, müsste man sich alles im Detail überlegen. Aber es wäre am besten für dich, wenn du die Überlegungen selber anstellst. Wenn du dann ein Konzept hast, kannst es ja wieder hier präsentieren und die anderen werden dir sagen, was sie davon halten.

Was meinst du mit Gesamtsystem? Es gibt Schwerter (1x3), Rüstung (2x3), Tränke (1x1). Und nen Inventar mit 20x20 Plätzen. Neue Typen sollen natürlich leicht einzufügen sein. Ich dachte sowas ist irgendwie weitgehend bekannt?

Du kannst ein 20x20 Bitarray benutzen, mit true = belegt und false = frei oder so. Dann wird das Bitarray bei jedem Hinzufügen und Entfernen entsprechend aktualisiert. Entfernen ist einfach, zum Hinzufügen kannst du bruteforcen, bei 20x20 Feldern passt das schon.
Die Items haben dann als Membervariable die Position, Größe, Textur/Bitmap, Erklärungstext, Mouseovertext und sonstigen Kram. Darauf aufbauend kann man dann Funktionen success = inventory->add(item), void inventory->remove(item), void inventory->sort(), item = inventory->getItem(position), void inventory->draw() usw. implementieren.

Mechanics

lüffl schrieb:

Was meinst du mit Gesamtsystem? Es gibt Schwerter (1x3), Rüstung (2x3), Tränke (1x1). Und nen Inventar mit 20x20 Plätzen. Neue Typen sollen natürlich leicht einzufügen sein. Ich dachte sowas ist irgendwie weitgehend bekannt?

Das ist uninteressant. Du denkst nicht global genug. Interessanter ist die Gesamtarchitektur des Spiels. Auch das Inventar muss da reinpassen. Oder du modellierst das Inventar ohne das Gesamtspiel, machst dir aber trotzdem Gedanken darüber ob es sinnvoll ist und zu einer sinnvollen Architektur passen würde.
Warum sollte sowas bekannt sein? Das ist ein sehr spezielles Problem. Was aber "bekannt" ist, ist Software Engineering und Software Architektur. Das sind völlig abstrakte Disziplinen, die es aber durch den hohen Abstraktionsgrad erlauben, für fast jedes Problem sinnvolle Lösungen zu finden. Von dem her wird er auch jeder, der etwas von Software Architektur versteht auch so ein Inventar modellieren können, das ist nichts besonderes.
Dafür muss man sich aber Zeit nehmen und über ein Gesamtkonzept nachdenken. Dabei werden durchaus noch viele Fragen aufkommmen, die man beantworten muss und dann ein Konzept aufsetzen, dass alles unter einem Hut vereint. Wenn man dann anfängt zu programmieren, werden natürlich noch weitere Probleme aufkommen und man wird Hacks und Workarounds benötigen, das gehört leider dazu. Aber je besser ein Konzept am Anfang ist, desto weniger Probleme wird man später bei der Umsetzung/Wartung haben.
Du bist jetzt z.B. auf die Frage gekommen, wie man das macht, dass ein Item nach dem Aufruf einer use Funktion aus dem Inventar verschwindet. Das ist aber bei weitem nicht alles. Wahrscheinlich würde man auf hunderte solcher Fragen kommen, wenn man sich intensiv mit dem Thema beschäftigt. Und wenn man sie alle erfasst hat (Requirements Engineering), kann man auch über eine konkrete Umsetzung nachdenken.

Mechanics

lüffl schrieb:

Allerdings müsste man jetzt ja wissen, wann man das Item nach dem "Benutzen" löschen soll, und wann nicht.

Um etwas zu verdeutlichen, was ich meine...
Du hast ja eine wichtige Frage gestellt, die sicher Einfluß auf die Modellierung des Inventars hat. Aber das ist nicht alles.
Ganz spontan paar andere Fragen, die mir in den Sinn kommen würden. Wenn du einen Heiltrank benutzt, wie kommt die Heiltrankklasse an die Spielerklasse und wie erhöht sie seine Gesundheit? Wenn du einen Trank mit begrenzter Wirkzeit trinkst, wie und wo wird ein Timer initialisiert, und wie wird das visualisiert und wie kommt man wieder an die Spielerklasse? Was ist mit kombinierbaren Items, z.B. Runen? Wie gesagt, man könnte sicher hunderte solcher Fragen finden. Jede dieser Fragen beeinflußt die Lösung des Problems. Daher ist eine einzige, aus dem Kontext gerissene Frage sinnlos. Die kann man nicht sinnvoll beantworten, ohne das Gesamtsystem ("Anforderungsraum") zu kennen und zu verstehen.

hustbaer

Du fragst hier, wie die Implementierungs-Details deines Inventory-Systems aussehen sollen.
Wie soll man die Frage beantworten, wenn man den Rest deines Systems nicht kennt?
Bzw. wenn man nichtmal weiss was das System alles können soll/muss.

Das kann nicht gehen.

Mach dir erstmal ein Game-Design, wo festgelegt wird was das System das du dann bauen wirst alles können muss.

Dann würde ich erstmal damit anfangen ein Datenmodell zu definieren. Also was gibt es für Entities, welche Werte haben diese Entities, was für Beziehungen gibt es etc.
Dann die nötigen "Funktionen" die es geben wird, welche Daten diese benötigen, und welche Veränderungen sie an deinen Entities vornehmen werden. Alles noch "high-level", also einfach nen beschreibenden Text - NICHT C++ Code.

Wenn du das hast, kannst du anfangen Code zu schreiben - ein System aufzubauen das das kann was dein Spiel braucht.