Antwort auf den Beitrag "Re:Sacred 2 PC: Probleme eines Spieleentwicklers (Zitiert)" posten:
Nickname:		Passwort:
Thema:
Nachricht:	>Hi, hab eben auf Gamestar.de die Kommentare zum Sacred 2 Release Patch gelesen und bin auf folgenden (langen) Kommentar gestoßen. Er beleuchtet meines Erachtens recht geht die Probleme der Spiel/Softwareentwicklung und zeigt auch gut die Publisher-Entwickler Beziehung: > >Hallo zusammen, > >kurze Anmerkung vorneweg: Im Gegensatz zu einigen anderen, beinhaltet mein Username(SMaton) hier auf Gamestar.de meinen *echten* Namen. D.h. wenn ihr an bestimmten Stellen nach Maton sucht, werdet ihr mich finden ;) Gleichzeitig merke ich hier auch an, dass ich meine eigene Meinung vertrete und das meine Aussagen *nicht* die Meinungen oder Ansichten anderer Personen oder Firmen widerspiegeln. > >So... nun zum Thema: > >Ich erspare euch die Suche und sage hier mal ganz offen, dass ich bis August *letzten* Jahres als freiberuflicher Programmierer an Sacred 2 gearbeitet habe. Neben der Core Technologie habe ich u.A. an der Basis für die NPCs (Tagesabläufe etc) und an der Entwicklung der Gegner gearbeitet. August *letzten* Jahres habe ich aus persönlichen Gründen den Vertrag mit Ascaron/Studio II aufgekündigt. Ich kann deswegen nichts genaues zum Ablauf innerhalb der Produktion von Sacred 2 bis zum Release sagen. Ich weis nichts über Verträge oder sonstige Abmachungen, die an irgendeiner Stelle in Bezug auf Sacred 2 gemacht wurden. > >Allerdings bin ich seit 12 Jahren mehr oder weniger in der Spiele-Branche. Ich habe sozusagen mein Standbein sowohl in der Spielebranche als auch in der "seriösen" Branche... D.h. meine Aussagen hier haben einen Erfahrungshintergrund und basieren nicht auf Vermutungen, Hoffnungen oder sonstigen der Fantasie entsprungenen Vorstellungen. > >Meine Aussagen sind gleichzeitig auch keine Entschuldigung für irgendwas, sondern vielmehr ein Appell für ein gewisses Verständnis dem gegenüber, was "hinter den Kulissen" geschieht und eine Bitte darum, die Leute, die dieses Werk geschaffen haben, zu respektieren und in ihrer Kritik (und ihrer Wut) konstruktiv und freundlich zu bleiben. > >Ich kann vollkommen verstehen, dass diejenigen, die Probleme haben, das Spiel auf ihrem Rechner zu spielen, gefrustet und wütend sind. Schließlich sind es zu 90% die gleichen, die das Spiel seit Monaten beobachten und als ihres Geldes würdig befinden. > >Es ärgert mich auch, wenn ich ein Spiel kaufe und Probleme habe, es auf meinem Rechner zu starten. Aber ich weis nicht wieso... das passiert mir kaum. Obwohl ich meinen Rechner (mit Vista) seit 2 Jahren vollmülle, Software installiere und wieder runterschmeisse und alles mögliche ausprobiere. Gleichzeitig ist der Rechner mein Arbeitsrechner. Ich scheine also eine Konfiguration zu haben, die "spielefreundlich" ist. Und hier sind wir beim ersten Problem, welches PC spezifisch ist: Jeder User hat seinen Rechner mehr oder weniger individuell gestaltet. Sei es die Hardwarezusammenstell ung oder die installierte Software, die auf dem Rechner benutzt wird. Und zur installierten Software gehört nicht nur euer Office Paket, der Webbrowser oder andere Spiele. Dazu gehören auch Treiber, Windowsupdates, Codecinstallationen, etc. > >Alleine die schier unendlich große Menge an Treibern für Grafikkarten machen ein vernünftiges Testen schwierig. Beispiel: Laptops. Die Laptop Hersteller verbauen meist mobile Versionen der Grafikchips. Diese beinhalten zwar chiptypische Bezeichnungen, sind allerdings auf niedrigeren Stromverbrauch geeicht. Der Laptop Hersteller geht nun in vielen Fällen hin und "optimiert" (*hüstel*) die Treiber des Chipherstellers, um den Grafikchip mit der im Laptop verbauten Hardware in Einklang zu bringen. > >Und da fängt an vielen Stellen der Ärger schon an: Der Spieler will jetzt seine Grafikkartentreiber auf seinem Laptop auf den neuesten Stand bringen, weil Spiel XYZ rausgekommen ist. Schließlich steht in der Anleitung (die wir alle ja immer Lesen *nochmalhüstel*), dass wir die neuesten Treiber installiert haben sollen. Sosie Rosie... also flott mal zu NVidia, AMD/ATI und Treiber gezogen. Tja... da kann es doch glatt passieren, dass die Treiber des Chipherstellers sich nicht installieren lassen mit dem Hinweis, man solle doch bitte beim Hersteller des Laptops nach neuen Treibern schauen. Der jedoch hat keinerlei Update. Spieler sind ja nun keineswegs dumm. Da gibt es dann eine gewissen Anzahl von Leuten, die sich in Ihrer Freizeit darum kümmern, Treiber auf ihrer Hardware zum Laufen zu bringen. Und diese Treiber werden dann von einigen anderen Spielern installiert. Das diese Treiber nicht unbedingt *ok* sind, interessiert nicht. Man hat schließlich jetzt die "neuesten" Treiber auf seinem Rechner. > >Aber "Oh Graus", das Spiel startet nicht richtig und zeigt nur Mist auf dem Bildschirm an. > >Jetzt muss man sich die Frage stellen: Warum ist das so? Wieso hat der Hersteller es verdammt nochmal nicht ordentlich programmiert, damit das Spiel auch auf meinem Laptop vernünftig läuft? > >Die Antwort ist: Der Hersteller hat sein bestes getan, um das zu testen. Heutzutage hat so manche Firma, die Spiele testet, mehrere Dutzend Rechner im Einsatz, mit verschiedenen Softwareinstallatione n, verschiedenen Treiberversionen, verschiedenen Windows Service Packs, etc. Und auf denen wird getestet. Das ist von vornherein schon ein riesen Aufwand "nur" die saubere Installation und den ersten Start zu testen. > >Ich kann mich daran erinnern, dass wir bei dem Publisher, bei dem ich vor mehrere Jahren gearbeitet habe, 15-20 Rechner hatten mit verschiedener Hardware. Da wurde dann ein frisches Windows auf die Festplatte gespielt und gleich hinterher das Spiel. Das waren DAMALS die Tests. Wenn das auf einem frischen Rechner sauber startet und danach spielbar ist, dann war das damals ok! > >Heutzutage werden dann Treiberversionen getestet. Im Grafikbereich muss dann evtl. je nach Treiberversion um einen "Bug" im Treiber herum programmiert werden. Das ist Realität! > >Und das war jetzt groß und breit nur ein Hinweis auf den Grafikbereich. Das gleiche kommt dann nochmal in Bezug auf Soundkarten, Prozessoren, Mainboards (Onboardsound, OnboardGFX) und wird in Zukunft wohl auch die Physik betreffen (SDKs auf verschiedenen CPUs). > >Ich höre schon "Ja, aber was ist mit den restlichen Bugs im Spiel? Wieso haben die Idioten den Mist nicht raus gemacht? Das ist doch offensichtlich, dass das so nicht ok oder sogar fehlerhaft ist!" > >Ich würde sagen, wir kommen bei den Fragen zu einem Thema, welches u.U. richtig ekelig werden kann. Hier kommen mehrere Faktoren zusammen, die man *nicht* falsch verstehen darf. Diese einzelnen Faktoren spielen eine wichtige Rolle, um bei der Softwareentwicklung *NICHT* verrückt zu werden! > >Kleine Bemerkung meinerseits: Es könnte einigen Leuten nicht gefallen, was ich jetzt von mir gebe und glatt dazu führen, dass ich innerhalb der Spielebranche keinen Job mehr kriege. Diejenigen, die mich kennen, wissen, dass ich immer schon auf den Tisch geklopft habe, wenn es irgendwo ein Problem gibt, gleichzeitig allerdings konstruktiv bleibe. > >Achtung: Dies ist keine Aussage in Bezug auf Sacred 2, sondern betrifft die Spieleentwicklung im Allgemeinen und gilt zu fast 100% auch auf die Softwareentwicklung außerhalb der Spielebranche. > >Wie gesagt, spielen mehrere Faktoren eine Rolle. Diese Faktoren greifen ineinander über und entscheiden in 90% der Fälle, wann das Spiel auf den Markt kommt, in welchem Zustand es ist und ob es die Firma, die das Spiel entwickelt hat, danach überhaupt noch gibt. > >Die Faktoren sind: Zeit, Geld, Milestones und Marktumfeld. > >Jemand, der sich mit Softwareentwicklung auskennt, wird sich wundern, warum ich Milestones und Marktumfeld nenne. > >Milestones, weil diese Entscheiden, ob der Entwickler für seine Arbeit überhaupt Geld erhält. Ich werde nicht ins Detail gehen, wie der Inhalt der Milestones festgelegt wird. Es sei jedoch gesagt, dass Milestones je nach Produkt 4 bis 8 Wochen auseinander liegen und neue Features (Gegner, Items, Spielfiguren, GUI-Elemente, Bildschirme und Dialoge, etc) beinhalten. Diese Milestones werden vom Publisher abgenommen und erst, wenn der Publisher zufrieden ist, gibt es Geld für den Entwickler. D.h. wenn der Entwickler in einem Milestone etwas nicht zur Zufriedenheit des Publishers implementiert hat, dann kann der Publisher hart bleiben und das Geld zurück halten. ACHTUNG: Weder der Publisher noch der Entwickler sind hier der Böse. Der Publisher investiert eine Menge Geld in das Spiel und möchte dafür einen entsprechenden Gegenwert. Der Entwickler arbeitet nach bestem Wissen und Gewissen am Spiel und setzt all sein Können ein, um die Milestones zu erreichen. > >Jetzt kann es allerdings passieren (und es passiert immer und immer wieder), dass bestimmte Dinge nicht so funktionieren, wie man sich das gedacht hat. D.h. dass ein bestimmtes Feature, wie es angedacht war, komplizierter umzusetzen ist, als es zuerst den Anschein hatte. Oder das eine Middleware (Physik, GFX-Engine, Netzwerk, Sound, ...) einen Fehler hat, der behoben werden muss. Oder dass der Grafiklieferant in Verzug ist oder falsch liefert. Es kann sogar passieren, dass Mitarbeiter krank werden und für 1-2 Wochen oder länger ausfallen. > >Es kann auch passieren, dass bestimmte Spielelemente keinen Spass machen und deswegen nochmal komplett überarbeitet werden müssen. > >In sehr, sehr vielen Fällen ist es so, dass die Mitarbeiter Überstunden noch und nöcher leisten, um die Aufgaben zu bewältigen. Die "Crunch-Time", wie man das nennt, wird dann eingeführt, um zu gewährleisten, dass Milestones erreicht werden. Gegen Release (also zum Ende hin) kann diese "Crunch-Time" u.U. extreme Ausmaße annehmen. Mir ist es persönlich passiert, dass ich mehr als 5 Monate lang in Crunchtime war, zeitweise über Wochen hinweg 20h am Tag gearbeitet habe und zu wenigen Zeitpunkten auch mal 2-3 Tage komplett durchgearbeitet habe ohne zu schlafen (schon einige Jahre her). Nicht, weil mir das Spass gemacht hat, sondern, weil ich wusste, dass wenn die Version nicht pünktlich abgeliefert wird, kein Geld mehr da ist und ich mir einen neuen Job suchen kann... > >Jetzt kann man sagen: Dann ist doch falsch geplant worden! Tja... in manchen Fällen mag das auch stimmen. Aber die oben genannten Gründe haben ihre Ursache nicht in falscher Planung. > >Ein Grund für falsche Planung ist, wenn man irgendwann feststellt, dass man eine wichtige Messeversion vergessen hat, die man allerdings braucht, um z.bsp. überhaupt einen Publisher zu finden. Oder dass man vom Publisher "plötzlich" gesagt bekommt, dass man doch bitte eine Vorführversion machen soll. Oder ein Video, oder Screenshots. Da werden dann Leute an stellen gebunden, die man nicht eingeplant hat. > >Wie man sieht, hängt mit dem Milestone der Faktor Zeit zusammen. Und wer Zeit sagt, sagt auch Releasezeitpunkt. In der Spielebranche gibt es 2-3 mehr oder weniger gute Momente, zu denen man ein Spiel veröffentlichen sollte: Um Ostern herum und in den 3 Monaten vor Weihnachten. Es hat sich gezeigt, dass Spiele sich zu den Zeitpunkten besser verkaufen (man möge mich korrigieren, wenn sich das Kaufverhalten in den letzten Jahren geändert hat). Der Sommer ist schlecht, weil dort Ferienzeit ist und die Leute in den Urlaub fahren. Ab Januar ist schlecht, weil die Leute ihr Geld für Weihnachtsgeschenke ausgegeben haben. Hört sich bescheuert an, ist aber so. > >D.h. also, man schaut, dass die Entwicklung des Spiels so ist, dass man zu einem "guten" Zeitpunkt erscheint. Das kann u.U. dazu führen, dass schonmal 3-4 Monate vom ursprünglichen Plan abgeknapst werden oder (wenn man das Budget hat) evtl. noch 1-2 Monate dran hängt. > >Im Zusammenhang mit Milestones und insbesondere mit *nicht* erreichten Milestones kann das schon mal ein arges Durcheinander werden, weil man sich mit dem Publisher hinsetzen und diese Milestones neu ausarbeiten muss, wenn es ein Problem gab. D.h. das Ganze ist recht dynamisch. > >Jeder kennt das abgedroschene Sprichwort "Zeit ist Geld". Leider ist grade dieses Sprichwort in der Spielebranche absolut wahr. Je länger die Entwicklung eines Spiels dauert, desto mehr kostet es. Schließlich müssen die Programmierer, die Grafiker, das Management, die externen Leute, die Zulieferer bezahlt werden. > >Der Entwickler des Spiels macht mit der Planung gleichzeitig auch eine Kostenkalkulation. Die Gehälter, Bürokosten und sonstigen Ausgaben als auch die Kosten für Zulieferer (Sound, GFX, Programmierung, z.T. Marketing) werden mit eingeplant und ergeben ein gewisses Budget. Mit einer Demo und den Budgetvorstellungen wird dann ein Publisher gesucht. > >Dieser versucht natürlich die Kosten zu senken, hilft dem Entwickler evtl. kostengünstigere Alternativen für Zulieferer oder Technologie zu finden, und kann dem Entwickler u.U. auch zusätzliches Personal stellen, um bestimmtes Wissen ein zu bringen. > >Der Publisher, wenn er mit dem Entwickler einen Vertrag unterzeichnet, fixiert für den Entwickler das Budget, definiert aber intern einen Buffer, den er nutzen kann, wenn sich die Entwicklung verzögert. Innerhalb dieses Rahmens ist der Publisher bereit, das Spiel zu finanzieren. > >Kommen jetzt Probleme auf (nicht erreichte Milestones), und der Publisher entscheidet, das Geld erst dann zu zahlen, wenn die Probleme behoben sind, kann u.U. passieren, dass dem Entickler das Geld ausgeht. Dann wird die versammelte Mannschaft in einen Raum gerufen und die Chefs stehen mit gesenktem Kopf vor einem und versuchen einem so schonend wie möglich beizubringen, dass diesen Monat das Gehalt ca. 3 Wochen später gezahlt wird... oder dass diesen Monat gar kein Geld da ist und sofort nachgezahlt wird, sobald wieder Geld da ist. > >Passiert das nicht ein, oder zwei mal, sondern desöfteren, dann kann das die Arbeitsmoral schon ganz schön drücken. Als Angestellter steckt man da in der Zwickmühle: Zum Einen möchte man dem Chef mal so richtig in die Fr... hauen, weil er mir mein Hart erarbeitetes Geld nicht zahlen kann. Zum Anderen will man das Spiel unbedingt fertig machen, weil man ja doch schon sehr viel Herzblut hinein gesteckt hat... ausserdem kann man die Anderen ja nicht hängen lassen! > >Das ist also eine paradoxe Situation: Da man Gefahr läuft, sein Gehalt nicht zu erhalten, macht man Überstunden, um dem entgegen zu wirken. > >Doch was passiert, wenn die verpassten Milestones sich anhäufen? Es ist ja nicht so, dass wenn man einen Milestone verpasst und nachbearbeitet, die anderen automatisch nach hinten geschoben werden. Der Releasetermin steht ja. Tja... hier gibt es mehrere Möglichkeiten: > >1. Das Budget erlaubt es, den Releasetermin zu verschieben. Wie oben gesagt, plant der Publisher in seinem Budget schon einen Buffer ein, den er nutzen kann. Halten sich die Kosten noch in Grenzen, dann kann der Releasetermin evtl. verschoben werden. > >2. Das Budget reicht nicht mehr und der Publisher muss nachrechnen, ob sich weitere Investitionen lohnen. Dazu werden dann vorraussichtliche Verkaufszahlen, Kundenreaktionen auf bisherige Screenshots und Vorführungen, aber auch Strafzahlungen mit eingerechnet. Ja, Strafzahlungen. Der Publisher muss, um das Produkt herzustellen, DVD-Presswerke, Druckereien usw. beauftragen. Verschiebt sich das Produkt, müssen diese Umdisponieren und da können Strafzahlungen auftreten. Wichtig: Je nach Publisher und Vertrag muss das Goldmaster (die DVD welche dem Presswerk gegeben wird, um die DVD herzustellen) 2 bis 4 Wochen vor Release abgeliefert werden. > >Lohnt sich das nicht, dann entscheidet der Publisher, den Vertrag zu kündigen. Für den Entwickler heisst das entweder das Aus oder die Suche nach einem neuen Publisher. > >3. Die dritte Möglichkeit ist komplexer. Der Entwickler hat ja sein Produkt geplant und eine Featureliste aufgestellt. Gemeinsam mit dem Publisher wird diese Liste dann durch gegangen und entschieden, welches Feature welche Priorität hat. Unterschieden wird zwischen A, B und C Features. > >A Features sind "Must have". D.h. das Spiel braucht ohne diese Features gar nicht erst auf den Markt zu kommen. > >B Features sind "Nice to have". D.h. das Spiel wird um so besser, je mehr dieser "Nice to have" Features im Spiel vorhanden sind. > >C Features sind "When we have time". D.h. wenn der Entickler noch Zeit hat, nachdem er A und B Features implementiert hat, dann kommt das evtl. mit rein. > >Ich glaube, es ist unnötig zu sagen, dass bei einem Projekt mit Zeitproblemen B und C Features entweder nicht mehr implementiert oder aber auf einen Patch verschoben werden (wobei Bugfixes oberste Priorität haben). > >Für den Entwickler ist es aber gar nicht so einfach, die Features in A, B und C zu unterteilen. Für ihn sind alle Features wichtig. Schliesslich machen sie das Spiel aus! Tja... da muss man halt in den sauren Apfel beissen. > >Wir sind jetzt also in der schönen Situation, dass wir uns zu Tode arbeiten und der Releasetermin näher rückt. Mittlerweile gibt es Featurestop (es werden keine neuen eingebaut), das Spiel ist im Testing und die Fehlerliste wird immer größer. > >WAS?!? WIE?!? FEHLER?!? Jupp... wir sind auch nur Menschen. Computerspiele sind sehr komplex. Es lassen sich nicht immer alle Teile als kleines, abgeschlossenes Element betrachten, und diese Elemente sind dann getestet und 100% Fehlerfrei. Das Zusammenspiel der verschiedenen Teile eines Spiels können Fehler aufwerfen, an die man im Traum nicht gedacht hat. Die Ursache kann dann an verschiedenen Stellen sein: Ein Fehler in der Programmierung, ein Fehler in den Daten oder aber auch ein Fehler in der Denkweise. In sehr seltenen Fällen können auch falsch verstandene Spielelemente als Fehler deklariert werden, weil der Tester dachte, sie müssten eigentlich anders funktionieren. > >Die Fehler werden dann sortiert. Die erste Sortierung geht nach reproduzierbar oder nicht. Sicher reproduzierbare Fehler sind einfacher zu beheben, weil man genau weis, was man machen muss, um das fehlerhafte Verhalten zu reproduzieren. Als Programmierer kann man dann im Code untersuchen, wie es dazu kommt und Gegenmaßnahmen einleiten (die dann evtl. zu neuen Fehlern führen könnten, weil ein anderer Teil an einer anderen Stelle im Programm plötzlich andere Daten bekommt und nicht mehr so reagiert, wie gewollt). > >Schwierig wird es bei Fehlern, die nur sporadisch oder nach längerer Spielzeit auftreten. Wie man den Fehler reproduzieren kann ist in 95% der Fälle nicht klar, so dass der Entwickler zum Teil darauf hoffen muss, dass der Fehler bei ihm auftritt, so dass er sich darum kümmern kann. In nicht seltenen Fällen werden bei Inhouse Testern (also Testern, die beim Entwickler im Büro sitzen) Entwicklungsumgebunge n installiert, so dass der Programmierer gerufen werden kann, sobald der Fehler auftritt. > >Man hat also jetzt eine Menge an Fehlern, die nach Reproduzierbarkeit sortiert wurden. Der nächste Schritt wird jedem Spieler die Wut in den Bauch treiben: Die Fehler werden nach Wichtigkeit sortiert. Dies ist besonders wichtig, wenn man kurz vor Release steht. Wie weiter oben genannt, muss das Goldmaster 2-4 Wochen vor Release abgeliefert werden. > >Fehler werden sortiert nach: > >1. Blocking: Das sind Fehler, die dazu führen, dass man das Spiel nicht durchspielen kann. Abstürze an bestimmten Stellen; Quests, die nicht funktionieren; Gegenstände, die fehlen; NPCs, die nicht da sind, wo sie sein sollten. Blocking Fehler haben oberste Priorität und in 99% der Fällen wird keine Goldmaster gemacht, auf der ein zu dem Zeitpunkt *BEKANNTER* Blocking Fehler ist. > >2. Non-Blocking: Nicht blockierende Fehler sind alle Fehler, die entweder sehr selten auftreten oder aber zum Durchspielen in der Hauptgeschichte des Spiels nicht wichtig sind. Fehler in Nebenquests, Darstellungsfehler an bestimmten Stellen im Spiel, aber auch Fehler, die evtl. mit nur einer Treiberversion auftreten oder mit einer bestimmten Hardware fallen in diese Kategorie. Diese Fehler werden mit Patches behoben. > >3. Performance: Auch wenn dies keine Fehler als solches sind, sehen Kunden es als Fehler an, wenn ein Spiel auf ihrer Hardware nicht sauber läuft. Der Entwickler ist darauf aus, so viele Kunden wie möglich zu erreichen. Performanceprobleme werden mit Patches behoben. > >In den meisten (ich sage nicht in allen) Fällen verbleiben im Spiel auf dem Goldmaster Probleme mit Treibern und Hardware, als auch Balancing Probleme. > >Nachdem ein Spiel als Goldmaster abgeliefert wurde (keine Zeit mehr, kein Geld mehr, also muss released werden), legen die Entwickler die Beine nicht hoch und geniessen ihre Cocktails auf einer Südsee Insel (ich kenne keinen, der sich das leisten könnte). Die Entwickler fangen an, die Bugs, die bekannt sind, zu beheben. Es wird am berühmt berüchtigten Release Patch gearbeitet. > >Es ist erstaunlich, wie viele Fehler durch Hardware Konstellationen auftreten. Oder durch Treiberinstallationen und Software. Man kann es glauben oder nicht, es ist aber so. Auch die Art und Weise, wie z.bsp. Windows eingerichtet wurde, spielt z.T. eine Rolle (Admin Rechte usw). > >Und genau das ist der Unterschied zur Konsole. Bei Konsolen hat man (meistens) eine Plattform, die bei jedem Kunden zu Hause gleich ist. Klar, es gibt Revisionen der Hardware, aber entweder werden diese vorsichtig gemacht, oder aber es wird (bei der aktuellen Generation) nachgepatcht. Aber viele hier werden gemerkt haben, dass dies bei Konsolenspielen recht selten der Fall ist (oder zumindest sehr, sehr viel seltener als auf dem PC). > >Die Entwicklung für Konsolen hat zwar ihre eigenen Probleme, ist aber im allgemeinen einfacher zu testen, da keine Treiberversionen, unterschiedlichen HW-Konstellationen, zus. Softwarepakete usw. beachtet werden müssen. > >Es wundert mich deswegen nicht, dass der PC als Spieleplattform von den Publishern und den Entwicklern stiefmütterlich behandelt wird. Spiele, die erst später oder gar nicht auf dem PC erscheinen, werden in letzter Zeit immer öfter angekündigt. > >Zum Thema Sacred 2: > >Wenn man sich Foren zu Spielen durchliest, so wie jetzt auch bei Sacred 2, dann kann man den Eindruck bekommen, das Spiel sei von vorne bis hinten bugverseucht, unspielbar und gepresste Krümelkacke. Die Redaktion hat bewusst auf eine Wertung verzichtet, was verständlich ist, und auf Fehler in ihrer Testversion hingewiesen. Gut finde ich, dass das Spiel mit der VerkaufsDVD und dem Releasepatch getestet wird. Die meisten Leute können das Spiel spielen, ohne auf störende Fehler zu treffen. Diejenigen, die in Foren schreiben, gehen in erster Linie dort hin, weil sie Hilfe für ihre Probleme suchen. Und dort schreiben sie dann auch. Diejenigen, die keine Probleme haben, gehen entweder gar nicht erst ins Forum oder aber haben nichts zu posten. Welchen Sinn macht es, wenn mach "Bei mir funktioniert das aber!" postet, wenn ersichtlich ist, dass es bei jemand anderem nicht funktioniert. > >"Siebt" man die Einträge dann auch noch ein bischen, dann sieht man dass einige Leute (ich sage nicht alle), das gleiche Problem in mehreren Threads posten, um z.bsp. einem anderen User, der sich auch über das Problem beschwert, mitzuteilen, was ihre Erfahrungen sind. > >Alles in allem entsteht dadurch der Eindruck, dass es gefühlte 2 Milliarden Menschen gibt, bei denen das Spiel auch nicht läuft. Ich habe schon so manchen Entwickler (auch mich) erlebt, für den nach seinem anfänglichen Stolz, ein Produkt fertig gestellt zu haben und so hart dafür gearbeitet zu haben, eine Welt zusammen bricht, wenn er sieht, mit welchen Kraftausdrücken er und seine Kollegen beschimpft werden. > >Da kann einem die Freude an der Arbeit vergehen, wenn der Stolz, den die Familie auf einen hat, durch Kommentare gedrückt werden, wie ich es erlebt habe: Ich ging mit meinem Bruder vor etlichen Jahren in einen MM. Meine Kollegen und ich hatten ein Spiel fertig gemacht und es stand den ersten Tag im Laden. Wie bei jedem Spiel, an dem ich gearbeitet habe, bin ich also durch die Läden gelaufen, um zu schauen, wo das Spiel zu haben ist, und wieviel schon von den Stapeln verschwunden ist. Besagter MM war der erste Laden, in den ich mit meinem Bruder ging. Er lief voraus, fand die Packung und rief dann zu mir rüber: "Hey, cool... schau mal, hier steht das Spiel, an dem du gearbeitet hast!" Als ich bei ihm ankam, standen 2 Leute bei ihm, mein Bruder hatte grosse Augen und die beiden drehten sich zu mir um: "Du bist also einer von denen, die den Mist hier programmiert haben... mach mal, dass das auf meinem Rechner funktioniert. Von vernünftiger Arbeit habt ihr bei eurem Drecksladen wohl noch nie was gehört..." > >Ich kann euch sagen, dass das Worte sind, die man nicht so schnell vergisst. Und die einen dann zur Überlegung bringen, warum man sich den ganzen Mist überhaupt antut. Die Anwort ist allerdings recht einfach: Weil man es liebt, Spiele zu spielen und Spiele zu schaffen. Weil man hofft, den anderen Spielern mit dem Produkt, was man geschaffen hat, etwas zu geben. Freude, Erstaunen, Erregung, aber auch Enttäuschung sind Spielerfahrungen, die wir mit dem Spielinhalt erzeugen wollen. Leider erzeugen Probleme, die man mit dem "Drumherum" hat, bei einigen Leuten nur das letzte. > >Diejenigen, die sagen: "Macht das vernünftig. Das ist euer verdammter Job.", denen stimme ich insofern zu, als dass wir unser Bestes geben, um unseren Job gut zu machen. Es ist allerdings nicht unser Job, uns beschimpfen zu lassen. Wir machen den Job auch nicht, um viel Geld zu verdienen. In der Spielebranche verdiene ich (obwohl ich seit 12 Jahren dabei bin) 30-50% weniger als ausserhalb der Spielebranche. > >Das Team, das hinter Sacred 2 steht, kann stolz auf ihre Arbeit sein. Sie haben geblutet (in vielerlei Hinsicht), aber durchgestanden. > >Gruß und Have fun...
	mailbenachrichtigung?