Open Registry of Game Information 

  • Fragen zum Datenmodell-Entwurf

  • Hier werden Fachthemen diskutiert. Welche Daten soll das System enthalten? Welche Funktionen soll das Neusystem enthalten?
Hier werden Fachthemen diskutiert. Welche Daten soll das System enthalten? Welche Funktionen soll das Neusystem enthalten?

Moderators: MZ per X, gene

 #36437  by gene
 03 Nov 2012, 00:46
Hier möchte ich Frage(n) zum Datenmodell stellen und auch gerne beantwortet haben :D

Hierzu:
http://wiki.oregami.org/display/OR/Release+Group+Cases
Was hat es mit dem "New Platform" und "Same Platform" auf sich? Was ist, wenn ein Spiel auf zwei Plattformen gleichzeitig rauskommt?
Warum wird das mit der Unterscheidung zwischen "Demo/Remake/Original" vermischt?
Außerdem vermischt du dann in diesem Feld noch die Eigenschaft "zensierter Inhalt".

Hier ein Alternativ-Vorschlag:
  • Feld 1: PlatformReleasegroupType: [Initial, Follow]
  • Feld 2: ReleaseGroupScope: [Original, Demo, Remake, Enhanced]
  • Feld 3: CensorshipType: [None, Light, Medium, Heavy]
Weitere Fragen kommen bei mir bestimmt noch auf...
 #36438  by hydr0x
 03 Nov 2012, 09:21
Da öffnest du die Büchse der Pandora mit der frage nach Multiplatformtiteln ;) Der Horror-Fall: Die Erst-VÖ enthält getrennte Medien für zwei Systeme, also z.B. DOS und Amiga. Aber im gleichen Karton. Viel Spaß :D
 #36440  by MZ per X
 03 Nov 2012, 23:07
gene wrote:Hier möchte ich Frage(n) zum Datenmodell stellen und auch gerne beantwortet haben :D
Nach einer Woche Urlaub ist irgendwie alles wie gelöscht, aber ich probier's trotzdem mal. :)
gene wrote:Was hat es mit dem "New Platform" und "Same Platform" auf sich?
"New Platfom" bedeutet lediglich, dass es das Spiel auf dieser Plattform vorher nicht gab. "Same Platform" bedeutet den entsprechend anderen Fall, also eine Veröffentlichung des Spiels, die sich von den Veröffentlichungen vorher stark unterscheidet.
gene wrote:Was ist, wenn ein Spiel auf zwei Plattformen gleichzeitig rauskommt?
Dann werden zwei neue ReleaseGroups fällig, pro Plattform eine, und beide bekommen zunächst mal "New Platform". Wenn wir es nicht besser wissen, werden wir auch beide Versionen als "nativ" kennzeichnen müssen.
gene wrote:Warum wird das mit der Unterscheidung zwischen "Demo/Remake/Original" vermischt?
Hier ein Alternativ-Vorschlag:
  • Feld 1: PlatformReleasegroupType: [Initial, Follow]
  • Feld 2: ReleaseGroupScope: [Original, Demo, Remake, Enhanced]
Hmm, klingt gut, wir können diese Daten gerne in einzelne Eigenschaften aufteilen.

Feld1 wäre also die Unterscheidung zwischen "New Platform" und "Same Platform", also quasi ein Feld "Erstveröffentlichung auf dieser Plattform ja/nein".
Als Feld2 würde ich die Art der Entwicklung sehen, also nativ, Port oder Emulator-Release.
Und Feld3 wäre dann... tja, wie nennt man das? ReleaseScope ist wohl ganz gut, vielleicht auch ReleaseExtent.

Natürlich ergeben dann einige Kombinationen dieser drei Felder wenig Sinn:
"ErstVÖ nein" + "Port" ?
"Emulator-Release" + "Remake"?
Aber das ist nicht schlimm. Erstens können wir diese Fälle durch intelligente Dateneingabe gleich ausschließen, sind aber zweitens gleichzeitig flexibel im Datenmodell, wenn ein solch unmöglicher Fall doch eintreten sollte. Aus welchen Gründen auch immer. :)
gene wrote:Außerdem vermischt du dann in diesem Feld noch die Eigenschaft "zensierter Inhalt".
  • Feld 3: CensorshipType: [None, Light, Medium, Heavy]
Bitte beachte, dass wir hier über die RG sprechen, nicht über das einzelne Release. Die RG wurden eingeführt, um Releases abzugrenzen, die sich stark von anderen Releases unterscheiden, d.h. also nur bei "heavy censoring", höchstens noch bei "medium". Keine oder leichte Zensur können wir über die RG nicht abbilden, denn dann wären wir wieder an dem Punkt, wo wir fast für jede Sprachversion eine eigene RG speichern müssten.

Ich schlage also vor, dass obige Feld3 um "Heavily Censored Version" zu ergänzen. Wie wir dann auf Release-Ebene die detaillierten Zensurinfos abbilden, ist noch zu klären.
gene wrote:Weitere Fragen kommen bei mir bestimmt noch auf...
Das hoffe ich! :D
 #36442  by hydr0x
 04 Nov 2012, 11:06
MZ per X wrote:
gene wrote:Was ist, wenn ein Spiel auf zwei Plattformen gleichzeitig rauskommt?
Dann werden zwei neue ReleaseGroups fällig, pro Plattform eine, und beide bekommen zunächst mal "New Platform". Wenn wir es nicht besser wissen, werden wir auch beide Versionen als "nativ" kennzeichnen müssen.
Wie würdest du denn meinen beschriebenen Fall abdecken? Zu beiden RG den gleichen Release zuordnen?
 #36443  by MZ per X
 04 Nov 2012, 13:28
hydr0x wrote:
MZ per X wrote:
gene wrote:Was ist, wenn ein Spiel auf zwei Plattformen gleichzeitig rauskommt?
Dann werden zwei neue ReleaseGroups fällig, pro Plattform eine, und beide bekommen zunächst mal "New Platform". Wenn wir es nicht besser wissen, werden wir auch beide Versionen als "nativ" kennzeichnen müssen.
Wie würdest du denn meinen beschriebenen Fall abdecken? Zu beiden RG den gleichen Release zuordnen?
So ist es gedacht, ja. ReleaseGroup und Release stehen in einer m-n-Beziehung zueinander, sodass ein Karton mehreren RGs zugeordnet werden kann.

Ob das ausreicht, um Multi-Plattform-Releases abzubilden, wird sich bei der Detailplanung der Releasedaten zeigen.
 #36460  by gene
 14 Nov 2012, 23:04
Wo ist denn bei der "Release Group" (RG) hinterlegt, für welches System die RG ist?
Es ist zwar das Feld "Title" vorgesehen, aber uns ist ja wohl klar, dass darüber das System nicht gescheit abgebildet werden kann.
Hast du das Feld einfach vergessen?
 #36461  by gene
 14 Nov 2012, 23:51
(Hinweis: ich habe die Feldbezeichnungen im Zitat angepasst, um meinen Text von deinem zu unterscheiden)
MZ per X wrote:
gene wrote:Hier ein Alternativ-Vorschlag:
  • Feld 1: PlatformReleasegroupType: [Initial, Follow]
  • Feld 2: ReleaseGroupScope: [Original, Demo, Remake, Enhanced]
Hmm, klingt gut, wir können diese Daten gerne in einzelne Eigenschaften aufteilen.

Feld-A wäre also die Unterscheidung zwischen "New Platform" und "Same Platform", also quasi ein Feld "Erstveröffentlichung auf dieser Plattform ja/nein".
Als Feld-B würde ich die Art der Entwicklung sehen, also nativ, Port oder Emulator-Release.
Und Feld-C wäre dann... tja, wie nennt man das? ReleaseScope ist wohl ganz gut, vielleicht auch ReleaseExtent.
Also, ich bin mit diesen bisherigen "Feld-Definitionen" total unzufrieden :(
  • Feld 1/Feld-A: Die Unterscheidung zwischen "Initial" und "Follow" finde ich sehr ungünstig bzw. irgendwie künstlich. Was wollen wir mit dieser Information überhaupt erreichen? Was ist, wenn es zunächst eine "Demo-Release-Group" für System X gab, und dann ein "Original-Release". Wie würde man diese beiden RGs dann kennzeichnen, beide mit "Initial" ? Können wir für dieses Feld ein paar Beispiele bekommen?
  • Feld-B: wie sollen die einzelnen Werte voneinander abgegrenzt werden? Wann ist es "nativ", wann ein "Port"? Ich denke da z.B. an (fast) zeitgleiche RG für SNES/MegaDrive, oder für Amiga/AtariST. Oder heutzutage an neue Spiele auf iOS/Android. Klar, früher in alten Zeitschriften gab's auch Tests von "Konvertierungen", aber es gab eben auch Tests von Spielen auf "Zweit-Systemen", die nicht als "Konvertierung" bezeichnet wurden. Bezüglich des "Emulator-Releases": wie kann man das denn eigentlich feststellen? Klar, wenn man irgendwo DOSBox auf einer CD entdeckt, ist alles klar. Aber was ist z.B. mit MegaDrive-Spielen auf iOS/Android? Wie soll man rausfinden, was zur Hölle das ist? Und interessiert es überhaupt jemanden?
  • Feld 2/Feld-C: dieses Feld ist meiner Meinung nach das einzige eindeutige der hier aufgelisteten. Einige weitere ausprägungen könnten gewiss noch dazukommen, aber die Unterscheidung zwischen "Demo-Version", "Full/Original", "Enhanced", "Remake" sollte vermutlich jeder verstehen.
 #36462  by Sidasa
 18 Nov 2012, 13:35
gene wrote:Wo ist denn bei der "Release Group" (RG) hinterlegt, für welches System die RG ist?
Es ist zwar das Feld "Title" vorgesehen, aber uns ist ja wohl klar, dass darüber das System nicht gescheit abgebildet werden kann.
Hast du das Feld einfach vergessen?
Die Frage hatte ich mir auch schon mal gestellt.
Eigentlich müsste so gut wie alles, was für ein Spiel zählt, auch für ein Spielsystem zählen.
Wann ein System angekündigt wurde, wann es wo veröffentlich wurde (mit welchen Features), Preisänderung, etc.
 #36466  by MZ per X
 21 Nov 2012, 17:50
gene wrote:Wo ist denn bei der "Release Group" (RG) hinterlegt, für welches System die RG ist? Hast du das Feld einfach vergessen?
Ich vergesse nie etwas! :mrgreen: Nein, die Hardware ist schlicht und ergreifend noch nicht eingebaut. Wenn Ihr schon weiterprogrammieren wollt, dann bastelt Euch für's Erste eine neue Tabelle "Platform" und verlinkt sie 1:n mit den ReleaseGroups.
gene wrote:Also, ich bin mit diesen bisherigen "Feld-Definitionen" total unzufrieden :(
Das müssen wir ändern, gene! :D
gene wrote:Feld 2/Feld-C: dieses Feld ist meiner Meinung nach das einzige eindeutige der hier aufgelisteten. Einige weitere ausprägungen könnten gewiss noch dazukommen, aber die Unterscheidung zwischen "Demo-Version", "Full/Original", "Enhanced", "Remake" sollte vermutlich jeder verstehen.
Fangen wir mal mit diesem Feld an, das ist in meinen Augen das Wichtigste und sollte auch ein Mussfeld jeder RG sein. Das ist ab jetzt Feld I. :)

Als nächstes würde ich aus Feld I die Zensurinfo wieder entfernen und diese in einem weiteren Mussfeld "Zensurrelease Ja/Nein" unterbringen, das ab jetzt Feld II heißen soll. Warum? Jede Demoversion, jede Originalversion, jedes Remake kann in bestimmten Ländern stark zensiert sein und eine eigene RG benötigen. Wenn wir in Feld I eine Eigenschaft "Highly censored version" hinterlegen, hätten wir Daten-Inkonsistenzen, weil jede dieser RG's gleichzeitig auch eine "Demo-Version", "Original", "Enhanced" oder "Remake" wäre.
gene wrote:Feld-B: wie sollen die einzelnen Werte voneinander abgegrenzt werden? Wann ist es "nativ", wann ein "Port"? Ich denke da z.B. an (fast) zeitgleiche RG für SNES/MegaDrive, oder für Amiga/AtariST. Oder heutzutage an neue Spiele auf iOS/Android. Klar, früher in alten Zeitschriften gab's auch Tests von "Konvertierungen", aber es gab eben auch Tests von Spielen auf "Zweit-Systemen", die nicht als "Konvertierung" bezeichnet wurden.
Zunächst mal grundsätzlich: Ob und wie man an eine Info rankommt, soll zunächst nicht unser Problem sein. Das werden die Experten später schon hinkriegen, die sind viel besser als wir. :) Ich finde solche Daten aber für spätere Recherchen / Auswertungen immer wichtig und ich bin nicht allein damit. Man kann dann zB schauen, ob bei den Portierungen die Testwertungen immer nach unten gehen oder nicht.

Dieses Feld soll ab jetzt Feld III heißen und ist ein Kannfeld. Es wird nur gefüllt, wenn Feld I "Original" ist und Feld II "nein". Alles andere ergibt in meinen Augen keinen Sinn. "Native" bedeutet für mich, dass das Spiel auf diesem System entwickelt wurde, "Port" bedeutet, dass eine bereits existierende Codebasis auf dieses System portiert wurde. Rein technisch gesehen.
gene wrote:Bezüglich des "Emulator-Releases": wie kann man das denn eigentlich feststellen? Klar, wenn man irgendwo DOSBox auf einer CD entdeckt, ist alles klar. Aber was ist z.B. mit MegaDrive-Spielen auf iOS/Android? Wie soll man rausfinden, was zur Hölle das ist? Und interessiert es überhaupt jemanden?
Mich interessiert das, wenn ich die Originalversion auf einem neuen System kaufen kann. Und andere wollen vielleicht nur echte Portierungen spielen, die das neue System voll ausnutzen. Ich finde diese Info schon sehr wichtig. Und wie gesagt, wie man an die Infos kommt, soll jetzt nicht unser Problem sein. Bei den Emulator-Veröffentlichungen gibt es ja zum Glück sehr viele, wo das glasklar ist. Man denke nur an die ganzen C64- und Amiga-Spielesammlungen für den PC.
gene wrote:Feld 1/Feld-A: Die Unterscheidung zwischen "Initial" und "Follow" finde ich sehr ungünstig bzw. irgendwie künstlich. Was wollen wir mit dieser Information überhaupt erreichen? Was ist, wenn es zunächst eine "Demo-Release-Group" für System X gab, und dann ein "Original-Release". Wie würde man diese beiden RGs dann kennzeichnen, beide mit "Initial" ? Können wir für dieses Feld ein paar Beispiele bekommen?
Wenn wir Feld I bis III wie oben umsetzen, dann können wir dieses Feld weglassen, denke ich. Denn die Werte "Remake", "Enhanced" und "Demo Version" implizieren ja schon dieselbe Plattform. Die berüchtigten Flash-Demos von Windows/Mac-Spielen sollten wir dann im Feld I als "Original" kennzeichnen.

Und, gene, ist es so besser? :D
 #36469  by hydr0x
 22 Nov 2012, 00:01
Wie und ob man an die Infos kommen kann ist aber bei Pflichtfeldern sehr wichtig, man kann die Objektdomäne ja nicht aussen vor lassen bei der Planung einer Datenbank. Ich würde in einer Datenbank über Menschen vielleicht gerne IQ, sexuelle Vorlieben, Lieblinsgfilm oder was weiß ich festhalten, aber da man dass unmöglich zu jedem erfahrne kann darf es kein Pflichtfeld sein und schon gar kein Schlüsselfeld. Darauf muss man schon aufpassen :)
 #36479  by MZ per X
 25 Nov 2012, 12:02
hydr0x wrote:Wie und ob man an die Infos kommen kann ist aber bei Pflichtfeldern sehr wichtig, man kann die Objektdomäne ja nicht aussen vor lassen bei der Planung einer Datenbank.
Das ist selbstverständlich richtig. Um bei den beiden oben genannten Mussfeldern I und II zu bleiben: Wenn eine neue ReleaseGroup erstellt werden soll, muss ja vorher schon klar sein, warum sie erstellt wird, im Sinne von "Ah, hier gab es eine Demoversion oder ein Remake, oder die deutsche Version war kastriert, etc.". Und die beiden Mussfelder I und II konkretisieren dieses Wissen bloß.
 #36486  by hydr0x
 25 Nov 2012, 16:02
MZ per X wrote:
hydr0x wrote:Wie und ob man an die Infos kommen kann ist aber bei Pflichtfeldern sehr wichtig, man kann die Objektdomäne ja nicht aussen vor lassen bei der Planung einer Datenbank.
Das ist selbstverständlich richtig. Um bei den beiden oben genannten Mussfeldern I und II zu bleiben: Wenn eine neue ReleaseGroup erstellt werden soll, muss ja vorher schon klar sein, warum sie erstellt wird, im Sinne von "Ah, hier gab es eine Demoversion oder ein Remake, oder die deutsche Version war kastriert, etc.". Und die beiden Mussfelder I und II konkretisieren dieses Wissen bloß.
So umgehst du das Problem aber nur. Denn was du damit sagst ist ja folgendes. Wenn ich nicht weiß DAS es eine Emulator-Release ist (dass es eine Release gibt weiß ich aber zu 100%), dann bleibt mir nichts anderes übrig als ihn als nativ zu erfassen. Dies ist dann aber evtl. gar nicht richtig, und schon hat die nativ-Gruppierung jede Aussagekraft verloren da ich grundsätzlich nie sagen kann ob ein Spiel wirklich nativ ist oder nur noch nicht anders eingestuft wurde. Wenn schon bräuchtest du stattdessen also einen Case Case 1 --> New platform; unknown/default.
 #36489  by MZ per X
 25 Nov 2012, 20:58
hydr0x wrote:Wenn schon bräuchtest du stattdessen also einen Case Case 1 --> New platform; unknown/default.
Bevor wir aneinander vorbeireden: Das ist Feld III und soll ein Kannfeld sein. Wenn dieses Kannfeld leer ist, dann haben wir Deinen Case 1.