SCS - Texturen und Oberflächen

„Unter der Haube“ Texturen und Oberflächen

Freitag, 24. Juli 2026

https://blog.scssoft.com/2026/07/under-hood-improved-material-system.html

Mit dem 1.60er Update haben wir für ausgewählte Lkw aus dem Euro Truck Simulator 2 und dem American Truck Simulator ein verbessertes „Materialsystem“ eingeführt. Heute gewähren wir nun einen Blick hinter die Kulissen und zeigen, wie dieses „Feature“ (Neuerungen) entstehen!

Die beiden Hauptverantwortlichen für diese Feature sind unsere Kollegen Daniel und Martin; sie haben das System für Lkw in beiden Spielen implementiert – und tun dies auch weiterhin – und arbeiten zudem nun auch an der Umsetzung für die Pkw im kommenden „Road-Trip“-Projekt für den American Truck Simulator.

Daniel – Technischer Leiter Fahrzeugentwicklung

„Ich arbeite seit über dreizehn Jahren bei SCS Software. Ich habe als 3D-Generalist angefangen und war anschließend als 3D-Vehicle-Artist (3D Künstler) sowie als Teamleiter für den Fahrzeugbereich tätig. Heute bekleide ich die Position des sogenannten Vehicle Technical Leader.

Meine Arbeit schlägt die Brücke zwischen den grafischen und den technischen Aspekten der Entwicklung. Ich arbeite eng mit Programmierern zusammen, um Fahrzeugfunktionen in die Engine zu integrieren, und unterstütze gleichzeitig die Artists dabei, effiziente Arbeitsabläufe zu etablieren. Zudem konzipiere ich neue Tools und technische Verbesserungen.

Bei der Überarbeitung des Materialsystems bestand meine Aufgabe darin, das Problem zu identifizieren, eine Lösung vorzuschlagen und gemeinsam mit den Programmierern deren Umsetzung in der Engine zu realisieren. Anschließend mussten wir einen praktikablen Arbeitsablauf für das Fahrzeugteam schaffen, damit das System einheitlich für verschiedene Fahrzeuge genutzt werden konnte. Die Programmierer schufen die erforderlichen Voraussetzungen in der Engine und bei den Shadern. Die Grafikdesigner konvertierten und optimierten daraufhin die Materialien für die jeweiligen Lkw.“

Martin – Senior 3D Graphic Designer

„Ich arbeite als Senior 3D Graphic Designer mit Schwerpunkt auf Fahrzeugen. Zudem war ich als Head of Content für das ‚Road-Trip‘-Projekt tätig. Ich war an der Auswahl der Fahrzeuge und ihrer spezifischen Varianten beteiligt, übernahm Recherche und Vorproduktion, leistete fachliche Beratung und arbeitete anschließend an der eigentlichen Erstellung der Fahrzeuge. Außerdem unterstützte ich Dan bei der Feinabstimmung des Materialsystems.

Autos sind schon lange meine Leidenschaft, insbesondere Sportwagen und Oldtimer – vor allem amerikanische Modelle. Dadurch konnte ich meine eigene Erfahrung und mein Wissen über die amerikanische Autokultur, die Geschichte und die technische Entwicklung einzelner Modelle in das Projekt einbringen.

Meine Hauptaufgabe war der 1967er Ford Mustang und alles, was mit dessen visueller und inhaltlicher Aufbereitung zu tun hatte. Ich war in die Auswahl des konkreten Fahrzeugs und der Variante eingebunden, führte Recherchen durch, trug Referenzmaterial zusammen, beriet bei der Datenerfassung und kümmerte mich um die eigentliche Erstellung des Modells und der Materialien.

Während der Entwicklung des neuen Materialsystems bereitete ich die einzelnen Oberflächen des Mustang vor und stimmte sie fein ab. Gemeinsam mit Dan nutzten wir dieses Fahrzeug, um zu überprüfen, wie sich die neue technische Lösung in der Praxis verhielt und welche Werte die genauesten Ergebnisse lieferten.“

Wie hat dieses Projekt begonnen?

„Die Entwicklung begann, während wir am ‚Road-Trip‘-Projekt arbeiteten. Die Innenräume von Pkw sind kleiner und dunkler als die von Lkw, weshalb die Schwachstellen des ursprünglichen Systems dort deutlicher zutage traten.“

Abgesehen von direktem Licht bot das ursprüngliche System keine Möglichkeit, Licht im Innenraum darzustellen. In der Realität macht sogenanntes indirektes oder reflektiertes Licht (Global Illumination/GI) einen großen Teil der visuellen Wahrnehmung aus. Das Spiel berücksichtigte dieses Konzept jedoch überhaupt nicht und war auch nicht dafür ausgelegt. Uns war klar, dass wir daran etwas ändern mussten.

Ein weiteres Problem bestand darin, dass die Innenräume der Lastwagen eine Vielzahl unterschiedlicher Materialien aufwiesen – etwa Stoff, Leder, Kunststoff, lackierte Oberflächen, Metall und Glas. Mit dem ursprünglichen System konnte man diese Materialien nicht naturgetreu darstellen, insbesondere bei indirektem Licht; wirkte alles sehr flach.

„‘Road Trip’ bot uns eine geeignete, abgeschirmte Umgebung für Entwicklung und Tests. Von Anfang an haben wir das System jedoch so konzipiert, dass es auch für Lkw eingesetzt werden kann“, sagt Daniel.

Was mussten Sie tun, bevor Sie mit der eigentlichen Umsetzung des verbesserten Systems begannen?

„Wir mussten die konkreten Fahrzeuge sowie die im Innenraum verwendeten Materialien durch umfassende Recherchen detailliert erfassen. Ich habe Fachzeitschriften, Fotos, verfügbare Unterlagen und die verschiedenen Ausstattungsvarianten analysiert. Bei der Datenerhebung hatten wir zudem die Gelegenheit, das jeweilige Fahrzeug persönlich zu begutachten, mit dem Besitzer zu sprechen und dessen Aufbau sowie Erscheinungsbild genau zu dokumentieren.“

Es reichte nicht aus, lediglich festzustellen, dass ein bestimmtes Teil des Innenraums beispielsweise aus Kunststoff, Leder oder Metall bestand. Wir mussten auch die Oberflächenbeschaffenheit, den Glanzgrad, das Lichtreflexionsverhalten, die Abnutzungserscheinungen, den Farbton sowie die Unterschiede zwischen den einzelnen Bauteilen untersuchen.

„Diese Untersuchungen bildeten die Grundlage, auf der wir später beurteilen konnten, ob die Materialien im Spiel dem tatsächlichen Fahrzeug entsprachen“, erklärte uns Martin.

„Wir mussten uns auch für eine bestimmte Richtung entscheiden. Da die Wahrung der Leistungsfähigkeit eine der wichtigsten Anforderungen war, suchten wir nach Ansätzen, die keine komplexen Rechenoperationen erforderten, und nach Techniken, die gute Ergebnisse bei minimaler Erhöhung der Rechenlast lieferten. Ich glaube, das Ergebnis unserer Bemühungen ist eine spürbare Verbesserung der Grafik bei minimalen Auswirkungen auf die Performance“, erklärte Daniel.

Wie sah der Prozess der Implementierung des neuen Systems in das Spiel aus?

„Wir mussten Änderungen an der Engine vornehmen, die betrafen, wie das Spiel reflektierende Texturen lädt und verarbeitet. Eine reflektierende Textur ist im Grunde ein Würfel, dessen Seiten jeweils eine Reflexion in einer anderen Richtung relativ zum Spieler zeigen. Ihre Verwendung ist wesentlich effizienter als die Berechnung echter Lichtreflexionen mittels Raytracing. Wir haben diverse Änderungen am Code vorgenommen, um direkten Zugriff auf einzelne Mipmaps zu erhalten. Eine Mipmap ist eine verkleinerte Kopie des Originalbilds; sie wird typischerweise verwendet, wenn sich ein texturiertes Objekt weiter vom Spieler entfernt befindet, um unschöne Aliasing-Effekte bei der Textur zu vermeiden. In unserem speziellen Fall führt eine geringere Auflösung jedoch automatisch zu einer weicheren Reflexion. Dies lässt sich für Materialien nutzen, die keine zu 100 % glänzende Oberfläche aufweisen, sondern eher eine physikalisch rauere Struktur besitzen, wodurch die Reflexion auf dem Material diffuser wirkt.“

Auf diese Weise haben wir verschiedene Abstufungen der Reflexionsglätte geschaffen: von hochglänzenden Oberflächen wie Chrom über glattere Reflexionen, wie sie bei Sitzbezügen aus Leder vorkommen, bis hin zu rauen, kaum reflektierenden Materialien wie Stoffen, bei denen eine Seite des Reflexionswürfels lediglich 2 x 2 Pixel groß ist. In unserem Fall ersetzt diese Methode die Irradiance Map; sie dient also primär dazu, das umgebende Lichtspektrum auf das jeweilige Material zu projizieren (Farbstich). Da das Spiel die Mipmaps ohnehin bereits berechnete, verursacht diese Änderung praktisch keinen zusätzlichen Rechenaufwand – und genau das war der Hauptgrund, warum wir uns für diesen Ansatz entschieden haben.

Neben den Änderungen an den Materialien mussten wir auch Kontrast und Beleuchtung im gesamten Spiel neu ausbalancieren, um extrem dunkle Bereiche zu beseitigen und eine realistischere Lichtwirkung zu erzielen.

Im Gegensatz zur ursprünglichen Lösung, bei der Reflexionstexturen nur für stark reflektierende Materialien – insbesondere Metalle – verwendet wurden, kommt das überarbeitete System bei jedem einzelnen Material im Fahrzeuginnenraum zum Einsatz. Die Materialien unterscheiden sich jedoch darin, wie stark die Reflexion im fertigen Bild sichtbar ist und wie weich sie dargestellt wird. Dadurch vermitteln selbst weniger stark reflektierende Materialien – vor allem Kunststoffe – den Eindruck von reflektiertem Licht, Farbnuancen und verbessertem Kontrast, besonders in den schattigen Bereichen des Innenraums. Spieler werden nun bemerken, dass der gesamte Innenraum tatsächlich auf die Umgebung des Lkw reagiert; fährt man beispielsweise an Bäumen vorbei, nimmt der Bereich des Innenraums nahe den Fenstern einen dezenten Grünstich an. Dies lässt das Spiel deutlich realistischer wirken als zuvor – und das ganz ohne die rechenintensive Berechnung der globalen Beleuchtung (Global Illumination, GI).

Nachdem die Technologie einsatzbereit war, mussten wir festlegen, wie die einzelnen Materialien unter den neuen Bedingungen angepasst werden sollten. Da nun jedes Material eine Reflexionskomponente aufweist, mussten wir die Einstellungen für alle Materialien komplett neu abstimmen. Um sicherzustellen, dass die vorhandenen Texturen mit den neuen Einstellungen korrekt funktionieren, mussten wir zudem deren Farb- und Glanzlichtkomponenten (Specular-Werte) an die Standardwerte anpassen, die wir in umfangreichen Tests ermittelt hatten.

„Der letzte Schritt für die systemweite Einführung war die Erstellung einer Materialbibliothek, damit wir nicht jeden Materialtyp für jedes Fahrzeug einzeln konfigurieren mussten“, erklärt Daniel.

Was waren die größten Herausforderungen bei der Implementierung des Systems?

„Die größte Herausforderung war die Vielfalt der Fahrzeuge. Die einzelnen Lkw wurden zu unterschiedlichen Zeitpunkten erstellt und nutzten jeweils andere Quelldaten, Texturen und Rendering-Verfahren. Es gibt kein einheitliches Konvertierungsverfahren, das für alle Lkw funktioniert. Jeder fertiggestellte Innenraum hat eine eigene Struktur und erfordert eine individuelle Vorgehensweise“, sagt Daniel.

Zudem beeinflussen sich die einzelnen Materialeigenschaften gegenseitig. Eine Änderung des Reflexionsgrads oder der Rauheit mag zwar das Erscheinungsbild einer Oberfläche verbessern, kann aber gleichzeitig dazu führen, dass sich das Material bei anderen Lichtverhältnissen ungünstig verhält. So wirkt ein Material, das bei direktem Tageslicht stimmig erscheint, in einem dunklen Innenraum womöglich zu glänzend oder verhält sich bei Nachtfahrten unnatürlich. Es galt daher, stets ein Gleichgewicht zwischen Realismus, Sichtbarkeit und konsistentem Verhalten zu finden. Ziel war es nicht, alle Oberflächen stärker hervorzuheben oder glänzender zu gestalten, sondern die Unterschiede zwischen ihnen präzise abzubilden.

Viele dieser Schritte wurden im Laufe der Entwicklung mehrfach überarbeitet. Das Ergebnis waren jedoch nicht nur Materialien für ein bestimmtes Fahrzeug, sondern auch Erfahrungen und Richtlinien, die die Arbeit an künftigen Fahrzeugen erheblich erleichtern werden.

„Der Prozess war nicht ganz einfach. Es reichte nicht aus, einfach ein paar Parameter anhand einer vorgefertigten Tabelle festzulegen. Wir mussten viele der Werte selbst ermitteln und haben sie gemeinsam mit Dan immer wieder direkt im Spiel getestet“, fügte Martin hinzu.

Wie haben Sie die Änderungen umgesetzt, ohne die Leistung zu beeinträchtigen?

„Unsere Spieler nutzen eine große Bandbreite an Hardware. Wir wollten keine optischen Verbesserungen einführen, die die Spielleistung erheblich verschlechtern oder das Spiel für manche Spieler sogar unspielbar machen würden. Daher basiert das System nicht auf einer neuen, rechenintensiven Beleuchtungssimulation. Es erweitert die bestehende Rendering-Pipeline und nutzt bereits vorhandene Daten effizienter.

Während der Entwicklung wurde die Leistung kontinuierlich überwacht. Das Ziel war eine sichtbare Verbesserung bei minimaler Belastung von Grafikkarte und Arbeitsspeicher. Zudem ist das System so konfiguriert, dass es auch bei mittleren oder niedrigen Einstellungen funktioniert – wenn auch mit gewissen Abstrichen: In diesen Fällen werden zwar keine Reflexionen in Echtzeit berechnet, und einige Vorteile – wie etwa realistische Farbreflexionen aus der Fahrzeugumgebung – gehen verloren, doch die Materialien selbst wirken weiterhin realistisch und lassen sich gut voneinander unterscheiden“, erklärt Daniel.

Bislang haben wir das verbesserte Materialsystem bei vier Lkw in ETS2 und ATS implementiert. Anstatt die Community warten zu lassen, bis alle Lkw aktualisiert sind, werden wir das verbesserte System schrittweise auch für weitere Fahrzeuge einführen. So können Sie die Verbesserungen bei einigen Modellen bereits genießen, während wir die übrigen fertigstellen. Wie Daniel hier erklärt:

„Jeder Lkw erfordert individuelle Anpassungen, eine visuelle Überprüfung sowie Tests aller Varianten – bei Tageslicht, bei Nacht, bei Regen und bei bewölktem Himmel. Daher war es nicht möglich, die gesamte Flotte auf einmal zu aktualisieren. Diese erste, kleinere Gruppe ermöglicht es uns, den gesamten Produktionsprozess zu überprüfen, die Qualität zu wahren und Feedback von den Spielern einzuholen.“

Wir hoffen, Ihnen allen hat dieser detaillierte Einblick in die Arbeit an unserem verbesserten Materialsystem gefallen. Setzen Sie unbedingt auch das „Ford Car Pack“ sowie das „RAM & Dodge Car Pack“ auf Ihre Steam-Wunschliste, damit Sie diese Neuerung bei den Fahrzeugen direkt nach der Veröffentlichung genießen können.

Vergessen Sie nicht, uns auf  X/Twitter, Instagram, Facebook, Bluesky, TikTok, und YouTube zu folgen, um Updates zu unseren Spielen direkt erhalten zu können! Oder abonnieren unseren Newsletter, um auf dem Laufenden zu bleiben. Bis zum nächsten Mal – gute Fahrt!

Beitrag von Petr, SCS – Software. Übersetzung von Angelwingking

SCS - Under the Hood - UI / UX

Under The Hood: UI/UX und QA

Samstag, 11. Juli 2026

https://blog.scssoft.com/2026/07/under-hood-uiux-qa.html

Heute nehmen wir Sie mit hinter die Kulissen der Entwicklung des Euro Truck Simulator 2 & American Truck Simulator, um einen weiteren wichtigen Teil des Prozesses beleuchten zu können, der Ihr Erlebnis auf der Straße mitgestaltet. Diesmal richten wir den Fokus auf die Qualitätssicherung (QA) im Bereich UI/UX und deren Rolle bei der Schaffung intuitiver, unterhaltsamer und ausgereifter Benutzeroberflächen für unsere Spieler.

Um Sie durch diesen spannenden Bereich zu führen, möchten wir Ihnen Petr und Jan aus unserem UI/UX-QA-Team vorstellen. Sie nehmen Sie mit durch ihren Arbeitsalltag, erläutern ihre Aufgaben und zeigen, wie sie sicherstellen, dass sich jedes Menü, jeder Button und jede Interaktion genau richtig anfühlt, bevor sie auf Ihrem Bildschirm erscheinen.

Petr – Lead für Console & UI/UX-QA

„Hallo! Ich heiße Petr und arbeite als QA-Lead für die Bereiche Konsole sowie UI/UX. Gemeinsam mit meinen Kollegen habe ich zwei Teams aufgebaut, die heute eine entscheidende Rolle dabei spielen, dass unsere Spiele technisch einwandfrei funktionieren und ein großartiges Nutzererlebnis bieten.

Wir sind für den Euro Truck Simulator 2 und den American Truck Simulator auf allen Plattformen zuständig – dazu gehören der klassische PC, das Steam Deck, VR, PlayStation sowie Xbox Series X/S. Neben den eigentlichen Spielen sind wir auch maßgeblich an der Testphase von Projekten wie Driving Academy, Coaches und Road Trip beteiligt.

Meine Arbeit konzentriert sich vor allem auf Koordination, Planung und die Analyse von Testergebnissen. Ich arbeite eng mit anderen Teams zusammen, um Fehler oder UX-Probleme so früh wie möglich zu erkennen und zu beheben. Mein Ziel ist es, unsere Abläufe so zu gestalten, dass das gesamte Team effizient und konzentriert arbeiten kann – ganz ohne unnötigen Druck im Vorfeld neuer Patch- oder DLC-Veröffentlichungen.

Zudem teste ich aktiv alles, woran mein Team gerade arbeitet. Das Testen macht mir nicht nur großen Spaß, sondern bietet meiner Meinung nach auch einen entscheidenden Vorteil: Durch die direkte Einbindung in den gesamten Prozess kann ich besser erkennen, wo wir uns als Team weiterentwickeln und verbessern können.

Ich stehe meinem Team jederzeit mit Rat und Tat zur Seite, wenn Unsicherheiten oder Fragen aufkommen, und lege großen Wert auf eine positive, freundliche Atmosphäre, in der die Zusammenarbeit allen Freude bereitet.“

Jan – Senior UI/UX-Tester

„Hallo, ich bin Jan und arbeite als Senior UI/UX-Tester mit Schwerpunkt auf Playtesting. Ich bin 31 Jahre alt und seit zwei Jahren bei SCS Software tätig. Ursprünglich habe ich als Junior-Tester ohne spezielle Fachrichtung angefangen, doch nachdem ich mich im Team eingearbeitet und unsere Entwicklungsprozesse kennengelernt hatte, entdeckte ich schnell meine Leidenschaft für User Experience.

Mit der Unterstützung und Anleitung von Petr, der zu diesem Zeitpunkt bereits Senior war, habe ich unseren Playtesting-Prozess mit aufgebaut und verfeinere ihn seither kontinuierlich.“

Was ist UI/UX-QA?

„Bevor ein neues Feature in unsere Spiele integriert wird, durchläuft es einen langen Prozess. Dabei spielt UI/UX (User Interface/User Experience) eine zentrale Rolle. Egal, ob es sich um ein neues Feature oder die Überarbeitung eines bestehenden handelt – alles beginnt mit einer Analyse und dem Austausch zwischen uns (der QA-Abteilung) und dem Game-Design-Team (GD). Bei Überarbeitungen müssen wir zunächst den Ist-Zustand bewerten: Was funktioniert gut, wo sind Änderungen nötig? Sowohl bei neuen Features als auch bei Überarbeitungen müssen wir uns zudem überlegen, welches Ziel wir erreichen wollen. Die Antworten auf diese Fragen bilden dann die Grundlage für alle weiteren Entscheidungen.“

Wie sieht ein typischer UI/UX-Testprozess aus und wie eng arbeiten Sie mit anderen Teams zusammen?

„Grundsätzlich versuchen wir, so früh wie möglich in die Feature-Entwicklung eingebunden zu werden und eng mit dem Game-Design-Team zu kooperieren. So sind wir auch schon in der nächsten Phase des Entwicklungsprozesses dabei und geben Feedback zum Design. Das bedeutet, dass wir uns das Design-Dokument ansehen und versuchen, vorausschauend zu denken. Wir stellen uns Fragen wie: ‚Ist das intuitiv? Ist sofort erkennbar, dass es sich um einen Button handelt? Haben wir etwas übersehen? Wie sieht es mit der Barrierefreiheit aus? Ist der Text auch auf einem kleineren Bildschirm gut lesbar?‘ und vieles mehr. Nach einem gewissen Austausch mit dem Game-Design-Team gelangen wir schließlich zu einem Design, das dann von einem Programmierer umgesetzt werden kann.“

Mit dem ersten spielbaren Prototypen beginnt die Phase, in der wir gewissermaßen zweigleisig fahren müssen. Einerseits gilt es weiterhin, das große Ganze im Blick zu behalten: das Design zu verstehen, zu sehen, wie die einzelnen Elemente ineinandergreifen, und die Hintergründe bestimmter Entscheidungen zu kennen. Andererseits müssen wir das Spiel nun auch aus der Sicht eines Spielers betrachten, der eine bestimmte Funktion zum ersten Mal erlebt. Wir müssen uns in einen Neuling hineinversetzen, der noch nie zuvor ein Videospiel gespielt hat – oder in einen Hardcore-Gamer, der zwar viel Erfahrung mitbringt, aber noch nie einen Truck-Simulator gespielt hat; oder auch in einen echten Lkw-Fahrer, der unsere Spiele während der Ruhepausen auf einem Handheld spielt. Unsere Spiele erreichen ein sehr breites Publikum, und das Design muss für all diese Spielertypen funktionieren und intuitiv verständlich sein.

In dieser Phase identifizieren wir weitere Probleme, schlagen Verbesserungen vor und suchen gemeinsam mit dem Game-Design-Team sowie den für das Feature zuständigen Programmierern nach möglichen Lösungen. Sobald wir mit dem erreichten Stand zufrieden sind, folgt die Validierung im nächsten Schritt.

Ein weiterer wichtiger Meilenstein in der Entwicklung des Features ist das interne Playtesting. Dies ist eine hervorragende Möglichkeit, neue Perspektiven von Mitarbeitern aus verschiedenen Unternehmensbereichen zu gewinnen, die die Designdokumente nicht kennen und idealerweise noch nichts über das Feature wissen. Vor Beginn der Tests legen wir fest, welche Fragen wir beantworten wollen: „Ist dieser Bildschirm intuitiv? Lassen sich alle Zubehörteile gut steuern? Hat die Ergänzung von X zu unnötigen Hürden im Ablauf geführt?“ Auf dieser Grundlage erstellen wir detaillierte Szenarien, die die Testpersonen durchlaufen. Ziel ist es, sie dazu zu bringen, sich mit dem (überarbeiteten) Feature auf eine Weise auseinanderzusetzen, die einen regulären Gameplay-Ablauf simuliert. Anschließend laden wir die Testpersonen in unser Playtest-Labor ein. Dort begleiten wir sie durch die Szenarien, beobachten ihr Verhalten und ihre Reaktionen, machen uns Notizen und stellen Fragen. Zudem setzen wir Eye-Tracking ein; dies liefert uns wertvolle Erkenntnisse darüber, worauf die Spieler ihren Blick richten – also welche Elemente zuerst wahrgenommen werden und welche völlig unbemerkt bleiben.

Nach Abschluss des Playtests füllen die Teilnehmenden einen Fragebogen aus. Dies gibt ihnen die Gelegenheit, sich eingehender mit der Funktion zu befassen, weitere Anmerkungen zu machen und womöglich eigene Ideen zu entwickeln.

Daraus gewinnen wir eine große Menge an Daten, die ausgewertet werden müssen. Hierbei wenden wir Methoden der angewandten Forschung an: Wir beginnen mit der qualitativen Kodierung, gefolgt von einer thematischen Analyse inklusive Häufigkeitsauszählung. Vereinfacht ausgedrückt gehen wir alle Rohdaten – also die Aussagen und beobachteten Verhaltensweisen – durch und ordnen sie verschiedenen Kategorien zu, wobei wir auch erfassen, wie oft sie genannt oder beobachtet wurden. Dies hilft uns, wiederkehrende Muster zu erkennen und diese übergeordneten Themenbereichen oder Problemfeldern zuzuordnen.

Anschließend erstellen wir einen Abschlussbericht, der das Verhalten, die Reaktionen und die Meinungen der Teilnehmenden zusammenfasst, grundlegende Probleme aufzeigt und mögliche Lösungsansätze vorschlägt.

Die weiteren Schritte hängen von den Ergebnissen des Playtests ab. Sollten wir tiefgreifende Probleme feststellen, die umfassende Designänderungen erfordern, müssen wir zur Konzeptionsphase zurückkehren und die vorangegangenen Schritte wiederholen. Dies mündet schließlich in einen weiteren Playtest, um zu überprüfen, ob die Probleme zufriedenstellend gelöst wurden. Ein gutes aktuelles Beispiel hierfür ist die Überarbeitung der Funktion „Zeit überspringen / Ausruhen“ (Skip Time / Rest), bei der zudem die Mechanik der Erschöpfung (Fatigue) in zwei separate Systeme aufgeteilt wurde: Erschöpfung und obligatorische Pause. Während des Playtests stellten wir fest, dass diese neue Aufteilung und deren Darstellung für die Spielenden sehr verwirrend waren. Die Funktion musste daher grundlegend neu gestaltet werden – mit großem Erfolg (zumindest hoffen wir das).

Wenn wir hingegen nur oberflächliche Probleme feststellen, die noch etwas Feinschliff benötigen, kümmert sich die GD-Abteilung darum, und wir können mit der abschließenden Testphase des Features fortfahren.

Bei diesem letzten Testlauf konzentrieren wir uns hauptsächlich auf die FQA (Functional QA) – das Design steht weitgehend fest, und wir stellen nun sicher, dass alles wie vorgesehen funktioniert. Sobald dies abgeschlossen ist, kann das Feature in den Hauptzweig (Main Branch) integriert werden. Dort übernimmt die Abteilung für Integration-QA und prüft, ob das Feature den Zusammenführungsprozess im gewünschten Zustand überstanden hat und keine anderen Funktionen beeinträchtigt wurden – aber das ist ein Thema für ein anderes Kapitel."

Was macht dir an der Arbeit im Bereich UI/UX am meisten Spaß?

Petr: "Was mir am meisten Spaß macht? Das ist eine schwierige Frage. Kurz gesagt: eigentlich alles! Alle in unserem Team sind leidenschaftliche Fans von Spielen unterschiedlichster Art und Genres. Daher ist es unglaublich bereichernd, eigene Ideen und Vorschläge für den Euro Truck Simulator 2 und den American Truck Simulator einbringen zu können.

Bei SCS gehen wir oft unsere eigenen Wege, was die Arbeit besonders reizvoll macht. Gleichzeitig stehen bei jeder Entscheidung unsere Spieler im Mittelpunkt. Bei der Entwicklung neuer Gameplay-Funktionen können Designer leicht in einen sogenannten ‚Tunnelblick‘ verfallen. Unsere Aufgabe ist es, diese Sichtweise zu hinterfragen und eine frische Perspektive einzubringen. Wir denken an unsere erfahrenen Trucker, verlieren dabei aber nie die Spieler aus den Augen, die gerade erst anfangen. Die Benutzeroberfläche des Spiels aus verschiedenen Blickwinkeln zu betrachten, ist sowohl ein wesentlicher Bestandteil unserer Arbeit als auch einer ihrer kreativsten Aspekte.

Wir setzen alles daran, unsere Spiele so zugänglich wie möglich zu gestalten und gleichzeitig sicherzustellen, dass der Spielspaß dabei nicht zu kurz kommt."

Jan: "Mir gefällt die Kombination aus technischen und menschlichen Aspekten. User Experience ist im Grunde eine Interaktion zwischen Mensch und Maschine, und man muss dafür sorgen, dass beide einander verstehen.

Das erste Projekt, das ich initiiert und umgesetzt habe, war die visuelle Darstellung der Grafikeinstellungen mittels Screenshots. So konnten Spieler leichter erkennen, welche Auswirkungen ihre Änderungen an der Grafik hatten. Das ist das perfekte Beispiel für das, was ich meine: Mich interessiert sowohl, wie die Dinge ‚unter der Haube‘ funktionieren, als auch, wie der Spieler sie wahrnimmt und versteht."

Welche Botschaft möchtest du unserer Community vermitteln, und wie wertvoll ist das Feedback der Spieler für die Verbesserung des Spielerlebnisses?

„Das Feedback der Spieler ist für uns unglaublich wichtig und eine ständige Inspirationsquelle. Wir freuen uns sehr, dass hier bei SCS immer mehr Initiativen auf der Grundlage eures Feedbacks entstehen. Ich möchte euch versichern, dass wir eure Kommentare, Ideen und Vorschläge wirklich aufmerksam lesen – nicht nur unser UI/UX-Team, sondern das gesamte Studio.

Es ist offensichtlich, wie sehr Ihnen unsere Spiele am Herzen liegen, wenn Sie sich so engagiert einbringen – und uns geht es ganz genauso. Wir lieben den Euro Truck Simulator 2 & den American Truck Simulator und wollen sie immer weiter verbessern. Wir möchten wirklich wissen, was Ihnen gefällt, welche Neuerungen Sie sich wünschen und was Ihre Meinung nach noch optimiert werden könnte. Wir haben bereits eine unglaubliche Menge an Feedback erhalten. Ich wünschte, ihr könntet die umfangreichen Dokumente sehen, in denen wir all eure Ideen und Wünsche sorgfältig sammeln und ordnen.

Leider können wir nicht jeden Vorschlag umsetzen. Dafür kann es viele Gründe geben, die nicht immer sofort offensichtlich sind – etwa Einschränkungen der Engine, begrenzte interne Ressourcen, technische Beschränkungen unserer Spielsysteme, Lizenzvereinbarungen und mehr. Aber bitte: Bleiben Sie weiterhin im Austausch mit uns! Ihr Feedback bleibt nie unbeachtet. Ihnen ist es schließlich zu verdanken, dass wir diesen Weg weitergehen und das Erlebnis gemeinsam immer besser machen können.

Danke an alle, die diesen spannenden Weg gemeinsam mit uns beschreiten!“

Beitrag von Dave, SCS-Software. Übersetzung von Angelwingking

SCS - Die Tester

Under The Hood, Qualitätssicherung der 

In-Game-Karte

Freitag, 19. Juni 2026

https://blog.scssoft.com/2026/06/under-hood-in-game-map-qa.html

Die Entwicklung von Euro Truck Simulator 2 und American Truck Simulator ist eine Gemeinschaftsarbeit vieler talentierter Teams von SCS-Software. Während Kartendesigner, Künstler, Programmierer und mehr das Fahrerlebnis gestalten, arbeitet ein anderes Team mit ihnen zusammen, um sicherzustellen, dass alles genau wie vorgesehen funktioniert, bevor die Spieler auf die virtuelle Straße gehen können.

In diesem „Under the Hood“-Blogbeitrag möchten wir zwei Mitglieder unseres In-Game-QA-Teams vorstellen: Ivan und David. Wir haben sie zu ihrem Arbeitsalltag befragt, dazu, wie sich das Testen in den Entwicklungsprozess einfügt, und warum Qualitätssicherung weit mehr umfasst als nur das bloße Spielen des Spiels – und mehr!

David – ATS Map QA Lead

„Hallo zusammen, liebe Trucker! Ich heiße David und bin 28 Jahre alt. Ich habe bei SCS als Junior-Tester angefangen, als ich gerade einmal 20 war – damals war ich der jüngste Mitarbeiter im gesamten Unternehmen. Heute bin ich QA-Leiter für das Map-Testing von ATS. Das bedeutet, dass ich die Tests aller ATS-Karten-DLCs organisiere und überwache, mich mit den Leitern unserer Map-Design-Teams abspreche, die komplexesten Probleme und Fehler löse, auf die wir stoßen, und einfach für mein Team da bin, wann immer Hilfe benötigt wird. Im Laufe der Jahre habe ich miterlebt, wie SCS-Software von einem Team mit rund 100 Mitarbeitern zu einem Unternehmen mit mehr als 400 Angestellten gewachsen ist. Als ich anfing, arbeiteten wir gerade am Oregon-DLC; es ist beeindruckend zu sehen, wie sich unsere Entwicklungs- und Testprozesse parallel zu unseren immer umfangreicheren Spielwelten weiterentwickelt und verbessert haben.“

Ivan – QA-Leiter für World Map Design

„Hallo zusammen! Ich heiße Ivan und bin seit etwas mehr als sechs Jahren bei SCS Software. Ich habe als Junior-Tester angefangen, übernahm aber schon bald die Verantwortung für die Koordination der Karten-Tests beim Euro Truck Simulator 2. Heute bin ich als ‚World Map Design QA Lead‘ tätig und leite unser gesamtes Karten-Testteam, das derzeit aus 20 Personen besteht. Gemeinsam überwachen wir die Tests sowohl für den American Truck Simulator als auch für den Euro Truck Simulator 2. Während sich mein Kollege Davincillo um die tägliche Organisation beim ATS kümmert, liegt mein Schwerpunkt seit Jahren auf dem ETS2.“

Wenn Leute „Game-Testing“ hören, stellen sie sich oft vor, man würde einfach den ganzen Tag Spiele spielen. Wie sieht die Realität aus?

„Beim Karten-Testen geht es definitiv nicht nur darum, den ganzen Tag zu spielen. Das ist ein klassischer Mythos. Zwar hat das ‚Spielen‘ durchaus seine Berechtigung, aber es findet eigentlich nur in der Endphase unseres Testprozesses statt. Die Realität ist weitaus methodischer. Wir verbringen Stunden oder sogar Tage damit, einen bestimmten Teil der Karte zu testen. Wir befahren denselben Straßenabschnitt mehrfach und überprüfen bei jedem Durchgang völlig unterschiedliche Aspekte, wobei wir verschiedene Kameraeinstellungen und Debug-Tools nutzen.

Bloßes Spielen reicht nicht aus, um ein guter Tester zu sein. Man benötigt bestimmte Fähigkeiten: Liebe zum Detail, eine logische und analytische Denkweise, ein gutes Verständnis für Standards der Spieleindustrie sowie die Leidenschaft, Spiele für andere noch unterhaltsamer zu gestalten. Auch Kommunikationsfähigkeit ist entscheidend, denn das Finden eines Fehlers ist nur die halbe Miete. Die andere Hälfte besteht darin, sicherzustellen, dass die richtigen Personen das Problem verstehen. Letztendlich sollte ein guter Tester den Entwicklern Zeit sparen. Anstatt nur zu melden, dass ‚etwas nicht stimmt‘, erklärt ein fundierter Bericht das Problem, wie es reproduziert werden kann, was die Ursache ist und wie es sich möglicherweise beheben ließe.“

Wie sieht ein typischer Arbeitstag für einen QA Lead aus?

„Jeder Tag ist ein wenig anders, aber im Allgemeinen besteht er aus einer Mischung aus Besprechungen, Koordination und Überwachung. Den Großteil meiner Zeit verbringe ich damit, Aufgaben zuzuweisen, den Testfortschritt zu verfolgen, gemeldete Fehler zu prüfen und mich regelmäßig mit den Entwicklern abzustimmen. Manche Tage verlaufen ruhig und konzentrieren sich auf die Planung, während es an anderen Tagen darum geht, unerwartete und dringende Probleme zu lösen. Ein wesentlicher Teil der Arbeit besteht in der engen Zusammenarbeit mit dem Team: Wir besprechen die gefundenen Fehler, ermitteln die beste Vorgehensweise und entscheiden gemeinsam, was am dringendsten bearbeitet werden muss.“

Worauf achten Ihre Teams beim Testen des Spiels vor allem?

„Das hängt stark von der jeweiligen Produktionsphase ab. In der Anfangsphase konzentrieren wir uns hauptsächlich auf das Straßennetz selbst, dessen Layout und ein flüssiges Fahrgefühl. Ein wichtiger Teil dieser Phase ist zudem die Überprüfung der Wirtschaftsmechaniken sowie der Platzierung von Spielelementen wie Tankstellen, Firmenstandorten und Lkw-Händlern. In späteren Phasen verlagert sich der Schwerpunkt auf die Fähigkeit der KI, sich im Straßennetz zu bewegen, sowie auf den visuellen Feinschliff, die korrekte Beschilderung und das Kern-Gameplay. Zu diesem Zeitpunkt prüfen wir auch die Performance in verschiedenen Bereichen, um problematische Einbrüche der Bildrate (Frame-Rate-Drops) zu identifizieren und zu beheben.

Grob gesagt konzentrieren wir uns auf fast alles, was mit der Karte zu tun hat. Dazu gehören Straßenverläufe und Kollisionen, die Auftragsökonomie, die Verteilung von Tankstellen, Schlaf- und Rastplätzen, die Kartenansicht (UI) und deren Symbole, Durchfahrtssperren, Fahrbahnmarkierungen, Verkehrsschilder, Geschwindigkeitsbegrenzungen, Ampeln, Navigation und Sprachführung, Zwischensequenzen in der Werkstatt, KI-Fahrwege, Trigger, Qualitätskonsistenz, Szenenlogik, Gelände, Vegetation, Welt- und Landesgrenzen, Asset-Kollisionen, Geländelücken, schwebende Objekte, performance-intensive Bereiche, Umgebungsgeräusche und vieles mehr!“

Was gefällt dir am meisten an der Arbeit in der Qualitätssicherung (QA)?

„Für viele ist Game-Tester ein Traumjob – und in vielerlei Hinsicht ist er das auch wirklich. Es ist ein unglaublich lohnendes Gefühl zu wissen, dass man das Sicherheitsnetz ist, das die Immersion der Spieler schützt und dabei hilft, das Spiel für alle zu verbessern. Es ist zutiefst befriedigend zu beobachten, wie sich ein chaotischer, fehlerhafter Build nach und nach in eine ausgefeilte Welt verwandelt, durch die Millionen von Menschen gerne fahren.

Wenn ein neuer DLC erscheint und man sieht, wie Spieler darüber sprechen, wie geschmeidig sich die Straßen anfühlen, wie großartig die Landschaft aussieht oder wie gut alles läuft – das ist ein fantastisches Gefühl. Man kann sich das ansehen und denken: ‚Ja, mein Team hat daran mitgewirkt.‘“

Wenn ein neuer Karten-DLC oder ein größeres Update in die Testphase geht: Wie gehst du bei einem so umfangreichen Projekt von Anfang bis Ende vor?

„Der QA-Prozess beginnt oft schon vor der eigentlichen Produktion. Wir geben frühzeitig Feedback zu Konzepten, um bekannte Probleme zu vermeiden, noch bevor die Entwicklung richtig losgeht. Sobald die Produktion startet, setzen wir auf einen agilen Testansatz: Wir durchlaufen während der Entwicklung mehrere Iterationen, anstatt bis zum Schluss zu warten und dann eine riesige Liste von Fehlern abzuliefern.

Unser systematischer Testprozess gliedert sich in vier Iterationen sowie einen Wirtschaftstest. Die erste Iteration konzentriert sich voll und ganz auf die Straßenführung; dabei stellen wir sicher, dass Straßen, Kurven und Steigungen sicher befahrbar sind – selbst mit den längsten Aufliegern und leistungsschwachen Motoren. Der Wirtschaftstest überprüft anschließend, ob Unternehmen korrekt Aufträge generieren und ob die Städte eine gute Vielfalt an Zielen bieten. Im weiteren Verlauf der Entwicklung verlagert sich der Schwerpunkt der späteren Iterationen auf die visuelle Qualität, die Konsistenz des Gameplays und den letzten Feinschliff.

Um die Tests überschaubar zu halten, unterteilen wir jedes Projekt in kleinere Abschnitte. Das führt bisweilen zu Dutzenden oder gar Hunderten von Einzelaufgaben, die bestimmte Straßen und Städte abdecken. Diese werden über den gesamten Entwicklungszeitraum hinweg nachverfolgt, sodass wir dieselben Bereiche in verschiedenen Stadien erneut prüfen können. Wir nutzen Karten, Checklisten, interne Tools und Bug-Tracking-Systeme, um sicherzustellen, dass jeder Quadratkilometer abgedeckt ist. Gleichzeitig ermutigen wir die Tester dazu, die Welt frei zu erkunden, denn unerwartete Probleme treten oft dort auf, wo niemand damit rechnet.“

Viele Spieler sehen nur das fertige Produkt. Wie viel Testaufwand steckt eigentlich in einer Kartenerweiterung, einem Update oder einem neuen Feature, bevor es veröffentlicht wird? Unterscheidet sich dieser Aufwand je nach Art der zu testenden Inhalte?

„Der Testaufwand ist enorm und variiert stark je nach Projekt. Kleinere Projekte, wie etwa Karten für besondere Events, lassen sich in wenigen Tagen gründlich testen. Ein riesiges Projekt wie die Erweiterung ‚Nordic Horizons‘ erfordert hingegen Tausende von Stunden intensiver Tests, bis es zur Veröffentlichung bereit ist.

Jede einzelne Straße, jede Stadt, jedes Unternehmen, jede Tankstelle, jeder Rastplatz, jede Mautstelle und jede Fährverbindung wird mindestens viermal getestet – und zwar jedes Mal von einem anderen Tester. Um einen Eindruck vom Umfang zu vermitteln: Unser Bug-Tracking-System ‚Mantis‘ verzeichnete 6.849 Meldungen für den Illinois-DLC, während für South Dakota bislang 6.318 Meldungen eingegangen sind. Die Bandbreite dieser Meldungen reicht von winzigen, kaum wahrnehmbaren Lücken im Gelände bis hin zu schwerwiegenden Fehlern, die zum Absturz des Spiels führen können. Jeder Meldung werden eine Priorität und ein Schweregrad zugewiesen, damit die kritischsten Probleme zuerst behoben werden.“

Wie eng arbeiten QA-Teams während der gesamten Entwicklungsphase mit Leveldesignern, Programmierern, Grafikern und anderen Abteilungen zusammen?

„Wir arbeiten abteilungsübergreifend sehr eng zusammen, da das Testen in den gesamten Entwicklungszyklus integriert ist. Als QA-Team für Leveldesign arbeiten wir am engsten mit den Leveldesign- und Grafik-Teams zusammen. Während der Großteil unserer täglichen Kommunikation über Berichte im Bug-Tracking-System ‚Mantis‘ abläuft, besprechen wir Probleme auch aktiv über private Nachrichten in unserem internen Chat-System und vereinbaren direkte Besprechungen, sobald ein Problem wichtig genug ist. Der Austausch mit der Programmierabteilung erfolgt meist nach dem ‚Need-to-know‘-Prinzip – also dann, wenn es Probleme mit unvorhersehbarem KI-Verhalten gibt oder wenn eine brandneue Code-Funktion direkt in das Level implementiert wird.“

Welche Tools oder Methoden helfen euch dabei, Probleme effizient zu erfassen, zu reproduzieren und zu melden?

„Wir nutzen verschiedene miteinander verknüpfte interne Systeme, um einzelne Fehler und den Gesamtfortschritt eines DLCs zu verfolgen. Dabei setzen wir ein spezielles internes Reporting-Tool ein, mit dem Tester Fehler direkt aus dem Spiel oder dem Level-Editor heraus in unsere zentrale Bug-Tracking-Datenbank übermitteln können. Der Bericht erscheint innerhalb weniger Minuten und lässt sich sogar direkt im Level-Editor selbst einsehen. So können Leveldesigner das jeweilige Problem sofort in ihrem aktuellen Arbeitsbereich erkennen und wesentlich effizienter beheben, was während der Entwicklung viel Zeit spart.“

Wenn es eine Sache gibt, die die Leute über die Qualitätssicherung (QA) und die Arbeit Ihrer Teams besser verstehen sollten – was wäre das?

„Wir möchten, dass die Spieler verstehen, dass das Testen von Karten eine anspruchsvolle technische Aufgabe ist – es geht nicht einfach nur darum, herumzufahren, die Landschaft zu betrachten oder zufällig über einen in der Luft schwebenden Baum zu stolpern. In Wirklichkeit ist ein guter Tester eine Mischung aus Detektiv und Datenanalyst. Wenn wir auf einer Autobahn auf eine seltsame Unebenheit in der Physik-Berechnung stoßen oder sehen, wie sich KI-Verkehr an einem Kreisverkehr staut, melden wir das nicht einfach nur und machen weiter. Wir müssen genau verstehen, warum das passiert. Fehler auf der Straße in konkrete, strukturierte Informationen zu übersetzen, die unsere Entwickler leicht verstehen und beheben können, erfordert Zeit, Geduld und fundiertes Wissen über das Spiel.“

Welcher Aspekt der QA-Arbeit würde die Spieler Ihrer Meinung nach am meisten überraschen?

„Die Spieler wären wahrscheinlich überrascht, wie viel Wissen über das Spiel und die reale Infrastruktur man benötigt, um ein guter Tester zu werden. Unser Team muss ein fundiertes Verständnis für komplexe interne Spielregeln, reale Verkehrsgesetze und regionale Standards bei der Straßenführung in verschiedenen Ländern haben.

Das ist vergleichbar mit dem Unterschied zwischen jemandem, der einen Lkw besitzt und ihn fahren kann, und einem Mechaniker, der den gesamten Motor ausbauen, ihn in seine Einzelteile zerlegen und wieder zusammensetzen kann. Es kann Jahre dauern, bis man ein hochqualifizierter Karten-Tester ist, und viele Tester entwickeln sich natürlich zu Spezialisten für bestimmte Bereiche des Spiels, weil sie so viel Zeit damit verbringen, hinter den Kulissen mit diesen spezifischen Systemen zu arbeiten.“

Bist du während deiner Zeit bei SCS Software schon einmal auf besonders denkwürdige, ungewöhnliche oder lustige Bugs gestoßen?

Ivan: „Auf jeden Fall. Simulatoren verfügen über unglaublich komplexe Physik-Engines, und wenn etwas schiefgeht, dann oft auf urkomische Weise. Es wird nie langweilig zu sehen, wie ein KI-Fahrzeug direkt ins Weltall katapultiert wird. Manchmal hinterlassen unsere Map-Designer auch kleine, kreative Überraschungen oder Scherze, die wir während der Entwicklung entdecken können – wobei wir natürlich immer darauf achten, dass sie nicht in die Live-Version des Spiels gelangen.“

David: „Ein unvergesslicher Moment ereignete sich, als ich gerade auf dem Gelände eines Firmenstandorts parkte. Ich hörte in der Ferne das Signalhorn eines Zuges; der Ton wurde immer lauter, bis er plötzlich direkt neben mir zu hören war. Das Problem war nur: Es gab dort keinen Zug, und es verliefen nicht einmal Bahngleise in der Nähe. Einen Augenblick später prallte etwas Unsichtbares gegen meinen Lkw und schleuderte ihn quer über das gesamte Firmengelände. Für ein paar Sekunden dachte ich tatsächlich, ich hätte ein Spuk-Gelände entdeckt.“

Wie wertvoll sind Fehlerberichte und Feedback aus der Community für die Verbesserung des Spiels?

„Das Feedback der Community ist für uns enorm wertvoll. Auch wenn unsere interne Qualitätssicherung sehr gründlich arbeitet, schlüpfen uns immer wieder Fehler durchs Netz. Die Spieler helfen uns dabei, diese aufzuspüren, indem sie auf Details oder Ungereimtheiten hinweisen, die uns vielleicht entgangen wären. Besonders nützlich ist dabei der Kontext, den die Spieler liefern. Viele kennen sich mit den realen Orten, die wir nachbilden, bestens aus und können schnell auf Ungenauigkeiten aufmerksam machen, die uns sonst kaum aufgefallen wären. Zudem erleben sie eine enorme Vielfalt an Spielsituationen; das hilft uns, Grenzfälle aufzudecken, die intern nur schwer zu reproduzieren sind.“

„Oft kann uns ein gut verfasster Bericht aus der Community stundenlange Fehlersuche ersparen, da die Spieler Screenshots, Videos, Logdateien, Spielstände und klare Anleitungen zur Reproduktion des Fehlers bereitstellen.“

Habt ihr eine Botschaft an unsere Community?

„Ein riesiges Dankeschön für eure Unterstützung, euer Feedback und dafür, dass ihr uns schon so viele Jahre begleitet. Es ist ein großartiges Gefühl, an einem Spiel zu arbeiten, bei dem den Spielern die Welt genauso am Herzen liegt wie denjenigen, die sie erschaffen. Euer Engagement spornt alle im Studio an, die Messlatte mit jedem neuen Bundesstaat, jedem neuen Land und jedem neuen Feature immer höher zu legen. Kommt gut ans Ziel – wir sehen uns auf der Straße!“

Wir möchten uns bei David und Ivan dafür bedanken, dass sie sich trotz ihres vollen Terminkalenders die Zeit genommen haben, mit uns über ihre Aufgaben in der Qualitätssicherung (QA) zu sprechen und darüber, welch entscheidende Rolle das Team dabei spielt, unsere Truck-Simulator-Titel zum Leben zu erwecken. Wir hoffen, ihr habt einen kleinen Einblick in die Arbeit hinter den Kulissen erhalten. Wenn euch diese Ausgabe von „Under the Hood“ gefallen hat, hinterlasst den beiden doch eine Nachricht in den Kommentaren oder auf unseren Social-Media-Kanälen. Bis zum nächsten Mal –und allzeit gute Fahrt!

Beitrag von Alex, SCS-Software. Übersetzung von Angelwingking