von Sara Petzold - Nvidia hat ein Update für Doom Eternal angekündigt, das eine Reihe grafischer Verbesserungen beinhalten soll. PC-Spieler kommen damit unter anderem in den Genuss von DLSS und Raytracing - die entsprechende Geforce-RTX-Grafikkarte vorausgesetzt.
Kostenlose Updates für bereits veröffentlichte Spiele sind immer toll, aber noch toller sind gratis Grafik-Updates. Genau ein solches hat Doom Eternal jetzt von Nvidia spendiert bekommen - bzw. wird es bekommen, im Laufe des Junis. Der Grafikkartenhersteller hat nämlich per Patch eine Unterstützung für Geforce RTX-Grafikkarten nachgeliefert, durch die id Softwares Shooter bald auch mit DLSS und Raytracing läuft.
Reflexionen, aber keine Beleuchtung
Nvidia präsentiert das RTX-Update in einem offiziellen Trailer, der zeigt, was sich mit DLSS und Raytracing an der Grafik von Doom Eternal verändert:
Der Trailer macht aber auch deutlich, dass Doom Eternal mit dem RTX-Update zwar Reflexionseffekte via Raytracing bekommt, aber keine Ambient Occlusion oder Schatteneffekte. Das Spiel läuft im Trailer übrigens in 4K-Auflösung mit einer Bildrate von 75 Fps bis 110 Fps auf einer GeForce RTX 3080Ti. Nvidia schreibt dazu:
"[...] Doom Eternal ist letztes Jahr erschienen und hat die Begeisterung von Kritikern und Fans auf sich gezogen, die nicht genug von der wilden Action, der spektakulären Optik und dem herausragenden Gameplay des Franchises bekommen können. Angetrieben von idTech, ids unglaublich schneller Spieleengine, überschreitet Doom Eternal die Grenzen des visuell Möglichen noch weiter durch das Hinzufügen von Ray-Tracing-Reflexionen und leistungssteigerndem Nvidia DLSS."
Das Grafikupdate für Doom Eternal gehört zu einer RTX-Initiative von Nvidia, in deren Rahmen der Hersteller für mittlerweile mehr als 130 Spiele entsprechende Raytracing- und DLSS-Support nachliefert. Einige Titel unterstützen in diesem Zusammenhang zusätzlich Nvidia Broadcast und Nvidia Reflex. Der RTX-Patch für Doom Eternal soll laut Nvidia noch im Juni 2021 erscheinen.
Die mit * gekennzeichneten Links sind Affiliate Links. Affiliate-Links sind keine Anzeigen, da wir bei der Recherche und Auswahl der vorgestellten Produkte unabhängig sind. Für Produktverkäufe erhalten wir eine kleine Provision, mit der wir die kostenlosen Inhalte der Webseite teilweise finanzieren.
Check Point warnt vor gefährlichen Trends unter Hackern
[datensicherheit.de, 01.06.2021]„Während der Corona-Krise griffen viele Menschen zu Videospielen, um die heimische Langeweile zu bekämpfen. Jedoch kann aus dem Spaß schnell ein ernsthafter virtueller Angriff werden, weil besonders Kinder zu wenig über IT-Sicherheit und richtiges Verhalten im Netz wissen“, warnt Check Point in einer aktuellen Stellungnahme zur eigenen Beobachtung eines gefährlichen Trends unter Cyber-Kriminellen.
Gamer zunehmend Zielscheibe für Hacker
Die Abriegelung der Länder und Einschränkung des Lebens habe zu einem enormen Anstieg der Nutzung von Videospielen und Konsolen geführt, um Kinder und Jugendliche während der monatelangen „Lockdown“-Maßnahmen bei Laune zu halten:
Laut einem Bericht von DFC Intelligence ist „Europa mittlerweile die zweitaktivste Gaming-Region mit 668 Millionen Spielern“. Infolgedessen seien sogenannte Gamer zunehmend zur Zielscheibe für Hacker geworden, zumal die meisten Spieler über verbundene Konten verfügten, „die Bankdaten, persönliche Informationen, E-Mails und so fort“ enthielten.
Verschiedene Angriffswege für Hacker im Gaming-Bereich
Check Point® Software Technologies Ltd. möchte die „wichtigsten Gefahren“ hervorheben, welche mit der Registrierung auf den verschiedenen Videospiel-Plattformen verbunden sein könnten, „und möchte sowohl Spieler als auch Eltern für die Gefahren sensibilisieren, denen sie ausgesetzt sind, wenn sie stundenlang vor ihren Bildschirmen sitzen“:
Herunterladen von inoffiziellen Webseiten Benutzer dieser Plattformen wendeten sich oft an Webseiten von Drittanbietern, auf denen Konten mit verschiedenen Spielen zu einem viel niedrigeren Preis als dem offiziellen angeboten würden. Diese böten indes keine Garantie, dass sie die Spiele sicher genießen könnten, ohne dass ihre persönlichen und finanziellen Daten für andere Zwecke verwendet würden oder eine bösartige Datei an den Download angehängt werde. Um ein solches Risiko zu vermeiden, empfiehlt Check Point demnach, „stets von offiziellen Websites die Spiele herunterzuladen und unter keinen Umständen auf Websites mit zweifelhafter Herkunft zum Kauf zurückzugreifen“.
Diebstahl der Bankverbindung
Ob auf mobilen Geräten oder Konsolen: Immer mehr Nutzer kauften Videospiele über virtuelle Stores der jeweiligen Plattformen, anstatt sie in Geschäften zu erwerben. Bei einem Online-Kauf müssten sie aber ihre Bankdaten eingeben – „und dies ist einer der einfachsten Angriffswege für Hacker“. Die Spieler und Eltern müssten unbedingt sicherstellen, dass die Website, die sie betreten, über alle erforderlichen Sicherheitsmaßnahmen verfügt: „Dazu müssen diese prüfen, ob die Buchstaben ,https://‘ am Anfang der URL stehen. Diese Buchstaben zeigen an, dass die betreffende Seite durch ein SSL-Zertifikat geschützt ist, eine Art von digitaler Sicherheit, die eine verschlüsselte Kommunikation zwischen einer Website und einem Webbrowser ermöglicht und alle eingegebenen Daten schützt.“
Phishing In diesen Fällen hätten die Hacker den Vorteil, „dass viele ihrer Opfer kleine Kinder oder Jugendliche sind, die möglicherweise nicht aufmerksam oder sachkundig genug sind, um die Anzeichen von Phishing zu erkennen“: Zum Beispiel verdächtige E-Mails und Textnachrichten, welche vor einer angeblichen Änderung eines Kennworts warnten oder Benutzerdaten aufgrund eines angeblichen technischen Fehlers seitens einer Spieleplattform abfragten. Um sich dagegen zu schützen, sollten die Spieler niemals auf Links in E-Mails von unbekannten oder unseriösen Absendern klicken und keine Anhänge herunterladen. „Am besten gehen diese auf die offizielle Website des Spiels oder der Plattform, melden sich an ihrem Konto an und prüfen, ob der Inhalt der E-Mail echt ist.“
Freigabe der Kamera, des Mikrofons und des Standorts Diese Berechtigungen würden hauptsächlich von mobilen Anwendungen und Videospielen benötigt. Jedoch könne ein Cyber-Angriff auf das Gerät oder die Spiele-Plattform selbst schlimme Folgen haben, da die Hacker den Zugriff auf alle Dateien und Informationen erlangen könnten, welche „von diesen Funktionen gesammelt wurden“. Die meisten Sozialen Netzwerke und Videospiel-Plattformen machten es zur zwingenden Bedingung, „dass alle diese Berechtigungen aktiviert sind“. Dennoch sollten Spieler darauf achten, diese Funktionen soweit wie möglich einzuschränken oder zu deaktivieren.
Hacker stellen ihre Angriffe mittlerweile sehr breit auf
Damit werde deutlich, dass Hacker ihre Angriffe mittlerweile sehr breit aufstellten und jede angreifbare Gruppe von Internet-Nutzern attackierten. Bei Videospielen werde es besonders deshalb gefährlich, weil die Ziele meist Kinder und Jugendliche seien und diese auf Plattformen, wie „Steam“ oder „GoG“, Konten einrichteten, in denen sie verschiedene sensible Informationen hinterlegten.
Einmal gestohlen, verfügten die Hacker über eine Sammlung von wichtigen Daten, mit denen sie alles tun könnten: „Diebstahl, Erpressung, Profil-Erstellung und so weiter.“ Check Point rät daher abschließend: „Jeder sollte daher gut überlegen, welche Informationen er auf diesen Plattformen offenlegt, damit Videospiele weiterhin ihren Zweck erfüllen: Spaß und Unterhaltung zu bieten.“
Clever Plays, das Independent-Spielestudio aus Montreal, freut sich über die heutige Veröffentlichung seines asymmetrischen Koop-Spionage-Abenteuers Operation: Tango. Diese lebendige Hommage an das Hollywood-Spionage-Genre, welche im Rahmen der Gamescom 2020 als “Bestes Multiplayer-Spiel” ausgezeichnet wurde, versetzt einen Spieler in die Rolle von Angel, dem “Field Agent”, und einen zweiten Spieler in die Rolle von Alistair, dem “Hacker”. Gemeinsam müssen sie sich durch eine Reihe von Missionen kämpfen, um eine globale Hightech-Bedrohung zu stoppen.
Das Spielerlebnis ähnelt dem eines Spionage-Escape-Rooms und schweißt die Spieler zusammen. Da jeder Spieler von einem anderen Gerät aus spielt, hat er eine ganz eigene Perspektive auf das Geschehen. Bei der Zusammenarbeit bleiben die Teams in ständigem verbalem Kontakt, um Rätsel zu lösen und hochbrisante Missionen in einer augmentierten, vollständig vernetzten und hochstilisierten Welt zu erfüllen.
Clever Plays wollte sicherstellen, dass die Spieler einfacher mit ihren Lieblings-Teamkollegen zusammenspielen können. Daher war die Möglichkeit, plattformübergreifend auf Konsolen und PCs zu spielen, ein wichtiges Feature für das Team. Außerdem haben sie den Friend Pass entwickelt, damit Spieler, die Operation: Tango besitzen, einen Freund einladen können, sich ihnen kostenlos über die kostenlos herunterladbare Demo des Spiels auf der Plattform ihrer Wahl anzuschließen.
„Bei diesem Spiel dreht sich alles um Kommunikation und ein Level an Zusammenarbeit, das über jeden typischen Koop-Titel hinausgeht“, sagt Mattieu Bégin, Mitbegründer und Lead-Designer bei Clever Plays. „Wir haben es als eine Erfahrung geschaffen, die man teilt, also wollten wir es den Spielern leicht machen, einen Partner auf unserem Discord zu finden oder einen Freund einzuladen und über alle Plattformen hinweg miteinander zu spielen.“
Operation: Tango ist ab sofort für 16,99 Euro auf Steam und für PS5, PS4 und PS5 PlayStation Plus-Abonnenten erhältlich. Das Spiel wird auch später in diesem Sommer für Xbox One und Xbox X/S Series sowie im Epic Game Store erhältlich sein. Weitere Informationen unter http://www.clever-plays.com/.
Wie findest du das?
Nicht sicher
0
Interessiert sich für die Welt der Pixel seit die Dinosaurier ausgestorben sind. Dabei vertreibt eine gute Simulation am Morgen, Kummer und Sorgen. Ist der Gründer vom PIXEL. Magazin und schreibt nach 10 Kaffee schneller Unfug als die Autokorrektur berichtigen kann.
Ich versprach mir Hilfe für meine App-Entwicklung. Die externe Entwicklerfirma lieferte aber vor allem Fehler und Ausreden. Was ich daraus gelernt habe.
Die Ergebnisse im App-Projekt kamen spät, Ausreden gab es dafür einige.(Bild: Pixabay)
Dieser Text ist eine Übersetzung. Das Original des Software-Entwicklers Rajiv Prabhakar ist hier zu finden.
Vor vielen Jahren beschlossen eine jüngere, naivere Version meiner selbst und eine Bekannte von mir, neben unseren Vollzeitjobs ein Bootstrapping-Startup zu gründen, also ein Startup ohne Fremdkapital. Meine Mitgründerin brachte die Idee, die Produktvision und die Kontakte für die ersten Nutzer mit, ich war für die technische Entwicklung zuständig. Unser Plan für das MVP war, mit einer iOS- und Android-App zu starten.
Ich habe viel Erfahrung in der Backend-Entwicklung, eine mobile App hatte ich davor noch nie entwickelt. Anstatt zu versuchen, es von Grund auf zu lernen, entschieden wir uns, externe Entwickler mit der Erstellung der mobilen Apps zu beauftragen, während ich die gesamte serverseitige Entwicklung, P/SaaS-Integrationen und die Infrastruktur verwaltete.
Kontext
Die Zusammenarbeit mit externen Entwicklern war keine neue Erfahrung für mich, was mir, im Nachhinein betrachtet, ungerechtfertigtes Vertrauen gab. Für ein früheres Startup hatte ich mit einem jungen Teilzeit-Freelancer in einem anderen Land gearbeitet. Er war mir von jemandem, den ich kannte, empfohlen worden, machte eine tolle Arbeit und verlangte weniger als 10 Dollar pro Stunde.
Damals war mir das nicht klar, aber wenn man bedenkt, wie talentiert und gewissenhaft er war, war das ein Schnäppchen. Jetzt verdient er in San Francisco ein sechsstelliges Gehalt.
Leider war er für unser neues Projekt nicht mehr verfügbar. Meine Mitgründerin wollte außerdem eine renommiertere Firma für unsere Frontend-Entwicklung. Also entschieden wir uns, nach einem Dev Shop, also einer Entwicklerfirma, zu suchen und nicht nach einzelnen Freiberuflern.
Wir waren bei der Auswahl natürlich sorgfältig: Wir haben uns unabhängige Bewertungen Dritter angesehen, nach Referenzen gefragt, mit früheren Kunden gesprochen und uns bei mehreren Anbietern umgesehen, bevor wir uns schließlich für den entschieden haben, der uns am vertrauenswürdigsten schien. Die Firma verlangte etwa 25 Dollar pro Stunde - deutlich mehr als vergleichbare Freiberufler. Wir dachten aber, dass wir damit ein erfahrenes und professionelles Unternehmen beauftragen und nicht nur eine beliebige Einzelperson. Wir dachten, das sei das Beste für uns.
Meine Mitgründerin, eine Anwältin, und ich versuchten natürlich, unseren Vertrag mit der Firma so detailliert wie möglich zu gestalten. Da wir wussten, dass Softwareprojekte extrem anfällig für Kostenüberschreitungen sind, verhandelten wir einen Festpreisvertrag mit einer Garantie für alle Fehler. Nach langer Vorarbeit, in der wir die Vertragsdetails festgehalten und jede einzelne Funktion, die sie für uns bauen sollten, ganz genau beschrieben hatten, war es an der Zeit, die erste Zahlung zu leisten und mit dem Projekt zu starten.
Handbuch für Softwareentwickler: Das Standardwerk für professionelles Software Engineering
Und genau hier haben wir einen entscheidenden Fehler gemacht.
Gemäß unserer Vertragsvereinbarung wurde das Projekt in drei Abschnitte aufgeteilt. Wir sollten 40 Prozent im Voraus bezahlen, bevor überhaupt irgendeine Arbeit geleistet wurde. Dann weitere 30 Prozent am Ende jedes der ersten beiden Abschnitte - und zwar, bevor wir die Ergebnisse des abgeschlossenen Abschnitts erhielten. In Anbetracht der Tatsache, dass es sich um ein Bootstrapping-Startup handelte und wir eine fünfstellige Vorauszahlung leisten mussten, ohne dass die Ergebnisse vor der nächsten Zahlung geliefert wurden, waren wir praktisch für die Dauer des gesamten Projekts gebunden.
Wir wussten das, dachten aber, dass es in Ordnung sei. Sie hatten gute Bewertungen aus unabhängigen Quellen, tolle Kundenreferenzen; Warnzeichen gab es nicht. Außerdem wussten wir, dass es nicht einfach ist, neue Entwickler in ein Projekt einzubinden, das von jemand anderem gemacht wird - also hatten wir ohnehin vor, das gesamte Projekt mit ihnen gemeinsam umzusetzen.
Im Nachhinein betrachtet war das die schlechteste technische Entscheidung, die wir getroffen haben, und das hat unser Startup ganz schön in Schwierigkeiten gebracht.
Eine der wichtigsten Funktionen für unsere App war ein Echtzeit-Chat. Während unserer Vertragsverhandlungen gaben uns die Entwickler einige SaaS-Empfehlungen, um die Erstellung der Echtzeit-Chat-Funktionalität zu vereinfachen - eine davon war Twilio Chat. Nach Prüfung der verschiedenen Empfehlungen schien Twilio die beste Option zu sein und wir einigten uns darauf, sie zu verwenden.
Als es an die Umsetzung ging, gerieten die Entwickler aber in eine Sackgasse: Sie konnten nicht herausfinden, wie man Twilio Chat mit React Native zum Laufen bringt - obwohl sie es waren, die Twilio Chat und React Native überhaupt erst empfohlen hatten.
Schlimmer noch: Anstatt uns die Wahrheit zu sagen und uns zu erklären, dass sie nicht weiterkamen, sagten sie uns einfach, dass Twilio Chat nicht mit React Native funktioniere - und wollten nun, dass wir zu einem völlig anderen Chat-Dienstleister wechseln (von einer Firma, von der wir noch nie gehört hatten), dass wir noch einmal von vorne anfangen und eine zusätzliche Gebühr für diesen Irrweg bezahlen (obwohl der Preis für das Projekt eigentlich fix sein sollte).
Das Schlimmste aber war, dass ihre Behauptung nicht einmal ansatzweise stimmte: Twilio Chat funktioniert einwandfrei mit React Native - sie wussten nur nicht, wie sie das hinbekommen sollten. Am Ende habe ich, ein Entwickler mit keinerlei React-Native-Erfahrung, viele Stunden mit der Lösungssuche verbracht und den Entwicklern dann beigebracht, wie es funktioniert. Und selbst, nachdem ich ihnen alles gezeigt hatte, brauchten sie mich immer noch, um ihnen Links zu Dokumentationen zu schicken und ihnen zu erklären, wie man die Twilio-APIs verwendet.
Hätte ich nicht herausgefunden, wie ich ihre Arbeit für sie erledigen kann, hätten wir ihre Empfehlung bestimmt befolgt. Wir hätten Twilio komplett aufgegeben und wären zu einem völlig anderen und minderwertigen Dienst gewechselt. Eine Entscheidung, die das Projekt um viele Monate und eine große Menge Geld zurückgeworfen hätte.
Ganz offensichtlich hätten also alle nicht-öffentlichen Nachrichten über private Kanäle implementiert werden müssen. Erstaunlicherweise implementierten unsere Entwickler aber alles über öffentliche Kanäle - was ich beim Durchsuchen der Twilio-Konsole feststellte. Wären wir so live gegangen, hätte jeder, der auch nur minimale Entwicklungserfahrung hat, die privaten Unterhaltungen jedes einzelnen Benutzers in der App belauschen können. Wenn ich das nicht selbst bemerkt hätte ... Die Entwicklungsfirma hätte ganz sicher keine Pen-Tester bezahlt, die solche Sicherheitsprobleme aufdecken.
Handbuch für Softwareentwickler: Das Standardwerk für professionelles Software Engineering
Das war ein grober Fehler. Noch schockierender ist aber, dass die Entwickler, anstatt sich dafür zu entschuldigen, unseren Änderungswunsch zurückgewiesen haben. Offensichtlich ist es einfacher, die Chat-Funktionalität mit öffentlichen Kanälen zu implementieren - und so zog man es vor, es so zu lassen. Erst als wir stark darauf drängten, änderten sie die Implementierung.
Überall Bugs
Einer der Gründe, warum wir unbedingt eine externe Entwicklungsfirma beauftragen wollten (und nicht einzelne Freiberufler), war der Support, der uns versprochen worden war: vor allem ein QA-Team, das die App ausgiebig testen würde, bevor sie uns gezeigt wird.
Bugs sind in jedem Software-Projekt unvermeidlich. Wir wussten also, dass die Firma keine Versprechungen machen konnte. Aber wir haben sie beim Wort genommen, als uns gesagt wurde, dass wir nur mit ein paar wenigen Fehlern rechnen müssten.
Wie wir später herausfanden, war das völliger Unsinn. Jede einzelne ihrer Lieferungen war voll mit Fehlern. Selbst die grundlegendsten Funktionen gingen nicht - ich hatte sogar den Verdacht, dass sie die App nie mit echten Smartphones getestet hatten. Wenn sie sie überhaupt getestet hatten. Meine Mitgründerin und ich mussten eine ganze Woche lang jeden Tag mehrere Stunden damit verbringen, alle Bugs zu dokumentieren und akribisch zu überprüfen.
Ein Beispiel für einen solchen Fehler: Wenn ein Nutzer oder eine Nutzerin mehr als 50 Kontakte hatte, wurden nur die ersten 50 in der App angezeigt. Auf alle anderen konnte nicht zugegriffen werden. Es stellte sich heraus, dass eine unserer SaaS-Integrationen mit einer Paginierung arbeitete und die Entwickler Code implementiert hatten, bei dem nur die erste Seite der Ergebnisse angezeigt wurde.
Da dieser Fehler erst bei 51 Kontakten eines einzelnen Nutzers ausgelöst werden konnte und wir noch in der privaten Testphase waren, dauerte es eine Weile, bis wir darauf stießen. Als wir den Fehler gefunden hatten, meldeten wir ihn. Sie haben ihn sofort behoben. Wir testeten ihren Fix und er schien gut zu funktionieren.
Als ich mir den geänderten Code anschaute, wurde mir jedoch klar, wie unsauber ihre Lösung war. Anstatt eine While-Schleife zu verwenden, um alle Seiten zu laden, hatten sie einfach eine If-Bedingung hinzugefügt, um die zweite Seite zu laden. Sobald Nutzer mehr als 100 Kontakte hätten, wäre er der gleiche Fehler wieder aufgetaucht.
Den ersten Fehler hätte man als Versehen entschuldigen können. Der zweite war fahrlässig. Die Entwickler müssen sich gedacht haben, dass wir sehr lange brauchen würden, um die zweite Ergebnisseite auszugeben und noch länger für die dritte. Sie wussten, was sie taten, sie wussten um die Grenzen ihres "Fix", und sie taten es trotzdem. Wenn wir ihren Code nicht sorgfältig untersucht hätten, wäre dieser Fehler auch in die Produktion gelangt.
Als Entwickler wusste ich aus eigener Erfahrung, wie nützlich eine Versionsgeschichte ist. Sie hilft zukünftigen Entwicklern zu verstehen, warum bestimmte Design-Entscheidungen getroffen wurden und wie bestimmte Funktionalitäten gebaut wurden. Außerdem bietet sie eine Vorlage für ähnliche Funktionen.
Während der Vertragsverhandlungen habe ich deswegen darauf bestanden, dass das endgültige Ergebnis ein Git-Repository sein sollte. Die Entwickler stimmten dem zu und sagten, dass sie auch intern Git verwenden. Als es an der Zeit war, uns den Quellcode zu liefern, schickten sie aber eine einzige Zip-Datei, die eine Mischung aus dem gesamten Quellcode und den generierten Dateien darstellte.
Handbuch für Softwareentwickler: Das Standardwerk für professionelles Software Engineering
Ich erinnerte sie daran, dass sie sich vertraglich verpflichtet hatten, uns ein Git-Repository zur Verfügung zu stellen. Tatsächlich sah ich in der Zip-Datei, die sie uns geschickt hatten, sogar ein .git-Verzeichnis - was darauf hindeutet, dass sie Git für ihre Entwicklung verwendet hatten.
Am nächsten Tag schickten sie uns prompt ein Git-Repository. Es enthielt ein einziges Commit - das aus genau der gleichen Zip-Datei bestand, die wir am Tag zuvor erhalten hatten.
Ich schluckte meinen Ärger darüber herunter und sagte ihnen, dass wir die gesamte Versionsgeschichte haben wollten, nicht nur einen einzigen Commit, der die gleiche Zip-Datei enthielt. Sie antworteten, dass sie einige "sensible Informationen" in ihrem Git-Repository hätten, die nicht für ein externes Publikum bestimmt seien. Daher könnten sie diese nicht mit uns teilen. "Der Vertrag sagt nur, dass wir ein Git-Repository liefern sollen. Er sagt nicht, dass das Repository alle Entwicklungs-Commits und die Versionsgeschichte enthalten soll."
Während der Verhandlungen hatten wir mehrfach erwähnt, dass die serverseitigen APIs noch nicht vollständig implementiert sind und dass wir die Backend-Entwicklung parallel zur Frontend-Entwicklung machen wollten. Außerdem sagten wir, dass ich ihnen zu Beginn des Projekts alle API-Endpunkte zur Verfügung stellen würde, von denen einige vollständig implementiert wären. So konnten sie sofort mit der Arbeit an den einfacheren Funktionen beginnen und diese wenigen Endpunkte verwenden. Wenn sie die ersten Funktionen fertig hätten, wären die APIs bereit für die nächsten.
Unser Ziel war es, Verzögerungen zu vermeiden und parallel zu arbeiten, um so insgesamt früher mit der App starten zu können. Wir haben das immer wieder so gesagt - und uns wurde stets rückgemeldet, dass alles in Ordnung sei.
Sobald wir das Geld bezahlt hatten, änderte sich das aber. Plötzlich weigerten sich die Entwickler, überhaupt mit der Arbeit zu beginnen, bevor die Backend-Entwicklung zu 100 Prozent abgeschlossen war - und zwar für jede einzelne Funktion des gesamten Projekts.
Glücklicherweise war ich zu diesem Zeitpunkt mit der Backend-Entwicklung beinahe fertig, da wir viel Zeit mit Vertragsverhandlungen und Designarbeiten verbracht hatten. Also war das am Ende kein Problem. Aber ich war schockiert und sehr enttäuscht, dass sie die Versprechen, die ihre Vertriebsmitarbeiter zuvor gemacht hatten, nicht einhielten.
In den Vorgesprächen hatten sie quasi den roten Teppich für uns ausgerollt. Als es dann aber losging, gruben sie sich ein und bestanden darauf, dass alles ganz genau nach ihren Vorstellungen ablaufen sollte.
My Way oder Highway
Zum Beispiel verwendete ich, nach eingehender Prüfung aller Optionen, Swagger, um die API-Endpunkte, ihre Eingaben, Schemata, Beschreibungen und ihr Verhalten zu dokumentieren. So wurde die Dokumentation in den Code eingebettet, automatisch generiert und auf dem neuesten Stand gehalten. Die Swagger-GUI bietet außerdem die sehr angenehme Möglichkeit, alle API-Dokumentationen zu durchsuchen und sogar API-Aufrufe zu Testzwecken direkt von der GUI aus zu machen.
Leider hatte die Firma ein anderes Vorgehen. Die Entwickler weigerten sich also, Swagger als Dokumentationsquelle zu nehmen. Stattdessen bestanden sie darauf, dass wir ihnen ein Word-Dokument per E-Mail schickten, mit dem gleichen Inhalt wie dem in Swagger, aber mit ihren spezifischen Formatierungsanforderungen.
Handbuch für Softwareentwickler: Das Standardwerk für professionelles Software Engineering
Wir diskutierten mehrere Tage lang, bevor sie schließlich nachgaben. Diese Einstellung zog sich jedoch durch den gesamten Entwicklungsprozess. Wir hatten die Entwickler beauftragt, mobile Apps unter Verwendung unserer Backend-APIs zu entwickeln. Sie waren aber sehr wählerisch, denn sie wollten, dass die APIs auf eine ganz bestimmte Weise funktionierten. Jedes Mal, wenn es eine philosophische Meinungsverschiedenheit über das API-Design gab, mussten wir ewig darüber debattieren.
Es ist möglich, dass all dies von ihrer Leidenschaft für API-Best-Practices rührte, aber ich vermute, dass es in erster Linie daran lag, dass sie ihre eigene Arbeit so unabhängig wie möglich machen wollten. Und an ihren Problemen, die benötigte Funktionalität mit einer bestehenden API zu implementieren.
Eine weitere große Überraschung nach dem Projektstart war die fehlende Kommunikation. In meinen früheren Projekten haben wir immer über Teamgrenzen hinweg direkt mit Technikern und Ingenieuren gesprochen, um Probleme besser verstehen und lösen zu können. Zu meiner Überraschung ließen unsere Entwickler das ausdrücklich nicht zu.
Gemäß der Richtlinien der Firma hatten wir nur einen Ansprechpartner, eine Projektmanagerin ohne Programmierfachkenntnisse. Trotz unserer Bitten durften wir nicht direkt mit den Entwicklern Kontakt aufnehmen, die an dem Projekt arbeiteten. Außerdem weigerte sich die Projektmanagerin auch, in Echtzeit über Chat zu kommunizieren. Sie bestand darauf, alles per E-Mail abzuwickeln.
Mit der Zeit führte dies zu großen Kommunikationsproblemen. Immer wenn die Entwickler eine Frage hatten oder etwas nicht wussten, schickten sie ihre Frage an die Projektmanagerin. Sie sammelte alle Fragen und schickte mir am Ende des Arbeitstages eine lange E-Mail. Meine Antwort sahen sie erst zu Beginn ihres nächsten Arbeitstages.
So brauchte selbst eine einfache Frage und Antwort 24 Stunden, um bearbeitet zu werden. Kompliziertere Diskussionen nahmen mehrere Tage in Anspruch, statt in einer 30-minütigen Chat-Sitzung besprochen und geklärt zu werden. Glücklicherweise erkannte die Firma gegen Ende des Projekts endlich, wie ineffizient dieser Prozess war und gab uns einen direkten Kontakt zu ihren Entwicklern. Leider war es da schon zu spät.
Wir wussten schon zu Beginn des Projekts, dass dies ein großes Problem werden könnte. Man versicherte uns aber, dass es nicht so kommen werde. Natürlich war es am Ende doch so. Es ist einfach sehr schwierig, agil zu sein, wenn man nur über eine E-Mail pro Tag kommunizieren darf.
Große Verzögerungen
Leider hatten die oben genannten Probleme reale Auswirkungen auf den Zeitplan: Was als Zwei-Monats-Projekt geplant war, dauerte am Ende sieben Monate. Das war schlecht für uns, da wir viele potenzielle Benutzer verloren, die nicht auf den Start warten konnten.
Handbuch für Softwareentwickler: Das Standardwerk für professionelles Software Engineering
Rückblickend waren diese Verzögerungen überhaupt nicht überraschend, wenn man bedenkt, dass es unseren Entwicklerin an technischem Fachwissen mangelte, sie auf einer Wasserfall-Methode bestanden und sich weigerten, direkt über Chat oder Telefonanrufe zu kommunizieren. Aber ich vermute, dass das nicht die einzigen Probleme waren.
Ich denke vielmehr, dass sie zwischendurch andere Projekte hatten, die sie für lukrativer hielten, und deshalb die Arbeit, die sie eigentlich für uns machen sollten, herunterstuften. Das war vermutlich auch der Grund, warum sie mitten im Projekt einen großen Personalwechsel in ihrem Entwicklerteam vorgenommen haben.
Wenn es eine Konstante bei all dem gab, war es die völlige Weigerung der Entwickler, die Verantwortung für irgendetwas zu übernehmen. Bevor sie an einer Aufgabe arbeiteten, bekundeten sie hundertprozentiges Vertrauen in ihre Fähigkeit, tolle Ergebnisse zu liefern. Wenn sie ihre Versprechen nicht einhielten, gab es hingegen immer jemanden, dem sie die Schuld daran gaben.
Sie können nicht herausfinden, wie man das Twilio-SDK verwendet? "Twilio Chat funktioniert nicht mit React Native."
(Tut es doch.)
Die Chat-Implementierung hätte alle privaten Unterhaltungen öffentlich zugänglich gemacht? "Die Alternative ist zu kompliziert."
(Deshalb haben wir Sie engagiert.)
Sie können nicht herausfinden, warum ein bestimmter Bildschirm 30 Sekunden zum Laden braucht? "Wir müssen 5 API-Aufrufe machen und das verlangsamt es."
(Diese 5 API-Aufrufe brauchen zusammen weniger als 1 Sekunde.)
Das Projekt hat dreimal länger gedauert als versprochen? "Die Server-API war sehr schlecht und fehlerhaft."
(Ja, ich bin sicher, das hat nichts mit Ihrer mangelnden Priorisierung, Kompetenz und Ihren Kommunikationsmethoden zu tun.)
Das Frustrierende an der Sache ist, dass dieser Ansatz funktioniert! Wenn ich nicht selbst Entwickler wäre, hätte ich alles geglaubt, was die Firma erzählt hat. Es gibt einen Grund, warum sie die direkte Kommunikation mit ihren Entwicklern blockiert - ihre Projektmanager sind Experten im Plaudern, selbstsicher und gut im Abwehren von Schuldzuweisungen. Wer sie anheuert, aber nicht die technischen Fähigkeiten hat, ihre Arbeit zu hinterfragen, ist wirklich zu bedauern.
Was ich daraus gelernt habe
Wenn man sich all die Dinge ansieht, die schiefgelaufen sind, wäre es sehr verlockend, einfach zu sagen: "Offshore-Entwickler sind schlecht." Das wäre aber nicht nur kleingeistig, sondern auch sehr limitierend. Aus Sicht von jemandem, der wie ich mit exzellenten Ingenieuren aus anderen Ländern zusammengearbeitet hat, ist es natürlich kompletter Blödsinn zu glauben, dass es nur in den USA gute Entwickler gibt.
Es ist auch verlockend, jetzt zu empfehlen, dass Sie Ihre Entwicklungsarbeit niemals auslagern sollten. Klar: Wenn Sie ein etabliertes Unternehmen wie Google oder ein VC-finanziertes Startup sind, ist es sinnvoll, alles selbst zu entwickeln und Entwickler mit sechsstelligen Gehältern zu beschäftigen. Aber für ein Bootstrapped-Startup mit einem kleinen Gründungsteam ist es mit Sicherheit gut, preiswertere Arbeitskräfte einzusetzen, die dabei helfen, Ihr MVP auf den Weg zu bringen. Es ist ein Ansatz, den wir schon bei anderen Gelegenheiten erfolgreich anwenden konnten.
Handbuch für Softwareentwickler: Das Standardwerk für professionelles Software Engineering
Es ist auch sehr verlockend, dazu zu raten, sich gegen alles, was bei uns schiefgelaufen ist, schützen zu wollen, indem man bestimmte Vertragsklauseln aushandelt. Leider ist ein solcher Ansatz zum Scheitern verurteilt. Denn es gibt viel zu viele Unbekannte und zu viel Subjektivität, als dass man jemals alles in einem juristischen Dokument festhalten könnte. Ganz zu schweigen davon, dass die rechtliche Durchsetzung von Verträgen durch einen Rechtsstreit ein gewaltiges Unterfangen ist.
Letztlich gibt es nur eine wichtige Sache bei der Beauftragung eines Freelancers oder einer Entwicklerfirma: Sie müssen die Möglichkeit und das Drohpotenzial haben, den Auftrag zu kündigen, wenn die Entwickler keine gute Arbeit leisten. Fast jedes Problem, auf das wir gestoßen sind, rührte von unserem Mangel an Einflussmöglichkeiten her. Da wir so viel Geld im Voraus bezahlt hatten, hatten wir keine Möglichkeit, den Auftrag zu kündigen und jemand anderen zu beauftragen - nicht einmal, als alles sehr schlecht lief.
Ein besserer Weg
Als unser Vertrag auslief, trennten wir uns von der Firma und atmeten erleichtert auf. Ich spürte förmlich, wie mir eine riesige Last von den Schultern fiel. Von nun an änderten wir die Art und Weise, wie wir mit externen Entwicklern arbeiteten, radikal. Hier unsere Liste mit Empfehlungen:
1. Erstellen Sie eine fortlaufende Liste von Funktionen, die gebaut werden sollen.
2. Finden Sie eine Handvoll Entwickler, vorzugsweise unabhängige Freiberufler; aber auch eine Entwicklerfirma wäre in Ordnung, wenn sie mit den folgenden Abläufen einverstanden ist.
3. Wählen Sie für jeden Entwickler das Top-Feature aus der Liste aus und besprechen Sie die Anforderungen, Schätzungen und Kosten für das Feature.
4. Lassen Sie sie diese Funktion implementieren und testen.
5. Lassen Sie jemanden aus dem Unternehmen den Pull-Request überprüfen, die aktualisierte Anwendung testen und alle problematischen Punkte markieren.
6. Wenn Sie zufrieden sind, fügen Sie die Funktion zusammen und stellen Sie sie bereit, so dass alle Gründer/Nutzer die App kontinuierlich überprüfen und bei Bedarf Feedback geben oder Änderungen vornehmen können.
7. Wenn Sie mit der Arbeit der Entwickler zufrieden sind, wählen Sie die nächste Funktion aus, an der sie arbeiten sollen, und wiederholen Sie diesen Prozess.
8. Wenn Sie mit der Arbeit nicht zufrieden sind, trennen Sie sich von ihnen und suchen nach einem Ersatz.
Es war faszinierend zu sehen, um wie viel reibungsloser und angenehmer der Entwicklungsprozess war, nachdem wir uns von riesigen Vorabverträgen befreit und sie durch den oben beschriebenen, schrittweisen Ansatz ersetzt hatten. Unsere Entwickler waren angenehmer in der Zusammenarbeit, zeigten mehr Flexibilität, kommunizierten zuverlässiger mit uns und produzierten bessere Arbeitsergebnisse in kürzerer Zeit.
Das Beste von allem war, dass wir nicht mehr für längere Zeit an einen einzigen Anbieter gebunden waren, was uns große Sicherheit gab. Wenn wir einmal nicht zufrieden waren, wussten wir, dass wir eine Woche später wieder gehen konnten. Das hat uns einige Male gerettet und eine große Last von uns genommen.
Umgekehrt bin ich mir sicher, dass auch die Entwickler diese Flexibilität zu schätzen wussten. Unsere fortgesetzte Zusammenarbeit war etwas, auf das wir uns jede Woche einigten, nicht etwas, zu dem sie sich durch einen Vertrag gezwungen fühlten.
Ist es möglich, mit einem großen Wasserfall-Projekt erfolgreich zu sein, wenn man unseren Fehler vermeidet und den richtigen Entwicklungsdienstleister engagiert? Sicher, aber wie zuversichtlich sind Sie, dass Sie nicht die gleichen Probleme bekommen? Dieses ganze Debakel hat mir eine neue Wertschätzung für Agilität gegeben, und warum es entwickelt wurde.
Zusammenarbeit mit dem Kunden statt Vertragsverhandlungen
Reagieren auf Veränderungen statt Befolgen eines Plans
Es hat sich herausgestellt, dass viele Entwicklungsfirmen sich weigern, auf diese Weise zu arbeiten und darauf bestehen, das Wasserfall-Modell zu verwenden, gepaart mit einem großen Vorabvertrag. Ich werde aber aufgrund meiner vorangegangenen Erfahrungen bei allen zukünftigen Unternehmungen auf der schrittweisen Vorgehensweise bestehen.
Unser erster Gegner in Humankind ist nicht die römische Armee oder eine andere Großmacht, sondern ein Hirsch, der uns kurz nach dem Start der Kampagne, also in der in der Jungsteinzeit, in die Quere kommt. Das Tier tötet zwar 27 Prozent unseres Nomadenstammes, aber dann können wir es doch erlegen.
Trotz des Erfolgs: Als ein paar Züge später ein Mammut am Bildschirmrand auftaucht, ergreifen wir doch lieber die Flucht - sonst schaffen wir es nie in das Industriezeitalter.
Genau das ist aber unser Ziel in dem Strategiespiel, das wie sein wichtigster Konkurrent Civilization zum Genre der 4X-Strategiespiele (Explore, Expand, Exploit, Exterminate) gehört.
Der Titel entsteht im Auftrag von Sega beim französischen Entwicklerstudio Amplitude Studios. Golem.de konnte eine inhaltlich und grafisch sehr fertige Version ausprobieren, an deren Balance allerdings noch gearbeitet wird. Möglicherweise hat der eigentlich harmlose Hirsch deshalb so großen Schaden angerichtet.
Zum Start von Humankind scheuchen wir auf der Suche nach Ressourcen und Land sowie Gegnern oder Verbündeten immer die mehr oder weniger gleichen Nomaden über die schön detailreiche Landschaft. Erst ein paar Züge später entscheiden wir uns für eine Zivilisation: Wir wählen die Ägypter.
Unter anderem sind auch Babylonier, Phönizier und Nubier im Angebot. Die können wir aber später spielen: Anders als in Civilization können wir für jede der sechs Epochen ein anderes Volk wählen und etwa nach den Ägyptern mit den Römern und deren erweiterten Militärkenntnissen neu starten.
Ziel ist es, nach 300 Zügen mehr Ruhmpunkte als die Gegner zu sammeln - etwa durch gewonnene Schlachten, durch Erfindungen oder den Bau von Wundern. Komplexe Siegbedingungen wie in Civilization soll es in Humankind nicht geben.
Mit unseren Ägyptern bauen wir die erste Stadt, was in Humankind etwas aufwendiger ist als im genannten großen Konkurrenten. Metropolen können größer sein, es gibt Verbesserungen im Stadtzentrum etwa zur Herstellung von Ressourcen.
Humankind Day One Edition (PC) (64-Bit)
Auch sonst geht Humankind auf eigene Art mit Land um. Die Welt ist in Regionen unterteilt, die wir etwa über das Errichten von Außenposten für uns reklamieren können. Vorerst haben wir mit unseren Ägyptern aber andere Probleme: Unsere Wettbewerber melden sich. Mit den Olmeken vereinbaren wir einen Pakt mitsamt offener Grenzen.
Die Babylonier sind leider etwas sperriger - unsere Bemühungen um Freundschaft kommen ins Stocken. Und die Mykener suchen sogar Streit: Es kommt zum Krieg. Den können wir in Humankind rundenweise auf separaten Schlachtfeldern austragen oder per Schnellmenü entscheiden lassen - was wir hier siegreich tun.
Die Steuerung wirkt durchdacht - wer mit Civilization klarkommt, dürfte auch hier keine fünf Minuten für die grundlegende Einarbeitung benötigen. In Sachen Grafik gefällt uns das sehr dreidimensionale und detailreiche Humankind sogar etwas besser als Civ; technische Basis ist die Unity-Engine.
Das Spiel bietet sieben Schwierigkeitsgrade, das Angebot reicht von Hamlet bis Humankind. Nach mehreren Verschiebungen ist die Veröffentlichung momentan für den 17. August 2021 geplant. Humankind erscheint gleichzeitig für Windows-PC, MacOS und Google Stadia.
PlayStation Plus hat in letzter Zeit wieder kräftig zugelegt: Heute erscheint Operation Tango, ein neuer Koop-Agenten-Titel für zwei Spieler beziehungsweise Spielerinnen, kostenlos auf PlayStation Plus für PS5-User. Auch Steam- und PS4-Spieler erfreuen sich natürlich des originellen Titels, müssen aber 16,99 Euro bezahlen. Später diesen Sommer kommen noch Xbox One und Xbox X/S Series sowie im Epic Game Store hinzu. So oder so: Das asymmetrische Multiplayer-Spiel vernetzt sie alle untereinander per Crossplay, sodass man so schnell keine Angst haben muss, irgendwann keine Mitspieler mehr zu finden.
Worum es geht, das haben Ana und Alex versucht, zusammen herauszufinden - wenn auch in der PC-Version - und sich dabei alles andere als clever angestellt. Im Grunde ist es durchaus vergleichbar mit einem Titel wie Keep Talking and Nobody Explodes. Eine/r hat eine Bombe vor sich, der oder die andere ist per Funk zugeschaltet und hat die Anleitung, wie man sie entschärft. Der Rest ist Kommunikation, denn sehen kann das tickende Ungetüm nur eine beziehungsweise eine von beiden Parts.
Kommunikation ist also alles - und das gilt auch für Operation Tango: Eine Agentin zu Felde, ihr "Operator" unterstützend, hackend, helfend an einem Computerbildschirm. Es ist ein steter Austausch von Informationen, und manchmal auch nur Emotes in Richtung einer gehackten Überwachungskamera, der in beide Richtungen gut funktionieren muss, will man eine Mission schaffen. Wenn man komplett frisch und ohne Plan herangeht, verwirrt vor allem das Cyberspace-Interface noch, hat man aber erstmal den Dreh raus, weiß man, wie der Hase läuft und lernt schnell, zum Punkt zu kommen. Und wenn es mal nicht klappt, ist das Spiel immer noch vergebend genug, dass es nicht gleich frustriert. Schaut euch am besten selbst an, wie das lief:
Action-Anteile konnten Ana und ich keine entdecken. Auch wird als Agentin weder gesprungen, noch anderweitig groß eure Geschicklichkeit auf die Probe stellend herumgeturnt. Aber das wäre wohl dem Gedanken eines einsteigerfreundlichen Koop-Spiels wohl auch nicht förderlich gewesen. Immerhin geht es in erster Linie darum, dem Partner oder der Partnerin clever klarzumachen, was man sieht, was zu tun ist oder welche Art von Hilfestellung man gerade braucht.
Auch die Gefahren hielten sich in Grenzen, was dafür sorgt, dass das Spiel nicht ganz so spannend ist, wie es sein könnte. Immerhin hat man nichts zu befürchten, außer, dass man die letzte, kurze Sequenz noch einmal probieren muss. Dann wiederum soll das hier auch in erster Linie ein Puzzle sein, das zusammen zu lösen Spaß bereitet. Die Agentenkulisse nehmt ihr am besten als geschmackvolle Verpackung mit und nicht als Versprechen, auch inhaltlich einen Thriller zu erleben.
Unterm Strich dennoch ein interessantes Experiment, dem man durchaus eine Chance geben sollte. Das war schon recht unterhaltsam, wenn es flutschte, und auch optisch ziemlich ansehnlich. Ich bin zwar nicht sicher, wie es um den Wiederspielwert der einzelnen Missionen steht, ein paar Zufallselemente halten einzelne Sequenzen jedoch interessant und zumindest einmal dürfte es sich lohnen, einen Einsatz aus der jeweils anderen Perspektive zu erleben. Insofern: Als PS-Plus-Goodie eigentlich das perfekte Spiel, zumal es so auch keinen Mangel an Mitspielern im Freundeskreis geben dürfte. Sehr nett!
Windows 8 – ohne Startsound. (Screenshot: Microsoft, t3n)
Bis Windows 7 hörten Nutzer von Microsofts Betriebssystem einen Sound, wenn der Bootvorgang abgeschlossen war. Mit Windows 8 war dieser Startsound verschwunden – wohl wegen Jensen Harris.
„Dü-dü“ – die Älteren unter euch erinnern sich sicher noch an die einzigartige Tonsequenz, die von 1992 an bei Windows 3.11 den Abschluss des Bootvorgangs verkündete. Nutzer sollten damit darauf aufmerksam gemacht werden, dass ihr PC einsatzbereit war. In den folgenden Jahren erhielten fast alle neuen Windows-Versionen wie Windows 95, 98, XP oder 7 ihren eigenen unverwechselbaren Startsound. Danach blieben die Computer aber still. Und das lag an Jensen Harris, wie dieser jetzt erklärte.
Ab Windows 8 fehlt akustische Begrüßung
Auf seinem noch relativ jungen Youtube-Kanal hat Harris ein rund 15 Minuten langes Video veröffentlicht, in dem er schildert, warum er den Startsound von Windows gekillt habe. Harris war ab 1998 rund 16 Jahre bei Microsoft tätig und als Director of Program Management für das Windows User Experience Team auch an der Entwicklung von Windows 8 beteiligt. Dass die akustische Begrüßung beim Hochfahren von Windows-Computern seit einem Jahrzehnt ausbleibt, hat Harris zufolge einen einfachen Grund – er störte zunehmend.
In dem oben angesprochenen Video führt Harris das natürlich etwas genauer aus. Zum einen rückte Microsoft mit Windows 8 das Thema Notebooks stärker in den Mittelpunkt. Heißt: Computer wurden nicht mehr nur am Schreibtisch gestartet, sondern auch im Wohn- oder Schlafzimmer oder gleich ganz außerhalb der Wohnung. Microsoft begann zu dieser Zeit auch, eine Touch-fähige Oberfläche für Windows zu entwickeln.
Startsound in vielen Situationen störend
Das Erweckungserlebnis für Harris in puncto Windows-Startmelodie war laut seinen Angaben aber ein Abend zu Hause, wie Winfuture berichtet. Harris habe neben seinem schlafenden Baby und wollte sein Macbook (sic!) hochfahren, um zu surfen. Weil er aber nicht sicher war, ob er den Ton bei dem Gerät ausgeschaltet hatte, ließ er das Macbook aus Angst vor einem möglichen lauten Störgeräusch gleich ganz aus.
In dieser Nacht sei ihm klar geworden, so Harris, dass ein Geräusch beim Start des Computers in vielen Situationen störend ist – und beauftragte sein Team den Startsound aus Windows 8 zu entfernen. Später habe er versucht, die Entscheidung rückgängig zu machen. Dafür sei es dann aber zu spät gewesen. Die Entwickler hatten den entsprechenden Code schon entfernt. Das Gute: Dadurch konnte der Bootvorgang beschleunigt werden.
![[PLUS] Lohnt sich Aufrüsten? Alte GPUs mit maximaler Übertaktung gegen aktuelle Grafikkarten](https://www.pcgameshardware.de/screenshots/1020x/2020/05/aufmacher_alte_GPUs_v2-pcgh1.png)
[PLUS] Lohnt sich Aufrüsten? Alte GPUs mit maximaler Übertaktung gegen aktuelle Grafikkarten
