deleted_57735
Guest
Unser Ziel ist auch nicht, alles so zu modellieren, dass man nen "zweites D2" draus machen kann. Wir wollen nur eine einigermaßen komfortable Möglichkeit geben, Überblick über seine Items zu bekommen und sich daraus on the fly einen Shop zu generieren.Ihr habt nicht die Spielgegenstände modelliert. Eure Verwaltung verwaltet im großen und ganzen nur eine Klasse von Objekten und das ist die Nutzereingabe. Nutzer geben Daten ein, ihr speichert sie, organisiert eine Zugriffskontrolle und gebt die Nutzereingabe formatiert wieder aus. Für mich sieht es so aus, dass ihr quasi von der Ausgabe her die Datenbank konzipiert habt und nicht von dem, was eine Itemverwaltung verwaltet - Items.
Ja, meine Güte, dann sag doch mal was du dir vorstellstUnd das ist vor allem deshalb schade, weil ihr damit hinter den Möglichkeiten relationaler Datenbanken und der Programmiersprache PHP bleibt.

Ehm, mir ist da noch ein bischen unklar, was du meinst. Wenn es dir darum geht, jedes Item möglichst genau modelliert zu haben: Da kann man es sich glaube ich auch einfacher machen. Da schreibt man sich in nen paar Minuten nen Skript, was die inD2-Itemdatenbank aufruft und alle möglichen Eigenschaften ausliest (wie ich, nur ich habe bisher nur Name Deutsch / Englisch und Itemqualität genommen. Vielleicht kommen später noch die variablen Stats dazu, ist im Grunde ne ganz einfache Sache.Klar. Woher bezieht das Spiel seine Informationen über alle möglichen Gegenstände? Aus den MPQs. Was verwaltet eine Itemverwaltung? Alle möglichen Gegenstände. q.e.d. Das einzige, was es braucht, d.h. was programmiert werden muss ist eine Programm, dass die in den MPQs gespeicherten Informationen so aufarbeitet, dass sie in eine Datenbank gehauen werden können. Dafür ist eine Modellierung dessen, was ein Gegenstand ist, nötig, in der die Eigenschaften und ihr Verhältnis untereinander abgebildet sind. Ich denke da erstmal nicht an die Abbildung in einer relationalen Datenbank, sondern wie man sinnvoll objektorientiert damit umgeht.
MfG

scrawl