Gabarello: Ein Roboter als Game Controller
comment
Feature

Gabarello: Ein Roboter als Game Controller


Die Therapiestunde wird zu einem interaktiven Erlebnis, ein Videospiel verwandelt das Therapiewerkzeug in einen Game Controller: Das interdisziplinäre Forschungsprojekt der Zürcher Hochschule der Künste offenbart Möglichkeiten und Herausforderungen für Entwickler im Feld der Applied Sciences.

Making Games

@ Facebook

Making Games

@ Twitter

Ein Roboter lehrt laufen: Der Physiotherapieroboter Lokomat® wird bei der motorischen Rehabilitation eingesetzt. Er therapiert Patienten, deren Hirnregionen, welche die Steuerung des Bewegungsapparates leisten, verletzt oder gestört sind und die daher nicht mehr gehen können. Die Therapie nutzt die Eigenheit des menschlichen Gehirns, ausgefallene Funktionen durch andauerndes Training in anderen Hirnregionen erneut auszubilden. So kann die verlorene Gehfähigkeit wieder er-langt werden. Der Lokomat wird weltweit in Spezialkliniken eingesetzt – so auch an den Universi-tätskinderkliniken Zürich, deren Version speziell auf Kinder und Jugendliche zugeschnitten ist, die dort den langen Weg der Rehabilitation beschreiten.
Entscheidend für den Therapieerfolg ist intensives Training im Lokomat. Bei Kindern stellt die Moti-vation allerdings einen kritischen Faktor dar: Oft müssen die Therapeuten gut zureden, um sie bei Laune zu halten und ihre aktive Teilnahme an dem Bewegungsablauf zu fördern. Da die Studienver-tiefung Game Design bereits erfolgreich Serious Games für das Kinderspital entwickelt hatte, fiel die Idee zur Entwicklung eines physiotherapeutischen Videospiels für den Lokomat auf fruchtbaren Bo-den. Therapeuten wie Mediziner erkannten schnell das Potenzial eines exakt auf die Situation entwi-ckelten »Applied Game«, das die kleinen Patienten begeistert und sie die Trainingssituation vergessen lässt. Daraufhin entstand ein interdisziplinäres Forschungsteam unter Beteiligung der ZHdK, des Ro-boterherstellers Hocoma AG, der Universitätskinderkliniken Zürich sowie des Sensory Motor Sys-tems Lab der ETH Zürich. Das Neuropsychologische Institut der Universität Zürich führte außerdem eine wissenschaftliche Evaluation des realisierten Projekts durch. Finanziert wurde das »Gabarello Vs. 1.0« (Game based rehabilitation for Lokomat) benannte Projekt von einer Stiftung zur Kinderhilfe.

Grundlage für die spätere Umsetzung: die Spielkonzepte Rollerball und Sternenstaub.

Viele Spielkonzepte ...
Um im neuen Themengebiet erste Spielideen entwickeln zu können, bestand die erste Aufgabe des Game Design Teams in der gezielten Beobachtung von Therapiesituationen sowie in der Erhebung der Vorgaben, Bedürfnisse und Wünsche der unterschiedlichen Parteien und Nutzergrup-pen.
Basierend auf den vorliegenden Anforderungen galt es außerdem ein breites Spektrum an Konzepten zu entwickeln, um Abhängigkeiten und Grenzen sowie Möglichkeiten der Spielentwicklung auszulo-ten. Dazu wurden zunächst sieben Spielkonzepte entworfen, um sich dem erklärten Ziel des Spiels zu näheren: der drohenden Monotonie entgegenwirken und den Kindern oder Jugend-lichen ein Training mit Vergnügen und ganzem Einsatz ermöglichen. Fünf der skizzierten Konzepte wurden anschließend in einer frühen Phase in zum Teil spielbare Prototypen umgesetzt und vom Team im Reha-Roboter getestet. Anhand der eigenen Erlebnisse sowie des wertvollen Feedbacks von Therapeuten und Medizinern konnten die Konzepte systematisch geschärft werden. Zunehmend rückte dabei die Benutzergruppe der Physiotherapeuten in den Fokus der Entwicklung, da diese entscheidende Hinweise über Laufrhythmen und die daraus folgende Gestaltung der Game Le-vel einbringen konnten. Darüber hinaus wurde deutlich, dass das Spielkonzept für Patienten und The-rapeuten gleichermaßen selbsterklärend sein muss und keinesfalls zu einer weiteren Beanspruchung führen darf. Denn neben dem Patienten und seinem Vorankommen im Therapiespiel muss der Thera-peut zugleich die Softwareeinstellungen des Lokomat überwachen. Schließlich ist das auf allen Ebe-nen aussichtsreichste Konzept realisiert worden, das neben attraktiv gestalteten Spielszenarien auch den Wiederspielwert über mehrere Therapiesitzungen berücksichtigt.

... ein Gameplay
Ein Ergebnis der Konzeptphase war die Anforderung nach einem stressfreien, freund-lichen Szenario, das einerseits genügend Wettbewerb bietet und andererseits ausschließlich positive Anreize verwendet. Entsprechend wurde die Spielfigur gestaltet: Ein kleiner Raumfahrer wird von einer Rakete auf einem Planeten abgesetzt und spaziert auf ihm herum. Spielziel ist es, möglichst viele herumschwirrende Lichter zu entfachen, mit denen der dunkle, versteinerte Planet beleuchtet und zum Leben erweckt wird.
Das Besondere und zugleich die weitreichendste Einschränkung in der Spielsteuerung ist, dass der Spielverlauf einzig durch die Intensität der Beinbewegungen beeinflusst wird. Der Patient treibt die Spielhandlung durch das eigene vom Roboter unterstütze Gehen voran und beeinflusst so den Spiel-verlauf. Die Spielsteuerung werten Roboter und Spiel dabei in Echtzeit aus. Die gemessene Anstren-gung eines Patienten fließt als Information direkt ins Spiel und entscheidet über die Wahl des Weges, die Fähigkeiten und den Zustand der Spielfigur. Diese kann zum Beispiel sichtlich weiter springen oder schneller laufen. Auf diese Weise werden kognitive wie koordinative Fähigkeiten gleichermaßen angesprochen.

Bereits seit dem frühen Prototypen von Gabarello wurde intensiv am Roboter getestet.

Der Roboter lernt spielen
Die erste technische Herausforderung bestand in der Anbindung des Therapie-Roboters an das Spiel bzw. der Abstimmung der drei Komponenten Lokomat mit Steuerungssoftware, Therapeuteninterface mit Interfacesoftware und VirtualReality-Computer (im folgenden VR-Computer) mit Videospiel.
Das Kernstück in diesem Setting stellt die Steuerungssoftware des Lokomat dar, die direkt mit diesem verankert ist und den Roboter verwaltet. Zur Aufgabe der Steuerungssoftware gehört neben der Steue-rung und Kontrolle des Automaten auch die Verarbeitung des Inputs des Therapeuten-Interfaces. Auf diesen Daten aufbauend streamt die Steuerungssoftware Livedaten über ein abgeschottetes Netzwerk. Das Videospiel auf dem VR-Computer empfängt dann diese speziell für Gabarello Vs. 1.0 zusam-mengestellten Rohdaten und bereitet sie auf. Als Protokoll kommt das User Datagram Protocol (UDP) zum Einsatz, das einen konstanten Stream der Live-Daten gewährleistet. Letztere werden vom Spiel als Floating-Point-Werte ausgelesen. Sie umfassen unter anderem einen Zeitindex (Timestamp), die Lage der Beine (Winkelangaben), eine Auswertung der Aktivität des Patienten (Biofeedback) sowie Spielsteuerungsinformationen (Neustart, Pause, Animationstypen etc.) der Interfacesoftware. Am Therapeuten-Interface können zusätzliche Einstellungen erfolgen, zum Beispiel Synchronisierung des Bewegungsablaufs der Spielfigur mit dem der Roboterbeine oder deren völlige Entkopplung. Das hier vorgestellte Setting mit dem Spiel Gabarello Vs. 1.0 unterliegt außerdem -- da im klinischen Rahmen angewendet -- medizinischen Bestimmungen. Die Software darf zu keinem Zeitpunkt eine Gefahr für den Patienten darstellen.

Ein Screenshot der finalen Version 1.0 von Gabarello. Als Grafik-Engine wurde Unity3D verwendet.

Exakte Spielsteuerung
Bei Testläufen mit Prototypen im Lokomat wurde deutlich, dass das analoge Auswer-tungssignal über die Aktivität des Patienten starken Schwankungen unterliegt und für eine direkte Spielsteuerung nicht geeignet ist. Das gelieferte Signal erlaubt zwar Rückschlüsse über die Aktivität der Teilnahme an der Bewegung, lässt sich aber nicht präzise genug vom Spielenden steuern. Denn in den verschiedenen Laufbewegungsphasen verfügt die Muskulatur über unterschiedlich starke Einwir-kungsmöglichkeiten. Zudem sind manche der Patienten aufgrund eingeschränkter Fähigkeiten oft nicht in der Lage, die Muskulatur genauer zu kontrollieren. Nach mehreren Trainingsexperimenten stellte sich eine Reduktion des analogen Signals auf drei digitale Stufen als gut steuerbar, individuell anpassbar und genügend einflussreich auf das Spielgeschehen heraus.

Spielschwierigkeit
Gabarello Vs. 1.0 beruht auf einem einfachen Spielkonzept, das wenige mentale und spielmechanische Anforderungen verlangt. Diese Designentscheidung folgte aus den Erfahrungen, die die Spielentwickler während der Tests im Lokomat sammeln konnten. Die andauernde Bewegung und körperliche Anstrengung durch das Training selbst bieten schon genügend Herausforderungen, das Spiel gibt dem Patienten primär einen Anreiz sowie ein Feedback über den eigenen Aktivitätsgrad. Daher wurden Schwierigkeitsgrade im herkömmlichen Sinn nicht verwendet.

Leveldesign
Die umgesetzte Version von Gabarello Vs. 1.0 basiert auf der Idee, dass der Spieler die Spielfigur über einen runden Planeten laufen lässt. Um eine andauernde Krümmung der Oberflä-che darzustellen, müssen entweder Gravitation und Kamera andauernd angepasst werden oder -- wie in diesem Fall realisiert -- sich der Untergrund und nicht die Spielfigur bewegen. Diese Lösung ver-einfacht auch das Leveldesign, da so gewisse Bereiche eines Levels nicht »auf dem Kopf« modelliert werden müssen. Um dies zu vermeiden, wird das Level in Bereiche unterteilt, die nach einer definier-ten Reihenfolge an die jeweilige Position gesetzt werden. Ist ein Levelteil außerhalb des Sichtbe-reichs, kann dieser komplett aus der Szene entfernt werden.
Die Level wurden entsprechend den Anforderungen so ausgestaltet, dass sie ebenso kurzfristig wie auch längerfristig motivieren können: abwechslungsreich durch grafische Detailtiefe, aber auch her-ausfordernd, weil verschiedene Wege unterschiedliche Anzahlen von herumschwirrenden Lichtern erreichbar werden lassen. Geachtet wurde insbesondere darauf, dass nicht nur stetig »intensives« Ge-hen belohnt wird, sondern auch das bewusste Abbremsen der Spielfigur. Die Langzeitmotivation wird auch dadurch unterstützt, dass der Planet so oft umgangen werden kann, bis alle Lichter entzündet sind. Dies fordert neben den motorischen auch planerische Fähigkeiten sowie ein bewusstes Auswäh-len der angebotenen Wege.

Gabarello und Lokomat als Therapieeinheit an den Universitäts-Kinderkliniken Zürich.

Jump
Da die Spielfigur physikalischen Regeln unterworfen ist, stellte sich das Leveldesign, insbesondere die Positionierung der Absprungpunkte und die Einstellung der Absprungkraft als schwierig heraus. Für das Gestalten eines Abschnittes musste an jedem möglichen Absprungpunkt eine vertikale Kraft definiert werden, mit der die Spielfigur »hochgeschossen« wird. Zur Erleichte-rung des Leveldesigns wurde aufgrund dieser Erkenntnis ein Script erstellt, das die notwendige Kraft für einen Absprung und einen entsprechenden Zielpunkt berechnet.
Für die Entwicklung einer entsprechenden Formel müssen die vorgegebenen und zu berechnenden Werte bestimmt werden.
Im Fall von Gabarello Vs. 1.0 war die Laufgeschwindigkeit gegenüber dem Boden, der Start und Zielpunkt und somit auch die Differenz zwischen diesen beiden Punkten bekannt:
deltaPos = sourcePos - targetPos;
Die Länge des Fluges wird automatisch durch die Laufgeschwindigkeit und die zurückzulegende Stre-cke vorgegeben:
flightTime = deltaPos.x / playerMovementSpeed;
Durch Umwandlung der Formel für die vertikale Flugbahn »y=(v*t)-((1/2)*g*t^2)« zum Beispiel mit-tels wolframalpha.com »solve(y=(v*t)-((1/2)*g*t^2), v)« konnte der für unsere Anwendung benötigte Algorithmus entwickelt werden. Dieser berechnet uns die benötigte Anfangsgeschwindigkeit basie-rend auf der Flugzeit, der Gravitation und des zu überwindenden Höhenunterschieds:
velocity = ((gravity * flightTime) / 2.0) + (deltaPos.y / flightTime);
Durch vorgängiges Verändern der Gravitation könnte zudem Einfluss auf die maximale Sprunghöhe genommen werden.

Anordnung und Abhängigkeiten der drei Softwareeinheiten.

Tipps für Applied Game Design
Frühes Prototyping: Oftmals existieren bei den Kooperationspartnern oder Auftrag-gebern von Therapiespielen zwar erste Vorstellungen über Spielgenre und -gestaltung. Konkrete An-forderungen, Einschränkungen oder Möglichkeiten können aber meist nicht genau angegeben werden. Daher empfiehlt es sich, früh Konzepte zu visualisieren und die Ideen anhand einfacher Prototypen mit allen Beteiligten wiederholt zu schärfen.

Offener Austausch: Im weiteren Verlauf eines Projekts ist es ratsam, die meist gegensätzlichen Standpunkte der beteiligten Disziplinen offen abzustimmen und zu einem gemeinsamen Standpunkt der Spielentwicklung zu vereinen. Dabei geht es auch um Fragen zu den Anteilen von Spaß und Moti-vation gegenüber »ernsten Aspekten« in den Trainingseinheiten.

Nutzungskontext und Benutzer: Eine Begutachtung des Lehr- oder Trainingskontextes sowie der Ziel- und Peer-Gruppen (Spieler, Therapeuten aber z.B. auch Eltern) ist unerlässlich und gibt Auf-schluss über wichtige Details, zum Beispiel ob bestehende Phobien oder einschneidende Erlebnisse die Spielgestaltung beeinflussen und daher auf narrativer, grafischer oder interaktiver Ebene berück-sichtigt werden müssen. In der Entwicklung von Gabarello Vs. 1.0 stellte sich etwa eine langsame Re-aktionsgeschwindigkeit vieler Patienten als ein wichtiger Restriktionsfaktor heraus.

Spielziel: Eines sollte jedoch bei der Integration all dieser Anforderungen nicht aus den Augen verlo-ren werden: das Ziel, ein rundum gelungenes Spiel mit einer gewissen Eigenständigkeit und einem Erlebnischarakter zu entwickeln, das den anstrengenden Prozess des Lernens vergessen macht.

Passende Entwicklungsumgebung: Es empfiehlt sich, mehrere Entwicklungsumgebungen zu prüfen. Im beschriebenen Projekt wurden zwei Game Engines evaluiert, die aufgrund der geringen Kosten und des bestehenden Erfahrungsschatzes des Teams in Frage kamen: Zum einen die Panda3D Engine, die über gute Anbindungsmöglichkeiten an externe Geräte sowie eine umfangreiche Library an Zu-satzfunktionen verfügt. Zum anderen kam die Unity3D Engine in Betracht, die durch ihren 3D-Editor für die Designer im Team eine erhebliche Arbeitserleichterung darstellte und darüber hinaus technisch via C# zahlreiche Bibliotheken bietet. Aufgrund der Ausrichtung des Projektes und der Zielgruppe der 6- bis 18-Jährigen wurden die visuellen Anforderungen entsprechend hoch angesetzt und daher die Unity3D Engine gewählt.
Cornelius Müller, René Bauer, Reto Spoerri, Prof. Ulrich Götz, Florian Faller

Cornelius Müller
ist Dozent für Game Design an der ZHdK.


René Bauer
ist Dozent für Engine-Programmierung an der ZHdK.

Reto Spoerri
ist wissenschaftlicher Mitarbeiter an der ZHdK.


Prof. Ulrich Götz
ist Leiter der Studienvertiefung Game Design an der ZHdK.


Florian Faller, lic. phil.
unterrichtet Game Design an der ZHdK.