SkyRoads

Aus toolbox_interaktion
Wechseln zu: Navigation, Suche

Ziel war es, SkyRoads, den Spieleklassiker von 1993, nachzubilden (offizielle Seite). Um der Interaktion gerecht zu werden, sollte der Spieler - anders als im Original - jedoch nicht mit der Tastatur spielen, sondern stattdessen mit seinem Körper selbst das Geschehen auf dem Bildschirm kontrollieren. Will der Spieler also einem Hindernis seitlich ausweichen, muss er zur Seite gehen. Um Schluchten zu überwinden, muss der Spieler springen.

Übersicht

Übersichtsbild.png

Umsetzung

Für die Erstellung des Spiels selbst wurde Unity als GameEngine gewählt, da hier mehrere Sprachen, unter anderem C# unterstützt werden. Zur Erfassung des Spielers im dreidimensionalen Raum wird eine Kinect eingesetzt.

Programmieren des Spiels

Aufgrund einiger Eigenschaften im Originalspiel, wie einer festen seitlichen Ablenkung bei Sprüngen und dem Abprallen auf bestimmtem Untergrund, war es nicht möglich, das Original zu verwenden. Dies hätte nämlich zur Folge, dass sich die Spielfigur anders verhält, als der reale Spieler. Eine Neuimplementierung war daher erforderlich.

Aufbau der Level

im Original nicht spielbares Demolevel
Collider eines Tunnels

Um so nahe wie möglich am Original zu bleiben, sollten die Level von Bluemoon übernommen werden. Den Aufbau der Binärdatei hatte glücklicherweise bereits ein anderer Nutzer veröffentlicht. An dieser Stelle musste also nur noch ein Programm geschrieben werden, das die Daten aus den Leveldateien ausliest. Als nächstes mussten sie in Unity nachgebaut werden. Hierzu wurden die Basisobjekte, also Quader und Tunnel nachgebaut. Beim Laden des Levels mussten sie dann nur noch an den richtigen Stellen kopiert werden.

Spielelogik und Kollisionserkennung

Einen Teil der Spielelogik wird einem von Unity bereits abgenommen, da regelmäßig neue Frames gezeichnet werden. Man muss daher nur noch Funktionen schreiben, die auf Nutzereingaben reagieren, sowie Ereignisse im Spiel (etwa Kollisionen) abfangen. Bei der Kollision muss unterschieden werden, welche Position das Raumschiff relativ zum anderen Objekt einnimmt. Bei einem Frontalzusammenstoß wird je nach Fluggeschwindigkeit entweder das Raumschiff komplett abgebremst oder das Spiel neu gestartet. Landet das Raumschiff auf einem Quader, bleibt es einfach darauf liegen. Bei einer seitlichen Kollision wird das Schiff abgebremst und gleichzeitig zurück auf die richtige Bahn geschoben. Um bei einer Röhre unterscheiden zu können, ob es sich um einen Frontalzusammenstoß handelt, oder die Röhre nur leicht seitlich gestriffen wurde, wurde die Röhre in mehrere Teilsegmente zerlegt (siehe Bild), die jeweils einen eigenen Collider erhielten. Die äußeren Collider führen dann in der Programmlogik zu einer seitlichen Verschiebung, sodass das Raumschiff anschließend neben oder in der Röhre ist. Der zentrale Collider setzt je nach Fluggeschwindigkeit diese auf 0, oder startet das Level neu. Auch die Quader mussten so zerlegt werden, um die Art des Zusammenpralls zu erkennen.

Erfassung des Spielers

Zur Erfassung des Spielers wurde eine Kinect verwendet. Neben dem Zugriff auf die Kamerabilder, erstellt die Kamera automatisch ein Skelett des Spielers und ermittelt dessen Koordinaten. Besonders interessant für uns war der Körperschwerpunkt, weshalb wir die Koordinaten des sogenannten "HIP_CENTER" als Position unseres Spielers verwendeten.

Zum Einlesen der Skelettposition und der schlussendlichen Ausgabe der Skelettpositionen über OSC diente uns Processing als einfache Programmierumgebung. Zum Einlesen des Kinect Skelettes diente uns die OpenNI Bibliothek. Zur Ausgabe wurde die oscP5 Bibliothek genutzt. Wurde ein Spieler von der Kamera erfasst, werden von dem Processing Sketch dessen Koordinaten ermittelt und direkt per OSC weiterversendet.

Zudem wurde ein Testprogramm erstellt, welches uns auch ohne Kinect das Versenden von simulierten OSC Nachrichten ermöglichte.

Integration der interaktiven Steuerung

Wie im vorangegangen Kapitel erwähnt, erfolgt die Kopplung von Processing und Unity über OSC. Das hat den Vorteil, dass die Aufgaben auf zwei Rechner verteilt werden konnten und relativ einfach über das Netzwerk die Positionsdaten geschickt werden konnten. Zudem konnte man so geschickt das Spiel mittels eines Standardprotokolls von der Steuerung trennen.

Verwendete Programmversionen

  • Unity 4.5.3
  • Processing 2.2.1
  • OpenNI 1.96
  • oscP5 update 23.12.2012

Quellcode

Quellcode Unity

Quellcode Processing (Kinect & Test)