Spieleentwicklung wirkt auf den ersten Blick wie ein chaotischer Mix aus Kreativität, Code und Koffein, aber unter der Oberfläche liegt ein Prozess, der sich von Requirements Engineering kaum unterscheiden lässt. Ob man jetzt ein kompliziertes Rogue-Like oder einen Farming-Simulator entwickelt, die Balance zwischen Spielmechaniken, beabsichtigtem Spielstil und Spielerfeedback ist ein komplizierter Tanz. In diesem Blog möchte Ich beleuchten, wie Spielentwickler bewusst oder unbewusst Requirements Engineering betreiben.
Das Herz jedes Spiels ist ein beabsichtigtes Spielerlebnis. Vielleicht ist es schneller, hastiger, taktischer Kampf, eine entspannte Entdeckungsreise durch eine gigantische Welt oder nervenaufreibende Schrecksituationen. Das ist das Äquivalent einer Funktionalen Anforderung – Was soll das Spiel erreichen?
Nehmen wir beispielsweise an, ein Entwickler möchte ein Stealth-Spiel entwickeln. Das ist die Vision. Aber was sind die Mechaniken? Schleichen, Verstecken, Sichtlinien vermeiden, das Erledigen von Feinden aus dem Hinterhalt. Das sind Beispiele, die man in eine Feature-Liste verwandeln kann. Damit diese Features jedoch so funktionieren, wie man sie sich vorstellt, müssen sie mit dem beabsichtigten Spielerlebnis einhergehen. Wenn die Gegner perfekt schiessen und den Spieler ohne Probleme entdecken spielt man plötzlich einen aggressiven Action Shooter und kein Stealth-Spiel. Hier kommt die Rückverfolgbarkeit ins Spiel: Sicher machen, dass Features die ursprüngliche Idee unterstützen.
Ein weiterer Aspekt, der von vielen Leuten unterschätzt wird und gleichzeitig einees der wichtigsten Teile für ein funktionierendes Spiel ist, ist die Balance von Schwierigkeitsstufen. Im herkömmlichen Requirements Engineering könnte man dies mit der Anpassung von Leistungsanforderungen vergleichen. Wie schnell ist zu schnell? Wie viele Gegner kann man ins Level generieren, bevor das Spiel unfair wird und keinen Spass mehr macht?
Diese „Herausforderungsanforderung“ lässt sich aufgrund des Zielpublikums ( der Endnutzer ) und des Genres erheben. Ein Soulslike-Spiel wird von Leuten gespielt, die eine Herausforderung suchen und damit rechnen, wieder und wieder zu sterben, während dieses Niveau an Schwierigkeit in einem Puzze-Spiel für Kinder nichts verloren hat. Wenn das Spiel diese impliziten Erwartungen nicht erfüllt, ist es irrelevant ob es mechanisch funktioniert, es wird nie zu einem erfolgreichen Produkt.
Spieler sind Stakeholder
Wie im herkömmlichen Requirements Engineering gibt es seitens der Nutzer verschiedene, manchmal miteinander in Konflikt stehende Bedürfnisse. Manche wollen mehr Story, manche wollen mehr Herausforderungen. Und manche möchten einfach den süssen Hund streicheln. Man kann es nicht jedem Recht machen, aber es ist wichtig, dass man das Publikum versteht und wo potentielle Konflike entstehen könnten. Dies erlaubt es, sowohl während der initialen Entwicklung Features richtig zu priorisieren, als auch nach Release des Endprodukts das Spiel in die richtige Richtung anzupassen. Spiele, die häufig angepasst werden, wie die meisten Mehrspieler-Spiele, veröffentlichen bei Neuerungen oft sogenannte Patch-Notes. In diesen stehen nebst den Änderungen oft auch die Begründungen dafür: „Es wurde ein Knopf zum Deaktivieren des Tutorials hinzugefügt ( Hohe Nutzernachfrage )“ oder „Der Schaden von Fähigkeit XY wurde verringert ( Die Fähigkeit ist zu stark. )“. Diese Änderungen stammen oft von direkten Spielerfeedback. Spielerfeedback ernst zu nehmen ist für den langfristigen Erfolg eines Spiels unglaublich wichtig. Es ist eine der einfachsten Möglichkeiten, Lücken zwischen dem beabsichtigten und dem effektiven Spielerlebnis zu erkennen.
Deswegen kann man Playtests wie eine Art Stakeholder Validation ansehen. Spielt sich das Spiel wie gewünscht? Entdecken Spieler Strategien, die das System aushebeln oder sogar Bugs nutzen? Scheitern Spieler an Stellen wo es nicht beabsichtigt ist? Das ist Requirement Engineering in purer Form: Man definiert das System ( das Spiel ), sammelt Nutzerfeedback ( Playtests ) und passt die Anforderungen wo nötig an. Auch bei Spielen gilt: Iteration ist keine Zeitverschwendung. Was entfernt werden muss, gehört entfernt, was überarbeitet werden muss, gehört überarbeitet. Die wenigsten guten Spiele ähneln am Ende ihrer Lebenszeit dem ersten Draft.
Also, das nächste Mal wenn Sie sich in einer immersiven, perfekt designten Welt wiederfinden denken Sie daran, das war kein Zufall, sondern ein lange andauernder Prozess.
