- Unkategorisiert
DevBlog: QA Detektive
Hallo ihr Lieben, ich bin Dorina, meines Zeichens die Leiterin der QA Abteilung für Anno 1800. Damit ihr mich besser kennenlernen könnt, hier zunächst ein paar Anmerkungen zu meiner Person:
Ich arbeite jetzt seit 13 Jahren in der Games Branche im Bereich QA, mit meinen ersten Schritten damals als studentische Aushilfe an Anno 1701. Einige Jahre später wurde ich dann fest als Development-Testerin für Anno 2070 angestellt. Heute empfinde ich es als große Ehre, die QA für Anno 1800 zu leiten und hoffe, dass dieser Blog euch einen guten Eindruck über die abwechslungsreiche Arbeit in der Qualitätssicherung verschafft.
Zum Thema Game Testing und QA scheinen die meisten Spieler eine teilweise sehr starke Meinung zu vertreten, denn Bugs sind häufig Gegenstand von hitzigen Diskussionen. Wenn selbst die Community Fehler im Spiel entdecken kann, sollte es doch schließlich nicht allzu schwer für die Entwickler sein, diese schnell und einfach zu beheben. Oder steckt hinter der Jagd nach Bugs vielleicht doch mehr?
Um genau diese Frage zu beantworten stellen wir heute das Anno 1800 QA Team ins Rampenlicht und werfen dabei einen Blick auf den komplexen Alltag eines Spieletesters.
Das QA Vorurteil – Jeden Tag nur Spiele zocken
Es gibt da dieses hartnäckige Vorurteil, das QA Tester den Großteil ihres Tages mit zocken verbringen. Sich in seinem Projekt auszukennen ist sicherlich ein wichtiger Teil des Jobs, in der Realität macht das eigentliche Spielen allerdings nur einen eher kleinen Teil des Alltags aus.
Stundenlang zu spielen, um ein Gefühl für das Feeling und die Funktionalität deines Projektes zu bekommen, passiert in der Realität tatsächlich eher selten. Unsere tägliche Routine wird vielmehr durch sehr spezifische Aufgaben bestimmt, bei denen wir bestimmte Features des Spiels auf Herz und Nieren testen um die Qualität einzuschätzen und um gemeldete Fehler zu untersuchen. Bei der Analyse eines Fehlers stellen wir häufig fest, dass die Ursache augenscheinlich nichts mit dem auftretenden Problem zu tun hat. Dadurch entwickelt sich die Fehlersuche zu einer komplizierten Untersuchung, da für das Reproduzieren eines Fehlers nicht nur die Ursache, sondern auch alle Zusammenhänge mit anderen Mechaniken und Spielelementen analysiert werden müssen.
Mit jedem neuen Meilenstein in der Entwicklung bekommen wir eine ausführliche Liste an Features, die bis zur nächsten Entwicklungsphase getestet werden müssen. Diese Liste bestimmt also die Ziele und um diese zu erreichen, ist Zusammenarbeit im Team und mit anderen Entwicklern (wie den für das Feature verantwortlichen Game Designern) unglaublich wichtig.
Als zentrale Anlaufstelle für die Produktion von Anno 1800 sitzt unser QA Team in der Mitte des Studios. Unsere Lage im Studio erlaubt uns eine gute Übersicht über das ganze Projekt und ermöglicht direktere Kommunikation mit den anderen Entwicklern; man könnte sagen das die QA das wachsame Auge der Spieleproduktion ist. Spawnt jemand von uns bei einem Entwickler ernten wir manchmal nervöse Blicke, denn höchstwahrscheinlich funktioniert eines Ihrer Features gerade nicht wie es sollte.
Der Detektiv und sein Handbuch
Wenn wir mit der Untersuchung eines Falls beginnen sind analytische Fähigkeiten, Erfahrung und Wissen über die unterschiedlichen Bereiche der Entwicklung unsere Werkzeuge zum Erfolg. Während wir an einem Fall arbeiten, wird das detaillierte Design Dokument (oder kurz DDD) zum Handbuch für den QA Detektiv. Das DDD definiert die Funktionen aller Spielelemente und hilft uns beim Erstellen von Testfällen, ob diese sich dem Design entsprechend verhalten und funktionieren. Wie in einem Belastungstest versuchen wir dabei sogar das System bewusst auszuhebeln um Fehlerquellen aufzuspüren. Ein wenig so als würden wir versuchen den Motor eines Autos bewusst an seine Grenzen oder ein System zum Absturz zu bringen. Die dadurch entstehenden Daten werden in einem Feedback-Report an den entsprechenden Feature Owner und weitere verantwortliche Entwickler weitergeleitet.
Ihr erinnert Euch an die Handelsrouten, die wir in unserem DevBlog letzte Woche vorgestellt hatten?
Das DDD beschreibt dieses Feature und alle zugrundeliegenden Systeme bis ins kleinste Detail: von Mechaniken, wie das Hinzufügen von Schiffen zu einer Handelsroute, Beschreibungen wie das Menü funktionieren soll, verbundene Audio Elemente, dargestellte Texte, die Funktionalität von Buttons und vieles mehr. Dies ist gleichzeitig die große Checkliste unserer Tests, in denen wir überprüfen, ob alle Elemente auch wie erwartet funktionieren.
Wenn das nächste Update dann einen Fix für den Fehler beinhalten, gehen wir erneut durch die Feature Liste um zu sehen, ob der Fehler behoben ist und ob sich keine neuen Bugs eingeschlichen haben.
Aber es geht nicht nur um das Entdecken und Ausmerzen von Bugs; wir helfen ebenfalls beim Balancing des Spiels, von den Produktionsketten bis zur Bewertung der Schwierigkeit der Kämpfe. Dabei müssen wir uns ständig selbst Fragen: funktioniert alles wie gedacht, fühlt sich der Spielfluss gut an und ist das Feature komplex genug (oder vielleicht sogar zu komplex)?
Die aus unseren Tests resultierenden Berichte werden dann mit den verantwortlichen Entwicklern im Detail diskutiert. Wenn dann Änderungen aufgrund des Feedbacks vorgenommen werden, heißt es für uns wieder zurück zum Anfang des Prozesses um neues Feedback zur Verfügung zu stellen.
Ein weiterer Unterschied zwischen der Arbeit in QA und QC (Qualitätskontrolle) ist, dass wir das Projekt als Ganzes überprüfen. Sollten wir herausfinden das ein bestimmtes Tool nicht richtig funktioniert oder sogar der Entwicklungsprozess behindert sein könnte, erhält das Produktionsteam sofort von uns Meldung und einen dementsprechenden Bericht.
Auf der Jagd nach Bugs!
Wenn wir während unserer Tests einen Bug finden, wird dieser in unserem Bug-Tracking Tool verzeichnet und in einem Bericht an den Game Designer weitergeleitet. Wie zuvor beschrieben setzt dies den Test- und Feedback-Prozess in Gang, bis der Fehler am Ende behoben wurde.
Ihr seid bestimmt mit dem Zitat „Kein Plan überlebt die erste Feindberührung“ vertraut?
Wenn wir Fehler nach Tests beheben besteht immer die Möglichkeit, dass der Fix irgendeinen anderen Fehler auslöst. Häufig wissen wir dabei zuerst nicht, was diesen Fehler eigentlich hervorruft und somit machen wir uns erneut auf die Suche nach dem Auslöser.
Durch die unglaublich komplexe Natur eines modernen Videospiels gibt es eine Grundregel: Wenn wir einen Fehler beheben, lösen wir damit eventuell einen Neuen aus. Ich vergleiche diesen Umstand gerne mit dem Schmetterlings-Effekt, bei dem jeder Flügelschlag eine unerwartete Serie an Ereignissen auslösen kann. Der Komplexität eines Spiels geschuldet, kann sich dieser Prozess von Fall zu Fall ändern, weil Bugs während der Entwicklung zum Alltag gehören. Wir stellen dabei sicher, dass die Produktion nicht blockiert wird, denn das beheben von Bugs könnte im schlimmsten Fall viele Stunden Arbeit für unser Coding-Team bedeuten.
Das Spiel besser machen
Unsere Arbeit hat noch eine weitere Ebene, welche nicht unbedingt mit dem unmittelbaren Beheben von Fehlern zu tun hat. Beim Observieren des Spiels und des DDD könnte uns auffallen, dass ein Element in einem Feature fehlt oder aufgrund unserer Erfahrung Probleme im Gameplay auslösen könnte. Sollte dies der Fall sein, stellen wir Vorschläge zur Verbesserung bereit, die erläutern was eventuell fehlt oder wie das Balancing verbessert werden könnte. Unser Team besteht aus verschiedenen Spielertypen und mit den unterschiedlichsten Jahren an Erfahrung und dieses gesammelte Wissen spielt hierbei eine wichtige Rolle. Diese Vielfalt erlaubt es uns schlussendlich eine Situation aus den unterschiedlichsten Blickwinkeln zu betrachten.
Sind da eifrige Bug-Jäger unter Euch?
Ich hoffe, dass dieser Blog euch einen guten Einblick in den komplexen Alltag eines Game Testers, der mit seiner Arbeit alle Aspekte der Produktion beeinflusst, geben konnte.
In der QA zu arbeiten erfordert Enthusiasmus, Passion und ein tiefes Verständnis für Videospiele und den Titel an dem Ihr gerade arbeitet.
Was denkt Ihr über den Joballtag eines professionellen Spieletesters – waren Euch die Informationen aus diesem Blog bereits vertraut oder konnten wir Eure Augen ein wenig öffnen? Wir würden außerdem gerne wissen ob Ihr bereits selbst auf der Jagd nach Bugs wart, ob nun als Teil einer Testphase eines Spiels, Mitglied einer Community oder vielleicht sogar auf einem professionellen Level?
Um den QA Aufgaben eines komplexen Aufbauspiels wie Anno 1800 gewachsen zu sein, verlangt es Erfahrung, Leidenschaft und Teamarbeit.
Kommentare
Kommentar hinterlassen
Hi,
ich finde, dass Bugs manchmal (wenn sie das Spiel nicht beeinträchtigen) sogar ganz lustig sein können, wenn z.B. Magier, wenn sie sterben, sagen > Als Schmied findet man immer Arbeit.< Auch wenn das manche nicht so sehen. 😀
Bugs selbst gesucht hab ich bisher nur beim ein oder ausschalten von Mods.
Auf Grund von Klausuren hänge ich übrigens derzeit hinterher was die Union angeht. Falls das jemanden interessiert.
Aber, das war sehr interessant und aufschlussreich. Danke. 😀
Viele Grüße
droggelcreeper
Danke für den Einblick. Ich finde es ist einer der unterschätzten Jobs und sehr wichtig. Vorallem wenn es wie beschrieben um das Zusammenspiel mehrerer Elemente geht und was für einen Einfluss sie aufeinander ausüben.
Ich habe persönlich nur Erfahrung in (Beta)tests in größerer Community oder bei kleineren Projekten. Persönlich finde ich es immer am frustrierendsten wenn man auf einen Käfer stößt, aber nicht in der Lage ist den zu reproduzieren. Da kratzt man sich am Kopf und wird teilweise echt verrückt und fragt sich wie man das vorhin denn nur geschafft hat^^
Sehr interessanter Artikel, vielen dank dafür. Nun verstehe ich das Prinzip der Qualitätskontrolle etwas besser, habe mich schon immer gefragt, wie das bei Euch abläuft. Wie gesagt, Anno ist sehr komplex und man muss aufpassen, das beim beheben eines Bugs nicht irgendwo ein anderer Fehler entsteht.
Außerdem habe ich mich immer gefragt, wie ihr Auslöser von Bugs findet, die selten auftreten oder nur unter gewissen Umständen… die Hardware und deren Treiber sind ja bei vielen Leuten unterschiedlich, außerdem auch der Spielstand… Gebäude x löst einen Absturz aus, Gebäude y nicht. Und manchmal weiß man überhaupt nicht, welches System/Feature zum Absturz führt.
Ich denke, diese Prozesse kann ich nun etwas besser verstehen. Eine Frage habe ich aber dennoch (sorry, wenn das im Blog beantwortet wurde, aber mir ist es irgendwie nicht ganz klar): was ist jetzt der Unterschied zwischen QA und QC?
Im Blogeintrag steht das so, als wären das zwei unterschiedliche Sachen… aber was genau?
Danke für den sehr informativen Beitrag :)!
Finde es wirklich interessant mal zu sehen wie viel mehr doch tatsächlich hinter der “Bug-Bekämpfung” steckt. Aber eine Frage, die sich mir stellt ist, ob das ständige Testen eines Features nicht manchmal auch nervig oder anstrengend wird? Also wenn ich mir überlege z.B. 5-10 mal das gleiche Feature zu testen, weil immer wieder neue oder andere Bugs auftreten, würde mich das mit der Zeit schon etwas nerven.
Bin schon gespannt was ihr diese Woche für uns auf Lager habt 🙂
und viele Grüße n0W4y
Hallo,
danke für den Artikel, ein wenig kenne ich mit den Biestern auch aus eigener Erfahrung aus. Als Programmier seine eigenen Fehler suchen zu müssen ist doppelte Freude …
Wie war das eigentlich mit dem “Noria-Bug” in 1404 und wieso hat man so einen dicken Fehler einfach drin gelassen ? Greift da der alte Trick “it’s not a bug, it’s a feature”?
hehe, ja so wurde es damals “verkauft” als Feature….. viel Wasser hilft viel….
Hey
Sehr intressant wussste dies gar nicht das ein Game Tester mehr macht als nur ,dass Gameplay zu testen. Wie Bugs behoben werden hatte ich mir auch Gedanken gemacht und wurde von euch bestätigt ,dass das ganze sehr komplex und aufwändig ist einen Bug zu beheben. Danke für eure mühe und die Zeit die ihr investiert ,dass das Spiel keine Bugs hat.
JST
Mal wieder sehr interessant. Doch da kommen mir wieder einige Fragen zum Thema:
Wie genau funktioniert das suchen nach dem Auslöser eines Fehlers? Habt ihr bestimmte Tools und Programme die euch dabei helfen, oder probiert ihr alle Funktionen des Features bis sich etwas auslöst?
Und woran erkennt man ob ein Bug auch wirklich einer ist? Wenn ein Schiff durch eine Insel schwimmt ist es denke ich offensichtlich, aber was wenn ein Bewohner eine sehr fragwürdige Tanzeinlage animiert. Es könnte ja auch einfach ein Gag des Entwicklers sein 🙂
– dadi
Wenn ein Bewohner eine solche Tanzeinlage hinlegt, dann ist das denke sehr wohl gewollt 🙂 Für Gebäude und deren dazugehörigen Animationen gibt es Tools, die den Anno entwicklern dabei helfen, eine authentische Grundsituation zu schaffen. Dort werden dann die Gebäude an sich bis aufs kleinste konstruiert und animiert. Wiederrum ein anderes Tool sorgt dafür, dass Abwechslung und nicht zeitgleiche Animationen der einzelnen Gebäude auftreten. So habe ich das zumindest verstanden 🙂
Um nach einem Problem gezielt zu suchen hilft in den meisten Fällen eigentlich nur ausprobieren und ausprobieren bis aufs geht nicht mehr. Dabei wird aber meist weit über den “normalen Gebrauch” des Features hinaus gegangen.
Hallo zusammen!
Danke erstmal wieder für diesen interressanten Blog!
QA ist sehr interessant, denn ohne es würde vermutlich nie ein Spiel so spielbar seien, wie wir es erleben.
Ich denke es ist nicht grade der einfachste Job, denn man hat grade auf der Suche nach Problemen und deren Wurzel sehr viel zu tun.
Aber denoch hat man denke ich einen sehr vielfältigen Beruf.
Mich würde interessieren, wie lange es im Durchschnitt dauert, bis die Wurzel eines Bugs gefunden wird und wie es weitergeht, wenn ihr den Game Designer benachrichtigt habt.
Ein Blog über diesen wäre sehr cool^^.
LG HarroLP
Chris9990306 hats eigentlich präzise auf den Punkt gebracht “….Vielen ist die harte Arbeit als Tester gar nicht klar. Leider auch seher vielen die einen Bug nur melden und denken, jetzt muss der Entwickler eine Code Zeile ändern und das Problem ist aus der Welt…..”
Dem ist nix hinzuzufügen. Möget ihr die richtige Auswahl an Testern treffen, so dass die Liste der Bugs recht kurz wird.
Im Öffi hatte ich ja mal laut gedacht, wie z.B. ich mit meiner Erfahrung mir die Auswahl vorstellen könnte.
In der Hoffnung, liebe Dorina, dass du uns demnächst mit einem Lächeln begrüssen wirst, warten wir auf die Dinge, die da kommen werden.
Hallo,
fand den EInblick auch sehr gut. Vielen ist die harte Arbeit als Tester gar nicht klar. Leider auch seher vielen die einen Bug nur melden und denken, jetzt muss der Entwickler eine Code Zeile ändern und das Problem ist aus der Welt.
Als Mitarbeiter einer IT Dienstleistungsfima kenne ich mich mit teschnicher Fehlersuche nur all zu gut aus und weiß, nur weil man die Ursache eines Problem gefunden hat, ist es noch lange nicht gelöst. Dreht man an einer Schraube gibts an einer anderen Stelle ein Problem. Oft heißt es testen, anpssen, testen, anpassen usw..
Stunde um Stunde vergeht während man mit Kollegen diskutiert wo ein Problem liegen könnte, wie man es am besten ausfindig macht und welche Auswirkungen eine mögliche Lösung nach sie zieht.
Deswgen an dieser Stellen auch tieften Respeckt an euch Speiletester und Entwickler. Ihr leistet tolle Arbeit.
Beste Grüße, weiterhin viel Erfolg und Spaß an der Arbeit wüncht
Christoph alias Chris9990306
Kann den Text leider nicht mer bearbeiten und bitte den Schreibfehler in Zeile 11 zu Entschulidigen. Ist mir erst nachträglich aufgefallen. Hier soll natürlich stehen “.. eine mögliche Lösung nach sich zieht”.
Und in Zeile 13 “Deswegen..”
Sehr schöner Einblick in euren Abteilungsbereich, vieles war mir schon geläufig doch einige neue Eindrücke konnte ich durch den Artikel mitnehmen. Ihr interagiert wie dedektive immer auf der Suche nach dem Übeltäter, Knobeln 2.0 find ich. Bei Beta und Alpha Einladungen schreibe ich an die betreffenden gern meine Erfahrungen, Eindrücke und Teile Fehler mit. Wobei selten ein feetback zurück kommt, dass ist zwar schade doch wenn der Fehler dann verschwunden ist freut es mich trotzdem. 🙂
Lg Johnny alias Wix0r
Schöner Artikel 🙂
Ich habe auch schon den einen oder anderen Bug in Spielen gemeldet, unter anderem bei Indie-Spielen, die natürlich auf die Hilfe der Community angewiesen sind. Und dabei melde ich nicht nur den Bug an sich, sondern ich versuche vorher auch immer zu analysieren, unter welchen Umständen er auftritt, und was passiert, wenn ich XY mache.
Leider habe ich keine Ahnung von Programmieren, weshalb meine Analyse sich auf das beschränkt, was man auch wirklich sehen kann als Spieler. Aber ich liebe das Gefühl, wenn ich merke, dass meine Analyse dem Entwickler dabei geholfen hat, die Fehlerquelle sofort zu lokalisieren und den Fehler zu beheben 🙂
Danke für den Einblick Dorina.
Wie wichtig die QA & QC sind sollte eigentlich jedem Spieler bewusst sein.
Mein Hobby ist die Webprogrammierung. Und ähnlich wie heise.de gestern wegen eines fehlenden Komma in der config für ~10 Minuten offline war, so habe ich als Unprofessioneller schon mehr als genug Erfahrungen mit der Fehlersuche machen müssen. Es kann extrem aufreibend sein und braucht wirklich passionierte Detektive um die richtig fiesen versteckten Fehler zu finden.
Im Zuge des Beta-Keys für Anno-Online ist mir ebenso vertraut, wie sehr sich das Spiel im Laufe der Entwicklung durch die Arbeit der QA verändern kann; sei es nun, weil Fehler behoben, oder weil “das Gefühl im Spiel” verbessert werden muss.
Von keinerlei sichtbaren Auswirkungen für den Spieler, über veränderte Texte in Buttons, bis hin zum kompletten Austauschs eines Features oder Menüs kann da alles bei herauskommen.
Wie auch schon andere vor mir würde auch ich mich aber für kleine Anekdoten über die fiesesten Bugs und deren Auswirkungen bei vorherigen Titeln, aber gerne auch im Zuge von 1800 interessieren.
Wenn ihr da also mal was zu schreiben mögt:
Was waren die fiesesten Fehler und ihre Auswirkungen die ihr in 1800 oder vorangegangenen Titeln gefunden habt?
Hallihallo,
Danke für diesen Einblick.
Ich stelle mir das gerade super schwierig vor, wenn ein Bug nur mit einer sehr speziellen Kombination von Faktoren auftritt. Zum Beispiel nur wenn der Marktschreier gerade ruft und der Marktkarren XY gerade Fleisch ins Lagerhaus liefert, während drei Fischerhütten gleichzeitig ihre Boote zu Wasser lassen.
Was war den so der schlimmste Bug über den ihr mal gestolpert seit? Wo ihr verzweifelt gesucht habt um eine Lösung zu finden, oder vielleicht auch einfach nur etwas lustiges oder sehr absurdes passiert ist.
Gerade wenn es um digitales geht, führt Fehler A nicht immer gleich zu Ursache B.
Ich arbeite mit komplexen IT Systemen und obwohl ich dafür zuständig bin mit unseren Programmen Server und Netzwerke zu überwachen, die sich mit tollen roten Meldungen bemerkbar machen, wenn es irgendwo ein Problem ist und zum Beispiel eine Festplatte vollgelaufen ist. Aber auch diese Programme laufen nicht immer einwandfrei, oder die Einrichtung der Überwachung.
Also hat man eine Routine entwickelt, wie man solche Fehler und Probleme analysiert und dann Schritt für Schritt nach der Ursache forscht und alle Möglichkeiten nach und nach ausschließt. Das sind dann sehr intensive Zeiten, an denen man kaum vom Schreibtisch weg kommt aber umso schöner ist es dann, wenn man den Fehler gefunden hat und alles wieder einwandfrei funktioniert.
Allerdings kenne ich das Gefühl, wie es ist wenn da jemand kommt und sagt, das etwas nicht funktioniert. Wenn unser Second Level Support persönlich bei uns aufschlägt, wissen wir auch genau, dass irgendetwas mal wieder “kaputt” ist und es muss sich jemand melden um es wieder ganz zu machen. Manchmal gibt es aber auch einfach Kuchen, und sie brauchen noch Unterstützung beim vernichten 🙂
LG Bellasinya
Ohh den ‘schlimmsten Bug’, den würde ich auch gern mal wissen^^.
LG HarroLP
Schöner Blog. Es wäre spannend zu hören, was denn in den letzten Teilen so die hartnäckigsten Bugs waren.
Ich arbeite als Softwareentwickler und das beschriebene klingt für mich auch nach Alltag.
Ich war bei 2070 schon beta Tester und hab auch einen ziemlich schlimmen Fehler entdeckt.
Hey,
sehr interessanter Einblick. Der Job klingt fantastisch 🙂
Ich durfte schon für Anno 1404 Tester sein und es hat ungelaublich viel Spaß gemacht, nach Fehlern zu suchen und diese zu reporten. Gemäß unseres Lehrers während meiner Weiterbildung, der nach einem Stück Programmcode und einer dazugegöhrigen Visualisierung wie wild auf alle Knöpfe gedrückt und geklickt hat, nur um einen Fehler zu provozieren, sehe ich euch aus der QA in einer ähnlichen Situation. Und dem Lehrer hat das richtig Spaß gemacht 😀
Wenn dann ein Fehler provoziert wurde hieß es dann nur:”Guck mal dabei” 🙂
Es motiviert ja ohnehin ungemein (so geht es mir zumindest) sein eigenes Programm (oder hier bei Anno Feature) weiter und weiter zu optimieren und gemäß dem vier-Augen-Prinzip sind diese QAs ein wertvoller Teil einer Entwicklung.
Weiter so!
Danke für diesen herrlichen Einblick.
Ich habe ein ganz klein wenig Erfahrung als Bug Jäger und Detektiv. Das verdanke ich komplett der Anno Serie. Ich mache Beta Tests seit Anno 1503 und finde das teilweise super spannend. Besonders wenn man erleben darf, wie ein gemeldeter Bug dann nach Update verschwunden ist. Gut, ich sitze dann hier hinter meiner kleinen Glasscheibe und sehe nicht, was so eine Bugmeldung in Bewegung setzt. Das wird mit dem Beitrag von euch nun etwas plastischer.
Sehr interessanter Beitrag mal wieder, danke dafür!
Ich selbst habe schon zich mal in Beta-Tests mitgemacht und bin Teil des Ubsisoft Gamelabs (also als Tester, nicht als Angestellter^^) und habe dementsprechend Erfahrung mit der Käferjagt und dem Testen von Spielen. Was ihr da beschreibt mit gezieltem Reproduzieren von Fehlern und dem ausfindig machen des Fehlers ist sehr spannend, wenn auch manchmal anstrengend und ermüdent.
Was mich interessieren würde ist, wie man bei einem Spieleentwickler in die QA respektive QC kommt? Ich finde beide Aspekte ungemein spannend, stelle es mir aber schwierig vor da ohne “game-related education“ rein zu kommen.
Ich mache meinen momentan Job gerne, aber Gaming ist einfach meine Passion und der Traum vom Arbeiten in einem tollen Team bei einem tollen Entwickler huscht nachts immer wieder in meinen Kopf, da wären 2-3 Infos für potentielle Quereinsteiger super toll!
LG
Arandur87
Mich interessiert an dieser Stelle mal, warum die Spieleentwicklung sich darauf beschränkt, stetig alles “Neu” erfinden zu müssen.
Macht es denn keinen Sinn, auf vorhandenes aufzubauen, um eben Folgefehler von Anfang an auszuschliessen? Ist das nicht umsetzbar?
Eines meiner absoluten Lieblingsspiele ist UnrealWorld. Hier kann ich selber modden und Gegenstände oder Aktionen skripten. Alles ist zwar Minimal gehalten, aber die Spieltiefe gibt es sonst nirgendwo. Das Spiel wird auch weiterhin, wenn auch sehr langsam, weiterentwickelt und es ist gar nicht notwendig, da jemals einen Nachfolger rauszubringen.
Also warum immer der Zwang ein komplett neues Game zu entwickeln, anstatt auf einem, sagen wir mal, Anno 1404 aufzubauen und lediglich Addons zu nutzen um neue Sessions mit anderen Zeitlinien und Möglichkeiten einzubauen?
In etwa so wie bei den Sims…hier braucht es nur das Grundspiel…welches Addon ich mit drauf spiele ist von mir und meiner Rechnerleistung abhängig.
Natürlich verstehe ich, dass die Technik sich weiter entwickelt und das es irgendwann nicht mehr möglich ist, auf einem Windows 10 noch Zork zu zocken, aber es muss doch möglich sein gewisse ausgereifte, kampferprobte und mittlerweile fehlerfreie Skripte zu behalten und in Folgespiele mit einzubauen. Das gleiche dürfte doch auch für das Grid, Mesh’s und viele andere Kleinigkeit gelten, so dass beim Zusammenbau eines neuen Spieles viele Fehler bereits von vornherein ausgeschlossen werden können.
Gibt es eine nennbare Zahl von eurer Seite aus, wieviele Bugs ihr so durchschnittlich in einem Spiel entdeckt, noch bevor es veröffentlich wird?
Liebe Grüße
de Diru
Games as a service nehmen genau diesen Gedanken auf. Sie behalten das alte und erneuern es immer weiter um bestimmte Elemente. Die Sims machen das schon ewig, und vor allem immer mehr Multiplayer-Shooter springen auf den Zug auf.
Aber das setzt auch eine breite Community vorraus, die über lange Zeit spielt und immer wieder bereit ist für Erweiterungen zu bezahlen, und eventuell auch Lootboxen zu erstehen.
Und das geht im Moment am besten, wenn man den eSport-Faktor mit drin hat.
Zusätzlich ist es gerade bei komplexen Codes immer schwieriger sich eine Skalierbarkeit offen zu halten. Es klingt einfach, wenn man sagt, ja das muss beliebig erweiterbar sein. Aber nehmen wir an, man fügt in Anno1404 jetzt wie auch immer eine Eisenbahn ein. Dann muss man alle Elemente, die davon betroffen sind anfassen und anpassen, und das kann wiederrum Auswirkungen auf andere Funktionen haben.
Da ist es manchmal einfach besser alle Altlasten loszuwerden und von vorne zu beginnen, oder nur die Konstrukte mitzunehmen, die fehlerfrei funktioniert haben und alles andere zu verwerfen.
Irgendwie hat Bellasinya schon fast alles dazu gesagt, kann ich ja in Ruhe weiter meinen Kaffee trinken 😀
Ich schau dennoch mal, ob wir eventuell ein paar weitere Details im Rahmen eines Q&A’s oder sogar Roundtable erläutern können. Die Sache ist für sich genommen so komplex, dass man locker einen zwei Stunden Podcast nur zu dem Thema abhalten könnte.
Tut euch keinen Zwang an. Ich bin für alle Infos und vor allem für Kaffe offen 🙂
Danke euch beiden und besonders dir Bellasinya, für die Antwort.
So intensiv wie hier, hab ich mich mit Gamedesign und allem drum und dran noch nie beschäftigt und die Idee hier die Spieler mit einzubeziehen ist großartig. Ich lerne hier wenigstens wöchentlich was Neues.
Große Klasse, immer weiter so.
Liebe Grüße
de Diru
Hallo Anno-Team,
erstmal vielen Dank für den schönen Blog. Tatsächlich war nicht so viel Neu für mich, durch Erfahrungen über Dritte war ich mir über des Umfangs bewusst. Trotzdem möchte ich meinen imaginären Hut ziehen, der Kampf gegen die Bug-Hydra (Schlage einen Kopf ab und es wachsen zwei nach) ist ein anstrengender und langer.
Diese Arbeit ist wie die eines Controllers, machst du deine Arbeit gut, fällt keinem auf das du “existierst”… bleibt ein Bug/Fehler im Spiel, zeigen alle mit dem Finger auf einen. XD
Ich selbst habe Erfahrung in der Jagd nach Bugs und Fehlern. Auf der einen Seite als Tester und auf der anderen als Spieler, versuchen Bugs auszunutzen um in Spielen schneller voran zu kommen. Durch das gewünschte ausnutzen von Fehlern, lernt man herauszufinden, welche Ursache für diesen notwendig sind. So muss Ereignis X eintreten, in Verbindung mit Y, damit der Bug ausgelöst wird. Diese Erfahrung hilft sehr, beim erkennen, analysieren und beschreiben von Bugs. Teilweise können diese Kette von Ereignissen sehr lang sein…
Ich habe für meinen Teil viel Spaß bei der Suche nach Bugs und die Analyse ihrer Herkunft.
LG Oldie
P.S: Eine Frage: Habt Ihr schonmal einen Fehler in einem Spiel gelassen, weil die durch die Lösung entstandenen Fehler, viel Schwerwiegender waren ? ^^
Was dein P.S.: angeht:
Ich bin da so gar kein Profi, aber ich kann mir das nicht vorstellen.
Das würde ja bedeuten, dass man absichtlich einen möglicherweise mutierenden Fehler drin lassen würde. Da weiß keiner was mit der Zeit daraus wird und am Ende zerhaut es dir dein Spiel.
Profi bin ich auch nicht, aber was Oldie da fragt, das macht für mich schon Sinn. Wenn ein Bug drin bleibt, weil das Beheben dieses Bugs noch viel schlimmeres zur Folge hätte, was dann womöglich das Game unspielbar macht – why not? Sonst hätten wir nach Release doch nichts mehr zu finden ;o), bugfrei gibts ja nicht.
Könnte mir nur erklären, dass ein Bug zum Release drin bleibt, da der Release halt bevorsteht bzw. der Gold Status. Danach gibt es dann einen Day-One Patch o.ä. oder es wird später herausgepatcht. Das ein Spiel so bleibt…glaube ich eher nicht.
Gutes Thema, ich spreche mal mit dem Team ob wir dazu nicht mal in einem Community Q&A eine Antwort verfassen können.
Bugfrei gibt es nur bei den Starship Troopers und die haben ordentlich zu kämpfen um ein “Bugfrei” an die Zentrale weiterzugeben.
XD
Da habe ich ja eine kleine Diskussion los getreten ^^ . . .
Es muss ja kein schwerwiegender Bug sein, kann ja auch einer kleiner sein. Dieser behindert das grundlegende Spielprinzip nicht, jedoch würde seine Lösung einen Spiel behindernden Bug hervorrufen. So nimmt man quasi das kleinere Übel.
Ich bin nicht so der Freund von Bugs, da sie den Zustand darstellen, wo aus technischer Hinsicht die gewollte Funktion den Dienst versagt und es zu einer spieltechnischen, optischen oder akustischen Ungereimtheit kommt, die ihre eigenen Wege aufweist, aktiviert oder behoben werden zu können und in der Regel auf mangelnde Präzision in der Programmierung rückgeführt werden kann. Eine Fertigkeit, die ich leider nie erworben habe. Da die Suche eines technischen Bugs von vielen Triggerfaktoren bestimmt wird, muss man augenscheinlich willkürlich verschiedene Szenarien durchgehen und das Auffinden eines solchen Fehlers hängt auch stark vom Zufall ab, da praktisch niemand in der Lage ist, alle Konstellationen durchzutesten mit dem Hinzufügen und Wegnehmen ALLER relevanten Variablen.
Aber wie es so schön heißt: Häufiges ist häufig!, finden Tester meist auch das, was der Konsument eben findet, weil er letztendlich selbst Konsument ist und das Spiel, mehr oder weniger, so spielt, wie es vorgesehen ist.
Was ich wesentlich interessanter finde, als die Suche nach Unstimmigkeiten in der Programmierung, ist das Testen der Spielmechaniken, die Balance und das Ineinandergreifen der Einzelkomponenten. Nicht der Fehler, der trotz richtiger Intention sich reingemogelt hat, sondern die Logiklücke selbst. Eine Mechanik, die nicht zu Ende gedacht ist, als ein Fehler, der auch dann auftritt, wenn das Programm die Intention korrekt umsetzt, die Intention aber bereits Mängel auffasst.
Eine solche Situation ist mir beispielsweise bei Playtest in Mainz untergekommen, ohne ins Detail zu gehen.
Ein Feature, dass eventuell nicht zuendegedacht wurde. Also kein Bug, sondern vielmehr ein Exploit oder Gamebreaker, trotz einwandfreier Umsetzung der Mechanik in technischer Hinsicht. Sowas finde ich wesentlich interessanter, da man diese Fehler hartnäckiger suchen und dabei oft um die Ecke denken muss. Außerdem spielen sie das Versteckspiel cleverer, weil sie ihre Existenz nicht hinausposaunen und keine offenkundigen “Fehler in der Matrix” sind. Sie springen nicht so ins Auge. Das sind die waren Feinde. Die Fehler im Kopf des Entwicklers, nicht die in seinem Code.
Ja QA Detektiv und in der QA Abteilung zu arbeiten ist, in meinen Augen, ein eher undankbarer Job. Während sich die Spieler über neue Features, Gebäude oder dergleichen freuen, sehen sie in der QA Abteilung eher immer den Buhmann wenn es dann doch ein Bug in das fertige Spiel schafft. Insofern finde ich den Blog schon interessant da er auch mal jene Seite der Spielentwicklung beleuchtet welche eher weniger im Rampenlicht steht, es sei denn ein “Käfer” hat sich doch ins Spiel verirrt.
Käfer und anderes Ungeziefer läuft mir gern über den Weg, bei Spielen aber hauptsächlich bei Tools, die eigentlich zum arbeiten da sind. Da habe ich wohl ein gewisses Händchen für. Schön, dass auch einmal die eher unscheinbaren Mitstreiter sich zeigen, ich kenne es selber aus dem Qualitätswesen, dass man immer nur als jemand gesehen wird der Kosten verursacht, Mehraufwand vorbeibringt aber kein Geld einbringt.
Ehrlich gesagt wusste ich bis eben nicht wirklich, welchen Arbeitsumfang so ein Spieletester tatsächlich hat.
Als kleines Kind dachte ich früher auch an das Klischee das man im Prinzip nur spielt, spielt und noch mehr spielt.
Naja jetz bin ich ja aufgeklärt 😀
Zwei Fragen hätte ich noch,
die gehören zwar eigentlich unter den Handelsroutenbeitrag aber wenn ich schon grad hier bin… 😀
-Wie sieht das eigentlich mit den Routen zwischen den Sessions aus?
Wird die extra Fahrzeit der Schiffe simuliert oder herrscht bei den Sessions das gleiche Transferoutenprinzip wie in 2205?
-Wird es wieder wie in 1701, 1404 und 2070 einen freien Händler geben, Bzw. neutrale Fraktionen die ebenfalls Handeln?
Falls ja; ist das System wie in 1701 ,dass man nur Waren verkaufen kann die tatsächlich von einer neutralen Fraktion à la freier Händler eingestellt sind, oder ist das System wie in 1404 und 2070 bei dem man Trenchcoat etc wirklich alles abliefern kann, was man zu viel hat?
Soll ich da echt noch ‘n großen Kommentar zu schreiben? 😉
Die meisten wissen ja eh schon Bescheid :p
Ich bin selber leidenschaftlicher Bug-Hunter der das Talent besitzt auch einige zu finden
Aber gerne Medaurus^^.
LG HarroLP
Bei echten Bugs ist es später die Community die rausfindet ob es tatsächlich klemmt, oder nur ein nicht verstandener Zusammenhang mit einem Feature ist. In der Vergangenheit haben sich vermeintliche Bugs oftnmals nur als Nichtkenntnis der Spielmechanik herrausgestellt. Wie auch immer Bugs in Erscheinung treten werden, die Com wird sie schon finden, auch wenns mal länger dauert. ^^
Gruß
Charles
Auffallend sind für mich immer diese Grafikbugs, die ab und zu in verschiedenen Spielen auftreten. Aber bei dieser Arbeit verschwinden 99% der Bugs.
Mal nach Mainz winkt.
Oh ja das alte Spiel: Beseitige einen Bug und erzeuge 2 neue…..das kennt jeder Tester glaube zur Genüge. Kenne das selber aus diversen Sachen, schon beim alten C64 waren Bugs beim programmieren ein Übel, wenn plötzlich zu lesen war: Error in Line xyz.
Bugjäger, mhh ich müsste jetzt lügen wenn ich nein sage 🙂 denn ich suche Käfer immer wieder gerne. Ab und zu trifft man dabei mal auf lustige aber öfters eigentlich auf welche die einem das Spiel verhageln.
Ich denke da gerade an den lustigen aus 2205, wo man aus 1 Einheit durch gezieltes im Kreis schicken am Ende die Menge auf unendlich heben konnte :). Der Bug trifft genau in das Schema, denn er entstand eher nebenher. Für die die nun schon wieder schreien……nein der Bug wurde gemeldet und gefixt!
Gerade die Suche nach Bugs finde ich spannend, genau wie Zusammenhänge zu erzeugen/finden die der Entwickler so gar nicht erdacht hatte. In meinen Augen gibt es kein Bug freies Spiel egal von wer es auf den Markt bringt, denn ein Entwickler kann nicht alle Situationen abdecken und testen. Was auch gut ist, denn sonst würden Jäger wie ich ja Arbeitslos 🙂
Hellau, Allaf & Alle Wille 🙂