So, liebe Mitstreiter, wie der Titel dieses Threads schon andeutet, möchte ich mich heute von meinen Idealvorstellungen zum Thema Versionsstand offiziell verabschieden und damit die finale Diskussion zum letzten "großen" Aspekt unseres Spiele-Datenmodells lostreten.
Zunächst möchte ich jedoch den Diskussionsstand nochmal zusammenfassen, den wir uns zu diesem Punkt in anderen Threads bereits erarbeitet hatten.
Im Thread "Datenmodell zu Spiel und VÖ (Teil 2)" hatten wir die grundsätzliche Theorie des Versionsstandes entwickelt und diskutiert:
Das Problem ist die Praxis. Ich habe anhand unserer Wikiseite von Monkey Island und den im Netz verfügbaren Daten versucht, die Theorie in die Praxis umzusetzen und die verschiedenen Versionsstände für MI zu identifizieren. Ich sehe mich aber nicht in der Lage, das zu einem befriedigenden Ergebnis zu bringen. Und ich sehe auch unsere späteren User nicht in der Lage, diesen Teil des Datenmodells (insbesondere für ältere/unbekannte Spiele) in eine funktionierende Praxis umzusetzen. Öfter weiß man zunächst nur, dass es eine VÖ gab, aber niemand hat sie. Und wenn sie jemand besitzt, kann er sie vielleicht nicht mehr installieren/spielen. Und was machen wir dann, wenn niemand Versionsstände einstellen kann oder will, aber alle wollen Screenshots und technische Specs supporten? Tja.
Das ist einfach ein Fall, wo ich zugeben muss: Es wird unpraktikabel, wir müssen die Idee der Speicherung des Versionsstandes pro VÖ begraben. Und das tue ich hiermit, wenn Ihr einverstanden seid.
Ein anderer Weg muss her, und ich sehe hier keinen anderen als die Erweiterung der VÖG um die am Versionsstand hängenden Daten. Das bedeutet hauptsächlich, dass wir pro Spiel noch mehr VÖG brauchen werden, beispielsweise für jede Sprachversion eine. Aber was soll's, bis jetzt denke ich noch, dass wir das Konzept der VÖG durch eine geschickte Benutzerführung ganz gut vor dem User werden verstecken können, also wird es uns auch nicht weh tun, wenn wir pro Spiel noch mehr VÖG haben.
Wenn Ihr zustimmt, werde ich in meinen nächsten Beiträgen Vorschläge zur Abbildung der o.g. Daten (Patches, Screenshots, Technik, Zensur) unterbreiten.
Zunächst möchte ich jedoch den Diskussionsstand nochmal zusammenfassen, den wir uns zu diesem Punkt in anderen Threads bereits erarbeitet hatten.
Im Thread "Datenmodell zu Spiel und VÖ (Teil 2)" hatten wir die grundsätzliche Theorie des Versionsstandes entwickelt und diskutiert:
floruc und gene hatten Bedenken, insbesondere floruc war der Meinung, wir bräuchten den Versionsstand gar nicht:Nun gibt es einige Daten, die für all die VÖ identisch sein müssten, die den gleichen Versionsstand des Spiels enthalten. Die Hauptbeispiele hierfür sind die technischen Spezifikationen und Infos zur Zensur. D.h. wenn ich also beispielsweise irgendeine deutsche Version eines zensierten Spiels kaufe, sei es nun die Erst-VÖ oder die Software-Pyramide-Version, dann werden beide VÖ wahrscheinlich dieselbe zensierte deutsche Version enthalten. Aus diesem Grund würde ich gerne den Versionsstand als vierte Datenebene definieren, um dort all diese Daten redundanzfrei sammeln zu können, die sich nur mit einem neuen Versionsstand ändern können.
Jeder VÖ wird ein Versionsstand zugeordnet, aber ein Versionsstand kann durchaus aus mehreren Einzelpatches bestehen. Ein neuer Versionsstand entsteht dann, wenn das Spiel mit diesem Versionsstand komplett veröffentlicht wurde. Ein neuer Versionsstand entsteht nicht bei einem einzelnen Patch, der als Ergänzung einer bereits veröffentlichten Version hinterher geschmissen wurde.
Im Thread "Datenmodell am Beispiel von Lotus 2" hatte ich gene gleich am Anfang mit einem radikalen Vorschlag geschockt, die VÖG aus unserem Datenmodell rauszuschmeißen und stattdessen den Versionsstand zu verwenden.So ganz überzeugt, dass wir ihn unbedingt brauchen, bin ich aber noch nicht. Natürlich gehören diese zu den "neueren" Spielen hinzu und ich bin auch dafür, dem in diesem Modell Rechnung zu tragen. Dennoch meine ich, dass man nicht noch eine 4.Hierarchieebene Versionsstand benötigt. Alle wesentlichen Aspekte lassen sich doch auch auf den bisherigen Ebenen VÖG/VÖ abbilden.
Einen bei näherem Hinsehen ähnlichen Gedanken hatte auch Mr.Orange am Ende des ersten Threads geäußert:Die VÖG (Plattform) ist eigentlich überflüssig, weil alle Informationen, die dort gespeichert werden sollen, sowieso in der Programmstandstabelle vorhanden sind. Ich schlage also vor, die VÖG (PLattform) wegzulassen. Ich weiß, ich habe vorher vehement für die VÖG argumentiert, aber die Meinung ändert sich halt, je tiefer man einsteigt.
Auch im Thread "Screenshot-Wirrwarr" klang dieses Thema zwischen florucs Zeilen mal mit an:Allerdings stelle ich mir die Frage, ob man statt
spiel->system->erstveröffentlichung
eben nicht lieber
spiel->version->systeme
spiel->version->veröffentlichungen
macht (Systeme und Veröffentlichungen sollen beide von Version ausgehen)
Dann könnte man eine Version für mehrere Systeme/Termine zusammen fassen, wenn die gleich oder ähnlich sind und man hat nicht mehr so viel Redundanz. Andererseits hätte man die Flexibilität, die Versionen nach beliebigen Gesichtspunkten aufzubauen,...
Nun ist die Theorie zum Versionsstand für mich immer noch klar und eindeutig: Es gibt veröffentlichte Versionsstände eines Spiels und Patches dazu, jede VÖ beinhaltet einen bestimmten Versionsstand und an diesem hängen weitere Daten wie technische Spezifikationen, Screenshots, Zensur mit dran.Außerdem würde ich die Screenshots nicht unbedingt in das hierarchische Datenmodell einordnen. Man kann doch die Screenshots eigentlich mit allen nötigen Informationen zu System/Version/Sprache... versehen. Sie hätten dann praktisch ihr eigenes Datenmodell. Das würde sich natürlich an unserem Modell zur Beschreibung der Veröffentlichungen orientieren, wäre aber nicht an dessen Hierarchie gebunden.
Das Problem ist die Praxis. Ich habe anhand unserer Wikiseite von Monkey Island und den im Netz verfügbaren Daten versucht, die Theorie in die Praxis umzusetzen und die verschiedenen Versionsstände für MI zu identifizieren. Ich sehe mich aber nicht in der Lage, das zu einem befriedigenden Ergebnis zu bringen. Und ich sehe auch unsere späteren User nicht in der Lage, diesen Teil des Datenmodells (insbesondere für ältere/unbekannte Spiele) in eine funktionierende Praxis umzusetzen. Öfter weiß man zunächst nur, dass es eine VÖ gab, aber niemand hat sie. Und wenn sie jemand besitzt, kann er sie vielleicht nicht mehr installieren/spielen. Und was machen wir dann, wenn niemand Versionsstände einstellen kann oder will, aber alle wollen Screenshots und technische Specs supporten? Tja.
Das ist einfach ein Fall, wo ich zugeben muss: Es wird unpraktikabel, wir müssen die Idee der Speicherung des Versionsstandes pro VÖ begraben. Und das tue ich hiermit, wenn Ihr einverstanden seid.
Ein anderer Weg muss her, und ich sehe hier keinen anderen als die Erweiterung der VÖG um die am Versionsstand hängenden Daten. Das bedeutet hauptsächlich, dass wir pro Spiel noch mehr VÖG brauchen werden, beispielsweise für jede Sprachversion eine. Aber was soll's, bis jetzt denke ich noch, dass wir das Konzept der VÖG durch eine geschickte Benutzerführung ganz gut vor dem User werden verstecken können, also wird es uns auch nicht weh tun, wenn wir pro Spiel noch mehr VÖG haben.
Wenn Ihr zustimmt, werde ich in meinen nächsten Beiträgen Vorschläge zur Abbildung der o.g. Daten (Patches, Screenshots, Technik, Zensur) unterbreiten.
Zu welcher Veröffentlichung sollte auch kein Problem sein, denke ich. Also sollte man auf jeden Fall Screenshots etc. zu Einzelveröffentlichungen zuordnen können.
