Vor einigen Monaten arbeiteten wir mit einem gro\u00dfen 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<\/a> mehr und mehr Beachtung findet, werden parallel zur Weiterentwicklung von Spielen Nutzerstudien zur Bedienung durchgef\u00fchrt, um diese stetig zu verbessern. So war es auch in unserem Fall. Der Entwickler war sich bez\u00fcglich der User Experience<\/a> 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 \u201ejoy of use\u201c und somit zur Gesamtexperience des Spiels beitragen. Dies wird allerdings schwierig, wenn sie vom Spieler nicht gefunden werden.<\/p>\n Ein Beispiel dazu aus The Legend of Zelda: Breath of the Wild: Die Herzen und die Energie von Hauptcharakter Link k\u00f6nnen durch das Kochen bestimmter Gerichte aufgef\u00fcllt werden. Daf\u00fcr muss der Spieler verschiedene Zutaten \u00fcberall 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\u00fcht. Sollte ein Spieler die F\u00e4higkeit des Kochens allerdings niemals finden oder nutzen, h\u00e4tte er trotzdem die M\u00f6glichkeit, alle Missionen des Spiels erfolgreich abzuschlie\u00dfen, da er noch andere Optionen zum Energiegewinn im Spiel angeboten bekommt. Das Kochen allerdings mit seinem \u201eZufallsprinzip\u201c des Ergebnisses bringt den Spielern einen besonderen \u201ejoy of use\u201c und die Nicht-Nutzung w\u00e4re mehr als schade. Zum Gl\u00fcck haben die Entwickler und Designer von Nintendo die Kochfunktion gut verst\u00e4ndlich eingef\u00fchrt, sodass auch ich gro\u00dfen Spa\u00df an ihrer Nutzung hatte.<\/p>\n Anhand dieses Beispiels wird deutlich, warum auch unserer Auftraggeber Interesse daran hatte, Nutzer- und Nutzungsinformationen zu den fraglichen Funktionen zu bekommen.<\/p>\n Wichtig gleich zu Beginn war, dass wir selbst Erfahrung mit dem Spiel sammelten. Hierf\u00fcr 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\u00e4uft 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\u00f6glichkeiten mit sich, kein Teilnehmer w\u00e4hlt denselben Weg, um zum Ziel zu kommen. Dies k\u00f6nnte man zwar \u00fcber sehr starke Leitung des Moderators erreichen, allerdings w\u00fcrde dies die Echtheit der Spielsituation deutlich einschr\u00e4nken. Besonders bei Open World Spielen ist der Explorationscharakter des Spiels ausschlaggebend und dieser kann nur untersucht werden, wenn die Spieler m\u00f6glich frei agieren k\u00f6nnen. Im Zelda Beispiel k\u00f6nnte dies bedeuten, dass die Teilnehmer zun\u00e4chst nur darum gebeten werden, ihre Energie aufzuf\u00fcllen 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\u00e4chsten 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\u00f6tige Zeit auf Funktionen zu verwenden, die nicht im Zentrum der Fragestellung standen. Im Beispielfall von Link k\u00f6nnte das beispielsweise die Nutzung des Bogens sein, um Tiere zu erlegen, die wiederum Fleisch zum Kochen verf\u00fcgbar machen. Die Nutzung des Bogens kann erkl\u00e4rt werden, da sie nicht im Zentrum der Fragestellung steht. Es sollte allerdings als Randerkenntnis aufgenommen werden, dass die Teilnehmer hierbei Probleme hatten.<\/p>\n 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\u00fcber hinaus besonders technische Voraussetzungen relevant: Das Spiel ben\u00f6tigte zum Beispiel eine gewisse Performance der Rechner und die Testteilnehmer sollten zudem ein Gamepad f\u00fcr die Durchf\u00fchrung nutzen und nicht Tastatur und Maus. Au\u00dferdem 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\u00fcr unseren Test mussten wir uns darauf verlassen, dass die Teilnehmer den Spielstand laut unseren Anweisungen vor dem Test eigenst\u00e4ndig 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\u00f6her als bei den meisten Usability Tests, wo der direkte Nutzen nicht immer klar f\u00fcr den Teilnehmer ersichtlich ist. Der zeitliche Aufwand und die Unsicherheit der Testsituation ist h\u00e4ufig pr\u00e4sent bei den Teilnehmern. Bei einem Spieletest reicht aber schon der erwartete Spielspa\u00df, um einer Teilnahme zuzustimmen. Dementsprechend gestaltete sich die Rekrutierung der 10 Teilnehmer recht unkompliziert.<\/p>\n Die Tests an sich mussten aufgrund der Komplexit\u00e4t des Spielverlaufs l\u00e4nger angesetzt werden als die normalerweise empfohlene Stunde zur Durchf\u00fchrung von Usability Tests. Wir versuchen diese gew\u00f6hnlich nicht zu \u00fcberschreiten, da Aufmerksamkeit und Konzentration von Teilnehmern gerade im remote Kontext bei l\u00e4ngeren Tests leiden. Au\u00dferdem ist gerade bei Tests im beruflichen Kontext die zeitliche Ressource oft ein Problem, weshalb k\u00fcrzere 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\u00fchren. Durch die Moderation wurde versucht, die f\u00fcnf Hauptfunktionalit\u00e4ten, die im Test untersucht werden sollten, m\u00f6glichst 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\u00fcbertragung ben\u00f6tigt wurde, bei einigen ein Problem. Ein Internet-Speedtest zu Beginn des Tests sollte in Zukunft durchgef\u00fchrt werden, um dieses Problem fr\u00fchzeitig zu erkennen.<\/p>\n F\u00fcr den Kunden wurden die einzelnen Tests aufgezeichnet und im Nachhinein Highlight-Videos zu den wichtigsten Erkenntnissen erstellt. Hierbei zeigte sich, dass eine zus\u00e4tzliche Visualisierung des Controllers interessant gewesen w\u00e4re. 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\u00fcrlichen Spielverlauf nicht zu unterbrechen.<\/p>\n Wir fanden durch die Tests einige interessante Erkenntnisse zur Nutzung der untersuchten Funktionalit\u00e4ten. Tats\u00e4chlich hatten viele Spieler die Funktionen \u00fcbersehen oder nicht erwartet. Der Grund hierf\u00fcr lag vor allem darin, dass Hinweise, die der Spieler zu ihrer Nutzung erhielt, in den meisten F\u00e4llen \u00fcbersehen wurden und au\u00dferdem 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\u00e4ufig ein Pr\u00e4sentationsformat w\u00e4hlen, aufgrund der Komplexit\u00e4t zu empfehlen und bietet eine gute Grundlage f\u00fcr die Weiterentwicklung. Hierbei muss der zeitliche Mehraufwand ber\u00fccksichtigt werden. Wir werteten auch einige Zusatzerkenntnisse aus, die sich auf dem Weg zum Testen der relevanten Funktionen zeigten. Diese f\u00fchrten zu weiteren Testszenarien, die in Zukunft beleuchtet werden k\u00f6nnen.<\/p>\n Zusammenfassend kann festgehalten werden, dass sich Game Testing und Usability Testing grundlegend nicht unterscheiden. Die Vorbereitung, Durchf\u00fchrung und Auswertung \u00e4hneln sich stark. Jedoch ist beim Game Testing aufgrund der Komplexit\u00e4t und der Varianten im Testverlauf eine zeitintensivere Vorbereitung seitens der Researcher und der Teilnehmer als bei einem klassischen Usability Test n\u00f6tig. Da aber die intrinsische Motivation f\u00fcr solche Tests besonders hoch ist, scheint dies nicht zu Schwierigkeiten bei der Rekrutierung zu f\u00fchren. Die Entwicklung hin zu mehr User Research im Gaming Bereich ist sehr w\u00fcnschenswert und wir freuen uns auf viele weitere Projekte dieser Art.<\/p>\n PS: Nicht aufgeben, wenn das Kochresultat nicht ganz so ist, wie erwartet \ud83d\ude09<\/p>\n <\/p>\n Wir haben Dein Interesse geweckt? Schau Dir unsere Leistungen<\/a> an!<\/strong><\/p>\nEin bekanntes Beispiel\u2026<\/h2>\n
![\"Zelda](\"https:\/\/www.centigrade.de\/wordpress\/wp-content\/uploads\/Zelda-Kochfunktion.jpg\")
<\/p>\nExploration vs. Moderation<\/h2>\n
Testteilnehmer mit besonderen Voraussetzungen<\/h2>\n
Wohin mit all der Erkenntnis?<\/h2>\n
Game Test & Usability Test \u2013 same same but different?!<\/h2>\n
![\"Zelda](\"https:\/\/www.centigrade.de\/wordpress\/wp-content\/uploads\/Zelda-Kochresultat.jpg\")
<\/p>\n