Datenbankschema für Achievement System

[Falc410]

Ich möchte in mein Webbassiertes Spiel ein Achievement System einbauen (Uni Projekt).
- Dazu gibt es mehrere Achievements von denen jeder Spieler mehrere erfüllt haben kann oder nicht (ManyToMany)
- Jedes Achievement kann ein oder mehrere Voraussetzungen (Conditions) haben die erfüllt werden müssen, eine Condition gehört zu einem Achievement (könnte hier auch ManyToMany Sinn machen?)
- Jeder Spieler soll einen Progress haben, so etwas wie einen Counter, damit ich dem Spieler anzeigen kann das er z.B. 3/4 bereits erfüllt hat und damit auch die Berechnung schneller geht. Ansonsten müsste ich ja jedesmal über die gesamte Datenbank schauen ob alle Voraussetzungen erfüllt sind.

Nun ist die Frage ob es mehr Sinn macht das jeder Spieler mehrere Progress hat, welche wiederrum genau einer Condition zu geordnet sind:

Oder ob jeder Spieler einen Progress hat, welcher dafür mehrere Conditions beinhaltet:

Oder ganz anders designen? Ich hab mit Datenbankdesign leider sehr wenig Erfahrung. Meine Idee (um es einigermassen performant zu machen) nach jeder Aktion vom Spieler über alle Conditions (die noch nicht 100% erfüllt sind) zu iterieren und diese in Progress ggf. hoch zu zählen. Sollte dabei eine Condition erfüllt sein wird geprüft ob das zugehörige Achievement erfüllt ist (falls alle anderen Conditions erfüllt sind).

Würdet ihr eine andere vorgehensweise empfehlen? Ich habe schon ein wenig gegooglet aber nichts gescheites gefunden. Alternativ kann ich ja über alle nicht erfüllten Achievements iterieren und dann für jedes Achievement die Conditions prüfen usw.

 

[abulafia]

Beim ersten Ansehen habe ich zwei Probleme.
Das erste siehst du ja selber: Gehört jede Condition wirklich nur zu einem Archievment? Sonst brauchst du eine m-n Verbindungstabelle.

Die Progress-Tabelle ist die Verbindungstabelle zwischen Player und Condition (m-n), denn jeder Spiele kann verschiedene Conditions erfüllen, und jede Condition kann von vielen Spielern erreicht werden.

 

[Falc410]

Ich hab das Gefühl, dass m-n Beziehungen alles ziemlich kompliziert machen und wollte so weit wie möglich darauf verzichten. Daher hatte ich mich entschlossen Conditions nicht doppelt zu verwenden sondern eben nur einem Achievement zu zu ordnen.

Mit der Progress Tabelle hast du recht. Ich versuche es mal als m-n Beziehungstabelle zwischen Player und Conditions zu modellieren.

Was mir jetzt gerade noch sorgen ist macht, ist die Gestaltung der Conditions. Ich will das möglichst generisch aufbauen. Im Prinzip benötigt jede Condition einen Operator (>,<,=, oder < x <) und einen Wert den es zu erreichen gilt, und eventuell noch eine Anzahl wie oft dieser Fall eintreten muss. Den Operator muss ich aber in einem String Feld in der Datenbank speichern und dann beim auslesen irgendwie per String Vergleich parsen um dann die entsprechende Typ-Operation auszuführen. Das kommt mir aufwendig und Fehleranfällig vor (String Vergleiche sind doch auch zu vermeiden, oder?).

Danke schon mal!

 

[Valhal]

Relationale Datenbank?

Dynamik und Generisch ist da immer etwas schwierig. Aber es spricht nichts dagegen wenn du für die Dynamik z.B. ein JSON formatiertes String Feld einbaust.

"Moderne" Datenbanken unterstützten auch JSON direkt... http://www.postgresql.org/docs/9.3/static/datatype-json.html

Dadurch bekommst du eine gute Dynamik hin:

{
"Operation": "=",
"blabla": "irgendwas",
}

String vergleiche sind absolut kein Problem.