Spieleentwicklung mit Android: Sorgenkind “Performance”

flo — Mon, 31 Aug 2009 12:29:27 +0000

Die Entwicklung von (kleineren) Spielen für die Android-Plattform ist selbst für Android-Neulinge (mit etwas Java-Erfahrung) kein großes Problem: Dank ausführlicher Beispiele und umfangreicher Dokumentation im SDK lassen sich schnell erste, ansehliche Ergebnisse erzielen. Vor allem, wenn man sich auf zwei Dimensionen beschränkt, genügen schon wenige Zeilen Code, um ein paar bewegte Grafiken auf das Display zu zaubern.
So konnte auch ich meine Idee zum Spiel Graviturn recht schnell in eine spielbare Anwendung umsetzen, die meine Vorstellungen von Bedienbarkeit und grafischer Ausgestaltung weitestgehend erfüllte. Allerdings tat sich mit steigender Komplexität ein recht unerwartetes Problem auf: Die Performance des Spiels wurde mit jeder zusätzlichen Zeile Code mieser und die Framerate erreichte irgendwann den inakzeptablen Bereich von 15-25 Frames pro Sekunde (man konnte also ein gewisses Ruckeln bei schnellen Bewegungen feststellen).
Über meine Erfahrungen auf dem Weg zu einem flüssigen, gut laufenden Spiel soll es daher nun im Folgenden gehen.

Google I/O 2009, Chris Pruett

Die meisten wichtigen Hinweise und Tipps habe ich dabei aus dem wirklich sehr empfehlenswerten, englischen Video Google I/O 2009 – Writing Real-Time Games for Android von Chris Pruett (Lafzeit: 1 Stunde).

Threads + sauberer Code

Zwei wichtige Punkte habe ich “glücklicherweise” von Anfang an richtig gemacht: der gesamte für das Spiel relevante Code (Physik-Berechnungen, Zeichnen, Spiel-Logik) war in einem gesonderten Thread (sodass ein langsames Spiel nicht die Anwendung selbst bremst und unbedienbar macht), und mein Code war recht sauber gegliedert: getrennte Methoden für Physik/Zeichnen/Benutzereingabe/… sowie eine vernünftige Unterteilung der Spielelemente (Spielfeld, Spielelemente) in entsprechende Klassen. Vor allem letzteres erleichtert jeglichen Umgang mit dem Code natürlich ungemein – sollte aber ja auch bei jedem Programmierer Standard sein
Die weiteren Ausführungen beziehen sich jetzt stets auf den Teil des Spiels, der in erwähntem Thread läuft, sprich zigmal pro Sekunde abgearbeitet wird. Im Einzelnen also die Berechnung der Position der Objekte auf dem Spielfeld/des Spielers, Kollisionsberechnungen, das Zeichnen von Spielfeld/Spieler/Objekten usw.

Messbarer Erfolg?

Als ersten Schritt habe ich einen Zähler eingebaut, der die Zeit misst, die pro Frame zum Berechnen und Zeichnen benötigt wird, und diese Info alle paar Sekunden über die Debug-Konsole ausgibt ( Log.d(, ); ). Mit diesem Zähler war nun das Messinstrument für den Erfolg oder Misserfolg aller kommenden Optimierungen geschaffen.
Eine Ausgabe innerhalb des Spiels selbst (etwa als Text, der auf die Zeichenoberfläche geschrieben wird) ist übrigens nicht empfehlenswert, da man sonst mit dieser Messung das Ergebnis ja bereits verfälschen würde.

Speicherallokation und der Garbage Collector (GC)

Der GC ist ein echter Zeitfresser

So ziemlich das schlimmste, was man innerhalb der Spielroutine überhaupt machen kann, ist das allokieren von Speicher, sprich das Erzeugen neuer Variablen/Objektinstanzen.
Denn jedes Objekt wird irgendwann wieder durch den Garbage Collector freigegeben, sofern es nicht mehr benötigt wird. Üblicherweise wird der GC spätestens bei etwa 10.000-20.000 Objekte aktiv und gibt diese dann in einem Rutsch frei. Dies dauert jedesmal etwa 200-400ms! In dieser Zeit wird das Spiel (bzw. das ganze System!) deutlich ausgebremst und die Framerate bricht für einen Moment komplett ein.
Lösung: Eine Anwendung ohne Objektinstanzen? Natürlich nicht, schließlich müssen die Daten irgendwo verarbeitet und (zwischen-)gespeichert werden. Allerdings sollte man sämtliche Objekte, die man öfters benötigt, bereits zu Beginn des Spiels instanziieren und dann immer wieder darauf zugreifen. Das heißt konsequenterweise auch:

Verzicht auf lokale Objekte zugunsten von globalen Objekten.

Das widerspricht grundsätzlich erstmal jedem guten Programmierstil, schließlich büßt man dadurch Übersichtlichkeit und Flexibilität ein. Doch das Opfer lohnt sich, denn der Garbage Collector ist häufig die größte Performancebremse.
Bei Graviturn habe ich beispielsweise bei der Kollisionsberechnung (Ball -> Wand) sehr häufig mit Point-Objekten gearbeitet (zur Verarbeitung von x/y-Koordinaten), die in jedem Durchlauf bei Bedarf lokal erzeugt wurden. Das hat dazu geführt, dass etwa alle 1-2 Sekunden der Garbage Collector aktiv wurde, und diese Objekte freigegeben hat. Durch Nutzung von globalen Variablen oder simplen Datentypen (etwa zwei int für x und y) konnte dies drastisch reduziert werden.

Ein sehr nützliches Hilfsmittel ist dabei DDMS (”Dalvik Debug Monitor”) aus den Android-Tools. Der DDMS bietet einen sogenannten “Allocation Tracker“, der sämtliche Allokationen protokolliert und inklusive der Position im Quellcode ausgibt. Damit lassen sich auf einfache Weise alle unnötigen Allokationen ausmachen und beseitigen.

Allokationstracker bei Graviturn

In meinem Fall konnte ich damit die Allokation auf ca. 100 Objekte alle 30 Sekunden beschränken. Da ein Level in meinem Spiel selten länger als ein bis zwei Minuten dauert, konnte ich den GC bequem zwischen den Leveln manuell auslösen ( System.gc(); ), wo dies nicht weiter störend ist.

Traceview verwenden (Android Profiler)!

Traceview der Zeichenroutine von Graviturn

Allen Performancebremsen, die sich mit den allgemeinen Tipps nicht beseitigen lassen, kommt man spätestens mit “Traceview”, einem sehr mächtigen Werkzeug aus der Android-Tool-Sammlung, auf die Schliche. Es handelt sich dabei um einen sehr übersichtlichen Profiler, welcher rekursiv für jede (!) Methode, die innerhalb des Messzeitraumes aufgerufen wurde, anzeigt, wieviel Zeit diese benötigt hat (absolsut und relativ, inklusive und exklusive deren Untermethoden).
Egal ob es eine langsame Kollisionserkennung, eine schlecht optimierte Zeichenroutine oder auch nur eine zu häufig durchlaufene Schleife ist: mit Traceview lässt sich jeder Flaschenhals aufspüren.
Die Verwendung ist allerdings nicht unbedingt trivial und würde den Rahmen dieses Artikels sprengen, einen guten Einstieg vermittelt der entsprechende Artikel im Dev Guide.

Noch ein paar allgemeine Tipps

Methodenaufrufe wenn möglich vermeiden
Da Methodenaufrufe immer zusätzlich Zeit kosten, sollte man beispielsweise Variablen einer Klasse lieber public machen, anstatt get- und set-Methoden zu verwenden. Zwar “unsauber”, aber schneller.
Gleitkommazahlen (float) vermeiden.
Je nach benötigter Genauigkeit könnten skalierte integer den entscheidenden Geschwindigkeitsvorteil bringen. Allerdings setze ich zugunsten der Flexibilität weiterhin Gleitkommazahlen ein.
statische Methoden verwenden so oft es geht
Keine Iteratoren verwenden
So praktisch und hübsch sie auch sein mögen, für die Performance sind sie leider schlecht. Mit einer simplen Schleife oder dergleichen lässt sich dasselbe sparsamer erreichen.

Die Liste lässt sich schier beliebig erweitern (hier sei nochmal auf das Video verwiesen), genannt habe ich nur die Punkte, die ich selbst erfolgreich angewandt habe.

Fazit

Es macht Sinn, sich schon frühzeitig Gedanken über die Performance eines Spiels zu machen, um sich zeitraubende Nachbesserungen und Korrekturen am Ende der Entwicklung zu sparen. Gerade weil Android auf einer Vielzahl von unterschiedlichen Endgeräten laufen kann, ist es bei der Spieleentwicklung wichtig, stets ein Maximum an Optimierung herauszuholen, um auch auf schwächerer Hardware ein flüssiges und angenehmes Spielgefühl zu wahren.
Im Fall von Graviturn konnte ich mit den hier aufgezählten Tipps die Framerate von ca. 20 Frames pro Sekunde auf über 50 steigern, was genug Puffer darstellt, um auf allen gängigen Geräten befriedigend zu laufen.

Graviturn 1.0 veröffentlicht

flo — Sat, 22 Aug 2009 11:43:32 +0000

Dank der Hilfe etlicher Betatester aus dem Blog und von android-hilfe.de (Danke nochmal!) konnte ich gestern nach einigen korrigierten Fehlern und Änderungen mein erstes Spiel Graviturn im Android-Market veröffentlichen.

Google gibt sich auch dabei alle Mühe, das ganze möglichst einfach und verständlich zu gestalten, und dank dem ausführlichen DevGuide war das eigentliche Publizieren eine Sache von wenigen Minuten (inklusive der Bezahlung von 25$ “Anmeldegebühr”).

Von dem Moment an habe ich natürlich gespannt auf die ersten Downloads beziehungsweise die ersten Bewertungen oder gar Kommentare gewartet – und schon nach wenigen Minuten gab’s die ersten fünf Sterne. Der schönste Lohn für all die Stunden Arbeit!

Inzwischen (nach 16h) wurde das Spiel fast 2000 mal heruntergeladen und hat eine für mich sehr erfreuliche Bewertung von 4,65 Sternen
Leider gab es “natürlich” auch wieder unerwartete Probleme, scheinbar stüzt bei manchen Benutzern das Spiel im 109. Level ab und auf dem HTC Hero stürzt sogar TouchFLO ab, sobald man das Telefon locked. Das sind leider Szenarien, die sich im Vorraus nur schwer testen lassen, nun wird’s wohl bald das erste Update geben. Dafür muss ich es allerdings erstmal schaffen, die Fehler (zumindest den ersten) zu reproduzieren…

Den versprochenen Blogeintrag zur Entwicklung des Spiels gibt’s übrigens auch noch irgendwann, allerdings stehen jetzt erstmal Klausuren an und die Zeit für anderes ist naturgemäß eher knapp…

Graviturn gibt es kostenlos im Android Market (bzw. Cyrket).

Graviturn – (m)ein erster Versuch der Spiele-Entwicklung

flo — Thu, 30 Jul 2009 19:40:55 +0000

Graviturn

Als leidenschaftlicher Programmierer war die freie und gute Erweiterbarkeit für mich natürlich ein wichtiges Kaufargument für ein Android-Phone, und so habe ich mich bereits vor dem Erwerb des Galaxys eine Weile mit dem Android-SDK auseinandergesetzt und ein wenig herumgespielt.
Neben unzähligen sinn- und funktionslosen Tests habe ich mich dann an etwas größeres gewagt: ein kleines, aber feines Spiel namens Graviturn.

Ziel des Spiels ist es, kleine rote Bälle vom Spielfeld zu rollen, indem man das Smartphone in die entsprechende Richtung neigt. Gleichzeitig dürfen aber ebenfalls vorhandene grüne Bälle genau dies nicht tun, man muss die einen also irgendwie loswerden und die anderen behalten. Glücklicherweise gibt es ein paar blaue Blöcke, an denen Bälle mit ein wenig Geschick und Knobelei abprallen oder blockiert werden, sodass man sich auf die anderen konzentrieren kann. Diese Blöcke kann man im weiteren Verlauf des Spiels auch teilweise selbst platzieren und entfernen, um bestimmte Wege zu blockieren oder zu öffnen.

Gewonnen!

Erzeugt werden die Level zufällig, das Spiel ist damit praktisch unendlich lange spielbar. Allerdings steigt der Schwierigkeitsgrad (Anzahl Bälle, Anzahl Blöcke) natürlich mit jedem Level an.
Als zusätzliche Motivation wird nach jedem absolvierten Level eine Mini-Statistik angezeigt, die das Ergebnis mit dem anderer Spieler vergleicht (über einen Online-Abgleich).

Veröffentlichen werde ich das Spiel wohl erst in einigen Tagen/Wochen, jetzt gilt es ersteinmal, mögliche Fehler zu finden und auszumerzen. Wer Lust hat, Beta-Tester zu spielen, darf sich natürlich gerne unter graviturn@androidig.de melden

Spielerklärung

Androidig.de » Entwicklung