Unity 5 im Event-Raum

Für die Umsetzung des Spiels begannen wir uns in Unity 5 einzuarbeiten. Unity ist eine 3D Spiel-Engine samt intuitiver Entwicklungsumgebung. Die Inhalte können auf zahlreichen Plattformen ( PC / Mac, Web wie Mobile ) abgespielt werden. Zusätzliche Funktionen können in der Programmiersprache C# geschrieben und online in Unitys „Asset-Store“ vertrieben werden. Das und eine große Community machen Unity sehr flexibel.

Die 3D-Modelle der Spiele-Grafik werden im Editor zu einer Szene zusammengesetzt und beleuchtet. Mit C# können wir ihr Verhalten beeinflussen, Objekte generieren oder zum Beispiel die Kamera bewegen.

Unity unterstützt von Haus aus Physik. Es simuliert die Gravitation die auf die Kaugummikugel wirkt und bewegt sie entsprechend bis sie auf ein Hindernis stößt, unsere Rinnen. Neigen wir die Rinnen kommt die Kugel ins Rollen. Statt die Kugel zu bewegen, bewegen wir ihre Umgebung – wie in einem realen Kugellabyrinth.

Anfangs sah das unnatürlich aus, die Kugel rutschte auf dem Boden und war zu träge. Über mehrere Tage haben wir die Gravitation erhöht und an Parametern wie der Reibung von Kugel und Rinne gefeilt bis sich die Kugel wunschgemäß verhielt.

 

Für den Einsatz im Eventmedialen Raum mussten wir Unity um ein paar Funktionen erweitern.

Um mit dem Sensor, Ableton Live für die Musik und weiteren Rechnern der Installation kommunizieren zu können haben wir das OSC-Protokoll integriert. Dieses ist nicht Standartmäßig Bestandteil von Unity, kann aber unter anderem im Assetstore erworben werden. Wir haben die unter der MIT Lizenz frei vertriebene Implementierung von Jorge Garcia eingesetzt.

Das Spiel ist an 5 Orten im Raum zu sehen: 3 Leinwände werden von Beamern bespielt, sowie 2 Touchscreens an den Lolliplattformen. Alle zeigen die gleiche Spielwelt leicht modifiziert, müssen also die gleiche Neigung und Kugelposition darstellen.

Um das umzusetzen boten sich 2 Möglichkeiten:
Entweder für jeden Ort einen eigenen Rechner einzusetzen. Da Unitys Physik eher auf Geschwindigkeit denn Präzision setzt, müssten wir aber zusätzlichen Aufwand betreiben um die Kugelposition auf allen Rechnern zu synchronisieren. Dazu kommen die Eingaben der Spieler an den Lolliplattformen, die wieder an alle PCs übermittelt werden müssten.

Oder ein Rechner bespielt alle 5 Orte und verarbeitet alle Inputs. Wir entschieden uns für diesen Weg. Auch hier half die Unity-Community mit zwei Skripten. Eines, das nach Programmstart das Fenster rahmenlos über 5 Monitore verteilt. Ein weiteres, um die Eingaben der 2 Touchscreens der Lolliplattformen an einem Rechner zu verarbeiten. (Unsere Touchscreens simulieren Mäuse. Unity unterstützt von sich aus nur eine Maus – was auf eine Limitierung von Windows zurück zu führen ist, die dieses Skript umgeht)

Der Soundraum sowie die Spielewelt und die Statusauswertung die abgefilmt ( unten ) und zu einem großen Output für 5 Monitore zusammengesetzt werden ( oben )
Der Soundraum sowie die Spielewelt und die Statusauswertung die abgefilmt (unten) und zu einem großen Output für 5 Monitore zusammengesetzt werden (oben)

Die Spielesounds müssen an konkreten Positionen im Raum abgespielt werden. So bekommen die Spieler der Lolliplattformen akustisches Feedback zu ihren Aktionen. Die Kugel soll hörbar über den Köpfen der Spieler hinweg rollen wenn sie die Leinwand wechselt. Um das in Unity umzusetzen müssen wir die Töne in einem von der Spielwelt unabhängigem 3D Raum positionieren. Die Position bestimmt wo der Ton zu hören ist und kann in Echtzeit verändert werden, quasi ein Panning im 3D-Raum. Eine andere Möglichkeit einen Sound an einen konkreten Lautsprecher zu senden bietet Unity nicht. Um das Rollen der Kugel über mehrere Lautsprecher zu verteilen ist das ideal. Da man auf 7.1 Kanäle beschränkt ist können größere akustische Installationen hier an ihre Grenzen kommen. Uns reicht das.

3D-Sensor

Nach ersten Tests mit einem Android-Handy und TouchOSC machten wir uns auf die Suche nach einem geeigneten Sensor um die Neigung der Handlungsplattform zu erfassen. Generell verwendet man hier eine Kombination aus Beschleunigungssensor, Drehratensensor und Magnetometer.

Wir entschieden uns für den Bosch BNO055. Der Chip besitzt neben den 3 genannten Sensoren auch die Rechenlogik um daraus unter anderem die konkrete Neigung zu berechnen. Bosch nennt das „Sensor Fusion“. Das spart uns Zeit, da wir die Berechnungen nicht selbst implementieren müssen.

Der Sensor wird auch mit Code-Beispielen als Arduino-Shield angeboten. Nach dem Auspacken mussten wir aber feststellen, dass das Shield entgegen dem Datenblatt nicht ohne weiteres kompatibel war zu unserem Arduino Mega. Hier gab es über die Jahre verschiedene Revisionen in denen das Pinlayout des Arduino verändert wurde. Mit Kabelbrücken ließ sich das Problem beheben. Dies funktionierte sogar mit einem alten Arduino Duemilanove, die im Datenblatt des Shields gar nicht aufgeführt waren.

 

Beitrag von Thomas Steinbach

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.