Datenmodell zu Spiel und VÖ (Teil 2)

[MZ per X]

Huzzah, die Entwicklung unseres Datenmodells geht in die zweite Runde!

Die Leute, die mitdiskutieren und mitentwickeln wollen, bitte ich zunächst, den ersten Thread zum Thema nochmal vollständig und in Ruhe zu konsumieren.

Außerdem bitte ich Euch, dass wir uns hier auf die Grundlagen konzentrieren, d.h. wir wollen zunächst klären, wie wir die vielen verschiedenen Veröffentlichungen/Versionen eines Spiels, die uns die Publisher ständig vor den Latz knallen, in der Datenbank abbilden können. Wir wollen noch nicht im Einzelnen diskutieren, welche Daten wir später auf welcher Ebene zuordnen.

Ich habe meinen Datenmodellvorschlag aus dem ersten Thread um die zusätzliche Datenebene "Patchlevel" ergänzt und versucht, das Ganze an einem frei erfundenen Spiel "Bei-Spiel" darzustellen. Die Datei liegt hier im Webdav-Verzeichnis, ich entschuldige mich im Voraus für meine künstlerischen Fähigkeiten.

Einige Bemerkungen dazu:

Die unterste Datenebene "Spiel" steht in einer 1-n-Beziehung zu den Veröffentlichungsgruppen (VÖG), da ein Spiel natürlich mehrere VÖG haben kann, aber eine VÖG nicht mehreren Spielen zugeordnet sein kann. Diese Beziehung wird durch die blauen, dicken Pfeile symbolisiert.

Wir brauchen pro Plattform mindestens eine VÖG, da bin ich mir relativ sicher.

Die VÖG stehen zu den Einzelveröffentlichungen (VÖ) in einer n-n-Beziehung, da eine VÖG natürlich mehrere VÖ enthalten kann, eine VÖ aber durchaus auch mehreren VÖG zugeordnet sein kann (Stichwort Multiplattform-Release). Diese Beziehung wird durch die blauen, dünnen Pfeile symbolisiert.

Die VÖ stehen zum Patchlevel in einer 1-n-Beziehung, da (hoffentlich) jede VÖ das Spiel nur in einer Version enthält, jeder Patchlevel aber natürlich mehrfach veröffentlicht worden sein kann. Diese Beziehung wird durch die farbigen Pfeile symbolisiert.

Als nächstes möchte ich eine Compilation ins Beispiel einbauen. Kennt irgendjemand ein Programm, mit dem man simpel und intuitiv solche Beziehungen abbilden und hin-/herschieben kann? Das von gene empfohlene ArgoUML ist mir zu abstrakt/kompliziert.

[gene]

Gibt's wirklich Multi-Plattform-Spiele zu kaufen?

Wollen wir nicht erstmal "klären", was genau eine VÖG und was genau eine VÖ ist, bevor du irgendwas mit Patches oder Compilation dazunimmst?

Ich wüsste z.B. gerne, wozu diese Dinge gehören: VÖG oder VÖ?

• Screenshot
• Packungs-Foto
• Website
• Programmierer, Publisher, etc.
• Testbericht in Zeitschrift
• System
• Erscheinungsjahr
• User-Bewertung
• EAN-Nummer

[Hawkmeister]

Also ich habe noch Schwierigkeiten, zu differenzieren. Vielleicht kann ich abends einfach zu schlecht abstrakt denken. Ich schreibe mal nieder, wie ich das verstehe.

Ich nehme für mich jetzt einfach mal ein Spiel her, um es für mich greifbarer zu machen. "Monkey Island" kommt mir in den Sinn.

Die Veröffentlichung ist demnach die Kombination aus dem Spiel auf einer einzelnen Plattform (z.B. PC), einem definierten Packaging (z.B. Low-Budget Release der Software-Pyramide) und einer zeitlichen Komponente (Versionsnummer oder Erscheinungsdatum?). Wahrscheinlich wäre auch eine jede Sprachfassung bzw. Lokalisierung eine neue Veröffentlichung? Das würde jetzt nicht für eine rein multilinguale Fassung gelten. Das wäre nach wie vor eine einzige Veröffentlichung. Aber da manche Länder unterschiedliche Schnittfassungen erhalten, wären das unterschiedliche Veröffentlichungen.

Jede Veröffentlichung kann daher problemlos einen anderen Versionsstand (Patches) haben - und somit könnten Cheats, Screenshots, etc. (also auch alle von gene aufgezählten Attribute) jeder Veröffentlichung exakt zugeordnet werden.

Die neue Version von Monkey Island für iPad / iPhone wäre dann auch nur eine neue Veröffentlichung.

Die Frage ist allerdings, wieviel Abweichung toleriert wird, dass eine weitere Version noch als eine neue Veröffentlichung gesehen werden kann - oder ob soviel geändert wurde, dass es ein neues Spiel ist? (Beispiel fällt mir gerade nicht ein. Obwohl… manche Vollpreistitel werden unter gleichem Namen für Handys veröffentlicht sind dann aber zum Beispiel nicht aus der Ego-Perspektive sondern isometrisch angelegt und mit einer anderen Spielmechanik versehen.) Das kann man wohl schwer prozentual festlegen und ist eher eine Ermessensfrage, oder?

Und wo würde jetzt die Veröffentlichungsgruppe dazwischen stehen? *ganz verwirrt schau*

[Hawkmeister]

Ich denke, man kann bei den Veröffentlichungen noch ganz gut gruppieren.

- Demo-Versionen / Previews
- Originaler Release
- optional: Originale Portierung, sofern eine Veröffentlichung auf einer anderen Plattform erst nach längerer Zeit erscheint
- Re-Release (Compilations, Low-Budget Auflagen, Heftbeileger)

Was meint ihr?

[MZ per X]

Gibt's wirklich Multi-Plattform-Spiele zu kaufen?

Oh ja. Meine letzte Anschaffung dieser Art war World of Goo (Win/Mac).

Wollen wir nicht erstmal "klären", was genau eine VÖG und was genau eine VÖ ist, bevor du irgendwas mit Patches oder Compilation dazunimmst?

Okay, versuchen wir es.

Eine VÖ ist jede Form eines Spiels, die irgendwie der Öffentlichkeit zugänglich gemacht wurde, ob mit oder ohne Geld. VÖ sind beispielsweise:

• Der Karton, den Du im Laden kaufen kannst.
• Die Jewel Case aus der Software-Pyramide.
• Der Download von Steam.
• Die Demoversion auf einem Zeitschriften-Beileger.
• Die geknackte Version mit Trainer, die irgendeine Piratencrew verbreitet hat.

Eine VÖG dagegen fasst mehrere gleichartige VÖ zusammen, damit keine Datenredundanzen entstehen. Ohne VÖG müsste man bestimmte Daten (wie zB einen Spieletest für ein bestimmtes System) zu jeder dieser gleichartigen VÖ immer wieder zuordnen. Eine VÖG wird definiert durch:

• Genau eine Plattform. (Amiga / C64 / Windows / Xbox / usw.)
• Genau eine "Patchlevelgruppe" (schon wieder Gruppe ). (Demoversion / Erst-VÖ / Enhanced Version / Re-Release)
• Genau eine Veröffentlichungsart. (Originalentwicklung / Portierung / Re-Release)

Ich wüsste z.B. gerne, wozu diese Dinge gehören: VÖG oder VÖ?
[*]Screenshot

Ich hatte ja schon mehrfach angedeutet, dass man mit Screenshots große Dinge tun kann. Sie sollen nämlich zu jeder Datenebene zugeordnet werden können.

• Beim Spiel können wir Screenshots speichern, die das grundsätzliche Gameplay zeigen.
• Bei der VÖG kommen Screenshots dazu, die die Besonderheiten der jeweiligen Plattform und/oder Patchlevelgruppe darstellen (zB Unterschiede zwischen CGA/EGA/VGA-Version bei einem alten DOS-Spiel oder Gameplay-Unterschiede bei Portierungen).
• Bei der VÖ kann man zB Screenshots vom Installer dazutun oder von einem Piraten-Intro, halt von allen Dingen, die spezifisch für diese VÖ sind.
• Beim Patchlevel kann man mit Screenshots zeigen, an welchen Dingen die Programmierer bei diesem Patch geschraubt haben, wenn das sinnvoll ist.

[*]Packungs-Foto

Eindeutig VÖ.

[*]Website

Würde ich sogar auf der Spielebene sehen, so als eine Art Linksammlung zum Spiel an sich. Ich sehe keinen großen Sinn darin, die Links noch auf die VÖG zu verteilen.

[*]Programmierer, Publisher, etc.

Der Publisher gehört auf jeden Fall zur VÖ. Auch die kompletten Credits würde ich gerne bei der VÖ speichern wollen. Das gibt zwar einige Redundanzen, aber die Credits jeder VÖ weichen nunmal ein wenig voneinander ab. Das Entwicklungsstudio könnte man eventuell bei der VÖG speichern, da es sich mit einer neuen VÖ (hoffentlich) nicht ändern wird.

[*]Testbericht in Zeitschrift

Eindeutig VÖG.

[*]System

Eindeutig VÖG.

[*]Erscheinungsjahr

Eindeutig VÖ.

[*]User-Bewertung

Da einzelne Portierungen teilweise erhebliche Qualitätsunterschiede aufweisen ---> VÖG.

[*]EAN-Nummer

Eindeutig VÖ.

So, jetzt habe ich mich doch auf Detailfragen eingelassen. Aber wenn es dazu beiträgt, dass mein Ansatz verstanden wird, ist alles gut.

[MZ per X]

Wahrscheinlich wäre auch eine jede Sprachfassung bzw. Lokalisierung eine neue Veröffentlichung?

Natürlich. Die in Deutschland verkaufte deutsche Version ist eine VÖ, und die in Russland verkaufte russische Version auch.

Das würde jetzt nicht für eine rein multilinguale Fassung gelten. Das wäre nach wie vor eine einzige Veröffentlichung. Aber da manche Länder unterschiedliche Schnittfassungen erhalten, wären das unterschiedliche Veröffentlichungen.

Wenn in einem Karton vier Sprachen drin sind, ist das trotzdem nur genau eine VÖ.

Jede Veröffentlichung kann daher problemlos einen anderen Versionsstand (Patches) haben - und somit könnten Cheats, Screenshots, etc. (also auch alle von gene aufgezählten Attribute) jeder Veröffentlichung exakt zugeordnet werden.

Ja, es sei denn, die Daten sind für mehrere VÖ gleich, dann sollten sie zur Vermeidung von Redundanzen einer VÖG zugeordnet werden.

Die neue Version von Monkey Island für iPad / iPhone wäre dann auch nur eine neue Veröffentlichung.

Exakt.

Die Frage ist allerdings, wieviel Abweichung toleriert wird, dass eine weitere Version noch als eine neue Veröffentlichung gesehen werden kann - oder ob soviel geändert wurde, dass es ein neues Spiel ist? (Beispiel fällt mir gerade nicht ein. Obwohl… manche Vollpreistitel werden unter gleichem Namen für Handys veröffentlicht sind dann aber zum Beispiel nicht aus der Ego-Perspektive sondern isometrisch angelegt und mit einer anderen Spielmechanik versehen.) Das kann man wohl schwer prozentual festlegen und ist eher eine Ermessensfrage, oder?

Wenn eine neue VÖ nicht zu den Daten passt, die auf der Datenebene Spiel zugeordnet sind, dann wird es ein neues Spiel.

Beispiel Genre-Klassifikation: Das Urspiel ist ein rundenbasiertes Strategiespiel. Plötzlich erscheint eine Portierung, die das Spiel auf Echtzeit umstellt. Wenn unsere Genre-Klassifikation einen Unterschied zwischen rundenbasiert und Echtzeit macht, dann muss ein neuer Spieleintrag her.

Und wo würde jetzt die Veröffentlichungsgruppe dazwischen stehen? *ganz verwirrt schau*

Hier hilft Dir hoffentlich meine Antwort an gene weiter.

[MZ per X]

Was mir gerade noch einfällt:

Zur Vereinfachung des Denkens könnt Ihr auch mal die VÖG durch die Plattform ersetzen. Also:

Spiel ---> Plattform ---> VÖ als einfacheres Denkmodell.

Nur bei unserem endgültigen Datenmodell können wir es halt nicht so einfach machen...

[Hawkmeister]

Ah, danke MZ per X, jetzt ist es klarer.

Die Veröffentlichungsgruppe dient quasi "nur" als Cluster um die Datenredundanzen zu vermeiden. Das macht Sinn.

Die einzige Befürchtung, die ich habe, kommt aus einer anderen Ecke, der Usability. Ich fürchte, dass einige Benutzer, die neue Daten eintragen, mit dem Modell der Veröffentlichungsgruppe nicht so ganz zurecht kommen und das bezüglich Sinnhaftigkeit dann falsch eintragen bzw. ob wir sie mit der Komplexität überfordern und sie dann keine Daten beitragen wollen.

Die strategische Frage wäre, ob man dafür eher Redundanzen in Kauf nimmt oder ob man es riskiert - ich drücke es mal krasser aus als es wahrscheinlich ist - Helfer zu "verprellen", dafür aber eine korrekte Datenstruktur hat.

Ihr seht, ich bin hin und her gerissen...

[MZ per X]

Die strategische Frage wäre, ob man dafür eher Redundanzen in Kauf nimmt oder ob man es riskiert - ich drücke es mal krasser aus als es wahrscheinlich ist - Helfer zu "verprellen", dafür aber eine korrekte Datenstruktur hat.

Diese Frage habe ich mir auch schon gestellt. Ich sage, wir sollten keine Redundanzen in Kauf nehmen, wenn möglich.

Unser Datenmodell entwickeln wir theoretisch, es soll und muss möglichst jeden in der Praxis vorkommenden Fall abbilden können. Was wir dann aber mit diesem Datenmodell in der Praxis machen, wie wir es in gute Usability verpacken und den Nutzer vielleicht gar nicht merken lassen, welche komplexen Daten im Hintergrund gespeichert werden, das wird unsere nächste große Aufgabe. (Oder anders ausgedrückt: Dafür haben wir ja unseren Hawkmeister... )

Und soooo viel schwieriger wird unser Datenmodell auch nicht werden. Die grundsätzliche Abfolge von Spiel-->Plattform-->VÖ findet sich in jeder besseren Spiele-Datenbank, wie zB in MobyGames oder in der OGDB. Wir abstrahieren nur noch etwas mehr, um eben vollständig zu sein.

[gene]

Ich finde das Modell (bzw. den zentralen Teil davon) nun auch verständlicher.

Spiel -> Spiel auf Plattform -> Einzelveröffentlichung des Spiels auf einem bestimmten Distributionsweg

Ich habe mir auch schon Gedanken darüber gemacht, dass das zu "komplex" für den Endanwender ist (insbesondere für denjenigen, der Daten eintragen/einsenden möchte). Aber das ist dann eine Frage der sinnvollen Anwendungssteuerung, dieses umfassende Modell gut zu verkaufen.
So kann man ja z.B. beim Hochladen eines Screenshots zu einem Spiel gezielt dem Hochladenden eine oder mehrere Fragen stellen, aufgrund deren Beantwortung dann der Screenshot dem "Spiel auf Plattform" oder einer Einzelveröffentlichung zugeordnet wird. Wird schon gehen.

[floruc]

Ich denke auch, dass die Veröffentlichungsgruppe sinnvoll ist. Allerdings sollten wir klare Kriterien haben, wann eine neue Veröffentlichungsgruppe erstellt wird und welche Informationen auf welcher Ebene hinterlegt werden sollen.
Ich habe mal NFSU2 als einfaches Beispiel mit recht vielen Releases von TLG als Diskussionsbeispiel genommen. Datei ist auf dem WebDAV-Verzeichnis als OpenOffice Tabelle.

[MZ per X]

Datei ist im Anhang...

Hmm, ich sehe nix, wie kommt man denn da ran?

[floruc]

Ja das mit dem Anhang hat irgendwie nicht geklappt. Jetzt ist es wie gesagt auf dem Netzverzeichnis

[floruc]

Ich habe jetzt mal X-Wing angeschaut, das Schema auf die bei TheLegacy gelisteten Releases angewendet und wieder als OpenOffice Tabelle auf WebDAV hochgeladen. X-Wing besteht aus Hauptspiel und 2 Addons. Außerdem gibt es eine verbesserte CD-Version mit Hauptspiel+Addons. Die Addons habe ich mal als neue Veröffentlichungsgruppe gesehen ebenso die CD-Version und die Mac-Version. Dann braucht man auf der Ebene der Veröffentlichungsgruppe auf jeden Fall die Kategorien "AddOn: ja/nein" und "Compilation: ja/nein". Außerdem habe ich "AddOn Nr." dazugenommen. Aber auch über die Eingruppierung von Imperial Pursuit und XWing Upgrade Kit, das ja auch das Hauptspiel eindeutscht, ist diskussionswürdige. Ebenso die Frage, wie man den Inhalt der CD-ROM Compilation abbilden soll?

Bisher sehe ich diese Kriterien für eine neue Veröffentlichungsgruppe:
[list=VÖ-Gruppen]
[*]Release auf einem bestimmten System
[*]Addon:ja
[*]Erweiterte Version:ja
[*]Compilation:ja
[/list]

Ich finde es einerseits gut, dass alle wichtigen Informationen zu X-Wing zusammenstehen. Auf der anderen Seite finde ich es gewöhnungsbedürftig, dass Addons und Compilations als eine Veröffentlichungsgruppe neben dem X-Wing-Hauptspiel im selben Eintrag stehen.

PS: Sorry für die großen Dateien. Ich habe zu besseren Visualisierung einfach die Cover reinkopiert. Ich versuche es demnächst mit einem anderen (Mindmap) Tool.

[MZ per X]

Ich habe jetzt mal X-Wing angeschaut, das Schema auf die bei TheLegacy gelisteten Releases angewendet und wieder als OpenOffice Tabelle auf WebDAV hochgeladen.

Erstmal danke für Deine Arbeit. X-Wing ist ein sehr gutes, wunderbar komplexes Beispiel, an dem wir unser Datenmodell weiterentwickeln können. Da Du das Spiel gut zu kennen scheinst, könntest Du eventuell noch eine kleine Übersicht über die veröffentlichten Patchlevel in Deine ODS-Datei einfügen? Wobei jede Sprachversion ein eigener Patchlevel ist.

Bisher sehe ich diese Kriterien für eine neue Veröffentlichungsgruppe:
[list=VÖ-Gruppen]
[*]Release auf einem bestimmten System
[*]Addon:ja
[*]Erweiterte Version:ja
[*]Compilation:ja
[/list]

Ich denke, dass Addons und Compilations grundsätzlich einen neuen Eintrag auf Spielebene erhalten müssen, eine neue VÖG beim Basisspiel wäre mE unlogisch und zu kompliziert. Was ist, wenn ein Addon vielleicht mal zu zwei Basisspielen gehört? Was ist mit vermeintlichen Addons, die das Basisspiel überhaupt nicht benötigen und nur marketing-technisch ein Addon sind? Was ist, wenn ein lupenreines Addon das Basisspiel stark verändert? Rechtfertigt eine Compilation alleine eine neue VÖG, selbst wenn das Spiel nur 1:1 wiederveröffentlicht wurde? Was passiert, wenn eine Compilation oder ein Addon selbst wiederum zig-mal gepatcht und wiederveröffentlicht wird? Oder wenn gar ein Addon mal ein Addon bekommt?

Nein, nein, das wird zu kompliziert. Addons und Compilations müssen zunächst auf Datenebene "Spiel" einen eigenen Eintrag bekommen, die dann irgendwie mit dem Basisspiel bzw. mit den in der Compilation enthaltenen Spielen verbunden werden. Sonst kommen wir mE in Teufels Küche.