Open Registry of Game Information 

  • Datenmodell: Abgesang auf den Versionsstand

  • 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

 #35604  by MZ per X
 07 Nov 2011, 19:39
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:
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.
floruc und gene hatten Bedenken, insbesondere floruc war der Meinung, wir bräuchten den Versionsstand gar nicht:
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.
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.
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.
Einen bei näherem Hinsehen ähnlichen Gedanken hatte auch Mr.Orange am Ende des ersten Threads geäußert:
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,...
Auch im Thread "Screenshot-Wirrwarr" klang dieses Thema zwischen florucs Zeilen mal mit an:
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.
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.

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.
 #35640  by gene
 14 Nov 2011, 22:56
Das bedeutet hauptsächlich, dass wir pro Spiel noch mehr VÖG brauchen werden, beispielsweise für jede Sprachversion eine.
Hmm, das gefällt mir überhaupt nicht.
Schauen wir uns mal dieses Bild an (ich habe auf die Schnelle einen meiner Entwürfe rausgesucht, und der hat auch noch die Versionen dargestellt):
lotus3_datenmodell.jpg
lotus3_datenmodell.jpg (89.54 KiB) Viewed 22373 times
Warum um alles in der Welt möchtest du auf einmal den "Baum" schon in der zweiten Schicht, der Veröffentlichungsgruppe, vergrößern? Das macht das daraus entstehende Datennetz meiner Meinung nach echt unübersichtlich, da die schöne, einfache Struktur "Spiel => System => Einzelveröffentlichung".

Meiner Meinung nach sollten wir den bisherigen Ansatz nicht "verwerfen", sondern einen anderen Weg wählen. Du sprachst ja schon an, dass man evtl. gar nicht weiß, zu welcher Version des Spiels ein Screenshot etc. gerade gehört oder vielleicht sind auch noch gar keine Details zu den Versionen eingetragen. Zu welchem System der gerade gemachte Screenshot gehört, sollte man auf jeden Fall wissen :D 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.
Parallel dazu kann man irgendwann und irgendwie die existierenden Versionen eines Spiels pflegen. Falls man dann weiß, zu welcher Version der Screenshot etc. gehört, kann man dann *zusätzlich* oder *nachträglich* diese Zuordnung vornehmen! Dadurch fällt der "Zwang" weg, dass man Details zu den Versionen haben muss, um Screenshots etc. einzureichen.
Außerdem blähen wir unsere Veröffentlichungsgruppen nicht unnötig auf! 8)

Ihr seid an der Reihe...
 #35787  by floruc
 01 Jan 2012, 21:46
Ich würde es auch sehr befürworten den Versionsstand als 4.Hierarchieebene zu begraben. Ich sehe ebenfalls massive Praxisprobleme auf uns zukommen (nicht nur bei Monkey Island).

Ich kann 100% verstehen, dass du die verschiedenen Versionen im Datenmodell abbilden willst. Und ich fände auch super, wenn wir das könnten. Aber wie du ja schon selbst anmerkst, müssen wir einen praktikablen Weg finden.

Ich denke, dass wir mit dem bisherigen Modell eigentlich schon eine ganze Menge abdecken können, ohne noch mehr VÖGs einführen zu müssen.

Einfache Patches zu bestimmten Spielen können wir entweder bei der VÖG bzw. VÖ einfach als Downloadlink hinterlegen (siehe bei der X-Wing Windows Compilation als Beispiel). In Ausnahmefällen lohnt es sich auch sicherlich inoffizielle Patches zu dokumentieren (z.B. Gothic 3, Vampire Bloodlines). In meinen Augen würde aber ein entsprechendes Feld bei der VÖG / VÖ mit Link ausreichen (z.B. zu Patches Scrolls).
Wenn tatsächlich ein riesiger Patch erscheint, der das Spiel sehr stark verändert (Bsp. The Witcher v 2.0 bzw. die Enhanced Edition), kann man ja tatsächlich eine neue VÖG anlegen, um das wiederzugeben.

Die verschiedenen Sprachversionen würde ich nicht als eigene VÖG abbilden, weil wir dann fast nur noch VÖG bekommen und diese dann praktisch sinnlos wird. Man bräuchte dann ja für fast jede VÖ eine eigene VÖG. Sprachversionen würde ich wie bisher bei der VÖ mit den Feldern "Textausgabe" bzw. "Sprachausgabe" beschreiben.
 #35877  by wingi
 17 Jan 2012, 10:58
Hmmm, gerade die verschiedenen Sprachversionen entsprechen den verschiedenen Titelcovern. Zu einer französischcen Spieleversion möchte ich kein deutsches Cover (ohne Kommentar) anzeigen.
 #36027  by MZ per X
 13 Jun 2012, 19:41
So, nachdem wir nun die Vereinssatzung und unsere neue Website entworfen haben, ist es an der Zeit sich wieder dem Datenmodell zuzuwenden. Ich möchte diesen Thread hier nutzen um das Datenmodell zu Patches festzuzurren.

Was ist ein Patch?

Ein Patch ist ein kostenloses Update für ein Spiel, das mit dem Ziel der Fehlerbereinigung / Nachbesserung veröffentlicht wird. Im Gegensatz dazu gibt es kostenlose Updates, die mit dem Ziel erweiterten Spielinhaltes veröffentlicht werden. Die heißen dann Addons. :)

Wenn ein kostenloses Update beides tut, also Fehler bereinigen und den Spielinhalt erweitern, dann sollte zunächst geschaut werden, ob das Update eher als Patch oder als Addon vermarktet wird. Im Zweifel sollte es als Addon in die Datenbank aufgenommen werden.

Wie passen Patches in unser Datenmodell?

Ich hatte zunächst überlegt, Patches mit einem eigenen Spieleintrag (wie Addons) in die Datenbank aufzunehmen, da sie einige Gemeinsamkeiten mit Addons aufweisen. Den Gedanken habe ich aber schnell wieder verworfen, da das in meinen Augen Overkill wäre und die Spiele-Tabelle unnötig aufblähen würde. Zu den Patches kann man einfach nicht so viele Daten zuordnen, dass ein eigener Spieleeintrag gerechtfertigt wäre.

Also bekommen Patches ihre eigene Tabelle. Ich denke, es ist relativ klar, dass Patches zur VÖG zugeordnet werden müssen. Für die Zuordnung zum Spiel sind sie einfach zu systemspezifisch, die Zuordnung zur einzelnen VÖ wäre zu redundant.

Was die Beziehungen angeht, so muss es in meinen Augen eine n-n-Beziehung sein. Jeder VÖG können natürlich mehrere Patches zugeordnet werden, das ist klar. Aber es wird wahrscheinlich auch Patches geben, die zwei oder mehr VÖG zugeordnet werden können. Vielleicht gibt es sogar Hybrid-Patches, Mac/Win oder so? Ich weiß es nicht, aber möglich ist es schon.

Welche Daten müssen wir zu einem Patch speichern?

Patchname / Version: "Version 1.1 deutsch"
VÖ-Datum: "24.12.2011"
Sprache(n): "deutsch"
Schalter: authorisiert / nicht authorisiert (vom Publisher/Entwickler)
Bemerkung zu Schalter: "Erster Patch der deutschen Community."

Weiterhin würde ich gerne noch dokumentieren, was genau ein Patch für Probleme behebt. Das wird sich nicht anders als über ein freies Textfeld machen lassen.

Abschließend würde ich gerne noch abbilden, wenn ein Patch die Systemvoraussetzungen und technischen Spezifikationen eines Spiels verändert. Dazu müsste man irgendwie ein Delta zu den ursprünglichen Specs abspeichern können.

So, was meint Ihr dazu? :)
 #36030  by Independent
 14 Jun 2012, 08:48
Was ist ein Patch?

Ein Patch ist ein kostenloses Update für ein Spiel, das mit dem Ziel der Fehlerbereinigung / Nachbesserung veröffentlicht wird. Im Gegensatz dazu gibt es kostenlose Updates, die mit dem Ziel erweiterten Spielinhaltes veröffentlicht werden. Die heißen dann Addons. :)
Wenn ein kostenloses Update beides tut, also Fehler bereinigen und den Spielinhalt erweitern, dann sollte zunächst geschaut werden, ob das Update eher als Patch oder als Addon vermarktet wird. Im Zweifel sollte es als Addon in die Datenbank aufgenommen werden.
Es gibt kein zweifel. Ein patch bringt immer verbesserungen und sollte spiel inhalte verbessert werden oder ausgebaut werden ist es trotzdem ein patch bei mir.

Ein add-on ist ein add-on dessen spiele mechanik verändert bzw neues hinzu kommt. Früher sagte man add-on dazu heute ist es ein DLC. Patches sind immer kostenlos, DLC nie bzw. sehr selten. Klar werden DLC auch kostenlos angeboten diese sind aber kein patch sondern ein add-on weil sie den spiel neue elemente hinzufügen.

Sollte ein patch die mechanik ändern/inhalte hinzufügen beruht dies auf eine fehlerhafte verkaufsversion und soll den spieler beruhigen. Es bleibt aber ein patch.

Wenn der herstelle ein dlc veröffentlicht wo auch bugs gefixt werden ist es ein addon.
Crysis 2: Da gibt es High Textures map zum beispiel. Diese sind kein patch sondern eine verbesserung des spiels also sozusagen ein kostenloses dlc bzw. add-on.

Also: Patch ist ein patch ob nur bugs gefixt wurden oder neue einheiten hinzu kommen sdpielt keine rolle.
Add-on bzw. DLC: Ist eine erweiterung des hauptspiels auch wenn bugs gefixt wurden.
Was die Beziehungen angeht, so muss es in meinen Augen eine n-n-Beziehung sein. Jeder VÖG können natürlich mehrere Patches zugeordnet werden, das ist klar. Aber es wird wahrscheinlich auch Patches geben, die zwei oder mehr VÖG zugeordnet werden können. Vielleicht gibt es sogar Hybrid-Patches, Mac/Win oder so? Ich weiß es nicht, aber möglich ist es schon.
Habe ich noch nie gesehen das ein patch für 2 systeme gleichzeitig ist. Wenn ein patch für win7 rauskommt und eins für linux sind es 2 patches für 2 systeme die je ein eintrag haben müssen. oder verstehe ich da was nicht?
Weiterhin würde ich gerne noch dokumentieren, was genau ein Patch für Probleme behebt. Das wird sich nicht anders als über ein freies Textfeld machen lassen.
Jup copy and paste vom hersteller.

Zurückgezogen vom hersteller weil... (fehlerhaft, keine angaben warum (Deadspace 2) etc.
Erneut veröffentlicht vom hersteller weil....
die größe des patches
ein link zum patch. Achtung: hier sollten wir immer auf eine seite verlinken die die patches immer on haben wie http://www.dlh.net zum beispiel. Mit denen sollten wir dann mal reden, keine direkt links natürlich.
Die auflistung des patches ist aus meiner sicht sehr wichtig.
Im zusammenarbeit mit der community/hersteller, also der hersteller hört auf die community wie eve online.
Patch rückgängig gemacht weil: vieles zu kompliziert gemacht wurde (eve online)
 #36031  by MZ per X
 14 Jun 2012, 11:15
Independent wrote:
MZ per X wrote:Ein Patch ist ein kostenloses Update für ein Spiel, das mit dem Ziel der Fehlerbereinigung / Nachbesserung veröffentlicht wird. Im Gegensatz dazu gibt es kostenlose Updates, die mit dem Ziel erweiterten Spielinhaltes veröffentlicht werden. Die heißen dann Addons. :)
Wenn ein kostenloses Update beides tut, also Fehler bereinigen und den Spielinhalt erweitern, dann sollte zunächst geschaut werden, ob das Update eher als Patch oder als Addon vermarktet wird. Im Zweifel sollte es als Addon in die Datenbank aufgenommen werden.
Klar werden DLC auch kostenlos angeboten diese sind aber kein patch sondern ein add-on weil sie den spiel neue elemente hinzufügen.
Und diese Unterscheidung ist genau der springende Punkt.

Wenn ein Update Geld kostet, kann es kein Patch sein. Kostet es kein Geld, müssen wir schauen, wie es vermarktet wird. Spielerweiternde Updates werden auch als solche vermarktet werden, die Publisher sind schließlich nicht blöde. :) Ist die Vermarktung trotz allem unklar, dann sehen wir uns die Inhalte des Updates an und entscheiden danach. Dieser letzte Fall dürfte aber nur extrem selten eintreten.
Independent wrote:
MZ per X wrote:Vielleicht gibt es sogar Hybrid-Patches, Mac/Win oder so? Ich weiß es nicht, aber möglich ist es schon.
Habe ich noch nie gesehen das ein patch für 2 systeme gleichzeitig ist. Wenn ein patch für win7 rauskommt und eins für linux sind es 2 patches für 2 systeme die je ein eintrag haben müssen. oder verstehe ich da was nicht?
Doch, Du verstehst das goldrichtig. Ein Windows/Linux-Hybridpatch wäre auch ein krasses Beispiel, das wohl so nie passieren wird.

Aber rein theoretisch könnte ich mir so etwas durchaus vorstellen, zB einen Patch für alle Unix-Systeme oder so. Wir sollten diesen Fall also abbilden können, denke ich.
Independent wrote:
MZ per X wrote:Weiterhin würde ich gerne noch dokumentieren, was genau ein Patch für Probleme behebt. Das wird sich nicht anders als über ein freies Textfeld machen lassen.
Jup copy and paste vom hersteller.
Darauf wird es hinauslaufen, ja. :) Ich hatte noch überlegt, ob man eventuell die Patches irgendwie kategorisieren sollte, mit zusätzlichen Schaltern. Aber das wird wohl nicht so sinnvoll sein.
Independent wrote: Zurückgezogen vom hersteller weil... (fehlerhaft, keine angaben warum (Deadspace 2) etc.
Erneut veröffentlicht vom hersteller weil....
die größe des patches
ein link zum patch. Achtung: hier sollten wir immer auf eine seite verlinken die die patches immer on haben wie http://www.dlh.net zum beispiel. Mit denen sollten wir dann mal reden, keine direkt links natürlich.
Die auflistung des patches ist aus meiner sicht sehr wichtig.
Im zusammenarbeit mit der community/hersteller, also der hersteller hört auf die community wie eve online.
Patch rückgängig gemacht weil: vieles zu kompliziert gemacht wurde (eve online)
Sehr interessante Vorschläge, danke!

Den Feldern "zurückgezogen am" (Datumsfeld) und "zurückgezogen weil" (Textfeld) sowie Patchgröße würde ich sofort zustimmen. Die Wiederveröffentlichung eines Patches würde ich dagegen als neuen Patch sehen.

Links sind auch gut, aber zur wirklichen Langzeit-Dokumentation sehe ich sie nur als Zwischenlösung. Irgendwann wollen wir sicher die Patches auf unseren eigenen Servern anbieten. :D
 #36032  by Independent
 15 Jun 2012, 06:04
Wenn ein Update Geld kostet, kann es kein Patch sein. Kostet es kein Geld, müssen wir schauen, wie es vermarktet wird. Spielerweiternde Updates werden auch als solche vermarktet werden, die Publisher sind schließlich nicht blöde. Ist die Vermarktung trotz allem unklar, dann sehen wir uns die Inhalte des Updates an und entscheiden danach. Dieser letzte Fall dürfte aber nur extrem selten eintreten.
Ein patch für ein spiel wo ich geld bezahlen muss ist mir noch nie unter die augen gekommen. Ein dlc der das programm erweitert aber gleichzeitig auch patches fixt die spielerelevant sind ist mir auch noch nie unter die augen gekommen.
Als beispiel: Mass Effect 3, verkaufsversion. Diese kann ich durch spielen ohne probleme. Jetzt kommt ein dlc der das spiel um eine zusätzliche mission erweitert aber gleichzeitig die ballance ändert(ist mir noch nie unter die augen gekommen, wenn dem so ist kam ein patch für das spiel raus) ist für mich ein dlc aber kein patch wo ich geld bezahlen muss um dieses durchzu spielen. Ich kann ME 3 auch so durchspielen.
Patches sind grundsätzlich kostenlos egal ob sie bugfixing machen, balance ändern, einheiten löschen oder was auch immer. Alles was die verkaufsversion beinhaltet und geändert wird ist, bleibt und war schon immer kostenlos.
Ein DLC erweitert das spiel um zusätzliche missionen, neue einheiten. Selbst wenn der panzer als beispiel weniger hitpoints bekommt(was ich noch nie erlebt habe) muss ich es nicht kaufen um das spiel durch zu spielen.
Kostenlose updates nenne sich kostenlose updates und nicht add-on. Aber wo ist der unterschied? Patch sagen wir, computerbild verbesserungsprogramm, der entwickler patch……
Ganz früher wo noch software rendering in war, so der übergang zu 3dfx kamen kostenlose updates raus. Dies war zum beispiel bei independence war so. Es kam ein update raus wo ich das spiel mit 3dfx unterstützung spielen konnte, es aber nicht musste. Es war ein update nicht mehr nicht weniger und es war kostenlos. Man sagte auch patch da zu.

Patch: Verbessert das hauptprogramm. Ob grafik, mechanik, einheiten balancing oder was auch immer es ist und bleibt ein patch was kostenlos ist.
DLC: Alles was der hersteller kostenlos zu verfügung stellt. Neue missionen, neue einhielten, neue multiplayer maps etc. ob kostenlos oder gegen bares spielt keine rolle. Selbst wenn dadurch einheiten verbessert wurden ist es kein muss dies zu kaufen.
Das geht auch ja gar nicht. Da ist spiel x wo festgestellt wird das einheit y zu stark ist. Jetzt bringe ich ein dlc raus was dies bereinigt + 2wweitere maps und soll dafür zahlen?
Call of Duty, dieses stim pack mit zusätzlich mp maps. Ich muss es nicht kaufen wenn ich es nicht spielen will und es wird auch nix an der balance des spiels geändert.
Patches müssen nicht zwingend installiert werden um das spiel spielen zu können. Es gibt hersteller die das machen (BF, 3 oder eve online da wo es sinn macht) aber trotzdem bleibt es kostenlos.
Update, ja was ist ein update…. Grübel….

Ein update so könnte ich es mir vorstellen war früher das wenn hersteller ein 3dfx patch rausgebracht haben da nur die grafik aufgewertet wurde. Es war mkostenlos un man musste es nicht kaufen m das spiel spielen zu können. Ich weis das weil ch dieses spiel hatte in der verkaufsversion ein bug war (man konnte es nicht durchspielen) und der 3dfx patch auch nix daran geändert hat bzw. der patch vorher erschienen ist. Ob der bug im 3dfx patch auch behoben wurde weis ich nciht aber es war kostenlos.

Edit: Da fällt mir noch ein was man auch noch erwähnen sollte: Wenn der hersteller ein patch anbietet wo die community aber gar nicht begeistert ist. Auch hier wieder eve online. CCP hatte mal vor das man im spiel selbst bessere munition gegen echtes geld kaufen konnte und so die mechanik des spiels verändern würde. Daraus haben sich ergeben das sehr viele spiele in jita (handelszentrum) als protest auf ein bauwerk schoss und so eve zum erliegen brachte und ccp sich entschuldigt hat dafür und die pläne begrub.

http://www.youtube.com/watch?feature=pl ... ESgZCM0iAQ
http://www.pcgameshardware.de/aid,83156 ... ture/News/
 #36033  by MZ per X
 15 Jun 2012, 08:04
Independent wrote:Patches sind grundsätzlich kostenlos egal ob sie bugfixing machen, balance ändern, einheiten löschen oder was auch immer. Alles was die verkaufsversion beinhaltet und geändert wird ist, bleibt und war schon immer kostenlos.Ein DLC erweitert das spiel um zusätzliche missionen, neue einheiten. Selbst wenn der panzer als beispiel weniger hitpoints bekommt(was ich noch nie erlebt habe) muss ich es nicht kaufen um das spiel durch zu spielen.
Weißt Du, was ich glaube? Ich glaube, dass wir beide einer Meinung sind, was Patches angeht! :)
Independent wrote:Edit: Da fällt mir noch ein was man auch noch erwähnen sollte: Wenn der hersteller ein patch anbietet wo die community aber gar nicht begeistert ist. Auch hier wieder eve online. CCP hatte mal vor das man im spiel selbst bessere munition gegen echtes geld kaufen konnte und so die mechanik des spiels verändern würde. Daraus haben sich ergeben das sehr viele spiele in jita (handelszentrum) als protest auf ein bauwerk schoss und so eve zum erliegen brachte und ccp sich entschuldigt hat dafür und die pläne begrub.
Wenn ein Patch nie veröffentlicht wurde, gehört er auch nicht in die Patchabteilung. Solche Sachen, wie Du sie beschreibst, sind eher Trivia.
 #36034  by Independent
 15 Jun 2012, 09:41
Klar das wäre ein trivia. Aber es gab zum beispiel bei eve patches die alles komplizioerter gemacht haben und sachen die keiner braucht und haben wollte aber ccp sich ein dreck darum gekümmert hat. Erst als wir alle in jita auf ein bauwerk geschossen haben war alles wieder so wie es vorher auch war. Sprich der patch wurde rückgängig gemacht war aber offiziell erschienen.
 #36035  by MZ per X
 15 Jun 2012, 12:16
Independent wrote:Sprich der patch wurde rückgängig gemacht war aber offiziell erschienen.
Okay, dafür werden wir ja die Felder "zurückgezogen am" und "zurückgezogen weil" integrieren. Dein vorheriger Beitrag klang für mich so, als wäre dieser problematische Patch gar nicht erschienen.

Danke für Deinen Input! :)
 #36051  by Independent
 21 Jun 2012, 14:21
Was man auch noch schreiben kann:

Ob der patch speicherstände unbrauchbar macht.
Und ob es ein muss patch ist. Logisch das jeder patch eigentlich installiert werden solte aber ich ertappe mich auch hin und wieder dabei wo ich es nicht tue.
 #36053  by MZ per X
 21 Jun 2012, 16:42
Independent wrote:Ob der patch speicherstände unbrauchbar macht.
Das ist eine Information, die wir aufnehmen sollten, ja.
Independent wrote:Und ob es ein muss patch ist. Logisch das jeder patch eigentlich installiert werden solte aber ich ertappe mich auch hin und wieder dabei wo ich es nicht tue.
Das hört sich für mich relativ subjektiv an. Oder meinst Du hier nur Patches, ohne die man das Spiel zB nicht beenden kann?