Inventar (Theorie)

[Circushund]

Hi,

Ich Bastel grad an einem Inventar und hab mir dabei mal ein paar grundlegende Fragen gestellt, da ich eine Klasse dafür erstellen möchte.

Dabei besteht ein Inventar für mich aus:
1) dem Inventar
2) den Slots
3) den Items

Nun hab ich mich (in einem Brainstorm) gefragt, was man alles mit Items machen kann?

a) man kann Item(s) dem Inventar hinzufügen (Add)
b) man kann Item(s) aus dem Inventar löschen (Delete)
c) man kann zwei Items miteinander verschmelzen(daraus entsteht ein neues Item (Fuse)
d) man kann die Positionen(Slots) der Items austauschen (Swap)
e) man kann Items gleichen Typs zusammenlegen(Collect)
f) man kann Items teilen (aufteilen) (Split)
g) man kann Items nach bestimmter Zeit verschwinden lassen! (Dissapear)

Beispiel:
c) Man hat zB. einen Angelhaken und einen Stock und bekommt daraus eine Angel.
e) man hat mehere Steine zusammengesammelt und möchte sie auf ein Slot zusammenlegen.
f) zB. eine brennende Kerze, die nach bestimmter Zeit erlischt.

Weiters kann man die Slots der Items nach mehreren Kriterien sortieren:
- nach gleichen Namen, Typ, Kathegorie
- nach ihrer Wichtigkeit?
- nach Anzahl der Items
usw..
Wobei das Sortieren des Inventars eher nicht so gang und gäbe ist (wenn überhaupt notwendig), da man es dem Spieler meist selbst überlässt.

Für das Inventar hab ich nun zwei Klasse angelegt namens:
Inventory
Items

In Inventory leg ich mir ein Array an (elements) was alle meine Objekte vom Typ "Items" hält.
Weiteres sind darin auch die Methoden "Add", "Delete" usw.
In der Klasse "Items" halte ich die Eigenschaften des Items, also Name, Anzahl usw..

Was denkt ihr davon? Gibt es evtl noch andere Sachen, die man mit Items in einem Inventory machen kann, die ich vergessen hab?
Im Laufe des weiterbauens des Games kommen einem ja meistens immer neue Ideen, was man mit Items so machen kann, weshalb ich das vorab schon klären will.

Falls Interesse besteht, kann ich die Klasse auch posten, wollte mir aber primär erstmal Gedanken manchen, wie ein Inventar ausschaut.

[rendner[i]]

Was deine Items können und nicht können musst du dir vorher schon grob überlegen, da kann dir sicher keiner richtig helfen ohne zu wissen wie dynamisch dein System sein soll.

Aber wo hast du denn derzeit die Klasse Slot, oder nutzt du keine?
Würde nämlich statt einem normalem Item Array doch lieber ein Slot Array nehmen.
Somit kannst du später abfragen wieviel freie Slots noch verfügbar sind.

[Circushund]

da kann dir sicher keiner richtig helfen ohne zu wissen wie dynamisch dein System sein soll.

..wär schon gut, wenns möglichst dynamisch wäre

Ich hab eine Test-FLA mit den zwei Klassen mal hochgeladen zum ausprobieren.
www.dwienand.de/Expo/InventarTest.zip
(Link wird in spätestens 1. Monat gelöscht)

[Omega Psi]

Ich würde eine Menge Service-Methoden implementieren:

interface IInventory {
    function addItem(item:Item):Void;
    function addItemAt(item:Item, index:Number);
    function collect():Void;
    function disapear(item:Item):Void;
    function deleteItem(item:Item):Void;
    function deleteItemAt(index:Number):Void;
    function fuseItems(item1:Item, item2:Item):Void;
    function getItemAt(index:Number);
    function getItemsByType(type:Sting):Array;
    function getItems():Array;
    function getNumberOfItems():Number;
    function hasItems():Boolean;
    function hasFreeSlots():Boolean;
    function sortByName():Void;
    function sortByType():Void;
    function swap(item1:Item, item2:Item):Void;
    function split():Inventory;
    function toString():String;
} 

[Omega Psi]

Hm, auch auf die Gefahr hin, dass ich mich gerade unbeliebt mache, aber du testest nicht gerade effizient. Ich würde das alles erstmal über die Textausgabe testen.

Die Klassen kannst du dann als Member oder via Verlinkung mit grafischen Objekten in Beziehung setzen.

[Circushund]

hi omega,

Hm, auch auf die Gefahr hin, dass ich mich gerade unbeliebt mache, aber du testest nicht gerade effizient. Ich würde das alles erstmal über die Textausgabe testen.

Wie meinst du das, über Textausgabe? Die Klasse bzw. deren Funnktionen teste ich immer über trace-Ausgaben. Da brauch ich keine grafischen Sachen. Ich hab nur die .FLA dazugebaut, weil ich es auch mal in Aktion sehen wollte.

Und wie als Member? Man kann ja unter "Verlinkung" einen Klasse "für die Gemeinsame Nutzung zur Laufzeit" angeben, meinst du das?

[Omega Psi]

Sorry, ich hab da in deinem Code einiges durcheinander gebracht. Trotzdem werde ich aus deinem Code nicht ganz schlau. Wieso kennt ein Item seinen Slot? Und wieso wird count unabhängig vom Slot gesetzt?

Das ganze ist schon unglücklich gelöst, weil du Abhängigkeite erzeugst, die nicht richti sind. Was ist wenn du einen Slots setzt, aber den Index des Slots falsch. Hinzukommt, dass sich Items nicht untereinander organisieren. Dafür ist das Inventar da.

Ich hab mal ein kleines Beispiel gemacht, was etwas mehr Sinn macht.

[Circushund]

hi omega,

Wieso kennt ein Item seinen Slot? Und wieso wird count unabhängig vom Slot gesetzt?

Stimmt, das sind Fragen die man sich stellen kann! Count muss natürlich unmittelbare bzgl. der Anzahl der Elemente sein.
Und stimmt, das mit den unnötigen Abhänigkeiten ist meist mein Grösstes Problem, wo ich am meisten zu knacken hab .

Allerdings hast du in deiner Klasse noch nicht die grundlegenden Operationen (bis auf adden!) integriert.

Ich hab nochmal eine Grafik gemacht, welche primären "Operationen" (sag ich jetzt mal so in meinem Leien-Programmierdeutsch ) man auf ein Inventar anwenden könnte.

[Omega Psi]

Naja, ich könnte natürlich auch alle anderen Funktionen implementieren, aber ich habe halt nur ein Beispiel gemacht, dass folgendes demonstrieren sollte: Wie stelle ich Abhängigkeiten zwischen zwei Klassen sinnvoll her. Die zu implementierenden Methoden sind auch nicht großartig schwer zu implementieren, da es nur Array-Operationen sind.

Du brauchst aber bei den Items noch andere Funktionen, vor allen Dingen wenn es um die fuse():Void geht. Da musst du dir mal klar machen, was fusioniert werden soll.

Die Abhängigkeiten kannst du so klären: Die Inventory und Item Klassen kannt du so übernehmen. Diese kapselst du jeweils in eine MovieClip-Klasse:

class screen.Inventory extends MovieClip {
    private var inventory:data.Inventory;
    public function Inventory() {
        super();
        this.inventory = new Inventory();
    }
    public function addItem(item:data.Item):Void {
        this.inventory.addItem(item);
    }
} 

class screen.Item extends MovieClip {
    private var item:data.Item;
    public function Item() {
        super();
        this.item = new data.Item();
    }
    public function getItem():data.Item {
        return this.item;
    }
    public function getName():String {
        return this.item.getName();
    }
    public function getType():String {
        return this.item.getType();
    }
    public function setName(name:String):Void {
        this.item.setName(name);
    }
    public function setType(type:String):Void {
        this.item.setType(type);
    }
    public function toString():String {
        return this.item.toString();
    }
} 

Der Grund, warum ich das so mache ist, dass ich so Logik und darstellung von einander trenne. So kannst du deinen Funktionalitäten unabhängig von der Darstellung implementieren und testen. Das ganze ist sehr MVC.

[Circushund]

Hi omega,

Diese kapselst du jeweils in eine MovieClip-Klasse:

..wie meinst du das?

Und wozu nimmst du "screen"<Punkt>"Inventory" und "data"<Punkt>"Inventory" bzw. "data"<punkt>"Item"?

Ich weiss eigetlich auch nicht, wozu ich eigentlich die MC-Klasse "extenden" sollte?


Auch müsste ich das Ganze dann auch auf mein Inventory irgendwie übertragen, dh. das Ganze Drag-Drop fähig machen. Da müsste man dann wohl auch viel mit Indexes arbeiten?

[Omega Psi]

Ich lege zwei packages an: screen und data. In dem Paket screen verwalte ich alle Klassen, die eine optische Representation der Daten realisieren (daher auch das Erben von MovieClip). Paket data verwalte ich das Datenmodell das ich durch Komposition einbinde. Vorteil: ich kann meine Spiele Engine unabhängig der Darstellung programmieren und was noch viel wichtiger ist, in den elementaren Funktionalitäten auch in anderen Spielen wiederverwenden oder unabhängig vom Spiel selbst weiterentwickeln.

Du muss auch mit gar keinen Indizes arbeiten, weil du mit den referenzen auf Items arbeitest. Diese werden in ein Array übertragen und mit den entprechenden Funktionen der inventory Klasse sortierst du die Items, suchst dir das richtige Item aus usw.

Thema Komposition vs Vererbung möchte ich in diesem Thread aber nicht diskutieren. Ich trenne gerne zwischen Darstellung und Datenmodell und arbeite mit grafischen Primitiven (MovieClips) lieber direkt und baue dadurch lieber meine Klassenbibleothek auf.

[Circushund]

hi omega,
ok, du gehst wohl wohl ziemlich streng nach dem MVC (Model-View-Contoler)-Paradigma oder? Was ja eigentlich auch eine gute Sache ist, doch ich kenne mich da noch nicht so aus? Die Trennung von Visuellen und der Data-Komponente ist natürlich eine gute Sache nur ich weiss eben nicht wie ich das umsetzen kann?
Also wie sähe das Praktisch aus? Ich mach mir zwei Ordner, nenn den einen Screen, den Anderen Date und pack da meine .as's rein?
In den Screen Ordner kommt die "Inventory" und in den "Data"-Ordner die "Item.as"?

[Omega Psi]

Praktisch sähe eine Umstzung in der verzeichnisstruktur so aus:

Applikation.fla
classes/data/Inventory.as
classes/data/Item.as
classes/screen/Inventory.as
classes/screen/Item.as
tests/InventoryTest.fla
tests/ItemTest.fla

Du könntest auch alles in eine Klasse packen, doch ich persönlich trenne gerne die Datenhaltung von der Datenvisualisierung.

[[je]]

Ich würde die Klassen auch namentlich trennen. Also lieber classes/screen/InventoryView.as
(Macht es einfacher zu navigieren finde ich)

[Omega Psi]

Kann man machen, mir persönlichen reichen die Pakete um zu navigieren.