1) Kostenlos

Vor allem wenn man sich noch nicht sicher ist, sollte man auf Kostenloses zurückgreifen, da professionelle Game Engines schon mal ein paar 100 bis 1000 Euro kosten können.

2) Java basiert

Für den Anfang ist es einfacher, in der gleichen Programmiersprache wie bei Android zu bleiben, da so einem viele Probleme erspart werden.

3) Open Source

Eigentlich müsste es nicht direkt Open Source sein, aber ich persönlich bin ein Fan von solchen Projekten, weil bei diesen meistens viele gute Leute dabei sind und oft so nette Addons etc. entstehen.

4) Gute Community / Anleitungen / Dokumentation

Damit man schnell in die Materie hineinkommt ist eine gute Community bzw. Anleitungen und Dokumentationen nie von Nachteil.

Im Grunde kommen so zwei Game Engines heraus, die AndEngine und libGDX. Schauen wir uns diese genauer an.

AndEngine

Die erste interessante Game Engine trägt dem Namen AndEngine und ist direkt für Android entwickelt worden. Sie bietet einen Grundmodul und sehr viele einzelne Erweiterungen an. Hier eine kurze Liste:

• Augmented Reality
• Live Wallpaper
• MOD Player
• Multiplayer
• Multi Touch
• Physics Box2D
• Robotium
• Scripting
• Scripting Generator
• SVG Texture Region
• Texture Packer
• TMX Tiled Map

Sowohl das Grundmodul, als auch die Erweiterungen werden als einzelne Projekte angeboten, die in die IDE (z.B. Eclipse) als Libraries eingebunden werden müssen. Hier muss man jedoch aufpassen, da es mittlerweile drei Branches gibt: GL ES 1, GL ES 2 und GL ES2-AnchorCenter. Vor allem bei den letzten zwei muss man aufpassen, da der einzige Unterscheid ein anderes Koordinatensystem ist und wenn das Basismodul und die Erweiterungen nicht übereinstimmen, kann es zu falschen Positionierungen kommen.

Die Einbindung in Android ist sehr einfach. Sobald man die Libraries eingebunden hat, muss man nur noch die SimpleBaseGameActivity statt der normalen Activity einbinden. Diese bietet die drei Standardfunktionen onCreateEngineOptions() (alle wichtigen Einstellungen z.B. Camera, Ausrichtung etc.), onCreateResources() (hier passiert das Laden aller Ressourcen: Grafiken, Audio etc.) und  onCreateScene() (hier passiert das Rendern) an.

Die Darstellung passiert in sogenannten Scenen. In diesen können dann einzelne Elemente dargestellt werden. Ein Recheck kann dann zum Beispiel mit

final Scene scene = new Scene();
Rectangle firstRect = new Rectangle(pX, pY, 180, 180, this.getVertexBufferObjectManager());
scene.attachChild(rectangleGroup);

dargestellt werden. Wie man sieht, alles ist sehr einfach gehalten.

Links:

• AndEngine – Beispiel -> https://github.com/nicolasgramlich/AndEngineExamples
• Tutorials  -> http://www.matim-dev.com/tutorials.html)

libGDX

Einen etwas anderen Weg gehen die Entwickler von libGDX. Dies ist im Grunde eine Cross Plattform Game Engine, die in Java programmiert ist. Bis jetzt werden folgende Plattformen unterstützt:

• Windows
• Linux
• Max OS X
• Android (+2.2)
• BlackBerry
• iOS
• Java Applet (requires JVM to be installed)
• Javascript/WebGL (Chrome, Safari, Opera, Firefox, IE via Google Chrome Frame)

Man sieht also, dass man hier einen Vorteil gegenüber von AndEngine hat, jedoch ist das Einrichten und der Einstieg dadurch ein bisschen komplizierter.

libGDX geht so vor, dass man einen Basisprojekt hat, in dem die ganze Programmierung stattfindet und dann gibt es einzelne Projekte für die Endgeräte (z.B. Android und Desktop), die unterschiedlich verlinkt werden müssen und in den unterschiedlichsten Sachen eingestellt werden müssen. Da dies am Anfang sehr verwirrend sein kann, hat AurelienRibon eine grafische Oberfläche programmiert, die einem die ganze Arbeit abnimmt und dann nur noch die Projekte in die IDE eingebunden werden müssen. Man findet sie unter https://github.com/AurelienRibon/gdx-setup-ui.

libGDX geht auch hier einen andren Weg und bietet die ganze Funktionalität nur in einer jar und nicht wie AndEngine bei der verschiedene Erweiterungen einzelne Projekte sind.

Wenn es um das Programmieren eines Spiels geht, sind die zwei Objekte Game und Screen wichtig.

Game ist eine abstrakte Klasse, die in der Hauptkasse implementiert werden muss:

public class myNewGame extends Game {

Diese ist für die ganze Logik des Spiels zuständig. Ähnlich wie bei AndEngine, wo es Scenen gibt, sind es bei libGDX Screens, wo die ganze Darstellung passiert. In diesem Fall ist Screens ein Interface, das eingebunden werden muss.

public class GameScreen implements Screen {

Ein Rechteck kann man dann zum Beispiel mit

shapeRenderer.rect(x, y, width, height);

darstellen.

Links:

• Demos -> https://github.com/libgdx/libgdx/tree/master/demos
• Tutorials -> http://obviam.net/index.php/table-of-contents/

Box2D

Für Hardcore-Fans, die gerne alles selber Programmieren, kann ich doch zumindest eine Library empfehlen und zwar Box2D. Bei Box2D handelt es sich um eine Physics Engine, die hauptsächlich zwei Bereiche abdeckt, Collision Detection und Physics, die oft sehr viel Wissen voraussetzen. Die eigentliche Library ist in C++ geschrieben (http://box2d.org/) jedoch gibt es auch einen Java Port, wie zum Beispiel JBox2D (http://www.jbox2d.org/)

Collision

• Continuous collision detection
• Contact callbacks: begin, end, pre-solve, post-solve
• Convex polyons and circles.
• Multiple shapes per body
• One-shot contact manifolds
• Dynamic tree broadphase
• Efficient pair management
• Fast broadphase AABB queries
• Collision groups and categories

Physics

• Continuous physics with time of impact solver
• Persistent body-joint-contact graph
• Island solution and sleep management
• Contact, friction, and restitution
• Stable stacking with a linear-time solver
• Revolute, prismatic, distance, pulley, gear, mouse joint, and other joint types
• Joint limits, motors, and friction
• Momentum decoupled position correction
• Fairly accurate reaction forces/impulses

Die große Herausforderung ist, dass man sich selber um das Rendern kümmern muss.

Links:

• Einführung -> http://www.spectrumcoding.com/tutorials/android/2013/08/01/android-gl-box2d.html

The post Open Source 2D Game-Engines für Android appeared first on Mobile USTP MKL.

In diesem Paper wird das Konzept und ein Prototyp eines Step-by-Step basierten Inhouse-Navigationssystems vorgestellt, welches aus technischen und finanziellen Gründen auf eine kontinuierliche Positionserkennung verzichtet und mit vergleichsweise geringem Aufwand an neuen Orten eingeführt werden kann. Im Vorfeld wurden in einer intensiven Recherche bestehende Systeme zur Positionsbestimmung in Gebäuden analysiert und auf ihre Zuverlässigkeit und Flexibilität untersucht. Diese Parameter führten zur Entscheidung, die Positionsbestimmung auf der Basis von künstlich angebrachten, visuellen Landmarks in Form von QR (Quick Response)-Codes zu realisieren. Eine mögliche Erweiterung durch Echtzeit-Lokalisierungssysteme wird jedoch nicht ausgeschlossen. Die Routingberechnung basiert auf dem Setzen von Knoten an Start-, Endpunkten und Abzweigungen sowie Kanten, die diese Knoten verbinden. Jeder Kante wird dabei nach Länge und Art eine Gewichtung zugeordnet, aufgrund derer mit Hilfe des Dijkstra-Algorithmus der kürzeste Weg zwischen zwei Knoten berechnet wird. Weitere Parameter bieten die Möglichkeit, auf die Routenberechnung einzuwirken und ermöglichen so eine Prioritätensetzung und im Bedarfsfall Barrierefreiheit bei der Navigation. Mit Hilfe eines einfachen Backends für die Erstellung eines Routing-Netzwerkes für ein neues Gebäude, können die Einrichtungskosten auf einem Minimum gehalten werden. Durch Klicken in einer Karte des Gebäudegrundrisses können schnell Wegzüge erstellt und durch Auswahl aus vordefinierten Knoten- und Kantenkategorien einfach parametrisiert werden. Um die Navigation anhand der berechneten Route für Smartphone-BenutzerInnen verständlich zu machen, wird die Route in kleinen, übersichtlichen Schritten (Steps) dargestellt, die sowohl auf einer maßstabsgetreuen Karte, wie auch als dynamisch generierter Text angezeigt werden. Die Zielsuche wird dabei durch eine Auswahlliste anhand von Knotenkategorien (Büro, Seminarraum, WC, …) erheblich erleichtert. Anhand eines Sets von Usabilitytests wird gezeigt, dass das System, bestehend aus den QR-Codes zur Positionsfindung und einer Smartphone-Anwendung zur Navigation, von BenutzerInnen ad hoc verstanden wird und zur Navigation innerhalb von den BenutzerInnen unbekannten Gebäuden eingesetzt werden kann.

Publikation und Präsentation stehen zum Download bereit:

Paper Forum Medientechnik 2013

Präsentation Forum Medientechnik 2013

Autoren

Ewald Wieser, Tomas Kasanicky, Florian Schiesterl, Bernhard Griessler, Christoph Fabritz, Kerstin Blumenstein, Grischa Schmiedl

Zitieren als

Wieser, E., Kasanicky, K., Schiesterl F., Grießler, B., Fabritz C., Blumenstein K. & Schmiedl, G., 2013. Smartphonebasierte Step-by-Step Indoor-Navigationslösung ohne kontinuierliche Positionserkennung. In Forum Medientechnik – Next Generation, New Ideas. St. Pölten: Fachhochschule St. Pölten.

The post Smartphonebasierte Step-by-Step Indoor-Navigationslösung ohne kontinuierliche Positionserkennung appeared first on Mobile USTP MKL.

Auf der Google I/O 2013 wurden unter anderem auch die neuen “Google Play Game Services” präsentiert.  Die erste Frage, die sich stellt ist, was bringen mir diese? Google bietet mit GPGS eine mehr oder weniger plattformunabhängige (Android, iOS und Web) Möglichkeit das Spielererlebis zu verbessern. Die GPGS beinhaltet 6 Dienste:

• Bestenlisten (Leaderboards)
• Erfolge (Achievements)
• Speichern in der Cloud (Cloud Save)
• Anmelden mit Google+ (Sign in with Google+)
• Diebstahlschutz für Apps (anti-piracy) -> nur für Android!
• Echtzeitmultiplayer (real-time multiplayer) -> nur für Android!

Der große Vorteil ist, dass Google ziemlich vieles von Haus aus anbietet. So geschieht die ganze Verwaltung, von z.B. Bestenlisten und Erfolgen, in der Google Play Developer Console von Google. Am Ende spukt diese ziemlich viele ID’s aus, die wir später für die Applikation brauchen. In dieser kann man dann zum Beispiel mit dem einfachen Befehl

mGamesClient.unlockAchievement("my_achievement_id");

ein Erfolg freischalten (genau es ist ein Einzeiler!). Will man eine Übersicht aller Erfolge haben (diese gibt es schon mit fertigem Design!), geht dies auch sehr einfach mit der Zeile

startActivityForResult(mGamesClient.getAchievementsIntent(), REQUEST_ACHIEVEMENTS);

Na gut, ein bisschen Vorarbeit braucht das Ganze, aber die meiste Arbeit nehmen einem die bereitgestellten Libraries ab.

Das erste Einrichten

Das erste Einrichten der Testapplikationen (die unter https://developers.google.com/games/services/downloads/#samples heruntergeladen werden können) gleicht einem Copy & Paste Marathon. Es müssen viele Dinge zwischen der Web Oberfläche (Google Play Developer Console) und dem eigentlichen Projekt in Eclipse kopiert werden, unter anderem die Zertifikat Erkennung (die mir sehr viele Probleme bereitet hat!), ID’s für Bestenlisten und Erfolge.

Bevor man dies tut, muss man noch zwei Libraries (google-play-services-lib, BaseGameUtils) in Eclipse einbinden und dem eigentlichen Projekt hinzufügen. Das ist aber schön in der bereitgestellten Anleitung (https://developers.google.com/games/services/android/quickstart) erklärt. Hier gab es keine unlösbaren Schwierigkeiten, bis auf die üblichen Importprobleme, die schnell gelöst werden können.

Hat man diese zwei Schritte gemacht, kann eigentlich nichts mehr schiefgehen, und die Applikation kann auf dem Handy installiert werden. Glaubt man! Die Schwierigkeit, die hier entstehen kann, es war zumindest bei mir so, ist das Signieren der Applikation, da nur signierte Applikationen mit dem Google Servern kommunizieren können. Jeder, der Applikationen in den Play Store stellen will, braucht einen sogenannten Keystore, mit dem Applikationen signiert werden. Dies geht normal über einen kleinen Dialog, bei dem Passwörter etc. eingetragen werden müssen. Natürlich wäre dieser Weg viel zu umständlich für das Testen der Applikation, deswegen generiert Eclipse einen eigenen debug.keystore, mit dem die Applikation automatisch signiert wird. Bindet man jetzt beide Keystores in die Developer Console ein, was normalerweise auch vorgeschlagen wird, kann es, wie bei mir, zu dem Problem führen, dass der eine oder der andere Keystore nicht erkannt wird. Das lag bei mir an der Tatsache, dass die “Play Game” Applikation, die für die Verwaltung am Handy zuständig ist, manche Daten im Cache speichert und deswegen der eine oder der andere Keystore nicht angenommen wird. Man muss also ab und zu den Chache löschen. Würde dies im offiziellen Troubleshooting stehen, hätte es mir einige Stunden Fehlersuche erspart!

Konklusio

Im Großen um Ganzen bin ich aber positiv überrascht, wie “einfach” alles geht, wenn es mal läuft. Die Dokumentation ist fast perfekt und die Beispiele geben einen guten Einblick in die ganze Thematik. Die vielen fertigen Elemente lassen sich sehr einfach einbauen und so können weitere Komponenten, wie Erfolge und Bestenlisten, in eigenen Spielen oder in den eigenen Applikationen eingebaut werden und das Plattformübergreifen.

The post Google Play Game Services – erste Erfahrungen appeared first on Mobile USTP MKL.

Helios soll jungen StadtbewohnerInnen und BesucherInnen Kunstwerke im öffentlichen Raum auf spielerische Art und Weise näher bringen. Der User springt in die Rolle eines Heißluftballonfahrers, der mit dem Kompass Kunstwerke entdecken kann. Dabei entfernt sich Helios von herkömmlichen Point-Of-Interest Lösungen und setzt den Fokus auf das “Entdecken” von nahe gelegenen Kunstwerken. Vor Ort wird der User dann mit interessanten Informationen rund um das gefundene Kunstwerk belohnt und erfährt so auf spielerische Art und Weise mehr über Wien.

Für die App wird der offene Datensatz “Kunstwerke im öffentlichen Raum” verwendet. Zusätzlich wurden 40 Fotos von ausgewählten Kunstwerken im Wiener Zentrum gemacht, welche das Auffinden für den User erleichtern sollen.

Link zur App:

https://akirchknopf-21110.php.fhstp.cc/helios/

The post Helios ist da! appeared first on Mobile USTP MKL.

ActionBarSherlock

Die neue ActionBar die ab Android 3.0 eingeführt wurde, war ein Segen für viele Android Entwickler, da diese endlich eine Einheitlichkeit von Apps ermöglichen sollte. Das große Problem waren jedoch ältere Android Geräte, die diese nicht unterstützen. Eine Abhilfe schafft hier die Library ActionBarSherlock, die die Funktionalität der Android ActionBar von der Version 4.x, bis auf die Android Version 1.6 portiert. Diese Library ist aus der Android Welt fast nicht mehr wegzudenken, also auf jeden Fall ansehen.

Link: http://actionbarsherlock.com/

ViewPageIndicator

Man steht oft vor der Schwierigkeit, eine nette Funktionalität in seine App einbringen zu wollen, man hat aber nicht die benötigte Erfahrung, oder Zeit, diese selber zu implementieren. Ein Beispiel hierfür ist ein Indikator, der anzeigt, das mehrere Views/Bilder durchgeblättert werden können. Hier kann einem die Library ViewPageIndicator behilflich sein, de viele Möglichkeiten von Text, bis hin zu Punkten anbietet.

Link: http://viewpagerindicator.com/

SlidingMenu

In immer mehr Applikationen taucht ein nettes Menü auf, das sich durch Wischen oder Antippen auf der rechten Seite öffnen lässt. Wenn man dieses in seiner Applikation benutzen will, steht man aber vor dem Problem, dass diese keine Standardkomponente ist und die Entwicklung eher etwas für fortgeschrittene Android Programmierer ist. Auch hier hat sich dieses Problems jemand angenommen und die Library SlidingMenu programmiert, die genau diese anbietet und sehr einfach implementierbar ist.

Link: https://github.com/jfeinstein10/SlidingMenu

Man sieht also, dass nicht Alles von Grund auf alleine entwickelt werden muss, sondern dass viele talentierte Programmierer ihre Implementierungen offen anbieten. Es reicht einfach zuzugreifen und seine eigene App mit tollen Funktionen zu erweitern.

The post Nützliche Android Libraries appeared first on Mobile USTP MKL.

Damit die Anwendung auf fast allen mobilen Endgeräten funktioniert, war es wichtig eine Technologie zu wählen, die auch von vielen unterstützt wird.  Da also keine native App infrage kommt, musste eine Web App her. Um die Entwicklung einfacher zu gestalten, wurde das Framework jQuery Mobile (Link) benutzt, das hauptsächlich die Oberfläche für mobile Endgeräte optimiert. Weiters wurde eine mySQL Datenbank für das Speichern der Daten benutzt. Diese beinhaltet eigentlich nur drei Tabellen, die Erste für die Geschichten, die Zweite für die Inhalte der Geschichten und in der Letzten werden die Antworten der Autoren gespeichert, da vor dem Schreiben einer Geschichte drei Fragen beantwortet werden müssen.

Mit Hilfe von PHP und jQuery Mobile wurde dann die Oberfläche generiert. Diese beinhaltet auch einfache Überprüfungen, damit der Benutzer zum Beispiel keine leeren Felder abschickt.

Zum T-Shirt gibt es nicht viel zu sagen. Mithilfe des Fotodrucks (Digitaldruck) wurde das unterstehende Bild, das mit Illustrator erstellt wurde, auf das T-Shirt gebracht.

The post Projekt: „Erzähl eine Geschichte“ (Umsetzung) appeared first on Mobile USTP MKL.

Nun zu den technischen Möglichkeiten. JOYN kann in vier Bereiche geteilt werden. Der erste Bereich ist die Kontaktliste, nun wird man sich denken, das hat doch jedes Handy, jedoch erweitert JOYN diese um eine aktive Komponente, die anzeigt, welche Kontakte überhaupt JOYN haben und welche Dienste bei diesen zur Verfügung stehen, da dies abhängig von der Geschwindigkeit des Netzes ist. So kann zum Beispiel nur mit einer schnellen Verbindung ein Videotelefonat gemacht werden.

Die zweite Funktion die JOYN bietet, ist ein Chat. Hier unterscheidet sich JOYN nicht wirklich von anderen Anwendungen, da die Standard-Funktionen wie Textnachrichten, Gruppenchats etc. angeboten werden.

Der nächste Punkt ist das Versenden von Dateien. Warum dies hier extra angeführt ist? Mithilfe von JOYN ist es möglich, Dateien auch während eines Gesprächs zu versenden, was jedoch nur mit einer entsprechenden Verbindung geht. Neben den Standard-Daten wie Bild, Video und Audio kann man über JOYN zum Beispiel auch seine aktuelle Position übermitteln. Natürlich werden alle Daten verschlüsselt übertragen, was bei anderen Anwendungen nicht immer der Fall ist.

Der letzte Punkt ist die bereits erwähnte Möglichkeit, eine Kamera während des Telefongesprächs einzuschalten.

Mittlerweile unterschützen unter anderem HTC, Huawei, LG Electronics, Motorola Mobility, Nokia, Research IN Motion, Samsung, Sony Mobile Communication und ZTE diesen Dienst und bei vielen Geräten ist dieser auch bereits vorinstalliert. Bis jetzt gibt es aber nur eine Version für iOS und Android.

Jedoch gibt es auch eine schlechte Nachricht. Leider wird JOYN noch von keinem österreichischen Mobilfunkanbieter unterstützt und es gibt auch keine offizielle Ankündigung, wann es so weit sein wird. Jedoch ist JOYN bereits bei unseren deutschen Nachbarn bei Vodafone und Telekom gestartet. Man kann also hoffen, dass dieser Dienst auch bald nach Österreich überschwappt und auch hier verfügbar wird.

Link: http://www.joynus.com/de/

The post JOYN – Das Ende der klassischen SMS? appeared first on Mobile USTP MKL.