Angeregt durch das Wachstum und die Popularität von iPhone-App-Entwicklungen, fragen sich viele Entwickler, wie sie den Markt auf andere Plattformen ausdehnen können. Einige von ihnen führten erfolgreiche Portierungen zu AppUp durch und stießen auf interessante Herausforderungen und Möglichkeiten zwischen den Plattformen.

Dies ist mein Gespräch mit Mike Kasprzak, CEO von Syhkronics, mit Fragen und Antworten über seine Erfahrungen bei der Portierung seines preisgekrönten Spiels „Smiles“ vom iPhone zu AppUp.

Zur Portierung verwendete Tools und Methoden Umgang mit Hardware-Unterschieden Beschleunigungssensor Tastatur Multi-Touch Überraschungen beim Portieren Beim Portieren verlorene oder verbesserte Funktionen Unterschiede beim Spielen Intel Support Tipps und Lernerfahrungen

Frage: Welche Tools und Methoden haben Sie für das Portieren Ihrer App zum Netbook verwendet und warum haben Sie diesen Weg eingeschlagen?

Mike Kasprzak:

Zunächst einmal habe ich für die Grafik OpenGL verwendet. Nahezu jede halbwegs anständige Plattform verfügt über eine Version von OpenGL (oder eine entsprechende API). Bei Mac, Linux und den meisten Handys ist sie deren einzige 3D-Grafik-API. Unter Windows ist sie ein Zubehör, aber sie ist immer da. OpenGL ist tatsächlich eine viel ältere API als DirectX, aber sie hat ein robustes, solides Design, das auch fast 20 Jahre später eine nicht unerhebliche Rolle spielt.

Ich habe mein Spiel in C++ geschrieben, dem sein Alter ebenfalls zugute kommt. Die iPhone-spezifischen Funktionen, die Objective-C-Code erfordern, habe ich in C-Funktionen und -Variablen untergebracht. Um also eine Portierung zum PC durchführen zu können, musste ich lediglich diese Funktionen umschreiben.

Ich baue mein Projekt manuell auf, damit ich Xcode-Projekte, Visual-Studio-Projekte und Makefiles in einem gemeinsamen Layout miteinander kombinieren kann. Um es richtig zu machen, sind etwas Planung und Recherche nötig, aber das ist viel besser als Dateien manuell hin und her zu kopieren. Das Setup meines Makefile ist angepasst und erkennt automatisch alle Dateien in meinem Projekt. Aber sowohl für Xcode als auch für Visual Studio erstelle ich ein Projekt manuell, indem ich meine gesamten Quelldateien reinziehe (ein Verzeichnis nach dem anderen).

Zum Synchronisieren meiner Dateien verwende ich Subversion (SVN), das auch hervorragend für Backups geeignet ist. Speziell verwende ich TortoiseSVN unter Windows und SCPlugin auf dem Mac. Beide integrieren direkt in Explorer/Finder, was ihren Gebrauch unglaublich vereinfacht.

Und auf der PC-Seite habe ich SDL als meine Host-API verwendet, anstatt nativen Windows-API-Code zu schreiben. Auf iPhone habe ich nativen Code geschrieben, aber die PCs sind alle SDL. Ein zusätzlicher Vorteil davon ist, dass es neben einigen mobilen Linux-Geräten (Nokia, Palm) sowohl unter Windows und Linux als auch auf dem Mac läuft.

Aber obwohl ich eine Reihe von Standard-Bibliotheken verwendet habe, habe ich dennoch meine eigene Wrapper-Bibliothek auf OpenGL und SDL geschrieben. Dadurch werde ich das Spiel irgendwann auf andere Plattformen ausdehnen können, z.B. auf DirectX unter Windows, die OpenKode-Plattform von Khronos (die OpenGL-Alternative zu SDL) oder auf die nativen APIs von Spielkonsolen, wie einer PlayStation.

Schließlich ist der Code des Spiels selbst wie ein Modul, das auf den speziellen Code der Plattform zugreift. Er hat eine Initialisierungsfunktion, eine Sprungfunktion und eine Zeichenfunktion. Dem Spielcode ist es gleichgültig, welche Form oder Größe der Bildschirm hat, er zeichnet einfach, was ihm gegeben wird. Jeder Frame des Spiels ist ein „Sprung“-Aufruf, dann „Zeichnen“, aber wenn das Spiel jemals zu langsam läuft, kann „Sprung“ mehrmals aufgerufen werden, um aufzuholen.

Frage: Wie sind Sie mit den Hardware-Unterschieden umgegangen, wie z.B. der Bildschirmauflösung oder der Multi-Touch-Technik im Vergleich zu Maus und Tastatur und Beschleunigungssensor im iPhone?

Mike Kasprzak:

In puncto Bildschirmauflösung gab es Einiges, was ich unternommen habe.

Als Erstes machte ich mein Spiel und die Benutzeroberfläche skalierbar. Das bedeutet, dass ich mich für die Bildschirmanzeige nicht auf Pixelkoordinaten verlassen habe. Das hört sich vermutlich etwas kompliziert an, aber der Trick dabei ist, eine Referenzauflösung zu wählen und sie bis zur eigentlichen Auflösung hochzuskalieren. Wenn also beispielsweise die Referenzauflösung 480x270 ist, könnte man sie vervierfachen und auf 1920x1080 hochskalieren (d.h. HD 1080p).

Vielleicht ist nicht ganz klar, dass diese Skalierung mit 3D-Grafikhardware und Texturen gemacht wird. Mein Spiel „Smiles“ ist ein 2D-Spiel, aber es verwendet die 3D-Grafikhardware des Gerätes, auf dem es läuft. Das einfache „Wie“ besteht darin, die „Z“-Koordinate nicht zu verwenden und Funktionen wie Z-Buffering zu ignorieren. Das Arbeiten mit 3D-Hardware erfordert etwas Mathematik, aber heutzutage ist alles 3D-beschleunigt. Es nicht zu verwenden, heißt Leistung zu verschleudern.

Als Nächstes achtete ich darauf, mein gesamtes Spiel mit einer sehr hohen Auflösung zu entwickeln. Obwohl mein ursprüngliches Ziel der Mini-Bildschirm des iPhone war (480x320), war die Auflösung der Originalbilder hoch genug für HD 1080p (1920x1080). An und für sich ist die Mathematik das Schöne dabei. Man kann Bilder in Smartphone-Größe (iPhone 480x320 und andere) herstellen, sie dann auf HD720p verdoppeln (Netbooks, Tablets, Telefone mit höherer Auflösung) und diese dann noch einmal auf volle HD-1080p-Auflösung verdoppeln (PS3s, Xbox 360s und High-End-Gaming-PCs). In der Praxis heißt das, dass man von oben mit den fertigen 1080p-Bildern anfängt, diese dann auf 720p halbiert und anschließend noch einmal halbiert, um die niedrige Auflösung für Zielgeräte wie Smartphones zu erzielen. Und dieses ständige „Halbieren“ kann man auch automatisieren.

Wenn also Bilder und Benutzeroberfläche für die Skalierung entwickelt wurden, muss man sich dem Seitenverhältnis zuwenden. Die oben beschriebenen Referenzauflösungen sorgen dafür, dass die Seitenverhältnisse erhalten bleiben, wobei man lediglich einen Skalar auswählen oder berechnen muss, der das Bild an den Bildschirm anpasst. Das kann allerdings zur Folge haben, dass an den Seiten oder am unteren Rand Leerräume entstehen. Anstatt dunkle Balken zu verwenden, löste ich in „Smiles“ das Problem auf zweierlei Art. Erstens erstellte ich einen Hintergrund der gekachelt werden kann, und zweitens machte ich ihn wirklich groß.

In Kacheln aufteilbare Effekte sind einfach und gut skalierbar. Man fügt einfach ein oder zwei weitere Reihen mit Kacheln hinzu, um zusätzlich vorhandenen Raum auszufüllen.

Bei großen Hintergründen geht es darum, etwas zu erstellen, was größer als der Bildschirm ist. Für gewöhnlich reicht die doppelte Breite und doppelte Höhe des Referenzbildschirms aus. Der Hintergrund selbst sollte nichts enthalten, was optisch wichtig ist, und dort, wo er sichtbar wird, nicht stören.

Was Multi-Touch angeht, hatte ich im Grunde überhaupt keine Probleme. Im Großen und Ganzen würde ich sagen, dass Multi-Touch überwiegend für Gesten verwendet wird. Pinch-Zooming, Drehen mit zwei Fingern usw. Abgesehen von all den modischen Dingen, dienen Touchscreens nur einem Zweck, dem Berühren.

Der Unterschied zwischen einem mausgesteuerten und einem Touchscreen erforderte hinsichtlich des Designs einige Überlegungen. Wenn man die beiden vergleicht, zeigen beide Positionen an, aber nur eine Maus bleibt, wo man sie hinbewegt hat. Was ich damit meine ist, dass einem ein Touchscreen nur anzeigen kann, wo er berührt wird, aber nicht, wo sich die Hand befindet. Während der Mauszeiger über dem Element bleibt, das man drücken möchte und auf den Klick wartet. Vom Design her bedeutet dies, dass wenn das Spiel durch die Einzelberührung eines Touchscreens funktioniert, es auch mit einer Maus funktionieren kann.

Genau genommen, gibt es einen dritten Eingabetyp, der bedacht werden sollte. Grafiktabletts und Tablet-PCs. Normalerweise trifft man sie nur in den Händen von Grafikern an, aber ein Grafiktablett vereint das Beste zweier Welten. Physische Positionierung (wo die Stiftspitze hingeht, geht der Zeiger hin) und Erhalt der Position.

Und wenn man es wirklich auf die Spitze treiben will, könnte man Kamera-basierte Zeigegeräte einbeziehen, wie Nintendos Wiimote, Sonys PlayStation Move, Eyetoy und Microsofts Natal. Die ersten beiden sind wie eine Maus, und die letzten beiden eine Art Multi-Touch.

Aber am Ende sind es alles Zeigesysteme. Mit unterschiedlichem Grad an Genauigkeit und Einfachheit, kann jedes von ihnen eine Position angeben. Das einfachste ist nach wie vor der Touchscreen; Positionierung ohne Beibehaltung der Position. Wenn man an diesem Punkt mit dem Design ansetzt, kann man normalerweise einen Weg finden, der mit jedem anderen Zeiger funktioniert.

Die fehlende Tastatur von Mobilgeräten veranlasste mich, das Spiel so zu entwickeln, dass es durchwegs mit einem Zeiger arbeitet (Touchscreen, Maus). Das macht es auch für gelegentliche Benutzer leichter. Kein Grund, die Hand von der Maus zu nehmen. Einfach klicken und los.

So wie Multi-Touch normalerweise für Gesten verwendet wird, wird ein Beschleunigungssensor zur Erkennung der Ausrichtung verwendet (Hochformat, Querformat). Die Festlegung des Spiels auf eine einzige Ausrichtung auf dem PC ist die gängige Lösung. Auf dem iPhone lief es am Ende darauf hinaus, dass ich die physische Rotation als einen Mechanismus im Spiel verwendete, und deshalb musste ich mir etwas einfallen lassen, wie ich dies auf Plattformen ohne Beschleunigungssensor erreichen konnte. Das führte dazu, dass ich der Benutzeroberfläche Drehschaltflächen hinzufügte.

Und jetzt ist das Spiel für alles gewappnet. :)

Mike Kasprzak:

Beim Portieren selbst gab es kaum Überraschungen. Aber als ich wirklich ernsthaft an die Grafikprogrammierung ging, fiel mir auf, dass der Intel GMA 950 ein wesentlich besserer Grafik-Chipsatz war, als man mir vermittelt hatte. Der GMA lässt den PowerVR MBX des Original-iPhone links liegen und kann problemlos die doppelte Auflösung liefern und hat immer noch Leistungsreserven. Ich verwendete sogar ein Netbook anstelle eines Notebooks, da es wunderbar mitmacht. Wenn ich aufwendige Arbeiten machen muss, sitze ich an meiner Quadcore-Workstation. Aber das brauche ich nicht immer. Ich kann mich frei im Haus bewegen oder draußen sitzen, ohne meinen „PC-Ersatz“, eine alte Laptop-Kiste, mit mir rumschleppen zu müssen.

Also die Überraschung: Ich kann im Grunde die Portierung AUF dem System selbst vornehmen.

Frage: Haben Sie Funktionen verloren oder erweitert bzw. verbessert?

Mike Kasprzak:

Das Spiel ist fast identisch, aber um den Termin einhalten zu können, habe ich es kurzzeitig um einige Funktionen gekürzt (Spielmodi). Beim nächsten Update sind sie wieder dabei und zusätzlich noch viele, viele andere. Es ging nur um den Termin und nicht um etwas, das ein Netbook nicht hätte tun können. Ich hatte nur keine Zeit dafür.

Die Netbook-Version war auch wie ein unbeschriebenes Blatt für mich, womit ich meine, dass ich sorglos Korrekturen und Änderungen am Design vornehmen konnte, da das Risiko, gesicherte Spiele oder hohe Bewertungspunkte der etablierten iPhone-Version zu zerstören, nicht bestand. Also ja, einige Spielmodi wurden anfänglich gekürzt, aber viele andere Dinge waren bereits geändert. Das ist der Luxus bei der Erstellung eigener Designs und ihrer Portierung. Wenn du dich entschließt, etwas zu ändern oder etwas anderes zu versuchen, kannst du das auf einer neuen Plattform tun. Offensichtlich möchtest du nichts tun, was ein Spiel ruiniert, aber ein Spiel auf eine neue Plattform zu bringen, gibt einem eine interessante Form von Freiheit.

Frage: Wie vergleichen Sie das Spielen selbst auf diesen beiden Geräten?

Mike Kasprzak:

Sie sind sich sehr ähnlich! Der Spielablauf von „Smiles“ funktioniert am besten auf einem Touchscreen, aber auch wirklich, wirklich gut mit einer Maus. Das ist der andere Aspekt von AppUp, der mich begeistert. Bis jetzt sprechen wir über Netbooks, aber OEMs sind dabei, auch MIDs und Tablet-PCs mit derselben Hardware (Intel Atom) zu entwickeln. Normalerweise gäbe es keine Möglichkeit, Kunden in diesem Markt zu erreichen, aber AppUp ist in der einmaligen Position, hierbei zu helfen.

Mike Kasprzak:

Das Einreichen war sehr einfach. Ich bin über keine wirklichen Probleme gestolpert, aber Intel war wirklich gut darin, Fragen, die ich hatte, zu beantworten. Jede Plattform hat kleine Unterschiede beim Einreichen. Deshalb reicht man ja ein und lädt nicht nur einfach einen Online-Download hoch. Aber AppUp ist definitiv eines der einfachsten Verfahren.

Mike Kasprzak:

Mein Rat: definitiv von Anfang an an die Portierbarkeit denken. Ich habe zugegebenermaßen viel zu diesem Thema zu sagen, aber im Kern ist es nicht so schwer zu verstehen. Schreibe deinen Spielcode in C/C++, ziehe OpenGL ES in Erwägung, stelle die Originalbilder in hoher Auflösung her. Auf die Art kannst du deinen Spielcode und was dazu gehört überall verwenden. Hänge ihn an etwas wie SDL an, und in ein, zwei Tagen läuft das Ganze bereits auf einem PC.