Jeder, der schon einmal eine App für mobile Geräte oder auch eine responsive Website erstellt hat, kennt die Herausforderung, die entstehen kann, wenn man ein Interface erstellen muss, das „mobile-friendly“ sein soll. Dabei heißt es oft: Viele verschiedene Seitenverhältnisse und Bildschirmauflösungen – und ein User Interface, das überall gut aussehen soll.

Während man sich in CSS dazu Prozentangaben für die Größe der Elemente bedient, geht das in Unity nicht so einfach. Oft kämpft man lange mit der Positionierung und Größe herum, nur um bei einem Wechsel auf eine andere Auflösung wieder alles durcheinander vorzufinden.

Im Folgenden sind daher zwei Tipps angeführt, wie man ein responsives Interface für Unity Apps erstellt.

Tipp 1: Die richtigen Einstellungen der Canvas

Die UI-Canvas ist das zentrale Element eines User Interfaces in Unity. Ohne eine Canvas kann kein UI-Element existieren, also wird beim Erstellen eines solchen gleich eine Canvas miterstellt, falls es in der Szene noch keine gibt. Standardmäßig sieht eine neu erstellte Canvas folgendermaßen aus:

Füllt man die Canvas nun mit UI-Elementen, sieht man im Play Mode schon nette Ergebnisse – bis zu dem Zeitpunkt, an dem man die Auflösung einmal ändert. Dabei zerfallen die Größenverhältnisse und man muss danach wieder einige Zeit aufwenden, bis man das ursprüngliche Aussehen wiederhergestellt hat. Das liegt an einigen Komponenten, die aus irgendeinem Grund ziemlich unbrauchbare Defaultwerte haben und die man deshalb am besten gleich zu Beginn ändern sollte, nämlich:

• Falls der Render Mode nicht auf „Screen Space – Overlay“ gestellt ist, ändert die Einstellung dementsprechend. Der Render Mode einer Canvas kann „Screen Space – Overlay“, „Screen Space – Camera“, oder “World Space” sein. Bei ersterem wird die Canvas einfach über die gesamte Szene drübergerendert. Zweiteres verhält sich ähnlich, nur dass das Interface über das Bild einer Kamera in der Szene gelegt wird. World Space, zu guter Letzt, bedeutet, dass die Canvas gar nicht über alles drübergelegt wird, sondern frei im 3D Raum positionierbar ist.

Wenn man nicht gerade einen speziellen Grund für etwas anderes hat, ist „Screen Space – Overlay“ die beste Wahl.

• Die Option Pixel Perfect zwingt die Elemente dazu, sich genau an den Pixeln auszurichten. Ob man das möchte ist Geschmackssache und hat keinen Einfluss auf die Responsiveness, denn der einzige Unterschied ist, dass bei eingeschaltetem Pixel Perfect die Kanten schärfer sind. Werden Elemente aber gedreht oder animiert können seltsame Artefakte entstehen.
  

• Hat man nur eine Canvas, kann die Sort Order ignoriert werden. Sie bezieht sich nur auf die Renderreihenfolge innerhalb des Layers, und da die Canvas standardmäßig im UI Layer (siehe rechts oben im Inspektor) ist, liegt sie sowieso über allen anderen sichtbaren Elementen in der Szene.

Target Display ist ziemlich selbsterklärend, und zusätzliche Shader Channels wird man in den meisten Fällen ebenfalls nicht brauchen, daher können diese Parameter ebenfalls ignoriert werden. Auch die Graphic Raycaster Komponente können wir außen vor lassen, doch die wichtigste Einstellung befindet sich in der Canvas Scaler Komponente:

• Der UI Scale Mode sollte unbedingt auf „Scale with Screen Size“ geändert werden. Das bewirkt, das die ganze Canvas überhaupt erst auf Änderungen der Bildschirmgröße reagiert. Scale Factor und Reference Pixels können bei 1 und 100 bleiben, die Reference Resolution habe ich in diesem Fall einfach auf ein HD-Hochformat gesetzt.

Eine richtig konfigurierte Canvas sieht dann so aus: (Die Rect Transform Werte ändern sich mit der Zielauflösung)

Tipp 2: Verwenden von Anchor Points

Nachdem die Canvas jetzt mit der Bildschirmgröße skaliert, müssen sich nur noch die Elemente darin richtig verhalten. Dies kann man über die Anchor-Einstellungen erreichen.

Ich habe als Beispiel einfach einen blauen Button erstellt. Ist er ausgewählt, erscheinen in der Mitte der Canvas vier kleine Pfeilchen, die ineinander zeigen. Das bedeutet, dass sich der Button momentan genau an der Mitte des Bildschirms ausrichtet. Das ist noch nicht ganz optimal, weil der Offset zum Rand dadurch nicht in Betracht gezogen wird. Klickt man auf das eingekreiste Symbol im Inspektor, erscheinen einige weitere Möglichkeiten, wie man die Anchor Points noch ausrichten kann.

Für ein responsives Interface wichtig sind hier die „Stretch“-Optionen in der rechten Spalte und der untersten Zeile. Diese verschieben die Ankerpunkte (die Pfeilchen) an den Rand der Canvas, und das Element wird dabei je nach der gewählten Einstellung mitskalieren.

Die Anchors können auch mit der Maus an beliebige Stellen verschoben werden, falls man ein sehr verschachteltes Interface oder besondere Anforderungen hat. Ich habe hier als Beispiel 10 Buttons auf einer Hochformat 16:9 Canvas. Die Anchor Points sind auf Bottom und Stretch gesetzt (auf dem oberen Bild die vierte Option von oben in der rechten Spalte) und orientieren sich daher an der unteren Bildschirmkante. Mit den oben gewählten Einstellungen der Canvas bleiben die Buttons auch in einem 3:2 Format an der gewünschten Stelle und skalieren mit – und sogar bei einer Änderung auf ein Querformat wie 16:9 skalieren die Buttons noch und verschwinden nicht aus dem Bild.

The post Responsive User Interfaces in Unity-Apps appeared first on Mobile USTP MKL.

Konzept

Create yAR own Adventure ist ein Platformer, bei dem man sich sein eigenes Level „in echt“ baut – man wählt aus einer Auswahl von bunten Kartonstücken aus und klebt diese an eine Wand oder ein Whiteboard. Das Spiel läuft als App am Smartphone, und sobald man die Kamera auf die Wand richtet und das Spiel die Kartonstücke erkennt, werden sie am Handy zu Plattformen, auf der der spielbare Charakter, der Pirat EARrrl, hüpfen und so im Level verstreute Münzen erreichen kann.

Man spielt also quasi gleichzeitig auf einer „echten“ und auf einer „digitalen“ Ebene. Der Pirat und die Münzen befinden sich auf der digitalen Ebene, und die Plattformen auf der echten. Durch alleiniges Herumbewegen des Smartphones können die Münzen also nicht erreicht werden, weil sie sich genau wie der Pirat immer mit der Kamera mitbewegen. Die Plattformen müssen also so platziert (oder gezielt von verschiedenen Standpunkten anvisiert) werden, dass der Pirat darauf springen und von dort aus dann die Münzen erreichen kann.

Umsetzung

Das Spiel wurde in Unity mit Hilfe der AR-Library Vuforia und dem Unity Asset „Corgi Engine“ programmiert.

Eines der zur Auswahl stehenden Kartonstücke.

Die Kartonstücke bestehen aus Buntpapier, das mit schwarzen Mustern bemalt ist, um Vuforia möglichst viele Erkennungsfeatures zu bieten, damit das Tracking gut funktioniert. Die Kartonstücke wurden eingescannt und in eine Vuforia-Datenbank eingepflegt, die in Unity importiert wurde. Sobald die App eines der Kartonstücke erkennt, platziert sie darauf ein gleich geformtes 3D-Objekt, auf dem der Charakter landen kann.

Das größte Problem bei der Umsetzung des Konzepts war nun, dass der Charakter auch wirklich auf den Plattformen stehen kann – was mit den Standard-Physics-Komponenten aus Unity nicht funktioniert, weil der Charakter die Plattform im 3D Raum berühren – also die gleiche z-Koordinate haben muss wie die Plattformen auch – um nicht vor oder hinter der Plattform runterzufallen, sobald der Spieler oder die Spielerin sich nach vorne oder hinten bewegt.

Hierfür wurde die Corgi Engine, ein kostenpflichtiges Unity-Asset, verwendet, das die Unity-Physics umgeht und stattdessen zur Kollisionserkennung Raycasts benutzt. Dadurch findet Überprüfung nur auf einer Ebene statt und es spielt keine Rolle, wie nah der Spieler am Kartonstück ist – ist er nur wenige Zentimeter entfernt, ist die Plattform im Spiel einfach größer.

Ein Screenshot aus der App.

Future Work

Eine interessante Gameplay-Erweiterung wäre, die Kartonstücke noch mehr ins Spiel einzubeziehen. Derzeit dienen sie einfach nur als Boden – denkbar wäre aber z.B. ein Kartonstück in Form einer Wasserschüssel. Dreht man das Kartonstück dann um, fließt im Spiel selber dann Wasser aus der Schüssel, an dem der Pirat nicht vorbeikommt. Auch Plattformen mit zusätzlichen Hindernissen wie Stacheln, die man durch Drehen der Kartonstücke beeinflussen kann, könnten eingebaut werden – das könnte u.U. sogar ein Multiplayer-Aspekt sein.

Konzept von Corinna Gerhold, Florian Taurer, Adam Gina & Magdalena Boucher

Vuforia: https://www.vuforia.com/

Corgi Engine: https://assetstore.unity.com/packages/templates/systems/corgi-engine-2d-2-5d-platformer-26617

The post Create yAR own Adventure – Eine Augmented Reality Platformer App appeared first on Mobile USTP MKL.

In Sachen Spieleentwicklung für verschiedene Plattformen sind Game Engines wie Unreal Engine und Unity wohl die am meisten genutzten Werkzeuge im professionellen Bereich. Mit den „großen“ Game Engines ist so gut wie jede Spieleidee, von simplen Clicking Games bis zu großen MMOs (Mass Multiplayer Online Games), umsetzbar.

Dieses Potential bringt natürlich einen Nachteil mit sich: Es erfordert verhältnismäßig viel Vorwissen, um es zu einem guten Ergebnis zu bringen – die Einstiegshürde ist für unerfahrene Programmierer also relativ hoch.

Corona setzt genau an diesem Punkt an. Neben den Cross-Platform Publishing Möglichkeiten – eine Codebasis schreiben, und damit die App für iOS, Android, Amazon Fire, Desktops oder sogar Apple-, Fire- und Android-TV builden (seit kurzem unterstützt Corona auch HTML5-Exporting für Browser) – wirbt es damit, besonders leicht zu lernen und einsteigerfreundlich zu sein.
Das erreicht das Framework durch die Skriptsprache Lua, in der alle Corona-Apps geschrieben werden. Lua ist schnell, kostenlos, open-source, und hat eine einfache Syntax. Damit ist es vor allem für Rapid Prototyping und für Leute mit geringen Programmierkenntnissen gut geeignet.

Unlimited. Powerful. Free.

Verspricht Corona – zusätzlich zu seinen cross-platform Möglichkeiten und der Lua-Basis bietet es viele Plugins an, die die Core-Funktionalitäten um Features wie In-App Werbung oder Analytics erweitern. Sollte eine Funktionalität tatsächlich weder in Corona selbst, noch in einem Plugin enthalten sein, lassen sich zahlreiche Libraries und APIs über das Framework aufrufen.
Damit bietet es schon ein großes Spektrum an Möglichkeiten, aber ganz so unlimited ist die „Game Engine“ dann doch nicht – sie beschränkt sich nämlich ausschließlich auf 2D-Apps.

Workflow

Corona ist einfach zu installieren. Einen Account muss man sich leider anlegen, aber das ist auch schon die einzige Hürde. Beginnt man ein neues Projekt, erstellt Corona automatisch einige Files und eine grobe Projektstruktur. Öffnet man das Projekt, erscheint der Corona Simulator (eine Live-Vorschau der App, wie man sie auch aus anderen Entwicklungsumgebungen kennt), ein Output-Fenster, und ein File Explorer. Corona bringt keinen eigenen Code-Editor mit sich, stattdessen kann man seinen bevorzugten Editor verwenden. Sobald man eine Änderung im Code speichert, wird das Ergebnis im Simulator angezeigt. Corona bietet ebenfalls ein Live-Building System an, bei dem die App auf die angeschlossenen Endgeräte deployed und wie im Simulator bei jeder Codeänderung geupdated wird.

Corona bietet in seinem Marketplace besonders viele sogenannte Templates an. Dabei handelt es sich um fertige Projekte, die man als Basis für sein eigenes Spiel verwenden kann – von gratis Templates für Flappy Bird oder einfache Jump’n’Runs bis zu Tower Defense Templates um 4000 Dollar findet man dort einiges, auf dem man aufbauen kann, was vor allem Anfänger durch schnelle Erfolge motiviert.

Links

https://coronalabs.com/

https://www.lua.org/

The post Corona – Ein einfaches 2D Cross-Platform Game Framework appeared first on Mobile USTP MKL.

Spine ist eine Animationssoftware, deren Funktionsweise und Workflow speziell auf das Erstellen von 2D-Animationen für Videospiele ausgerichtet sind. Da vor allem Mobile Games hinsichtlich Speicher und Rechenleistung im Vergleich zu PC- oder Konsolenspielen eher begrenzt sind, und Grafiken bei vielen Spielen einen großen Teil des Speicherplatzbedarfs bilden, bietet Spine gerade dabei große Vorteile, von denen einige im Folgenden kurz vorgestellt werden sollen:

Kleinere Spritesheets

Ein steuerbarer Hauptcharakter in einem Spiel hat üblicherweise zumindest eine Walk- und eine Idle-Animation – also eine Animation, die dann abgespielt wird, wenn der Charakter einfach nur herumsteht. Dazu kommen dann vielleicht noch Jump-, Attack-, Hit-, Die- oder sonstige Animationen.

Bei klassischer Frame-by-Frame-Animation würde es für jede dieser Animationen ein Spritesheet geben, auf dem alle Frames der jeweiligen Animation zu sehen sind. Bei einer Animation mit der Dauer einer Sekunde sind das zwischen 10 und 30 Einzelframes – dementsprechend groß werden die Spritesheets und in weiterer Folge der Speicherbedarf.

In Spine wird ein zu animierendes Objekt aus einzelnen „Körperteilen“ zusammengesetzt, und ähnlich wie beim Rigging eines 3D-Modells mit einem „Skelett“ versehen. Dieses Skelett, an dem die einzelnen Attachments (Also die Körperteile) hängen, kann dann beliebig posiert und animiert werden. Spine interpoliert zwischen den einzelnen Keyframes und Posen und braucht für beliebig viele verschiedene Animationen genau ein Spritesheet mit den Körperteilen des Objektes. Zusätzlich dazu sind die Animationen auch um einiges flüssiger als Frame-by-Frame-Animationen.

Aus diesem 124KB großen Spritesheet unseres Hauptcharakters in unserem Semesterprojekt „Save the Geese“ setzen sich 5 verschiedene Animationen zwischen 30 und 200 Frames zusammen.

Wiederverwenden von Animationen
Ist ein Rig eines Charakters in Spine mit seinem Skelett und all seinen Körperteilen einmal aufgebaut, können diese ausgetauscht werden, zum Beispiel um den Charakter mit verschiedenen Rüstungen oder Waffen darzustellen. Diese „Skins“ können jederzeit gewechselt oder kombiniert werden, auch während einer Animation.

Überlagern von Animationen
Ein weiterer großer Vorteil von Spine ist die Möglichkeit, Animationen zu überlagern – ein Charakter könnte zum Beispiel per Knopfdruck mit einer Waffe schießen, während er gleichzeitig läuft, ohne dabei die Lauf-Animation zu unterbrechen. Dies ist bei Frame-by-Frame-Animation so gut wie nicht möglich, da man dabei eine Lauf-Animation, eine Schießen-Animation und eine Laufen-und-Schießen-Animation bräuchte, und wieder individuelle Spritesheets dazu.

Prozedurale Animation
Eine der größten Stärken von Spine ist auch die Möglichkeit, Animationen parallel zur Laufzeit zu manipulieren. Eine Open Source Spine-Unity-Runtime, die nur in das Unity Projekt importiert werden muss, ermöglicht es, per Code auf alle Einzelteile eines Charakter-Rigs zuzugreifen. Dadurch lassen sich Effekte erzielen, die anders nur mit großem Programmieraufwand realisiert werden können, wie etwa dass der Charakter mit seinem Blick der Maus folgt, immer in die Richtung eines Gegners schießt, sich passend zur Neigung eines Objektes, auf den der Charakter steht, mitbewegt, Objekte richtig aufhebt und herumträgt und vieles mehr.

Spine entstand anfangs aus einem Kickstarter-Projekt und wird ständig weiterentwickelt. Es gibt auch ein Forum, in dem die Entwickler und Communitymitglieder auf Fragen antworten.
So viele Vorteile das Animationsprogramm auch bietet – es ist leider nicht ganz gratis. Der Preis für eine Professional-Lizenz, mit der man Spine auf zwei Rechnern installieren darf, beträgt ungefähr 300 Dollar. Es gibt zwar eine Essential-Version um knapp 70 Dollar, die aber kein Meshing (die Möglichkeit des Verformens der einzelnen Grafiken, das optisch einen großen Unterschied macht) unterstützt und somit nur für bestimmte Projekte sinnvoll ist.

Links:

http://esotericsoftware.com/

http://esotericsoftware.com/spine-unity

The post Spine: 2D-Animation für Unity appeared first on Mobile USTP MKL.

Idee / Motivation

Die Idee zu diesem Prototypen entstand durch ein Spiel auf einer Art Feriencamp: Die Jugendlichen wurden in Gruppen eingeteilt und bekamen jeweils ein Foto, das irgendein Objekt aus einer ungewöhnlichen Perspektive zeigte. Anders als bei vielen Schnitzeljagden dieser Art war es aber nicht das Ziel, den abgebildeten Gegenstand zu finden, sondern herauszufinden, von welchem Ort aus das Foto aufgenommen worden war – man verfolgte sozusagen als Gruppe an Detektiven die Spur des Verbrechers – und am richtigen Ort war der Hinweis zum nächsten Ort versteckt. Die Gruppe, die als erste den Zielort gefunden hatte, gewann.

Der ursprüngliche Plan für die Web-App war, dass die Spieler einer vorgeschriebenen Geschichte folgen sollten, die von einem (evtl. animierten) Charakter am Bildschirm erzählt wird, und dass diese Geschichte pro gefundenem Ort etwas weitergeht, bis der gesuchte „Verbrecher“ gefasst (also der letzte Ort gefunden) wird.

Da dies den Nutzungskontext der Anwendung nicht zuletzt wegen der zwingenden Bindung an einen einzigen Ort aber extrem einschränken und die Erstellung von neuen Schnitzeljagd-Routen für Gruppenleiter sehr kompliziert machen würde, wurde das Konzept abgewandelt und auf die Einbindung einer Geschichte verzichtet.

Funktion und Umsetzung

Die Leiter der Gruppen und „Hoster“ der Schnitzeljagd-Route erstellen zunächst einen beliebigen Kurs, dem ihre Gruppen später folgen werden, indem sie ihn zunächst mit ihrem Smartphone selbst entlanglaufen und Orte fotografieren. Dabei speichert die App das Foto (in Sepiafarben, zur leichten Erhöhung der Schwierigkeit) und den dazugehörigen GPS-Standort in einer Datenbank. Die Stationen werden nummeriert, und sobald der Kurs fertig ist, bekommt er eine fünfstellige ID-Nummer zugewiesen.

Danach können die Gruppen mit der Schnitzeljagd beginnen, indem sie die ID des Kurses und einen Gruppennamen eingeben. Daraufhin wird ihnen das erste Bild angezeigt, dessen Aufnahmeort gesucht werden soll. Sind die Gruppenmitglieder der Meinung, den Ort gefunden zu haben, können sie ihre Position überprüfen lassen. Dabei wird die aktuelle Position des Smartphones mit der in der Datenbank gespeicherten Position verglichen. Ist die Entfernung kleiner als 5 Meter, gilt der Ort als gefunden. War die Position falsch, verschwindet der Überprüfen-Button für eine Zeit, damit man nicht einfach darauf los raten kann.

So folgen die Gruppen den Hinweisen um die Wette. Wird der letzte Ort gefunden, wird eine Siegesmeldung angezeigt.

Future Work

Um den kompetitiven Aspekt der App zu verbessern, wäre es sinnvoll, die Zeit zu erfassen, die jedes Team für die Fertigstellung des Kurses benötigt hat, und diese am Ende auf einer Bestenliste anzuzeigen. Was das Spiel ebenfalls verbessern würde, wäre eine Möglichkeit, die einzelnen Gruppen ihre Jagd an verschiedenen Orten beginnen zu lassen, damit nicht alle nebeneinander laufen oder zeitversetzt starten müssen. Dies bringt jedoch die Schwierigkeit mit sich, dass die Routen als Kreis aufgebaut sein müssen, um sicherzustellen, dass alle eine gleich lange Strecke laufen müssen – damit fiele aber die Möglichkeit eines richtigen „Zielorts“ weg.

Momentan setzt das Spiel voraus, dass alle Gruppenmitglieder die Umgebung, in denen die Hinweise gesucht werden müssen, ausreichend kennen, um mit den aufgenommenen Bildern etwas anfangen zu können. Eine Implementierung eines Kompasses wäre hier eine gute Hilfestellung, damit Schnitzeljagden auch in unbekannteren Umgebungen gespielt werden können.

Links

Geolocation API

The post Mobile Detektivjagd appeared first on Mobile USTP MKL.