Entwicklung eines VR-Systems für Kinder zum Entwerfen und Erproben interaktiver Objekte
Februar 2021
Überblick
Smart Codesign VR ist der Prototyp einer Plattform zum Erstellen und Erproben interaktiver „intelligenter Objekte“ in virtueller Realität. Die Spielenden wählen drei Karten – je eine für Umgebung, Eingabe und Ausgabe – und legen anschließend mit Körperbewegungen fest, wann ein Objekt reagiert und was es tut. Das fertige virtuelle Objekt können sie in einem Park platzieren und sein Verhalten testen.
Das Projekt baut auf SNaP (The Smart Nature Protagonists) auf, einem Brettspiel des i3Lab am Politecnico di Milano. In SNaP erfinden Kinder durch die Kombination von Karten intelligente Objekte und beschreiben sie in einem Satz auf Papier. Ziel dieses Projekts war, diese Beschreibungen in virtuelle Objekte zu übersetzen, die Kinder zusammensetzen und mit denen sie durch eigene Bewegungen interagieren können.
Unser vierköpfiges Team entwarf und implementierte das System als Abschlussprojekt des Kurses Advanced User Interfaces am Politecnico di Milano im Studienjahr 2020–21. Wir gestalteten es für Kinder von 11 bis 13 Jahren und berücksichtigten besonders Kinder mit neurologischen Entwicklungsstörungen (NDD). Der in Unity und C# für Oculus Quest 2 entwickelte Prototyp unterstützt den vollständigen Ablauf von der Kartenauswahl bis zur Interaktion im virtuellen Park.
SNaP und der Gestaltungskontext
Ein Spiel, in dem Kinder gestalten
In SNaP übernehmen zwei bis vier Kinder die Rolle von „Designern“, während eine erwachsene Begleitperson den „Bürgermeister“ spielt. Der Bürgermeister stellt eine Aufgabe vor. Die Kinder besprechen Ideen und kombinieren Karten, um ein intelligentes Objekt zu entwerfen, das darauf eingeht. Das Spiel soll Kreativität, Zusammenarbeit und die Fähigkeit fördern, Ideen auszudrücken. Auch die Nutzung durch Kinder mit neurologischen Entwicklungsstörungen wurde berücksichtigt; therapeutische oder pädagogische Wirkungen wurden in diesem Projekt jedoch nicht untersucht.
Drei Kartentypen: Umgebung, Eingabe und Ausgabe
SNaP umfasst drei Kartentypen mit unterschiedlichen Aufgaben.
Umgebungskarten stellen das Objekt dar, das intelligent werden soll: Baum, Bank, Schaukel, Gewässer, Stein, Straßenlaterne, Abfalleimer, Fahrrad, Brücke, Treppe oder Schultasche. Es sind vertraute Gegenstände und Elemente von Parks und Straßen. Die Umgebungskarte bestimmt das Objekt, das die Eingabe- und Ausgabefunktionen enthalten wird.
Eingabekarten legen fest, was das Objekt erkennt oder worauf es reagiert, etwa einen Knopf, Bewegung, Berührung, Abstand, Temperatur, Feuchtigkeit, Helligkeit, Farbe, Schall, Feuer, Wasserstand oder eine Wettervorhersage. Sie stehen für die Eingaben des intelligenten Objekts, vergleichbar mit Sensoren.
Ausgabekarten bestimmen die Reaktion des Objekts: leuchten, einen Ton erzeugen, vibrieren, sich bewegen, etwas anzeigen, aufzeichnen oder Informationen senden. Sie stehen für seine Ausgabefunktionen, vergleichbar mit Aktoren.
Die Umgebungskarte gibt einem Eingabe-Ausgabe-Paar seinen Kontext. Mit Bewegung als Eingabe und Ton als Ausgabe könnte ein Abfalleimer einen Ton erzeugen, wenn jemand danebenwirft; eine Straßenlaterne könnte ankündigen, dass sich jemand nähert. Eingabe und Ausgabe bestimmen das Verhalten eines Geräts. Die Umgebung verbindet dieses Verhalten mit einer Alltagssituation.
Geschriebene Ideen in interaktive virtuelle Objekte übersetzen
Zum Zeitpunkt dieses Projekts endete eine SNaP-Sitzung mit einer schriftlichen Beschreibung des von den Kindern entworfenen intelligenten Objekts. Parallel entwickelte i3Lab ein „physisches Board“, das ein Tablet mit Arduino verband, um diese Beschreibungen in reale Prototypen umzusetzen. Smart Codesign VR untersuchte einen anderen Ansatz mit virtueller Realität – einem Medium, das das Forschungsteam für diesen Zweck noch nicht untersucht hatte.
VR bot zwei Möglichkeiten. Erstens konnten Kinder durch Bewegungen des ganzen Körpers Prototypen gestalten: Greifen, Tragen, Anleuchten und Malen mit einem Pinsel wurden zu Mitteln, um Bedingungen und Verhalten festzulegen. Zweitens konnten ihre Ideen als virtuelle Objekte sichtbar werden, mit denen sie unmittelbar interagieren konnten. Aus einer schriftlichen Beschreibung konnte ein Objekt mit Größe und Form direkt vor ihnen entstehen.
Vorgesehene Nutzende
Vorgesehen waren Kinder von 11 bis 13 Jahren, mit besonderem Augenmerk auf Kinder mit neurologischen Entwicklungsstörungen. Das Entwerfen eines intelligenten Objekts erfordert ein gewisses logisches Denken; deshalb wurden sowohl SNaP als auch die VR-Version für diese Altersgruppe gestaltet.
Das Projekt sollte Kindern helfen, ihre Ideen durch praktisches Prototyping und Interaktion auszudrücken. Das waren Gestaltungsziele, keine nachgewiesenen therapeutischen oder pädagogischen Ergebnisse; der Prototyp wurde nicht mit Kindern evaluiert.
Einen angenehmen Raum gestalten
Auf Grundlage der im Projekt herangezogenen Materialien orientierten wir die Raumgestaltung an vier Bereichen: Klang, Licht und Farbe, räumliche Organisation und Materialien. Beim Klang berücksichtigten wir die Abschirmung von Geräuschen, einstellbare Lautstärke und ruhige, gleichmäßige Töne, um auf Geräuschempfindlichkeit einzugehen. Für Licht und Farbe erwogen wir einen ruhigen, wenig gesättigten Hintergrund, bei dem helle, kräftige Farben auf kleine Flächen beschränkt bleiben sollten. Auch klare räumliche Grenzen, eine geordnete Anordnung, einfache und gut erkennbare Formen sowie ungehinderte Bewegung gehörten zu den Gestaltungsüberlegungen. Eine virtuelle Umgebung erlaubt es, diese Aspekte zu kontrollieren. Ihre Wirkung auf das Wohlbefinden der Nutzenden wurde in diesem Projekt nicht untersucht.
Grenzen und Risiken von VR
Das Projekt berücksichtigte auch Grenzen und Risiken von VR: Hardwarekosten, Bewegungskrankheit, Belastung von Kopf und Nacken durch das Gewicht des Headsets, Unfälle durch die verdeckte Sicht auf die reale Umgebung, Augenbelastung bei längerer Nutzung und Bedenken hinsichtlich einer Abhängigkeit durch übermäßige Immersion.
Diese Überlegungen führten zu drei Gestaltungsentscheidungen: einfache Interaktionen mit genügend Herausforderung, um Lernen zu unterstützen; klare visuelle und akustische Gestaltung ohne übermäßige Reize; und ein eindeutiger Abschluss. Sobald Prototyping und Erprobung im Park beendet sind, endet die Aktivität, statt zu einem unbegrenzten Aufenthalt in VR anzuregen.
Der Prototyp: Erlebnis und Implementierung
Vier Phasen des Erlebnisses
Die Anwendung besteht aus vier Phasen: Startbildschirm, Kartenauswahl, Prototyping und Interaktion im virtuellen Park.
1. Startbildschirm
Die Anwendung öffnet sich mit einer Titelansicht und wartet auf einen Tastendruck am Controller. Diese bewusste Pause gibt der spielenden Person Zeit, das Headset aufzusetzen und sich zu positionieren, bevor das eigentliche Erlebnis beginnt.
2. Kartenauswahl: Greifen und ablegen
Die spielende Person wählt je eine Umgebungs-, Eingabe- und Ausgabekarte, indem sie das zugehörige Objekt greift und in die passende Box legt. Diese Interaktion nutzt den dreidimensionalen Raum der VR. Sind alle drei Boxen gefüllt, führt eine Audioanweisung zum Prototyping. Die Reihenfolge der Auswahl ist frei, doch für das Fortfahren werden alle drei Karten benötigt.
3. Prototyping: Bedingungen und Verhalten durch Bewegung definieren
Das Prototyping ist der Kern des Systems. Die Spielenden bestimmen die auslösende Bedingung für die gewählte Eingabekarte und die Reaktion für die gewählte Ausgabekarte. Jede Karte hat ihre eigene Interaktion mit Bewegungen, die Tracking in sechs Freiheitsgraden erfordern.
Wählt man beispielsweise „Wettervorhersage“, erscheinen in Reichweite Objekte für Sonne, Wolken, Regen, Gewitter und Schnee. Die spielende Person greift eines davon und richtet dessen Strahl auf das Zielobjekt, um die Bedingung festzulegen. Ist „Leuchten“ als Ausgabe gewählt, nimmt sie einen Pinsel, taucht ihn in einen Farbeimer und bemalt das Zielobjekt, um dessen Leuchtfarbe zu wählen. Zum Entfernen einer aufgetragenen Farbe taucht sie den Pinsel in den „Wasser“-Eimer und streicht erneut über das Objekt.
Eine wichtige Implementierungsentscheidung war, mehrere Eingabe-Ausgabe-Paare für ein einzelnes Objekt zu unterstützen. Ursprünglich war nur eine Regel vorgesehen, etwa „bei Sonnenschein rot leuchten“. Mehrere Paare ermöglichen unterschiedliche Reaktionen auf verschiedene Bedingungen: Rot bei Sonne, Blau bei Regen und Weiß bei Schnee. Jedes Paar kann vor der Bestätigung getestet und bei Bedarf erneut bearbeitet werden.
4. Der Park: Das Objekt testen
Nach der Bestätigung gelangt die spielende Person in einen virtuellen Park, platziert das Objekt, löst die definierte Eingabebedingung aus und beobachtet die Reaktion. Eine Feier markiert die erfolgreiche Funktion des Objekts und beendet das Erlebnis.
Gesamtablauf
Die folgenden UML-Aktivitätsdiagramme fassen das Erlebnis zusammen. Das obere Diagramm zeigt den Gesamtablauf; die beiden darunter erläutern die Interaktionen für „Wettervorhersage“ und „Leuchten“. Verzweigungen zeigen, wie die Spielenden nach den Anweisungen zur Kartenauswahl zurückkehren oder nach Bestätigung und Test ihr Objekt erneut bearbeiten können.
Hardware und Werkzeuge
Der Prototyp wurde für Oculus Quest 2 entwickelt. Das Tracking in sechs Freiheitsgraden unterstützt Drehen, Fortbewegen und die Handhabung virtueller Objekte. Weil wiederholte praktische Interaktion im Mittelpunkt stand, schloss das Team Smartphone-basierte Headsets aus, die auf Tracking in drei Freiheitsgraden beschränkt sind.
Die Anwendung wurde in Unity und C# entwickelt. Das Paket Oculus Integration verband sie mit Quest 2 und stellte APIs für das Verhalten der VR-Kamera, das Rendering und Controller-Eingaben bereit.
Vier Szenen und 13 Klassen
Das System verwendet vier Unity-Szenen, eine pro Phase des Erlebnisses. Es umfasst 13 Klassen, darunter drei abstrakte Klassen.
Die Titelszene enthält eine einzige Klasse, TitleSceneCore, die nach einem Tastendruck zur nächsten Szene wechselt.
Die Kartenauswahlszene verwendet CardSelectionSceneCore und CardSelectionDetector. CardSelectionSceneCore erzeugt drei Detektorinstanzen, je eine für die Umgebungs-, Eingabe- und Ausgabebox. Jede Box zieht ein nahes Kartenobjekt an und markiert dessen Kategorie als ausgewählt. Sobald alle drei Auswahlen abgeschlossen sind, schreibt die Szene sie in die statische Klasse SmartObject und wechselt weiter. SmartObject bewahrt diese Daten über Szenenwechsel hinweg und verbindet so die vier Szenen zu einem durchgängigen Erlebnis.
In der Prototyping-Szene koordiniert PrototypingSceneCore den Ablauf. Das Verhalten von Card wird durch eine Vererbungshierarchie dargestellt: Card ist die Basisklasse, InputCard und OutputCard sind davon abgeleitet, und konkrete Klassen wie Weather, Fire, MakeSound und LightUp implementieren die einzelnen Interaktionen. Card, InputCard und OutputCard sind abstrakt, weil nur die konkreten Unterklassen Prototyping-Vorgänge ausführen.
PrototypingSceneCore verwaltet eine Liste von Instanzen für Eingabebedingungen und eine weitere für Ausgabeverhalten. Sind „Wettervorhersage“ und „Leuchten“ gewählt, enthalten die Listen Weather- beziehungsweise LightUp-Instanzen. Zu Beginn wird je eine Instanz erzeugt; die Hinzufügen-Schaltfläche erstellt ein weiteres Paar. In jedem Frame wertet das System die Eingabebedingungen aus und ruft die zugehörigen Ausgabeverhalten auf. Bestätigt die spielende Person das Objekt, wird isConfirmed auf true gesetzt, und die zusammengestellten Verhaltensdaten werden in die statischen Eigenschaften von SmartObject geschrieben.
Die Interaktionsszene enthält eine einzige Klasse, InteractionSceneCore. Sie übernimmt die Platzierung des Objekts im Park, das Testen der definierten Bedingungen und Reaktionen sowie die abschließende Feier.
Smart Object“ bezeichnete statische Klasse bewahrt Daten zwischen den Szenen. Attribute und Methoden sind zur besseren Lesbarkeit vereinfacht.Quellcode:
github.com/takafumihoriuchi/SmartCodesignVR — Assets/myScripts
Ergebnisse und offene Arbeiten
Neun von 49 Karten implementiert
Der Prototyp implementiert neun Karten. Seine Kernfunktionen funktionieren: Kartenauswahl, Definition von Bedingungen und Verhalten, Verwaltung mehrerer Instanzen und Datenübertragung zwischen Szenen. Das bildet eine Grundlage für weitere Karten, deren Implementierung jedoch noch aussteht. Sechs zusätzliche Karten wurden entworfen, aber nicht implementiert; die übrigen 34 benötigen sowohl Interaktionsgestaltung als auch Implementierung.
| Status | Karten |
|---|---|
| Implementiert (9) | Umgebung: Baum, Straßenlaterne, Straßenschild, Abfalleimer, Brücke Eingabe: Feuer, Wettervorhersage Ausgabe: Ton erzeugen, leuchten |
| Nur entworfen (6) | Eingabe: Knopf, Geschwindigkeit, Schall Ausgabe: bewegen, vibrieren, senden |
| Noch nicht begonnen (34) | 15 Umgebungskarten, 16 Eingabekarten, 3 Ausgabekarten (anzeigen, aktivieren, aufzeichnen) |
Keine Evaluation mit Nutzenden
Der Prototyp wurde nicht mit Nutzenden evaluiert. Die Entwicklung fiel in die Zeit der Fernteilnahme während der COVID-19-Pandemie. Weder ein Präsenzworkshop mit VR-Headsets noch eine Alternative aus der Ferne ließ sich organisieren. Das Projekt zeigt, dass sich das entworfene Erlebnis als funktionsfähiger Prototyp implementieren lässt. Seine Gebrauchstauglichkeit für Kinder und sein Nutzen in einem therapeutischen Umfeld bleiben ungeprüft.
Eine künftige Evaluation würde untersuchen, wie intuitiv die Bedienoberfläche beim Prototyping ist. Mögliche Messgrößen sind Bearbeitungszeit, Übereinstimmung des fertigen intelligenten Objekts mit der ursprünglichen Idee und Anzahl unbeabsichtigter Tastendrücke. Ein anschließender Fragebogen auf Basis der System Usability Scale (SUS) würde zusätzliche quantitative Daten liefern. Mit Einwilligung und geeigneten Verfahren könnten Sitzungen aufgezeichnet werden, um die Bewegungen der Teilnehmenden zu beobachten. Für das Projekt von 2021 wurde ein Alter von 13 Jahren zur Evaluation vorgeschlagen, um die Zielgruppe von SNaP mit den damals herangezogenen Oculus-Hinweisen in Einklang zu bringen. Jede künftige Studie müsste die Teilnahmevoraussetzungen anhand der dann geltenden Hinweise und des Forschungsprotokolls neu beurteilen.
Künftige Arbeit
Vorrang bei der Weiterentwicklung hat die Verfeinerung von UI und UX. Aufgrund begrenzter Zeit und Erfahrung floss der größte Teil der Arbeit in funktionsfähige Kartenkombinationen; die visuelle, akustische und haptische Gestaltung blieb weniger ausgearbeitet. Auch die Rolle von Text in VR muss neu betrachtet werden: Informationen, die für eine flache Fläche gestaltet wurden, könnten in einer räumlichen Benutzeroberfläche (SUI) besser vermittelt werden. Sprachinteraktion ist ein weiterer Ansatz, der für die vorgesehene Zielgruppe untersucht werden sollte.
Das Projekt zeigte drei Forschungsrichtungen auf. Erstens ein Vergleich mit dem am i3Lab entwickelten physischen Board. Frühere Forschung berichtete von einem stärkeren Gesprächsaustausch, wenn Teilnehmende dasselbe kooperative Spiel in einer virtuellen statt einer physischen Umgebung spielten; das legt einen nützlichen Vergleich der beiden Plattformen nahe. Zweitens die gleichzeitige Teilnahme mehrerer Personen: Passend zum Namen „Codesign“ könnten Kinder in VR gemeinsam Objekte bauen. Drittens ein standardisiertes Format zur Beschreibung intelligenter Objekte, mit dem Entwürfe zwischen Plattformen übertragen werden könnten.
Zusammenfassung
Dieses Projekt schuf eine Umgebung zum Prototyping intelligenter Objekte. Die drei SNaP-Kartentypen wurden in Bausteine übersetzt: das Objekt, seine Auslösebedingungen und seine Verhaltensweisen. Die Spielenden verbinden sie durch Greifen, Zeigen und Malen. Der funktionsfähige Prototyp macht aus einer schriftlichen Idee ein interaktives virtuelles Objekt, dessen Verhalten als zwischen Szenen übertragbare Daten dargestellt wird.
Takafumi Horiuchi, Paul Cozma-Ivan, Elmira Katsajeva und Olivia Ludkiewicz, „Design and Implementation of a Smart Object Prototyping Platform in Virtual Reality for Children with NDD“, Abschlussprojekt im Kurs Advanced User Interfaces (Studienjahr 2020–21), Politecnico di Milano, Februar 2021.