Ein UX Dienstleister, der Spiele testet, das passt doch gar nicht zusammen, denken Sie? Das könnte man meinen, aber so unterschiedlich sind UX und Gaming Methoden gar nicht. Anhand eines aktuellen Beispiels möchte ich zeigen, worauf beim Game Testing besonders zu achten ist.
Vor einigen Monaten arbeiteten wir mit einem großen Spielestudio zusammen, um ein bekanntes Open World Spiel zu testen, das bereits seit vielen Jahren auf dem Markt ist und von vielen Millionen Spielern auf der ganzen Welt gespielt wird. Da auch in der Spieleindustrie in den letzten Jahren das Thema User Research mehr und mehr Beachtung findet, werden parallel zur Weiterentwicklung von Spielen Nutzerstudien zur Bedienung durchgeführt, um diese stetig zu verbessern. So war es auch in unserem Fall. Der Entwickler war sich bezüglich der User Experience einiger Funktionen seines Spiels unsicher. Er vermutete, dass sie kaum genutzt werden. Diese Funktionen waren zwar nicht zwingend notwendig, um das Spielziel zu erreichen, allerdings wurden sie aus einem guten Grund entwickelt und sollten zum „joy of use“ und somit zur Gesamtexperience des Spiels beitragen. Dies wird allerdings schwierig, wenn sie vom Spieler nicht gefunden werden.
Ein bekanntes Beispiel…
Ein Beispiel dazu aus The Legend of Zelda: Breath of the Wild: Die Herzen und die Energie von Hauptcharakter Link können durch das Kochen bestimmter Gerichte aufgefüllt werden. Dafür muss der Spieler verschiedene Zutaten überall in der Welt finden. Welche Zutaten welche Gerichte und damit wie viel Energieschub ergeben, muss der Spieler dabei vor allem durch Ausprobieren herausfinden oder indem er Google bemüht. Sollte ein Spieler die Fähigkeit des Kochens allerdings niemals finden oder nutzen, hätte er trotzdem die Möglichkeit, alle Missionen des Spiels erfolgreich abzuschließen, da er noch andere Optionen zum Energiegewinn im Spiel angeboten bekommt. Das Kochen allerdings mit seinem „Zufallsprinzip“ des Ergebnisses bringt den Spielern einen besonderen „joy of use“ und die Nicht-Nutzung wäre mehr als schade. Zum Glück haben die Entwickler und Designer von Nintendo die Kochfunktion gut verständlich eingeführt, sodass auch ich großen Spaß an ihrer Nutzung hatte.
Anhand dieses Beispiels wird deutlich, warum auch unserer Auftraggeber Interesse daran hatte, Nutzer- und Nutzungsinformationen zu den fraglichen Funktionen zu bekommen.
Exploration vs. Moderation
Wichtig gleich zu Beginn war, dass wir selbst Erfahrung mit dem Spiel sammelten. Hierfür sollte genug Zeit eingeplant werden, ein Unterschied zum klassischen Usability Test. Es war essenziell, dass wir im Spiel gut Bescheid wussten (vor allem in Bezug auf die zu testenden Funktionen), da ein Game Test deutlich flexibler abläuft als ein Usability Test. Bei einem Usability Test erstellen wir im Normalfall ein Testszenario, das mehr oder weniger gleich bei allen Testteilnehmern durchlaufen wird, um alle relevanten Fragestellungen zu beantworten. Ein Spiel bringt viel mehr Variationsmöglichkeiten mit sich, kein Teilnehmer wählt denselben Weg, um zum Ziel zu kommen. Dies könnte man zwar über sehr starke Leitung des Moderators erreichen, allerdings würde dies die Echtheit der Spielsituation deutlich einschränken. Besonders bei Open World Spielen ist der Explorationscharakter des Spiels ausschlaggebend und dieser kann nur untersucht werden, wenn die Spieler möglich frei agieren können. Im Zelda Beispiel könnte dies bedeuten, dass die Teilnehmer zunächst nur darum gebeten werden, ihre Energie aufzufüllen und zu beobachten, wie sie vorgehen. Sollte das Kochen gar nicht genutzt werden, kann der Moderator nach einiger Zeit einen Hinweis darauf geben und wiederum die erste Interaktion damit beobachten. In unserem Testfall haben wir uns dazu entschlossen, zwar einen bestimmten Startpunkt im Spiel vorzugeben und auch im Verlauf des Tests immer wieder Hinweise auf die nächsten Schritte zu geben (damit alle Funktionen getestet werden). Die Interaktionen an sich haben wir den Teilnehmern allerdings komplett freigestellt. Wichtig war jedoch, den Teilnehmern an testirrelevanten Stellen zu helfen, um keine unnötige Zeit auf Funktionen zu verwenden, die nicht im Zentrum der Fragestellung standen. Im Beispielfall von Link könnte das beispielsweise die Nutzung des Bogens sein, um Tiere zu erlegen, die wiederum Fleisch zum Kochen verfügbar machen. Die Nutzung des Bogens kann erklärt werden, da sie nicht im Zentrum der Fragestellung steht. Es sollte allerdings als Randerkenntnis aufgenommen werden, dass die Teilnehmer hierbei Probleme hatten.
Testteilnehmer mit besonderen Voraussetzungen
Die Voraussetzungen der Teilnehmer des Spieletests waren ein weiterer wichtiger Unterschied zu einem klassischen Usability Test. Die testrelevanten Eigenschaften der Zielgruppe/Persona wurden zwar wie immer festgelegt (hier zum Beispiel, dass sie noch keine oder wenig Erfahrung mit dem spezifischen Spiel haben sollten, aber trotzdem Erfahrung mit Open World Spielen), allerdings waren darüber hinaus besonders technische Voraussetzungen relevant: Das Spiel benötigte zum Beispiel eine gewisse Performance der Rechner und die Testteilnehmer sollten zudem ein Gamepad für die Durchführung nutzen und nicht Tastatur und Maus. Außerdem sollten die Teilnehmer einen bestimmten Spielstand schon vor dem Test erreichen, da die relevanten Funktionen erst ab einem gewissen Level nutzbar waren. Link findet beispielsweise bestimmte Kochzutaten auch erst, wenn er gewisse Teile der Welt entdeckt hat. Für unseren Test mussten wir uns darauf verlassen, dass die Teilnehmer den Spielstand laut unseren Anweisungen vor dem Test eigenständig erreichten. Wir konnten wie erwartet feststellen, dass die intrinsische Motivation der Teilnehmer bei einem solchen Test sehr hoch war und die meisten die Voraussetzungen in den Test mitbrachten. Die intrinsische Motivation scheint hier höher als bei den meisten Usability Tests, wo der direkte Nutzen nicht immer klar für den Teilnehmer ersichtlich ist. Der zeitliche Aufwand und die Unsicherheit der Testsituation ist häufig präsent bei den Teilnehmern. Bei einem Spieletest reicht aber schon der erwartete Spielspaß, um einer Teilnahme zuzustimmen. Dementsprechend gestaltete sich die Rekrutierung der 10 Teilnehmer recht unkompliziert.
Die Tests an sich mussten aufgrund der Komplexität des Spielverlaufs länger angesetzt werden als die normalerweise empfohlene Stunde zur Durchführung von Usability Tests. Wir versuchen diese gewöhnlich nicht zu überschreiten, da Aufmerksamkeit und Konzentration von Teilnehmern gerade im remote Kontext bei längeren Tests leiden. Außerdem ist gerade bei Tests im beruflichen Kontext die zeitliche Ressource oft ein Problem, weshalb kürzere Tests attraktiver sind. In unserem Fall war ein kurzer Test allerdings nicht praktikabel, um die relevanten Funktionen auszuprobieren. Dies schien aufgrund der Kurzweiligkeit der Spielsituation aber bei den Teilnehmern nicht zu Problemen zu führen. Durch die Moderation wurde versucht, die fünf Hauptfunktionalitäten, die im Test untersucht werden sollten, möglichst bei allen Teilnehmern zu beobachten, ohne jedoch zu viel vorzugeben. Es zeigte sich, dass trotz der angelegten Voraussetzungen an die Technik der Teilnehmer, diese nicht bei allen mitspielte. Dementsprechend kam es bei einigen wenigen vor, dass sie aufgrund technischer Schwierigkeiten nicht alle Funktionen im Zeitfenster von zwei Stunden testen konnten. Vor allem die Internetverbindung war aufgrund der hohen Framerate, die bei der Bildschirmübertragung benötigt wurde, bei einigen ein Problem. Ein Internet-Speedtest zu Beginn des Tests sollte in Zukunft durchgeführt werden, um dieses Problem frühzeitig zu erkennen.
Wohin mit all der Erkenntnis?
Für den Kunden wurden die einzelnen Tests aufgezeichnet und im Nachhinein Highlight-Videos zu den wichtigsten Erkenntnissen erstellt. Hierbei zeigte sich, dass eine zusätzliche Visualisierung des Controllers interessant gewesen wäre. Wir hatten zwar meist nachgefragt, welche Buttons die Teilnehmer nutzen, um gewissen Funktionen zu testen, allerdings nutzten die Teilnehmer zum einen unterschiedliche Controller und zum anderen konnten die genutzten Buttons nicht zu jedem Zeitpunkt abgefragt werden, um den natürlichen Spielverlauf nicht zu unterbrechen.
Wir fanden durch die Tests einige interessante Erkenntnisse zur Nutzung der untersuchten Funktionalitäten. Tatsächlich hatten viele Spieler die Funktionen übersehen oder nicht erwartet. Der Grund hierfür lag vor allem darin, dass Hinweise, die der Spieler zu ihrer Nutzung erhielt, in den meisten Fällen übersehen wurden und außerdem eine Inkonsistenz der Buttons zur Nutzung der Funktionen beobachtet wurde. Die Auswertung erfolgte in Form eines Reports, der diese und weitere Keyfindings im Detail beschrieben hat. Dies ist im Vergleich zum Usability Test, wo wir häufig ein Präsentationsformat wählen, aufgrund der Komplexität zu empfehlen und bietet eine gute Grundlage für die Weiterentwicklung. Hierbei muss der zeitliche Mehraufwand berücksichtigt werden. Wir werteten auch einige Zusatzerkenntnisse aus, die sich auf dem Weg zum Testen der relevanten Funktionen zeigten. Diese führten zu weiteren Testszenarien, die in Zukunft beleuchtet werden können.
Game Test & Usability Test – same same but different?!
Zusammenfassend kann festgehalten werden, dass sich Game Testing und Usability Testing grundlegend nicht unterscheiden. Die Vorbereitung, Durchführung und Auswertung ähneln sich stark. Jedoch ist beim Game Testing aufgrund der Komplexität und der Varianten im Testverlauf eine zeitintensivere Vorbereitung seitens der Researcher und der Teilnehmer als bei einem klassischen Usability Test nötig. Da aber die intrinsische Motivation für solche Tests besonders hoch ist, scheint dies nicht zu Schwierigkeiten bei der Rekrutierung zu führen. Die Entwicklung hin zu mehr User Research im Gaming Bereich ist sehr wünschenswert und wir freuen uns auf viele weitere Projekte dieser Art.
PS: Nicht aufgeben, wenn das Kochresultat nicht ganz so ist, wie erwartet 😉
Wir haben Dein Interesse geweckt? Schau Dir unsere Leistungen an!