J2me

J2ME Game Development Einführung Hintergründe Seit Mitte der 90er Jahre sind Handys und Mobile Geräte immer mehr im kommen. Vom technischen Helfer wurden sie zum Modischen Accessoire, zum Assistenten in allen Lebenslagen und vor allem auch zu einer neuen Freizeitbeschäftigung einer ganzen Generation. Schon seit Jahren drang ein Ruf der konsumbereiten und vor allem finanzkräftigen Masse zu den Herstellern. Es wurde nach neuen Zusätzen für Handys gefordert: Individuelle Betreiberlogos für Displays, der neueste Charthit als Klingelton oder eine pfiffige Ansage auf der eigenen Mobilbox. Das Handy wurde immer mehr zum Zeitvertreib: Die eigentlich nur als Lückenfüller gedachten Spiele auf den Handys gerieten immer mehr in das Interesse der Kunden. Das Problem war hierbei jedoch schnell ersichtlich: Fehlende Vertriebswege seitens der Hersteller, mangelnde Erfahrung im Bereich Entertainment Software sowie fehlendes Personal drang die Konzerne dazu, externe Firmen mit der Entwicklung von Spielen zu beauftragen. Für die Firmen war dies jedoch nicht lukrativ genug. Immerhin mussten die Programmierer sich mit der Technik einzelner Geräte vertraut machen, direkt mit den Herstellern in Verbindung stehen und ausserdem waren keinerlei Standards definiert. Zudem war dies den Handy – Entwicklern selbst ein Dorn im Auge.

Immerhin

mussten

sie

aussenstehenden

detaillierten

Zugang

zu

allen

Entwicklungsunterlagen sowie dem Betriebssystem geben.

Deswegen richtete sich das Augenmerk der Gerätehersteller sowie unabhängiger Entwickler auf die Programmiersprache Java. Das Java – Konzept sieht neben einer Objektorientierung vor allem die Plattformunabhängigkeit vor, und genau dafür wurde sie auch entwickelt. Java – Programme werden nicht in Maschinencode übersetzt, sondern in Geräteunabhängigen Bytecode der von einer sogenannten „Virtual Machine“, also einer virtuellen Maschine interpretiert wird. Diese sogenannte VM kann für jede Plattform implementiert werden und muss sich an die Java – Standards halten. So ist ein einmal geschriebenes und kompiliertes Programm auf jeder VM lauffähig. Würde man nun eine Virtuelle Maschine für Mobile Geräte bereitstellen, so könnte diese jedes Java – Programm ausführen. Java ist eine C++ ähnliche Sprache mit einer verbesserten Objektorientierung, verbessertem Exception sowie einigen weiteren Neuerungen.

Kernfeature von Java ist allerdings eine enorme Klassenbibliothek die eine Vielzahl von Möglichkeiten in den Bereichen Fenstermanagement (User Interfaces), Networking, File – Handling usw bietet. Da ein Handy natürlich nicht alle Features eines PCs bieten kann wurde von der Firma Sun Microsystems eine abgespeckte Version der Java – Klassenbibliothek geschaffen: MIDP. Daher wurde Java mit seiner Klassenbibliothek für mobile Geräte auf den Namen J2ME getauft: Java 2 Micro Edition. Sun bezeichnet J2ME Anwendungen sinnigerweise als sogenannte MIDlets, wurden doch schon Java Applikationen für Web – Anwendungen als Applets und Serveranwendungen als Servlets bezeichnet.

Vermarktung Spiele im Bereich Mobile Games werden nicht direkt über den Handel vertrieben. Im folgenden sei das gängigste Modelle vorgestellt:

Vermarktung über Internetportale Webseiten für Handy – Nutzer gibt es wie Sand am Meer. Servicedienstleistungen rund ums Handy wie Logos und Klingeltöne, SMS - Kontaktbörsen, Shops und vieles mehr sind dort an der Tagesordnung. Besucherzahlen von über 1 Million pro Tag sprechen für den Erfolg. Seitdem J2ME – Geräte der breiten Masse zugänglich sind haben solche Portale ihr Angebot auf J2ME Software erweitert und so den Startschuss für den breiten Verkauf von Handyspielen gegeben. Bekannteste Portale sind in Deutschland www.uboot.de bzw. www.jamba.de

Ansonsten ist es mittlerweile auch durchaus üblich, dass Gerätehersteller selbst Spiele in Auftrag geben, oder Firmen dies als Werbepräsent an ihre Kunden verschenken.

Der Verkaufspreis eines Spiels ist denkbar gering: Er bewegt sich für ein einfaches J2ME – Spiel bei etwa 3 Euro pro Stück.

Casual Gamer Der Standardspieler (sog. Casual Gamer) ist zwischen 14 und 40 Jahren alt und spielt im Schnitt etwa 20 Minuten. Laut einer Studie spielt er hauptsächlich zu Hause sowie bei Wartezeiten, z.B. am Bahnhof oder in Pausen. Er fordert Kurzweil und eine möglichst kurze Einarbeitungszeit.

Spieledownload Die Spiele können drahtlos, also „Over The Air“ heruntergeladen werden. Nach dem Bezahlvorgang (Meist per Mehrwertnummer) bekommt man per SMS einen WAP – Link zugeschickt der nur wenige Minuten gültig und nur einmal aktivierbar ist. Dieser WAP – Link kann dann vom Käufer angewählt werden. Das Gerät lädt die Applikation dann in wenigen Minuten auf das Gerät und installiert es gleich von selbst.

Einführung in J2ME Die Java Micro Edition enthält mit MIDP eine Klassenbibliothek für alle denkbaren mobilen Geräte: Handys, PDAs usw. und hat sich mittlerweile als Standard für geräteunabhängige Handysoftware durchgesetzt.

Die MIDP – Klassenbibliothek enthält Objekte, die eine einheitliche Schnittstelle für die unterschiedlichsten Displays und Eingabemethoden bilden, da jeder Hersteller für sowas ja seine eigenen Routinen und Protokolle zur Verfügung stellt. Der J2ME – Entwickler muss sich also im Idealfall nicht um Geräteabhängigkeiten kümmern: Was auf einem Gerät funktioniert, funktioniert auch auf dem eines anderen Herstellers. (Dies ist jedoch leider noch nicht der Fall, Programme müssen immer noch portiert werden)

Die Klassenbibliothek MIDP bietet dem Programmierer Klassen und Routinen zur Ausgabe und Verarbeitung von Grafiken, Zur Verwaltung von Systemmenüs sowie zur Interaktion mit der Firmware, hierbei im speziellen Systemfunktionen wie der System Timer, File Handling, aber auch Kommunikation, Multithreading und vieles mehr. Die Implementierung der Funktionen selbst ist hierbei Sache des Herstellers.

Der eigentliche J2ME - Programmierer kommt und kann auch nicht damit in Kontakt kommen, so kann der Hersteller einerseits seine Standards wahren und schützen, auf der anderen Seite muss sich der Entwickler nicht mit Details einzelner Geräte herumschlagen und erreicht somit eine absolute Plattformunbhängigkeit.

Manche Geräte bieten jedoch Zusatzfeatures wie einen Vibrationsalarm, Lautsprecher zur Soundausgabe, Grafikbeschleunigung und vieles mehr. Um dies zu nutzen müssen extra Bibliotheken des jeweiligen Herstellers verwendet werden: Dadurch müssen erste Kompromisse gezogen werden, ausserdem wird hierdurch die Portierbarkeit bereits stark eingeschränkt. Ausgefeilte Objektorientierte Konzepte und Frameworks sind hier von nöten, um eine Portierung überhaupt zu ermöglichen.

Jeder Hersteller von Mobilen Geräten mit Unterstützung für J2ME bietet mittlerweile ein eigenes SDK (Software Developer Kit) an. Natürlich versteht jedes Gerät Bytecode der aus J2ME – Code erzeugt wurde, jedoch bieten die Hersteller noch mehr an, als eigentlich im Standard (sogenannter MIDP1.0 Standard) definiert wurde. Hierzu zählen z.B. Sound und Vibration, aber auch Grafikbeschleunigung usw. Das Wireless Toolkit (WTK) von Sun ist hierbei der Standard. Um die technischen Möglichkeiten eines Gerätes aber voll ausnutzen zu können, sollte immer auf das entsprechende SDK des Herstellers zurückgegriffen werden.

Die Virtuelle Maschine Die VM wird von jedem Hersteller selbst implementiert. Er ist dafür verantwortlich dass die Standards eingehalten werden, dass sein Look And Feel (also Design – Standards, Menüführung, Tasten usw) übernommen wird. Ausserdem muss er dafür Sorge tragen, dass die Funktionen auf seiner Hardware konsequent und performant durchgeführt werden.

Technische Details

Abbildung: Siemens M50

Geräte Geräte mit J2ME sind zur Zeit: •

Siemens SL45i, SL42, M(T)50, C55, S55

•

Nokia 3410, 6310i, 7650

•

Motorola Accompli 008

•

PDAs mit PalmOS

Jedoch kommen täglich neue Geräte auf den Markt die J2ME unterstützen.

Displays Unterschiedlichste Displayauflösungen: •

96 * 80

•

101 * 64

•

...

Verschiedene Farbtiefen: •

1 Bit

•

8 Bit

•

12 Bit

Controls Jedes Gerät bietet andere Möglichkeiten ein Spiel zu steuern: Manche Mobiles haben extra Game – Keys bzw Joysticks, andere verwenden die Standard Zifferntasten.

Weitere Merkmale •

Die meisten Geräte besitzen keine Floating Point Unit (FPU)

•

Sehr wenig Speicher verfügbar

•

Sehr unterschiedliches verhalten der VMs

Aufgrund der unterschiedlichen Technischen Merkmale und Möglichkeiten verwendet man in Standard – J2ME Spielen eine maximale Auflösung von 96 x 64 Pixel und eine Farbtiefe von 1 Bit (Also Schwarz – Weiß). Da aber immer mehr Geräte mit einer größeren Möglichkeit Farben darzustellen auf den Markt kommen werden für diese Geräte extra Grafiken erstellt.

Massenmarkt Da sich die Portierung eines Spiels auf ein Gerät mit einem sehr geringen Verbreitungsgrad nicht lohnt, werden zur Zeit meist nur folgende Geräte unterstützt: •

Siemens SL45i, SL42, M(T)50, C55

•

Nokia 3410, 6310i

Entwicklungsprozess Spielkonzepte Der Casual Gamer spielt nur sehr kurz und fordert keine langwierigen und eintönigen Missionen. Ausserdem muss die Einarbeitungszeit möglichst kurz gehalten werden. Daher bieten sich nur noch wenige Spielgenres an, die für Mobile Games umgesetzt werden können. Interessanterweise wiederholt sich hier jedoch die Geschichte. In den 80er Jahren, als Commodore mit seinem C64 sehr erfolgreich war, sind die meisten Spielkonzepte und Genres entstanden, die heute wieder gefordert werden: •

Logik und Denkspiele

•

Actionspiele

•

Arcade – Games (Spiel gegen die Zeit)

•

Sportspiele

Auch waren damals die technischen Möglichkeiten sehr eingeschränkt, weswegen ähnliche Bedingungen wie heute im Bereich „Mobile Gaming“ herrschten.

Design Document Im Design Document wird genau festgehalten wie das Spiel ablaufen soll. Spielkonzept, Grafikstil, Menüs, Punktevergabe, Highscores, Levels, Story und vieles mehr werden dort genau definiert und das ganze Entwicklerteam muss sich daran halten. Dies ist in etwa vergleichbar mit einem Pflichtenheft in der herkömmlichen Softwareentwicklung.

Game Design Das Spieledesign ist gerade bei J2ME – Spielen extrem schwierig. Aufgrund der sehr geringen Displayauflösung kann nicht jedes Konzept untergebracht werden. Spielelemente müssen richtig arrangiert werden, um eine Spielbarkeit zu erreichen. Levels müssen abwechslungsreich gestaltet werden, da sonst – gerade bei solch gefordertem Kurzweil – das Spiel schnell zur Seite gelegt wird. Umfragen haben gezeigt dass vor allem Jugendliche spielen.

Jugendliche fordern ein Actionreiches Spiel mit viel Abwechslung und wenig Tiefgang. Das Spiel muss so gestaltet werden dass sich jeder sehr schnell zurechtfindet und dass während des Spiels keine Verwirrung entsteht. Klar definierte Aufgaben und Ziele um mit möglichst einfachen Mitteln eine Vielfältige Spiellandschaft entstehen zu lassen. Dies ist nicht immer einfach und erfordert viel Geschick und Feinarbeit, aber ebenso auch eine große Anzahl von Testern sowie eine sehr genaue Auswertung des Feedbacks dieser.

Programmierung J2ME Programme dürfen nicht sehr viel Speicherplatz benötigen. Bei den meisten Geräten (insbesondere Nokia) liegt die Grenze für ein ausführbares Programm inklusive aller Ressourcen (Grafiken, Töne, Leveldaten) bei maximal 30 Kb. Deswegen muss darauf geachtet werden, dass möglichst wenig Grafik - Files sich wiederholen und einfache Grafiken prozedural generiert werden. Bei der Programmierung wird ein (weistgehend) prozedurales Modell verwendet. Objektorientierung hilft zwar bei der Softwareentwicklung, jedoch benötigt gerade das Anlegen von Objekten eine Menge Speicherplatz, den man einsparen kann.

Gerade bei der Planung ist darauf zu achten, dass möglichst viel Code wiederverwendet wird. Modularisierung von oft verwendetem Code wie zum Beispiel Font- beziehungsweise Spriteroutinen, Kollisionsabfragen und vieles mehr können zu einem schnelleren Entwicklungsergebnis führen. Ausserdem muss der Code nur einmal geschrieben und getestet werden: So reduziert sich der Aufwand, und die Fehlerfreihheit steigt.

Der sogenannte Heap Memory, also der Speicher der dem Programm zur Verfügung steht, ist sehr klein. Man muss auf ein ausgefeiltes Speichermanagement achten um nicht zu viel Speicher zu verbrauchen. Statische Speicherbereiche benötigen am meisten Platz, da sie permanent im Speicher liegen und auch nicht wieder entfernt werden können. Bei der Allokierung von dynamischem Speicher ist darauf zu achten (insbesondere bei Containerklassen) dass nicht zu viel angefordert wird. Auch sollte man nicht gerade benötigteten Speicher sofort wieder entfernen, da so wichtiger Speicher für einen anderen Anwendungsfall blockiert wird. Gibt es einen Speicherüberlauf, so stürzt die Anwendung ab, und der Spielspaß nimmt ein tragisches Ende.

Grafik Grafiken sind das wichtigste in jedem Spiel. Sie sind einer der wichtigsten Bestimmungsfaktoren in Punkto Spielspaß. Gerade bei Spielen auf mobilen Geräten sind diese sehr wichtig, denn das ist meist die einzigste Kaufentscheidung. Wie bereits erwähnt besitzen die gängigen Displays zur Zeit nur eine sehr geringe Auflösung. Um den Aufwand an Grafiken zu verringern, beschränkt man sich auf eine Auflösung von 96 x 64 Pixeln (Dies ist die Mindestauflösung). Bei Geräten mit geringfügig größerer Auflösung wird das Bild zentriert dargestellt. Da die meisten Geräte heutzutage immer noch Schwarz / Weiß – Grafik besitzen, ist der Grafiker zusätzlich enorm eingeschränkt. Rundungen und Schattierungen müssen durch gezielte Techniken dargestellt werden, um ein realistisches Ergebnis zu erzielen. Um eine annähernd realistische Schattierung darstellen zu können greifen Grafiker oft auf das sogenannte Dithering zurück, eine Technik bei der ein dunklerer Schatten mit mehr Bildpunkten, ein hellerer mit weniger Bildpunkten dargestellt wird.

Ein weiteres Problem bringt die geringe Auflösung mit sich: Grafiken können nicht beliebige Größen annehmen, meistens steht für eine Spielfigur nur eine Auflösung von 8 x 4 Pixeln zur Verfügung. Dies kann natürlich je nach Spielprinzip variieren, jedoch müssen die Grafiker mit so wenig Pixeln wie möglich auskommen. In der Zeit von komplexen Zeichen und Bildbearbeitungsprogrammen wird wieder auf eine alte Technik zurückgegriffen: Pixel für Pixel wird von Hand gesetzt und an das Spieldesign angepasst. Es ist daher immer wieder erstaunlich, was Grafiker mit solch wenigen Bildpunkten für „Kunstwerke“ erschaffen.

Diese Spielgrafiken unterscheiden sich in 2 Hauptkomponenten: Statische Grafiken (Hintergründe, Menügrafiken, Logos) und sogenannten Sprites (Spielfiguren, Cursor, Gegenstände). Sprites sind Grafiken welche im Spielaufbau dynamisch verwendet werden und sich auf Knopfdruck oder Ereignisse hin bewegen. Sprites lassen sich wiederum in statische Sprites (ein Einzelbild) sowie animierte Sprites (Mehrere Einzelbilder die zusammen kombiniert eine Animation ergeben) unterscheiden.

Abbildung: Eine Standardgrafik aus einem Spiel: 8 x 4 Pixel

Test Der Test von Spielen ist enorm wichtig. Eine Absolute Fehlerfreihheit muss garantiert werden. Hierzu zählen zum einen Logikfehler im Spielgeschehen, zum anderen aber auch Tests auf Speicherüberläufe sowie einem unmöglichen Spielerverhalten. Mehrmalige Tastenaktivierungen in Situationen wo diese eigentlich nicht gefordert sind, Test auf Bereichsüberschreitungen und Korrektheit der Software sind wichtig, da nur ein fehlerfreies Produkt zu einem zufriedenen Kunden führt. Ausserdem würde dadurch der Spielspaß erheblich getrübt, was ebenfalls nicht im Sinne des Herstellers sein dürfte.

Ein Test durch externe Personen die nichts mit der Entwicklung zu tun haben, ist ebenfalls sehr wichtig. Spieler sind sehr unterschiedlich und bedienen das Spiel daher auch anderst. Während der eine versucht durch einen langen Tastendruck eine Aktion auszulösen, kann der andere es durch ein mehrmaliges drücken versuchen. Gerade dies sind Situationen die den Entwicklern oftmals nicht auffallen. Dies fällt erst auf, wenn man in die langen Gesichter der Kunden blickt, wenn das Spiel nicht funktioniert.

Portierung Die Portierung der Spiele von einem Gerät auf das andere ist meist sehr schwierig. Wie bereits oben angesprochen sind im Standard weder Sound noch Vibration enthalten, und müssen erst durch herstellereigene Bibliotheken aktiviert werden. Dies erfordert ein ausgefeiltes Framework dass alle nötigen Funktionen kapselt und dem Programmierer in einer Art Schnittstelle alle notwendigen Funktionen anbietet. Im besten Fall muss dann nur noch die Schnittstelle auf das neue Gerät (z.B. bei der Portierung eines Spiels von Siemens auf Nokia Geräte) umgestellt werden, und die Portierung ist abgeschlossen. Da aber meist im Spiel weitere, direkte Herstellerabhängigkeiten stecken ist dies kaum möglich. Zum einen sind dies nachträglich eingebaute Funktionen der Hersteller die vom Framework nicht unterstützt werden und nun von Hand geändert werden müssen. Zum Anderen können dies auch Geräteabhängigkeiten sein die auf unterschiedliche Implementierungen in der virtuellen Maschine beruhen. Alles in allem macht die Portierung der Spiele derzeit am meisten Probleme.

Probleme Wie bereits angesprochen ist die Portierung nicht immer ganz einfach. Fehlende Kooperation zwischen den wichtigsten Geräteherstellern zeigt sich vor allem bei den Virtual Machines. So ist der Zufallsgenerator von Siemens anderst implementiert wie der von Nokia. Auch hat die Nokia Virtual Machine ein ganz anderes Laufzeitverhalten wie die von Siemens. Hier kann es Geschwindigkeitsunterschiede bei der Verarbeitung von diversen Methoden bis Faktor 100 geben. Auch wird ein Aufruf einer Methode auf den Geräten unterschiedlich verarbeitet, was zum plötzlichen Absturz der Software führen kann.

Ein anderes Problem ist der Test auf den erhältlichen Emulatoren. So kann es durchaus Vorkommen dass ein Programm auf dem Emulator wunderbar läuft, auf dem Gerät jedoch seinen Dienst verweigert. Der Emulator für ein bestimmtes Gerät besitzt einen größeren Speicherbereich, Methoden der VM sind anderst implementiert, ausserdem läuft der Emulator um einiges Schneller als das Gerät, dass er eigentlich emulieren sollte. (Besonders Siemens M50 und SL45 Emulatoren)

Ein Technisches Problem bei der Entwicklung stellen die verwendeten Displays sowie die Verarbeitung der Tasten dar. Gerade bei den Massenmarkt – Handys sind die Anzeigen meist von minderer Qualität und „flimmern“ bei einer schnellen Bewegung von Grafiken. Tasten reagieren nicht immer auf einen Druck bzw. reagieren erst verzögert, was zu einem echten Ärgerniss für den Spieler werden kann.

Ein weiteres Problem stellt derzeit das Nokia 3410 dar. Als Handy mit dem größten Anteil am Markt (2002) wird es in Deutschland und Österreich derzeit noch mit einer alten Version seines Betriebssystems verkauft. Dies ist nur bedingt kompatibel zu MIDP1.0. So werden nicht alle Grafiken unterstützt (nur kleine Auflösungen) und das Betriebssystem erlaubt es einer J2ME – Anwendung nicht, Dateien zu schreiben. Zudem springt die Systemuhr unter Last innerhalb einer Minute um bis zu 8 Sekunden vor beziehungsweise zurück. Dies hier sind nur ein paar Beispiele, täglich werden neue Fehler entdeckt: Das Nokia Entwicklerforum wird von der täglichen Flut von Anfragen und Neumeldungen derzeit fast erdrückt.

Fazit J2ME – Games stellen einen interessanten Markt dar, der momentan aber noch in den Kinderschuhen steckt. Immer mehr Java – fähige Handys werden kommen – Der Ruf danach ist sehr groß. Mobile Game Developer schiessen überall auf der ganzen Welt aus dem Boden, Immer mehr Portale bieten J2ME – Spiele an. Was die Zukunft bringt ist klar: Immer bessere Spiele, immer raffiniertere Ideen. Ob sich das Ganze auch für die Entwickler lohnt bleibt abzuwarten. Hier müssen die Gerätehersteller noch einiges an Arbeit leisten.

Thomas Obermaier (2002) [email protected]