GameStar hyped Games im Vorfeld um bei den Tests zurückzukrebsen

Okay, das heißt also, es steht zwar Gamestar drauf, aber ist dennoch separat? Sehr verwirrend...

MfG Ska

 

Gamestar und Gamepro sind die gleiche Redaktion, aber die Magazine haben unterschiedliche Themen (PC und Konsolen) (klick)

 

Vor allem hat Gamepro nie den Codex bekommen. Was ziemlich unverständlich ist.

 

Schau mal, dass wusste ich gar nicht Aber die Migration ist dann aber noch noch ganz erfolgreich, weil ich das nicht wusste. Ihr solltet das plus von gamepro abkoppeln, damit es eindeutiger wird ²²

 

Das war auch nur ein joke. Der negiert alles Darum ist das davor auch negiert, was es wiederum wahr macht

PS: Und das ist kein joke: Ich freue mich darüber, dass das plus Abo auch für gp gilt

 

Ich kann die Kritik von Medienbiene (nicht nur was die Gamestar betrifft) durchaus nachvollziehen und teilweise teile ich diese. Ich kann jetzt keine konkreten Beispiele nennen (dazu müsste ich noch mal einige Ausgaben durchblättern), aber ich hab bei den Previews das Muster erkannt, das erst mal alles runtergebetet wird was die Entwickler/Publisher erzählen. Im finalen Meinungskasten wird dann meist noch was kritisiert oder es wird eine Befürchtung geäußert, diese wird dann aber meist direkt wieder mit einem "aber die Entwickler haben ja noch Zeit" oder einem "Dieses oder Jenes fällt nicht so schwer ins Gewicht, weil..." entschärft.

Ich verstehe das Previews wichtig sind und die Leute diese lesen wollen (mich eingeschlossen). Aber Spieleredakteure sollten sich zurückhalten mit Superlativen oder Lobpreisungen bei Spielen, die sie nur angespielt oder schlimmer noch, nur vorgeführt bekommen haben. Sie sollten wissen das sie nur die besten und sauber laufensten Level präsentiert bekommen und sollten, was das finale Spiel angeht, vorsichtig und skeptisch bleiben.

Natürlich sind auch Spieleredakteure nur Menschen und Spielefans und freuen sich auf die neuen Spiele, aber sie sollen keine blinden Fanboys sein die alles super geil finden und jede Skepsis über Bord werfen. Es darf einfach nicht sein, daß ein Spiel, dass laut Preview der Oberhammer wird im Test als totale Krücke entlarvt wird. Dann fragt man sich halt wie diese extreme Dikrepanz zustande kommt.

 

Umgekehrt wird ein Schuh draus, ein Call of Duty, AC etc bekommt überhaupt große Previews weils die Leute interessiert

 

Und woher genau sollen die Redakteure diese Kristallkugel nehmen?

Das konnte interessanterweise bisher noch keiner Beantworten.

Sofern ein Spiel nicht so mies ist das schon die Vorführversion rumspackt, wie soll der Redakteur anhand einer polierten Fehlerfreien Demo wissen ob das Spiel am Ende auch fehlerfrei erscheint?

Abgesehen davon sehe ich das ganze ziemlich eingefärbt von dem Grundgedanken den man durchdrücken will. Zu Battlefield 4 gab es bei der gamescom einen sehr ausführlichen Artikel wo die durchgescripteten Vorführungen bemängelt hat. Bei anderen Anspielpreviews wurde erwähnt das man von der Route die der Entwickler empfohlen hat abgewichen ist und dann einen CrashtoDesktop hatte.

Aber abgesehen davon, (ohne es böse zu meinen) spreche ich der Redaktion die Kompetenz ab anhand einer Vorführung oder eines selbst gefunden Fehlers zu wissen wie schwerwiegend dieser Fehler ist und wie schwer der behebbar ist.

Eine häßliche Figur kann tatsächling ein großer Mangel an Texturen und Modellierung sein. Oder nur ein falsch eingestellter LOD. Ich bin selbst Softwareentwickler und wir hatten einen großen Fehler der sich im Endeffekt auf eine Stelle im Code zurückzuführen war. Ich war an einem Beta-Test beteiligt wo das Spiel nur auf meinem PC nicht lief, auf allen anderen aber Problemlos. Es hat 4 Wochen Testing gekostet um herauszufinden das Zahlenwerte im Code vorher durch die Übersetzung gejagt wurden und , und . unterschiedlich verwendet werden bei der Zahlendarstellung in Deutschland und Amerika. Davor war das ganze Spiel völlig unspielbar.

Wie schwer ein Bug sich auswirkt kann ein Redakteur beurteilen, wie schwer er zu fixen ist ganz sicher nicht. Ein Redakteur hat nicht das Fachwissen um zu sagen das der Zieltermin in 6Monat mit einem grünen Releasebericht gehalten werden kann. Wenn er dazu auch nur die Teile (zuweilen noch geschönt, gel Colonial Marines?) zusehen bekommt die am besten funktionieren wandert die ganze Forderun entgültig ins ad absurdum.

Wie wäre es mal andersum? Was ist falsch daran von seinen lesern Lesekompetenz zu erwarten? Zu verstehen wie eine Preview (GS ist da ja sehr transparent) entsteht und die entsprechenden Schlussfolgerungen selbst zu ziehen? oder einfach warten bis der finale Test da ist? Man kann nicht immer erwarten das andere für einen denken.

 

Fehlendes Fachwissen dürfte wohl weniger das Problem sein, als das fehlende Wissen wie der Code tatsächlich aussieht.

Mal ganz davon abgesehen, dass ich dir da eigentlich voll zustimme, liegt darin aber auch wahrscheinlich das Problem.
Auch wenn man die nötige Lesekompetenz eigentlich voraussetzen können sollte, haben viele Leute diese einfach nicht. Ich sehe das immer wieder an der Arbeit. Ich bin unteranderem für die Erstellung und Pflege der Installationsanleitungen der von uns bereitgestellten AV-Produkte zuständig. Mal davon abgesehen, dass das Zielpublikum andere IT-Admins sind, und ich den Mist trotzdem auf DAU Niveau schreiben muss, kommen da immer wieder Rückfragen von Dingen die 1-zu-1 in der Anleitung stehen, sei es, "Was muss ich da Auswählen\Installieren" (schau auf den verdammten Screenshot, da ist sind die Optionen markiert, oder lies den scheiß Text den ich in 4 Stündiger Arbeit geschrieben habe, da stehts drin) bis hinzu, "Welchen Befehl muss ich da eingeben". Da muss ich mir dann schon manchmal die Frage stellen wozu ich eigentlich die Arbeit investiere, wenn ich dann doch händschen halten muss, weil der andere zu dämmlich ist einer detailiert beschriebenen und bebilderten Anleitung zu folgen. Und da sind studierte und sogar Doktoranden dabei.

Zu sagen das man eigentlich von seinen lesern die notwendige Lesekompetenz erwarten sollte um das gelesene zu verarbeiten und zu verstehen, ist das Eine, meine Erfahrung zeigt mir aber, dass die Erwartungshaltung die man an den Leser hat häufig nicht mal ansatzweise mit der Realität übereinstimmt.

Zu guter letzt muss ich aber auch einfach mal sagen, das wer sich durch ein Preview hypen lässt, selbst daran schuld ist wenn er von Endprodukt enttäuscht ist. Das gleicht gilt im übrigen auch für diese Unart "Developer Diaries". Viele sehen das als "Kommunikation mit den Fans" und verstehen einfach nicht, dass es eigentlich nur Werbung für das Produkt ist und nur den Zweck hat einen Hype aufzubauen, und nicht um zu informieren.

 

Serienbriefe in Adobe Indesign. Es erwartet ; statt , beim Import, muss man Windows vorher auf US Englisch umstellen, dann aus Excel exportieren

Es gibt studierte ITler die nicht wissen wie man einen Computer zusammenbaut... oder wo die Kommandozeile im Windows ist...

Oder wie man ein simples(!) Makro schreibt

 

Die "Wahrheit" ist immer das, was der Leser am Ende draus macht. Kann deine Erfahrungen nur teilen. Ist einer der Gründe, weshalb ich nie wieder irgendwas mit Kundendienst machen will. Wenn du Anleitungen schreibst, die im Prinzip ein Fünfjähriger verstehen sollte. Drei Schritte: Klicke erst hier, dann dort und dann noch mal hier. Und du bekommst eine Email vom User: "Wo soll ich draufklicken?" Und du schreibst denen, dass es exakt in der Anleitung steht. "Nein." Hrgn.

Erinnert mich ein wenig an das leidige Thema Path of Exile vs Diablo. Wo mir einerseits Leser unterstellen, dass ich PoE nur deshalb nicht höher werte, weil wir dann "Ärger mit Blizzard bekommen", gleichzeitig gibt's aber auch User, die sind felsenfest davon überzeugt, dass PoE nur so gut bei mir abschneidet, weil ich auf "Blizzard-Bashing" stehe. Ist nur eines von vielen Beispielen. Manchmal ist es vollkommen egal, was du sagst oder wie du es umschreibst. Es gibt Leute, die lesen nur das heraus, was sie lesen wollen. Und gegen vorgefertige Meinung hilft sowieso nichts.

EDIT: Diese Aussage werde ich bereuen in 3... 2...

 

Es kommt aber auch immer auf die Schreibweise an.

Ein "Spiel XY hat jetzt endlich Einstellung [...]!", liest sich anders als ein "Spiel XY bietet die Möglichkeit folgende Einstellungen [...]."

 

Da hast du natürlich Recht. Problematisch sind auch gewisse Headlines. *hust*

 

Das ist ja grundsätzlich nicht schlimm, aber wenn es eine wirklich detailierte Schritt-für-Schritt Anleitung gibt, dann sollte jemand der Studiert hat doch eigentlich in der Lage sein dieser auch zu folgen... ist was ich vor ein paar Jahren noch dazu gesagt hätte. Heute ist meine Reaktion einfach nur noch Handfläche => Stirn.

@Berserkerkitten
Ja, Support ist die Hölle, glücklicherweise muss ich das bald nur noch am Rande machen ^^

 

Jo solche Kandidaten gibt es leider. Am besten war aber der EDV Techniker den ich mal getroffen der nicht mal wusste wie man einen Bildschirm anschließen muss...

Es ist dann schon fraglich warum die Dann in ihrem Beruf tätig sind.  vorallem Wen ein berufsfremder mehr weiß

 

Eben weil sie keine Kristallkugel besitzen ist es absolut unmöglich schon in einer Preview von dem Spiel, der tollen Spielwelt, dem Progressionsystem, usw. zu schwärmen, wenn sie das fertige Produkt noch gar nicht kennen. Darauf will ich ja hinaus. Natürlich können sie nicht wissen wie verbuggt ein Spiel am Ende sein wird, aber genauso wenig können sie von "einer lebendigen Spielwelt mit großer Interaktionsmöglichkeit" reden (ist hier nur ein Beispiel).
Genauso wie immer die tollen Entscheidungsmöglichkeiten bei manchen Spielen genannt werden. Bei wievielen Spielen haben solche "Entscheidungen" denn wirklich mal ne Auswirkung? Ne handvoll vielleicht. Sowas wird aber nicht kritisch hinterfragt, sondern man freut sich schon drauf wie toll das wird.

Klar, Lesekompetenz sollte vorhanden sein und ich weiß auch wie man Preview zu lesen/werten hat. Die Zeiten wo ich durch Previews oder Ankündigungen gehyped wurde sind lange vorbei. Ich bin da meist eher skeptisch und erwarte meist nichts Tolles (vor allem im AAA Bereich). Ist vielleicht auch falsch, aber ich beobachte die Entwicklung des Spielemarktes schon ne lange Zeit.

Aber es macht die Gamestar (und auch die anderen Magazine) eben nicht glaubwürdiger, wenn die Previews und die Tests meilenweit auseinander liegen.

 

Nicht?
Ich finde gerade das macht sie glaubwürdig.

Mal ein uraltes Beispiel dazu:

Als Rebel Assault damals raus kam, vor gefühlten 100 Jahren, waren alle aus dem Häusschen. Es sah toll aus, es nutzte CD-ROMs, mWn sogar als erstes Spiel überhaupt oder eines der ersten. Es wirkte für die damalige Zeit in der Preview wie ein Star Wars Film, den man selbst spielen kann, etwas bis dato noch nie Gesehenes. Entsprechend überschlug man sich, zurecht.

Als das Spiel dann raus kam und nach einigen Stunden Testspiel, stellte sich jedoch eine gewisse Ernüchterung ein: alles war repetitiv und geskriptet, die Illusion des spielbaren Films klar als solche zu erkennen, die vielbeschriebene Freiheit eine Lüge, die Luft nach einiger Zeit raus. Ergo wichen diverse Tests und Previews voneinander ab. Ebenfalls wieder zurecht. Dennoch bekam es durch die Bank gute Noten, weil es grafisch eine Revolution darstellte und die damaligen Testsysteme das auf Augenhöhe mit spielerischen Gehalt setzten. Heute würde man sagen: ein historischer Blender.

Das mag zwar ein sehr altes Beispiel sein, aber das Prinzip funktioniert heute immer noch so. Wie sollte es sonst auch laufen? Sollte man von einer beeindruckenden Preview nicht schreiben, dass sie beeindruckend war? Sollte man von einer mittelmäßigen Releaseversion nicht schreiben, dass man sie nur mittelmäßig fand? Was kann denn der Tester dafür, dass Erst- und Finaleindruck sich nicht decken? Ein Preview ist ja genau das, ein erster Vorabblick. Es ist kein Vorab-Test! Und selbst wenn es so einer wäre, könnte sich in der Zwischenzeit noch Vieles ändern.

 

Ich denke man sollte auch einfach mal die Kirche im Dorf lassen. Wie häufig kommt es vor, dass der Test eklatant vom Eindruck den man vom Preview hatte abweicht? Das ist doch eher die Ausnahme, als die Regel. Klar, dass vor Release gehypte Spiele dem Hype selten gerecht werden ist quasi die Norm, aber das liegt ja nicht an Previews, sondern daran das man konstant mit Infos vollgesch(m)issen wird und sich am Ende selbst hyped. Das Preview ist da nur ein kleines unbedeutendes Glied in der Kette. Für den Rest ist man selbst verantwortlich.

 

Ich stelle es mir auch sehr schwer vor die Balance zwischen wirklicher Begeisterung als Spieler und der journalisitischen Distanz als Redakteur zu finden. In den Beispielen von Medienbiene werden eben manche Dinge aus Previews schon als Fakt dargestellt, etwa wie lebendig eine Spielwelt sei oder wie abwechlungsreich die Missionen sind, obwohl längst nicht klar ist, dass es auch später im Spiel so sein wird.
Hier würde ich mir etwas mehr Distanziertheit wünschen. Desweiteren solltet ihr als erfahrene Redakteuer gut unterscheiden können was wirklich gut werden könnte und wo man euch was vormachen möchte. Es gab etliche Spiele wo mir als nicht Games-Profi klar war, das das später kaum Spaß machen würde, z.B. No mans sky. Da konnte ich von Anfang nicht nachvollziehen warum die Spielepresse das so feiert. Es war doch klar das millionen prozedural generierte Planeten schnell langweilig werden und auch das Gameplay recht stupide wird.

 

Selbst wenn man Einblick in den Code hätte, könnte man keine sinnvollen Aussagen treffen. Moderne Spiele sind sehr komplexe Software, deren Code man kaum nach einer kurzen Durchsicht sinnvoll beurteilen kann. Generell ist für jeden Entwickler Code, den man nicht selbst geschrieben hat, nahezu immer scheiße.

Was Bugs angeht: was für einen Spieler nach einem simplen Fehler aussieht, kann sehr komplexe Ursache haben, deren Fixes weit mehr auf Aufwand erfordern, als man es glauben mag. Das geht einem ja schon mit deutlich weniger großen Projekten so. Mit zig Teams, sehr großen Repos, zig Stunden Compile-Zeit usw., sieht die Sache noch mal ganz anders aus.

 

Ich hab gar noch ein älteres Beispiel

The 7th Guest, was schwarfelte man damals doch in Previews rum "Zukunft der Unterhaltung" "Eine neue Ära" was kam bei dem Reviews raus. "75%" als Wertung und "13 mehr oder weniger schwere Rätsel in einer Grafikblenderverpackung"

Im Gegensatz zu 7th Guest macht Rebel Assault aber immerhin rudimentär spass Würd mich nicht wundern wenn 7th Guest irgendwann bei Legendär schlecht auftaucht.

 

Was ich damit meinte war, dass ich mir durchaus vorstellen kann, dass der eine oder andere Redakteur den Code grundsätzlich verstehen könnte, der fehlende Einblick in den Code somit das deutlich größere Hindernis darstellen dürfte.

Das geht einem schon manchmal mit simplen Skripten so, vorallem wenn man das nicht täglich macht

 

Wir haben auf Arbeit neue Software, die erfordert neue Makros, niemand ausser zwei Leuten kann die schreiben und die machen das nicht für andere, alle verloren (und gerade die ITler können das NICHT )

Ein gewisser anderer Verlag hat Previews aus Screenshots und einem EA Werbeflyer gebaut

 

Du, ich hab Zweifel, dass ich den Code verstehen könnte und ich bin jetzt seit über zehn Jahren in der Branche. Missions-Scripts etc. sind eine Sache, aber Engine-Komponenten in C/C++? Geh mir weg ...

Das geht einem schon oft genug so, wenn man es täglich macht.

 

Oh Gott, dass geht mir auf Arbeit jeden Tag so, es wird was an den Prozessen geändert und man braucht entweder ein neues Makro oder man muss das eben selbst von Hand machen

99% machen das von Hand anstatt einen (!) Eintrag in dem Makro zu ändern ... weil das ja soooo kompliziert ist...

 

... genauso, wie auch nicht klar ist, ob es nicht in der finalen Version doch genauso so drin sein wird. Das kann man über jedes einzelne Pixel und jedes einzelne Feature sagen. Soll man also am Ende besser gar nichts sagen, weil man generell nicht wissen kann, wie es am Ende sein wird? Zum Zeitpunkt der Preview sind die gesehenen Dinge tatsächlich Fakten. Aber eben keine vollständigen und ohne Pflicht solche auf ewig zu bleiben! Das muss man wissen, wenn man Previews liest, dass alles auch ganz anders werden kann, dass es keinerlei Garantien für gar nichts gibt.

Wenn man mir eine frühe Version von Skyrim zeigte mit einem überarbeiteten PC-Interface (Inventar!), dann würde ich in einer Preview schreiben, dass Bethesda endlich dazu gelernt hat, endlich PC-Spieler ernst nimmt, endlich ihre alten Code-Schnippsel überarbeitete! Wäre es dann meine Schuld, wenn in der Release-Version doch wieder nur Konsolen-Listen drin wären, wie gehabt? Woher hätte ich das wissen sollen, wie viel Erfahrung braucht man, um in die Köpfe der Verantwortlichen und in die Zukunft blicken zu können?

Einige Dinge kann man einschätzen, zumindest gemessen an bisherigen Erfahrungen und sie als bedenklich einstufen, wie etwa ob prozedurale Riesenuniversen wirklich so unterhaltsam sind. Das ist aber auch geschehen. Anderes kann man hingegen nicht einschätzen, siehe das fiktive Bethesda-Beispiel. Doch in allen Fällen ist und bleibt es Kaffeesatzleserei, da man die Zukunft nicht kennen kann.

Was ist denn z.B. mit den Extremfällen, bei denen im Laufe der Entwicklung sich so viel veränderte, dass die finale Version mit dem Ursprung nichts mehr zu tun hatte, nicht mal mehr dasselbe Genre teilte? Wie sollte man sowas vorhersehen können? Wie soll man die komplexe Verzahnung der Features und ihre Wirkung auf den Spieler wissen nur anhand des Kennens der Einzelelemente? Eine wunderschöne Welt kann durchaus wunderschön sein, sonst wäre sie ja keine wunderschöne Welt . Aber dass sie am Ende vielleicht leer ist und damit öde wirkt und damit ihre Schönheit ad absurdum führt, kann man nicht herauslesen, bloß weil man sie in der Entwicklung gesehen hat. Woher hätte man wissen sollen, dass der Entwickler sie nicht zu füllen weiß?

 

Äh, wieso zitierst Du mich mit Dimis Namen?

Du meinst Macros in Office? Danke, dann lieber C/C++.

 

Das ist doch die Norm. Ich arbeite in einem IT-Betrieb, ich behaupte einfach mal, von den ca. 900 Personen die bei uns Arbeiten, können, wenn ich großzügig bin 10% Skriptsprachen, und ca. 5% wissen wie man in Excel eine einfach Formel schreibt. Der Wissensstand von IT-lern, gerade in Bezug auf Prozessautomatisierung, ist erschreckend. Ich würde jetzt nicht behaupten das ich ein Experte in sachen Skripting bin, aber eine der ersten Sachen die ich mir in meiner Ausbildung zum FiSi beigebracht habe war Skripting, angefangen hab ich mit VB, dann kamen Batchskripte, jetzt Powershell, selbst einige Programmiersprachen habe ich mir im Ansatz selbst beigebracht, weil es mir auf den Senkel ging sich ständig wiederholende Arbeiten per hand zu machen. Ich automatisiere meine Arbeit wo ich nur kann, selbst wenn die Automatisierung "nur" in der Verwendung der "Suchen und Ersetzen" Funktion von Notepad++ besteht (die übrigens extrem Mächtig ist). Ich krieg schon die Krätze wenn ich die Kollege dabei beobachte, dass die in CSV-Dateien jedes Komma per Hand durch ein Semikolon ersetzen, nur um die in Excel direkt korrekt angezeigt zu bekommen. Mal davon abgesehen das Excel das selbst Konvertieren kann, ist es offenbar unglaublich schwer einfach STRG+H zu drücken, und ein "," im Suchfeld und ein ";" im Ersetzenfeld einzugeben.

Naja, genug ausgekotzt. Ich mach dann mal weiter mit meiner nicht zu automatisierenden Sisyphusarbeit (Verflucht seist du Mediawiki)

 

Die Wahrheit ist, dass wir Programmierer einfach unglaublich faul sind. Zu faul zum lernen, zu faul zum ausprobieren, zu faul für Blödheit, für Intelligenz, für alles, sogar zu faul zur Automatisierung. Das wiederum liegt daran, dass wir von morgens bis abends vom Compiler gesagt bekommen, wie bekloppt wir sind, da wir schon wieder tausend neue Fehler generierten. Die Grundeinstellung von uns ist eine Mischung aus Depression, Masochismus, Wut, Unverständnis, Ungeduld, Selbsthass und Spaß an (vermeintlich) brillanten Gedanken als einzig Spaß machendes Pro-Argument .Irgendwann kann man die Kiste nicht mehr sehen, irgendwann ist man froh, wenn man noch wenigstens Bock aufs Zocken hat. Es sei denn natürlich, man ist ein Code-Geek und atmet auch in der Freizeit statt Luft einen beliebigen C-Dialekt. Aber dann lebt man auch nur teilweise in diesem Universum hier und hat mehr Ähnlichkeit mit besagten Compiler, als jemanden aus Fleisch und Blut

 

Ne Makros für einen AS/400 Clienten.

Das ist eigentlich alles ziemlich simpel und ganz einfach. Wenn da jetzt wer kommt der absolut keine Ahnung von irgendwas hat ok, aber studierte? Itler? die das nicht können?

 

@Yeager Wenn ich mir die Qualität einiger Programme mit denen ich arbeiten muss so anschaue, dann glaub ich dir aufs Wort ^^

 

Ja, das ist auch intern nicht anders. Wenn ich mir manche Tools, Programmbibliotheken, ja sogar ganze Programmiersprachen mal unter der Lupe angucke, wird mir anders.

Nur mal ein Beispiel:

In allen möglichen Sprachen ist der Punkt-Operator das Standardzeichen für objektorientierte Zugriffe, also z.B.: Auto.Reifen , dann wäre "Auto" die Klasse (eine Art Matritze oder Vorlage, bei der bestimmte Dinge vorab definiert sind und von der ich ein zur Laufzeit generiertes Objekt erzeuge, damit man nicht immer das Rad neu erfinden muss, wörtlich) und "Reifen" z.B. das Attribut, also eine Schublade für bestimmte Werte und -arten oder eine Unterklasse, siehe z.B.: Auto.Reifen.Druck, dann wäre "Druck" das Attribut, gemessen und definiert in einem physikalischen Druckwert, zb. "bar" oder "pascal", newton pro meter usw..Am besten würde man es noch kleinschreiben, da eine weitere Konvention Großschreibung als Kennzeichen für Klassen sieht, aber ok.

C++, VC, C#, Java, Delphi, PL/SQL, VB.net, VB6 und viele weitere nutzen das so.
PHP jedoch nicht.

Bei PHP ist der Punktoperator ein Pfeil "->" (völlig intuitiv für "Punkt" ^^) und der Punkt selbst steht für Konkatenationen, also "Zusammengeklebe" von Strings, sprich Zeichenketten. Also wäre dort Auto.Reifen.Druck einfach nur: "AutoReifenDruck". Ich weiß nicht, welcher ****** sich das hat einfallen lassen. Ich weiß nicht, ob er nur besonders kreativ sein wollte, ob es historisch aus der Zeigerthematik entstanden ist (quasi interne Links auf Speicherstellen, die mit Wert oder mit Referenz getätigt werden) oder was die sonstigen Beweggründe waren. Aber man darf damit leben. Und das ist nur ein winziges Beispiel.

So mancher ewig resistente Bug in Spielen, die ja auch nix anderes sind, als Programme, sich technisch quasi gar nicht von beliebiger anderer Software unterscheiden, geht darauf zurück, dass irgendeine propietäre Sub-Software benutzt wurde, auf die man selbst keinen Zugriff hat oder aus rechtlichen Gründen die Quellen nicht ändern darf, sofern sie überhaupt vorhanden sind, meistens nicht - die den eigentlichen Bug erzeugt, entweder direkt oder durch eine Verkettung unglücklicher Umstände. Das weiß der User natürlich nicht, er sieht nur das Endergebnis: Irgendwas geht nicht. Also ist es in seinen Augen der Programmierer, der muss es gewesen sein. Er ist doch der große "Gott", der alles ändern kann. Während einem selbst die Hände gebunden sind.

Der Bug des Crash to Desktop bei Xcom 2 Vanilla, der sich manchmal ereignet, ist solch ein Fall. Firaxis hat sich totgesucht im eigenen Code, aber nix gefunden. Man vermutet, dass er durch Teile der Engine oder anderer Drittsoftware entsteht, kann da aber nur wenig machen. Darauf verzichten geht aber auch schlecht, sonst darf man wieder das Rad neu erfinden, was eine neue Bugquelle ist, ewig dauert und ewig viel kostet.

 

Puhhh, du würfelst gerade ganz schön viel durcheinander. Also, "objektorientierte Zugriffe" gibt es nicht. Du erzeugst ein neues Objekt mit einem Konstruktor

Code:

Vehicle reifen = new Vehicle (); //Java

reifen ist die Bezeichnung, new initialisiert den Konstruktor. In dem Fall immutable. Der Konstruktor selber wird in der Klasse definiert (immer public + klassenname, mehr nicht+ggf. Übergabeparameter, keine Rückgabe). Der "." ist ein (Methoden unter Java; Funktions unter c++)-Aufruf, du musst dir aber die Klassen bzw. (wenn) packages selber ziehen (oder programmieren).

Um das zu verdeutlichen:



Die Klasse vehicle hat die Variable horsepower, und die beiden Methoden. mit reifen.setHorsePower(85); setzt du die ps, mit reifen.getHorsePower(); bekommst du deinen Wert angezeigt.

Und: Sorry, da kickt gerade der Informatiker. Ist nicht böse gemeint, aber die Dinge muss ich jede Woche zwei mal in einer Übung erklären