30K, Entstehung und Behebung

[Sagittarius]

Als ein Backer sich im Spectrum über 30K und seine finanziellen Verluste ärgerte und bei CIG nachfragte, bekam er eine sehr detaillierte Antwort die einige Fragen beantwortet und Einblicke in die Entwicklung ermöglicht.

 

 

 

Clive Johnson CIG@cjohnson

Zitat:

"In Ihrer Frage gibt es eine ganze Menge zu beantworten. Ich werde versuchen, auf die wichtigsten Punkte einzugehen, aber bitte entschuldigen Sie, wenn Sie das Gefühl haben, dass ich etwas Wichtiges ausgelassen habe.

 

Wann werden die Server stabil sein? Am Ende der Beta-Phase. Warum nicht schon vorher? Weil wir erst den Rest des Spiels fertig machen müssen.

 

Wenn an einem Spiel als geschlossener Alpha gearbeitet wird, liegt der Schwerpunkt auf der Entwicklung von Features und Inhalten. Stabilität und Fehlerbehebung treten in den Hintergrund, und es werden nur Fragen behandelt, die die weitere Entwicklung behindern würden. Das mag unprofessionell klingen, aber die Idee dahinter ist, Ideen so schnell und kostengünstig wie möglich auszuprobieren. So können die Entwickler herausfinden, welche Teile des Spieldesigns funktionieren und welche überarbeitet werden müssen. Es hat keinen Sinn, Zeit mit der Fehlerbehebung für eine Funktion zu verbringen, die sich jederzeit ändern oder sogar ganz aus dem Spiel entfernt werden kann. Die Entwicklung wird mit dem Spiel in diesem halbgeschädigten Zustand zumindest solange fortgesetzt, bis alle Funktionen und Inhalte gesperrt sind. Das Spiel geht dann in die Beta-Phase der Entwicklung, in der Fehlerbehebung, Optimierung, Balance und Feinschliff im Vordergrund stehen. Im Idealfall wird während der Beta-Phase nicht an den Features gearbeitet, aber es werden fast immer in letzter Minute noch einige Änderungen eingefügt.

 

Bei SC handelt es sich natürlich um eine offene Entwicklung, d.h. während der Schwerpunkt in der Alpha-Phase noch darauf liegt, verschiedene Ideen auszuprobieren, muss das Spiel stabil und funktionsfähig genug sein, damit die Geldgeber es testen und ihr Feedback geben können. Das Schlüsselwort dort ist "genug", was natürlich nicht perfekt bedeutet. Es ist wichtig, dass wir die richtige Balance zwischen Fehlerbehebung und Weiterentwicklung finden: zu viel Fehlerbehebung und Entwicklung verlangsamt sich, zu wenig und wir bekommen nicht genug Feedback oder die Fehler behindern die Weiterentwicklung.

 

Hat CIG die richtige Balance zwischen Fehlerbehebung und Weiterentwicklung?

 

Das Problem bei der Feststellung, ob ein Build "stabil genug" ist, besteht darin, dass wir nur betrachten können, wie sich die Stabilität auf die gesamte Spielerbasis, d.h. den Durchschnitt, auswirkt. Es wird daher einige glückliche Geldgeber geben, die weit weniger Abstürze oder andere Probleme als der Durchschnitt erleben, während es einige arme Seelen geben wird, für die der Build ein fehlerbehaftetes Crash-Fest zu sein scheint. Fragen Sie die glücklichen Spieler, ob wir die richtige Balance haben, und sie könnten sagen, nein, das Spiel ist stabil genug, und wir müssen uns mehr auf die Erweiterung des Spiels konzentrieren. Fragen Sie die Unglücklichen, vielleicht sagen sie dann immer noch nein, aber sie wollen, dass wir die Arbeit an neuen Funktionen einstellen, bis alle aktuellen Fehler behoben sind. Nur sehr wenige Leute werden ja sagen.

 

Als Faustregel gilt: Bevor wir einen Patch für Live veröffentlichen, versuchen wir sicherzustellen, dass er mindestens so stabil ist wie die vorherige Live-Veröffentlichung. Einige Patches können für bestimmte Spielweisen mehr oder weniger stabil sein als frühere, aber insgesamt sollte die Stabilität von Patch zu Patch besser werden. Natürlich klappt es manchmal nicht so, wie wir uns das wünschen, und die durchschnittliche Stabilität wird am Ende nicht so gut sein wie bei der vorherigen Version.

 

Warum beheben wir nicht die Server-Abstürze, die 30000 Unterbrechungsfehler verursacht haben?

 

Das tun wir. Es sieht nur so aus, als ob wir es nicht tun, denn unabhängig von der Ursache führen alle Serverabstürze dazu, dass Clients die gleichen 30000 Unterbrechungen der Verbindung erhalten. Diese Verbindungsunterbrechung geschieht, weil die Clients nach dem Absturz des Servers plötzlich keinen Netzwerkverkehr mehr von ihm empfangen. Sie warten dann 30 Sekunden lang, um zu sehen, ob der Datenverkehr wieder aufgenommen wird (falls der Server vorübergehend blockiert war oder es einen kurzen Netzwerkausfall gab), bevor sie aufgeben, zu den Front-End-Menüs zurückkehren und den Trennungsfehler anzeigen. Während dieser 30 Sekunden sehen die Clients, dass sich die Türen nicht öffnen und dass KI, Terminals und andere Einheiten nicht mehr reagieren. Befürworter verwechseln diese Symptome manchmal mit einem Anzeichen dafür, dass der Server kurz vor dem Absturz steht, und man sieht im Spiel-Chat vielleicht, dass ein Serverabsturz bevorsteht, aber in Wahrheit ist der Server bereits tot. Es handelt sich um einen Ex-Server. Er hat aufgehört, ein Ex-Server zu sein. Wenn wir ihn nicht auf seine Stange genagelt hätten, würde er die Gänseblümchen in die Höhe schieben. (Der Chat im Spiel funktioniert nur deshalb weiter, weil er von einem anderen Server verwaltet wird).

 

Wenn ein neuer Patch für PTU vorbereitet wird, stehen fast täglich neue Builds zum Herunterladen zur Verfügung. Sobald DevOps im ATX den neuen Build auf die Server gepusht und zum Download zur Verfügung gestellt hat, überwachen sie den Build während der ersten Stunden und arbeiten dafür oft bis spät und suchen nach allem, was auf ein Problem hinweist, das sofort behoben werden muss. In den nächsten Stunden spielen die Leute das Spiel, laden ihre Absturzberichte hoch, reichen sie beim Issue Council ein, antworten auf Feedback-Foren usw. Server-Abstürze werden alle automatisch in einer Datenbank aufgezeichnet. Wenn die EU-Studios aufwachen, sieht die technische Qualitätssicherung die hochgeladenen Client-Abstürze und die aufgezeichneten Server-Abstürze durch und nimmt eine erste Einschätzung vor, wer die schlimmsten Übeltäter sind, je nachdem, wie oft sie auftreten und wie schnell nach dem Beitritt zu einem Spiel. Serverabstürze landen fast immer an der Spitze des Stapels, allein schon deshalb, weil sie mehr Menschen betreffen als einzelne Clientabstürze. Jiras werden erstellt und an die Produktion weitergeleitet. Die Produktion erledigt hier drei Dinge: erstens schickt sie den Absturz Jiras zur Triage an die Leads, zweitens bestätigt sie die Prioritäten und welche Abstürze die QA versuchen sollte, zu reproduzieren oder anderweitig zu unterstützen, drittens meldet sie besonders schlimme Abstürze bei den Direktoren für Prioritätsanrufe, falls zusätzliche Personen umbesetzt werden müssen, um eine rasche Lösung zu gewährleisten. In der Zwischenzeit triagieren die Leiter die Abstürze und stellen sicher, dass sie an die richtigen Programmierer in den richtigen Teams gehen. Dann untersuchen die Programmierer die Fehler, wobei sie oft mit der QA zusammenarbeiten, um so viele Informationen wie möglich über den Fehler zu finden. Meistens können die Programmierer einen Fix noch am selben Tag committen, aber manchmal kann es ein oder zwei Tage länger dauern. In seltenen Fällen kann es ein paar Wochen dauern, um das Problem aufzuspüren und einen Fix zu finden. In sehr seltenen Fällen ist der Fehler ein Symptom eines tieferen Fehlers, der eine Umstrukturierung eines Systems erfordert, damit es auf eine andere Art und Weise funktioniert, nicht rechtzeitig oder ohne erhebliches Risiko für den aktuellen Patch durchgeführt werden kann und zu einem Rückstand hinzugefügt werden muss, der für eine zukünftige Version eingeplant werden muss. Sobald ATX online geht, veröffentlichen Community und DevOps ihre Berichte über den vorherigen Build aus den Informationen, die sie im Laufe des letzten Tages gesammelt haben. Die Produktion gibt einen Build mit allen neuesten Fixes frei und trifft sich mit QA, Community und DevOps, um zu beurteilen, ob der neue Build wahrscheinlich besser sein wird als der letzte oder ob zunächst zusätzliche Fixes erforderlich sind. Die Produktion gibt ihre Empfehlung an die Führungskräfte weiter, die an diesem Tag eine Go/No-Go-Entscheidung über den Versuch treffen, den neuen Build an PTU zu übergeben. Falls ja, beginnen ATX QA und DevOps damit, sich durch eine Vorab-Checkliste zu arbeiten, deren Bearbeitung mehrere Stunden in Anspruch nimmt. Wenn L.A. online geht, können die EU-Programmierer alle Probleme übergeben, die speziell für die L.A.-Teams bestimmt waren oder an denen die EU-Teams gearbeitet haben, die aber ungelöst sind und von einer weiteren Untersuchung profitieren würden, nachdem die EU für den Tag fertig ist. Wenn ATX die Vorab-Checkliste ausgefüllt hat, und wenn der Bau abgeschlossen ist, beginnt der Zyklus von vorn.

 

Wenn wir die Abstürze beheben, warum kommt es dann immer wieder zu 30000 Verbindungsabbrüchen?

 

Zwischen jeder vierteljährlichen Veröffentlichung ändern wir eine Menge Code. Einiges davon ist komplett neu und einiges davon sind lediglich Änderungen an bestehendem Code. Jede Änderung, die wir vornehmen, birgt die Chance, dass sie Fehler enthalten könnte. Wir sind auch nur Menschen und alle machen von Zeit zu Zeit Fehler, so dass jedes Quartal das Potential hat, eine Menge neuer Fehler hinzuzufügen. Es gibt Prozesse, die die Wahrscheinlichkeit, dass das passiert, verringern, aber einige schlüpfen immer wieder durch. Sobald ein Fehler entdeckt wird, muss er behoben werden. Manchmal funktioniert eine Korrektur nicht. Manchmal wird der Absturz nur in einigen Fällen behoben, aber nicht in allen. Manchmal ist in der Korrektur selbst ein Fehler enthalten, der andere Probleme verursachen kann. Eines der Dinge, die wir recht häufig sehen, ist, dass, sobald ein häufiger Absturz behoben ist, ein oder mehrere andere Abstürze häufiger auftreten werden. Das passiert, weil der Absturz, der gerade behoben wurde, die anderen Abstürze so stark blockiert hat, wie es sonst der Fall gewesen wäre. Wie oben erwähnt, gibt es auch Abstürze, die nicht sofort behoben werden können und warten müssen, bis mehr Zeit zur Verfügung steht, um sie richtig zu beheben, oder bis andere geplante Arbeiten abgeschlossen sind. Letztendlich werden jedoch die meisten der häufigsten Abstürze behoben. Was dann übrig bleibt, sind die wirklich seltenen Abstürze, die Abstürze, die nur einmal im Monat auftreten und über die wir noch nicht genügend Informationen haben, um sie zu beheben oder zu reproduzieren. Einer dieser seltenen Fehler allein wird keinen großen Unterschied machen, aber hundert solcher Fehler würden für mindestens drei Serverabstürze pro Tag ausreichen.

 

Wenn wir die Server nicht stabil machen können, warum bieten wir dann nicht irgendeine Art von Wiederherstellung an?

 

Es wurde vorgeschlagen, dass die Bereitstellung einer Art Frachtversicherung verhindern könnte, dass Spieler große Summen an aUEC verlieren, wenn ihr Server mitten im Frachtlauf abstürzt. Ich glaube, dass dies in Erwägung gezogen wurde, aber es ist klar, dass dies als Exploit missbraucht werden könnte. Solange dieses Problem nicht gelöst ist, ist es unwahrscheinlich, dass eine Frachtversicherung im Spiel auftaucht.

Ein weiterer Vorschlag ist, eine Art Wiederherstellung nach einem Serverabsturz hinzuzufügen. Die Idee dabei ist, dass bei einem Serverabsturz alle Clients mit einem 30000 wie jetzt in die Menüs zurückgeworfen würden, dann aber die Möglichkeit hätten, sich einem neu aufgebauten Server anzuschließen, der den Zustand des Originals aus der Persistenz wiederhergestellt hat. Das ist eigentlich etwas, was wir uns erhoffen, aber es erfordert mehr Arbeit am SOCS und volle Persistenz, bevor es geschehen kann, so dass wir noch weit davon entfernt sind.

Es gab auch andere Vorschläge, wie z.B. Clients oder Server, die den Zustand des Spiels in lokalen Dateien speichern, aber diese sind nicht sicher, oder es wäre eine vorübergehende Lösung und eine Verschwendung von Arbeit für die Implementierung und Wartung, die stattdessen auf die Arbeit an der richtigen Lösung verwendet werden könnte.

Im Moment ist es am besten, wenn wir weiterhin Abstürze beheben, sobald wir sie finden, und hoffen, dass die Server stabil genug sind, dass die meisten Spieler das Spiel testen können."

Übersetzt mit www.DeepL.com/Translator (kostenlose Version)

 

Quelle:https://robertsspaceindustries.com/spectrum/community/SC/forum/50259/thread/server-issues-30k/3034939

 

[Gryf]

Klare und ehrliche Antwort (mit Erklärung) wenn es so mal immer wäre. 

[Ernie]

@SagittariusDanke, DAS ist mal eine ausführkliche Erklärung und genau das, was bei so komplexen Prozessen eigentlich klar sein sollte. Und der Humor gefällt mir

" Es handelt sich um einen Ex-Server. Er hat aufgehört, ein Ex-Server zu sein. Wenn wir ihn nicht auf seine Stange genagelt hätten, würde er die Gänseblümchen in die Höhe schieben. "

[Chrisie]

Ja, was soll man von Clive Johnsons Aussagen halten? Wenn 99 (oder wieviel auch immer) weiter Sonnen- und Planetensysteme noch in das Spiel eingefügt werden sollen, dann haben wir noch 99 weitere Jahre Star Citizen Alpha mit instabilen Servern? Da bin ich aber gespannt.

[Alter.Zocker]

vor 53 Minuten schrieb Brusian:

Ja, was soll man von Clive Johnsons Aussagen halten? Wenn 99 (oder wieviel auch immer) weiter Sonnen- und Planetensysteme noch in das Spiel eingefügt werden sollen, dann haben wir noch 99 weitere Jahre Star Citizen Alpha mit instabilen Servern? Da bin ich aber gespannt.

Die große Hoffnng bzw. eines der vielen Versprechen seitens CIG/CR besteht ja darin, dass man davon ausgeht, wenn ein "Pilot-System" (hier Stanton) erst mal mit allen relevanten Gameplayelementen fertig entwickelt ist und weitestgehend fehlerfrei läuft, dass dann das Generieren weiterer Systeme (mittels zumindest teilweise prozeduralem Prozess) als "Varianten" dieses Pilotsystems relativ schnell vonstatten gehen sollte. Da diese "Varianten" alle auf dem erprobten und weitestgehend bugfrei getesteten Pilotsystem aufbauen, sollen auch die ganzen "Kopien" ebenfalls bereits in Rohfassung relativ fehlerfrei daherkommen.

 

Andererseits glaube ich pers. nicht, dass auf diese WEise ausschließlich prozedural generierten Systeme sonderlich interessant und abwechslungsreich werden, ich befürchte hier dann MMO-typisch generischen Einheitsbrei mit nur wenig Abwechslung. M.E. wird hier nach der prozeduralen Generierung noch an jedem System einiges an manueller NAcharbeit nötig sein, um daraus wirklich interessante und abwechslungsreiche WElten zu schaffen, wo man eben nicht nach dem dritten oder vierten Anflug das Gefühl bekommt: Wenn man drei bis vier Welten gesehen hat, hat man alle WElten des "Verse" gesehen.

 

Vermutlich wird irgendwo ein Mittelweg zwischen effektiver "Massenproduktion" von generischem Content und einzeln per HAnd nachgearbeiteten,  abwechslungsreichen Individualwelten beschritten werden müssen. Das wird halt v.a. vom verfügbaren Budget (Geld sowie Zeit) abhängen und der Art und Weise, wie das CIG-Management um CR damit umgeht. Da sind gerade bei CR und der Art und WEise des Geschäftsmodells auch durchaus gewisse BEdenken angebracht, aber das ist im PRinzip ja auch nix Neues, das war (zumindest mir in meinem Falle) schon vor meiner ersten Spende 2014 bewusst und stellt für mich zugleich auch das Hauptrisiko bei diesem PRojekt aus BAckersicht dar.

Bearbeitet 1. Juni 2020 von Alter.Zocker

[Chrisie]

Also wenn Stanton fertig ist, könnte so langsam man mit dem Angehen der Beta rechnen? Oder so ähnlich. Und daß das seine Zeit brauchen wird, ist auch klar. Das wäre natürlich eine Ansage die ich verstehe. 

[Sagittarius]

@Brusianich vermute das STANTON Mitte 2021 fertig ist, die Beta ist aber noch Lichtjahre entfernt. Wenn ich mich richtig erinnere ist ein Releases bei 10-15 Systemen geplant. Pyro ist ja schon in Arbeit und ich freu mich rießig drauf. Bevor Pyro für Citizen freigegeben werden kann muss aber Server Meshing funktionieren, so ist mein Stand.

Wir sollten uns erstmal auf SQ42 freuen.

[Sagittarius]

Ich verlinke einfach mal das neue und sehr interessante Video von @AstroSam hier in diesen Beitrag

 

 

[Jaabbaa]

Hmm ist ja grundsätzlich ne schöne Sache das man überhaupt mal Ansatzweise erfährt warum die 30000er da sind ,nur finde ich diese Antworten bescheiden ,klar hat die Entwicklung Priorität, aber sollte der Sinn einer spielbaren Alpha nicht sein zu Testen unbd damit logischerweise auch länger als ne halbe Stunde am Stück zu spielen?

 

So kommt doch gar kein vernünftiges Testen von uns Backern zustande ,wenn ich nicht eine Mission oder nicht einen Trading Run durchführen kann.Den 30000er zu beseitigen muss oberste Priorität haben ,so einfach ist das.Da muss ich auch kein Programmierer sein um das zu verstehen, Testen kann ich nur in einer halbwegs stabilen Testumgebung ,was versteht CIG an dieser simplen deduktiven Logik nicht?

 

Erst gestern habe ich das wieder gemerkt, wollte mal nen Trading Run mit der Reclaimer machen, was wieder im 30000er Desaster endete, der vordere Aufzug der Reclaimer funktionierte gar nicht, der hintere durch den bin ich durchgeglitcht, dann habe ich es ins Schiff geschafft ,habe  dann wegen der nicht funktionierenden VTOLs bei der Reclaimer mit den Manövrierdüsen ne halbe Stunde Echtzeit! bis aus  der Atmospähre gebraucht ,und als ich dann losspringen wollte kam der 30000er.

 

Und dann durfte ich noch als Belohnung 1 Stunde Echtzeit die Reclaimer wieder neu claimen, ganz ehrlich sowas vermiest mir jegliche Lust am Testen ,also nach 1,5 Stunden verschwendeter Freizeit für mich habe ich SC beendet und das wars

 

 

[Sagittarius]

@Jaabbaagenau so wie gesagt im Video. Ich spiele Stunden ohne 30k und mache einen Run nach dem anderen ohne Probleme und bei anderen gibt's Schwirigkeiten. Machmal ist es auch gar kein 30k sondern nur ein Clientcrash, verursacht durch Hardware oder Treiber. Du bekommst dann im Menü in der Infotafen das Angebot "return to last Session" oder so ähnlich, das übersehen eben viele.

 

Übrigens kannst du, je nach Planet und Atmopshäre ab ca. 10k-12k Meter Höhe die Orbitalstation, OM's oder andere Punkte anspringen, da hast du 20min gespart und mit etwas Kleingeld kannst du die Claimzeit der großen Pötte erheblich reduzieren.

PS: mit einer Reclaimer einen Trading-Run ist aber auch ne Ansage, da hätte ich auch ohne Bugs kein Bock drauf.

[Ruafu]

Hier ein Video von einem U-Tuber, der für 30k Abbrüche recht elegante Methoden entwickelt hat, um seine Fracht zu schützen:

 

 

[Gast Astriminator]

Am Ende der Beta werden die Server stabil? Dann brauch ich keine Mission anfangen oder überhaupt StarCitizen spielen. Ich habe 10-mal versucht eine Mission zu Kisten Beschaffung zu machen. Das macht leider kein Spaß. Ich hoffe wir erleben mal die Beta. Ich habe an den Anfängen keine 30K abstürzt gehabt, sind aber jetzt mehr geworden.

Wenn man die Zahlenden Kunden an der Stange halten will, und wir in schiffe investieren, dann sollt man die Server Stabilisieren.

[Burton_Guster]

Du kannst sowieso noch nicht "spielen", nur testen! Das wird jedem auf dem Weg von der Registrierung bis zum Starten der Alpha mehrfach angezeigt und daher gut kommuniziert, da kann man CIG keinen Vorwurf machen.

 

Warum sie die Fehler nicht "einfach beheben" steht in der Stellungnahme im Eröffnungspost (die letzten Abschnitte). Kurz: Wenn sie die Fehler beheben würden, müssten Sie danach die Entwicklung einstellen und dürften keinerlei Code mehr ändern. Denn die fortschreitende Entwicklung und der damit verbundene ständig neue Code ist letztlich Grund für die Abstürze.

 

Ändern muss CIG auch gar nichts.

1. Erstens wäre es extrem ineffektiv für die Entwicklung, noch mehr Zeit und Ressourcen in permanentes Polishing einer laufenden Entwicklung zu stecken.

2. Die stark steigenden Spielerzahlen und Einnahmen bestärken CIG darin, dass sie auf dem richtigen Weg sind und der Großteil der Community den Zustand der Alpha einordnen kann.

 

Das hält uns natürlich nicht davon ab, permanent über Bugs zu schimpfen und uns auch mal zu ärgern. Aber ich lass die Alpha dann einfach mal wieder ein paar Wochen liegen und schau später wieder rein.

Man will ja SC auch nicht "satt" haben wenn es irgendwann mal fertig wird.

[Sagittarius]

@Burton_GusterIch weiß nicht ob es noch die Buchstaben wert ist auf so was zu antworten, es steht doch alles da und wurde schlüssig erläutert. Vielleicht liegt es daran dass es niemand liest oder es ist zu viel Text, ich weiß es nicht.

 

Es würde mal geschätzt 6 Monate polish in Anspruch nehmen um die gröbsten Dinge zu patchen  und wenn 3 Monate später ein neuer Masterpatch kommt, ist alles wie vorher. Das sind 6 Monate für die Katz, ich verstehe einfach nicht warum dass bei manchen nicht ankommt.

[Seebo]

Warum ? Das erkläre ich ihr so.

es sind die meisten nicht gewohnt das ein Spiel offen entwickelt wird und von daher denken viele das dieses Spiel wohl fertig ist ?! Und wenn man dafür bezahlt will man auch mindestens so etwas verbuggtes wie Cyberpunk hihihihihihi (nichts gegen CP ich mag es )

[Alter.Zocker]

Es ist, wie @Seeboschrieb: Für die meisten SC-Neulinge ist der Umstand der offenen Spieleentwicklung genau so ungewohnt, wie das Finanzierungsmodell, mit dem Backer durch ihre "Spenden" lediglich die Entwicklung unterstützen (Backen) und dafür von CIG ein "Pixel-Dankeschön" (Ingame-Schifflein udgl.) erhalten.

 

Ich kann dies aber aus Sicht der "Neulinge" auch verstehen und versuche selber immer wieder, die ganze Sache aus ihrem Blickwinkel zu betrachten, bevor ich mehr oder weniger freundlich darauf reagiere.

 

CIG/CR wirbt natürlich mit allen in der Games-Branche üblichen Marketing-Mitteln um neue Unterstützer, das beinhaltet u.a. pompöse Show- und Messeauftritte genau so, wie ein nicht versiegender Strom an Video- und Bildmaterial auf allen zielgruppen-relevanten Medienkanälen, teilweise von CR/CIG (bzw. deren PR-Maschinerie) selbst erstellt, teilweise aber auch von besonders enthusiastischen und CR/CIG zugetanen "Fans" (ich nenn sie mal "Influencer"). Wir sind uns sicher alle einig, das die Marketing-Maschinerie von CR/CIG bisher wie geschmiert läuft, der permanente Spendenstrom bescheinigt  diesbezüglich auch den vollen Erfolg. Diese Marketing-Instrumente (Videos, Bilder, Websites, Events,...) unterscheiden sich jedoch kaum von denen, die auch sonst zur Markteinführung von klassisch (fertig)entwickelten Spielen zum Einsatz kommen. Im Detail betrachtet betont CR/CIG natürlich an vielen Stellen, dass es sich hierbei um eine laufende Entwicklung handelt und kein fertiges Produkt, das alles in Änderung ist und man nix kauft sondern Spendet usw. usf. Aber diese Hinweise erfolgen im Gegensatz zu dem sonstigen "multimedialen Overkill" im Zusammenhang mit SC meist in kleiner gehaltenen, englischen Textbausteinen, ganz ähnlich zu den allseits gewohnten EULA/AGB/Cookie-Passagen, die man ohnehin nur noch genervt wegklickt obzw. geflissentlich überliest. Dadurch kann ich mir schon vorstellen, dass angesichts des sonst vorherschenden Marketing-Pomps solche Hinweistexte auch gerne hin und wieder etwas in den Hintergrund geraten. Viele der Interessenten, für die es inzw. völlig normal ist, sich von der allseits einströmenden Internet-Medienflut auf "YouTube", "Twitch" und Co. usw. in ihren Warnehmungen und Entscheidungen leiten zu lassen übersehen hierbei, dass  bei SC  im Gegensatz zu vielem Anderen, was sie sonst gewohnt sind, einiges anders ist: Eine Spende für eine Entwicklung (mit ungewissem Ausgang) versus das Bezahlen für eine konkrete Gegenleistung in Form eines mehr oder weniger fertig entwickelten PRoduktes (lassen wir mal die jüngsten Turbulenzen um CP2077 an dieser Stelle außen vor, das war ja auch nicht "normal"). All die vielen Videos und das auf Events und dWebsites udgl. gezeigte Material entspringt stand Heute nur zu einem Teil aus dem, was wir heute (abzüglich von Bugs usw.) in PU/PTU zu Gesicht bekommen, ein erheblicher Teil ist Concept-Art (was dann auch immer dabeisteht, aber wieder klein und verschämt am Rand) oder gar nur eine von CR's "Visionen". Für NEueinsteiger ist das alles aber auf den ersten Blick so miteinander verwoben und kaum voneinander zu trennen, dass hier m.E. schnell falsche Erwartungen "induziert" werden, die dann beim "reralen" Kontakt mit dem Stand der Entwickung trotz der vielen "Disclaimer" im Kleingedrukten zu einer gewissen ERnüchterung und  damit Enttäuschung führen können. Und das um so mehr, um so weniger sich Neueinsteiger VOR dem finanziellen Einstieg in SC gründlich und umfassend informieren und auch mal "hinter die pompöse Fassade" schauen, wo es einem auch nicht immer so leicht gemacht wird, wie im pompösen Bilder- und Video-Rausch der Marketing-Maschinerie(keine Videos und Bilder, sondern schnöder, enggeschriebener und juristisch verschwurbelte Textbausteine in einer oftmals fremden Sprache).

 

Klar kann man immer sagen: Pech gehabt, selber Schuld, hättets Euch halt vorher richtig informiert usw... Alles richtig, aber hin und wieder mal aus der eigenen abgeklärten Perspektive ausbrechen und sich in die anderen, durchaus auch "YT-konsum-verblendeten" Sichtweise hineinversetzen, eröffnet einem auch selbst eine gewisse Erkenntnis und Nachsichtigkeit, vielleicht mal auf den nächsten GAST-Beitrag ähnlicher Kategorie lieber gar nicht zu reagieren, als sich zu echauffieren...

Bearbeitet 15. Januar 2021 von Alter.Zocker