Open Registry of Game Information 

  • Datenmodell zu Spiel und VÖ (Teil 2)

  • 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

 #34760  by MZ per X
 22 Mar 2011, 21:48
So, floruc, ich schulde Dir noch eine Antwort. :) (Jetzt mal davon abgesehen, dass ich im anderen Thread ein Modell ohne VÖG vorgeschlagen habe.)

floruc wrote:1. Beispiel: Mal ganz banal, ein Spiel wird nur auf einer Plattform veröffentlicht und erhält gar keinen Patch (z.B. irgendein alter DOS-Klassiker). Er hat damit nur eine Version und alle wesentlichen Informationen sind aus VÖG/VÖ zu entnehmen.

Es gibt viele solcher Spiele. Sehr viele. Leider können wir uns bei der Entwicklung des Datenmodells nicht am einfachsten Beispiel orientieren, sondern müssen schauen, ob wir die schwierigen Spiele abbilden können.

floruc wrote:2. Beispiel: Ich nehme mal wieder mein NFSU2 Beispiel: Multiplattform Release, für PC wurde die beiden Patches 1.1 / 1.2 für die jeweiligen Sprachversionen veröffentlicht. Hier müsste man dann bei den Releases für die jeweilige Region die entsprechenden Patches verlinken. Die Budget Releases von NFSU2 für PC sind z.B. nicht gepatcht. Die Patches für die deutsche Version müsste dann sowohl für die deutsche Erstveröffentlichung als auch für das Budget Release auf der Ebene VÖ hinterlegt werden. Ok, das ist ein Stück Redundanz, die ich aber für verschmerzbar halte.

Lass dieses Spiel mal noch auf einem Dutzend Zeitschriften veröffentlicht werden und/oder in weiteren zig Budget-Releases in vielen Ländern. Das wird eine Fronarbeit, da überall die Patches zuzuordnen. Wenn Du einmal den Versionsstand eingegeben hast, kannst Du ihn jeder VÖ zuordnen und hast dann einen zentralen Ort, an dem Du zB die Patches und Systemanforderungen speichern kannst. Und durch die Zuordnung sind diese Infos dann sofort bei jeder VÖ sichtbar. Der Versionsstand vereinfacht solche Dinge einfach grundlegend.

floruc wrote:3. Beispiel: Für The Witcher wurde zeitverzögert eine Enhanced Version veröffentlicht. Diese gibt es als neu verpackte Ladenversion und als Patch-Download für die Besitzer der Erstveröffentlichung. Die neue Ladenversion ist eine neue VÖG, da die Inhalte des Spiels wesentlich erweitert/verändert werden. Hier greift das Kriterium für eine neue VÖG. Bei der Erstveröffentlichung würde ich den Patch bei den jeweiligen Veröffentlichungen hinterlegen. Evtl. kann man dort die Information hinterlegen, dass das Spiel damit der neuen VÖG Enhanced Edition gleicht. Würde uns der Patchlevel bei The Witcher wirklich helfen?

Schau mal hier, wieviele VÖ-Info dieses Spiel bei MobyGames hat, und das sind nur die VÖ des Originalspiels. Mit dem Versionsstand könntest Du einmal hinterlegen, welche Patches es für die jeweilige Vollversion gibt, und hättest die Info bei jeder VÖ mit diesem Versionsstand sofort dabei. Ohne große Handarbeit.

floruc wrote:Was soll der Patchlevel bei modernen Onlinerollenpielen oder auch bei Singleplayer Spielen mit komplexen Patchstrukturen abbilden: den aktuellen Stand oder auch die Versionshistorie?

Natürlich auch die Versionshistorie. Mein Ziel wäre es, dass der User irgendeine VÖ anklicken kann und sofort sieht, in welcher Version das Spiel dort enthalten ist und welche Patches er noch braucht, um die neueste Version spielen zu können. Und dass er gleich noch sieht, was diese Patches eigentlich verändern. :)

Moderne Onlinespiele sind natürlich noch ein anderes Kaliber, die werden ja fast täglich gepatcht und teilweise weiß niemand (mehr), wie die Versionshistorie eigentlich war. Bei diesem Genre werden wir uns wohl auf die Hauptpatches konzentrieren müssen.
 #34929  by mr orange
 06 May 2011, 12:55
Ich frage mich, ob man die Patches überhaupt benötigt. Wer hat ein Interesse daran, ob da - im schlimmsten Fall - lediglich drei Bugs beseitigt wurden. Da könnte man vielleicht eine Art Timeline oder "Lebenslauf" zu dem Spiel machen, in dem das erwähnt wird. Z. B. das Hinzufügen der Directx-/3dfx-Unterstützung damals bei Interstate 76.. Aber da jetzt noch extra einen eigenen Mechanismus einzubauen, der so was abbildet und einen erheblichen Aufwand bedeutet, sollte man sich - zumindest zu Beginn - sparen. Mit so etwas kommt man vom Hundertsten ins Tausendse, weil dann noch irgend was kommt - Vielleicht, wer den Patch entwickelt hat oder so.

Nee - So was sollte man in meinen Augen vielleicht später mal einführen. Lieber die ganze Struktur modular aufbauen und zuerst Kernfunktionen und dann nach und nach evtl. noch weitere Features (Wie die Patches eben)
 #34943  by floruc
 15 May 2011, 14:24
Ich halte das Thema Patches schon für interessant. Sie sind zwar in erster Linie für PC-Spiele der neueren Generation relevant, stellen aber mittlerweile einen wichtigen und praktisch nicht mehr wegdenkbaren Bestandteil von Spielen dar. Die Frage ist, wo man Grenzen bei der Dokumentation zieht. Im bisherigen Beispielthread zur Datenmodellierung von WoW habe ich ja die Patchhistorie, die bei Mobygames angefangen wurde, übernommen. Diese ist praktisch ewig lang und wird durch die zahlreichen Addons zusätzlich erschwert. Leider kenne ich mich bei WoW mangels eigener Spielerfahrung zu wenig aus, um zu beurteilen, welchen Einfluss die Patches auf das Spiel haben. Außerdem ist WoW ein schönes Beispiel dafür, dass insbesondere sehr neue Spiele immer häufiger auf ein Autopatchsystem setzen.
Als "Zwischenlösung" könnte ich mir allerdings eine Kooperation z.B. mit patches-scrolls vorstellen, die eine recht ausführliche Patch-Historie für viele Spiele pflegen. Evtl. könnten wir erstmal Links dorthin einpflegen und in einem zweiten Schritt die Überführung in unser Datenmodell vornehmen.
 #34949  by mr orange
 16 May 2011, 12:17
Ich sehe da allerdings das Problem kommen, dass ja etliches Patches/Updates teilweise nur für bestimmte Versionen eines Spiels herausgebracht wurden. Da stellt sich für mich die Frage nach der Praktikabilität, schließlich muss das einer einpflegen. Und ich glaube immer noch nicht, dass das jemand später nutzen wird.

Vielleicht dann höchstens einen Entity-Typ Patch oder Update oder so, wo sämtliche Patches/Updates für ein Spiel gespeichert werden (Version, Stichpunkte, Datum) - aber eben nicht aufgeschlüsselt nach Versionen.
 #34950  by mr orange
 16 May 2011, 12:28
http://www.oregami.org/forum/viewtopic.php?f=32&t=32689&start=0#p34861
Das hier ist irgendwie an mir vorbei gegangen.. Das gefällt mir schon ziemlich gut.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, z. B.:

Spiel:
"Lotus 2"
Version: "USA"
Systeme: Mega Drive, Amiga, PC
Entwickler: Sowieso, Sowieso 1, Sowieso 2
Publisher: ...

Das hätte man mit dem anderen System 3x speichern müssen (Mega Drive, Amiga, PC). Wo es nötig ist, könnte man hingegen, die Versionen stärker differenzieren, z. B.:
"Lotus 2"
Version: "USA Mega Drive"
Systeme: Mega Drive
Entwickler: Sowieso 3, Sowieso 4
Publisher: ...

etc.

Der Vorteil ist ganz klar weniger Redundanz. Was mich allerdings daran selber stört, ist, dass die Konsistenz der Versionen nicht gegeben ist.