Mehr Spaß mit mehr Spielern

Entwicklung von Multiplayer-Spielen mit MIDP

David Price und dem Forum Nokia Team

MIDP (Mobile Information Device Profile) ist ein Profil der Java Micro Edition (Java ME), das inbesondere auf die Fähigkeiten kleiner mobiler Endgeräte ausgelegt ist. Eine davon – und das zudem eine sehr reizvolle – ist die Entwicklung von Multiplayer-Spielen für MIDP-Handys. In unserem Beitrag beschreiben wir die Grundlagen und die verschiedenen Technologien, die zur Verfügung stehen, um Multiplayer-Spiele zu entwickeln, und zeigen auf, welche Arten von Spielen mit diesen Technologien realisierbar sind und welche nicht.

Es existieren bereits zahlreiche unterhaltsame und innovative Single-Player-Spiele für das Mobile Information Device Profile (MIDP). Aber was MIDP-Handys zu wirklich besonderen Spielgeräten macht, ist ihre einzigartige Online-Funktionalität und die Tatsache, dass Spieler sie jederzeit mit sich tragen. Dieses Szenario wird noch viel interessanter, wenn mehr Entwickler beginnen, Multiplayer-MIDP-Spiele zu entwickeln.

Hinsichtlich den User-Interface-Möglichkeiten von MIDP-Telefonen gibt es zwei Arten von Screens: Das sind zum einen die High-Level UI Screens, die strukturierte Informationen und Formulare anzeigen und deren Layout vom Handy selber erstellt wird, und zum anderen Low-Level UI Screens, die lediglich ein Canvas darstellen, auf dem das MIDlet beliebig Grafikinhalte ausgeben kann (Abb. 1 und 2).

Abb. 1: Beispiel für High-Level UI Screens

Abb. 2: Beispiel für Low-Level UI Screens

Mit dem proprietären Nokia UI API ist man in der Lage, den gesamten Screen des Handys auszunutzen. Ein Beispiel hierfür zeigt Abbildung 3. Die auf den Markt gekommenen MIDP 2.0-Handys bringen diese Full-Screen-Fähigkeit aber inzwischen standardmäßig mit sich (Abb. 3). Der einfachste Ansatz für Multiplayer-Spiele ist, dass mehrere Spieler ein Spiel auf dem gleichen Handy spielen, das sie während des Spiels untereinander weitergeben. Dies funktioniert gut bei einfachen zugbasierten Spielen, ist zuverlässig und verursacht keinerlei Kosten für die Datenübertragung (Abb. 4).

Abb. 3: Beispiel für einen Nokia UI API FullCanvas Screen

Abb. 4: MIDP HTTP Networking
Kommunikation per HTTP

Eine Alternative bietet die Kommunikation per HTTP, die von allen MIDP-Handys unterstützt wird. Eine vollständige Beschreibung und ein Codebeispiel, wie man HTTP in MIDP (und Java Servlets auf der Serverseite) verwendet, findet man im Nokia.com-Forum. Die HTTP-Unterstützung, die in MIDP vorgeschrieben ist, ist die HTTP-Client-Unterstützung. Das bedeutet, dass das MIDlet wie ein Webbrowser agiert. Es sendet einen HTTP Request an den HTTP Server und erhält eine HTTP Response zurück. Das ist alles, was der HTTP-Standard garantiert, und alles, auf das sich das MIDlet verlassen sollte. Im Detail bedeutet dies, dass MIDlet-Programmierer manchmal den Fehler machen, sich auf die folgenden Features der Internet-HTTP-Implementierung zu verlassen, die in Mobilfunknetzwerken normalerweise nicht funktionieren:

  • HTTP Streaming: Da Internet-HTTP-Implementierungen auf dem Streaming-TCP-Protokoll aufsetzen, können sie sich dies zunutze machen und ununterbrochene Streams von Daten über HTTP übertragen. Mobilfunknetze können jedoch auch eine Nicht-TCP-Implementierung (z.B. WAP) verwenden, die möglicherweise kein Streaming unterstützt. Viele Mobilfunknetze warten ab, um einen kompletten Request oder Response zu puffern, bevor sie ihn senden und so scheitern HTTP Streaming MIDlets normalerweise, wenn sie auf realen Handys in diesen Netzwerken betrieben werden sollen. Aus dem gleichen Grund sollte man nicht versuchen, Daten in kleinen Stücken zu übermitteln, da unter Umständen nichts empfangen wird, bis alle Daten gesendet wurden.
  • verzögerte Response: Ein anderer Trick, den MIDP-Entwickler oft versuchen anzuwenden, wenn sie merken, dass HTTP Streaming nicht funktioniert, ist, das Senden der HTTP Response vom Server zu verzögern, bis ein bestimmtes Ereignis eintritt (z.B. der Zug eines Gegenspielers). Eine offene Verbindung kann in einem Mobilfunknetz kostenintensiv sein und inaktive Verbindungen werden üblicherweise wesentlich schneller durch ein Time-out beendet, als dies im Internet passiert.
  • multiple HTTP-Verbindungen: Mobiltelefone haben oft nicht die Ressourcen, um mehrere offene HTTP-Verbindungen zu unterstützen, da diese sehr kostspielig in Bezug auf Datenstrukturen und Datenpuffer sein können.

Das Fazit, das sich aus diesen Punkten ergibt, ist, dass man, wenn man sein MIDlet zuverlässig und portabel halten möchte, daran festhalten sollte, einen Request zu senden und auf dem Server umgehend mit einem Response zu antworten. Ein HTTP Server hat keine Möglichkeit, eine Verbindung zu einem HTTP Client aufzubauen. Wenn der HTTP Server das MIDlet-Spiel über ein Event informieren muss (etwa wenn der andere Spieler seinen Zug ausgeführt hat), dann muss das MIDlet in periodischen Abständen „pollen“, indem es einen HTTP Request an den Server sendet.

Mobiles HTTP Networking ist für kleine Mengen an Daten, die Spiele typischerweise übertragen, nicht teuer, besonders dann, wenn sie über Paketdatenprotokolle wie GPRS implementiert sind. MIDP 1.0 spezifiziert keine Unterstützung für irgendein Netzwerkprotokoll außer HTTP. Trotzdem unterstützen einige MIDP 1.0-Handys andere Protokolle wie zum Beispiel TCP Sockets. Wenn man sicher ist, dass man lediglich diese Handys adressieren will, kann man die Portabilität opfern, um den Vorteil dieser Features nutzen zu können.

MIDP 2.0-Kommunikationstechnologien

HTTPS ist „sicheres HTTP“, das beispielsweise von E-Commerce-Diensten im Internet eingesetzt wird, und muss von MIDP 2.0-Implementierungen unterstützt werden. Das Transmission Control Protocol (TCP) ist eines der grundlegenden Protokolle des Internets. Es ist ein zuverlässiges, verbindungsorientiertes Protokoll, was Folgendes mit sich bringt:

  • Daten, die gesendet werden, werden immer einmal in der korrekten Reihenfolge und fehlerfrei empfangen (ansonsten schlägt die Verbindung möglicherweise fehl).
  • Eine Verbindung wird zwischen den beiden kommunizierenden Maschinen aufgebaut und für die gesamte Dauer der Kommunikation aufrechterhalten.

Eine übliche Analogie ist, dass sich eine TCP-Verbindung wie ein Telefonanruf zwischen zwei kommunizierenden Maschinen verhält. Im Internet wird HTTP üblicherweise mithilfe von TCP implementiert. Ein Socket bezeichnet den Endpunkt einer TCP-Verbindung. Ein Server Socket auf einem TCP Server nimmt hierbei neue Verbindungsanfragen entgegen und erstellt einen neuen Socket für jede Anfrage. Die Zuverlässigkeit von TCP vereinfacht oft das Programmdesign erheblich. Wenn es jedoch über ein unzuverlässiges Netzwerk verwendet wird, dann kann die Performanz unter Umständen signifikant schlechter sein als bei Verwendung des User-Datagram-Protokolls, auf das wir später noch genauer eingehen werden. Wenn ein Paket verloren geht, versucht TCP nämlich, es erneut zu senden, und liefert keine nachfolgenden Pakete, solange das verlorene Paket nicht erfolgreich übertragen wurde. Wenn man dieses zuverlässige Wiedersenden nicht benötigt, ist der Einsatz von UDP möglicherweise sinnvoller. Während MIDP 1.0 keine Unterstützung für TCP enthält, spezifiziert MIDP 2.0 den TCP-Support, stellt es dem Hersteller jedoch frei, ihn auf dem Gerät zu implementieren. Das User-Datagram-Protokoll ist also ein weiteres fundamentales Protokoll des Internets und ist ein „unzuverlässiges“ paketorientiertes Protokoll, was bedeutet:

  • Gesendete Datenpakete können einmal, mehrmals, nie oder sogar in einer falschen Reihenfolge empfangen werden.
  • Es besteht keine Verbindung zwischen den kommunizierenden Maschinen. Jedes Paket wird individuell adressiert.

Eine beliebte Analogie ist hierbei, dass sich UDP-Pakete wie Briefpost verhalten, wobei die Datenpakete mit Briefen oder Postkarten vergleichbar sind, die zwischen den kommunizierenden Maschinen verschickt werden. Der Begriff „Datagram“ bedeutet in diesem Fall einfach Datenpaket. UDP verursacht sehr wenig Overhead bei der Kommunikation und ist im Allgemeinen die effizienteste Netzwerktechnologie. Viele Anwendungen benötigen nicht die Zuverlässigkeit von TCP, besonders dann, wenn Daten zeitkritisch sind. Beim Video Streaming ist es beispielsweise oft besser, ein Paket zu verlieren, anstatt Folgepakete aufzuhalten, um ein bereits veraltetes Paket erneut zu übertragen.

Es wird oft diskutiert, ob das UDP- oder das TCP-Protokoll besser für Spiele geeignet ist. Die lange Latenzzeit von Mobilfunknetzen neigt dazu, den Unterschied zwischen den beiden Protokollen zu verstärken. Weitere Informationen hierüber findet man bei Multitude’s Fireteam. Zwei übliche Lösungsansätze sind:

  • Verwenden Sie beide Protokolle – UDP-Datagramme für Nachrichten, die nicht zuverlässig sein müssen, und eine TCP-Verbindung für Nachrichten, die zuverlässig sein müssen.
  • Nutzen Sie nur UDP, aber implementieren Sie einen dünnen Layer darüber, der es erlaubt, bestimmte Nachrichten zuverlässig zu übertragen und andere nicht. Dieses Verfahren wird im User Datagram Protocol RFC 768 beschrieben.

Mobiles UDP Networking ist für kleine Mengen an Daten, die Spiele üblicherweise übertragen, nicht teuer, wenn es über ein Paketdatenprotokoll wie GPRS implementiert wird. Unter der Berücksichtigung der Latenzzeit mobiler Netzwerke ist es normalerweise nicht nötig, Pakete öfter als einmal pro Sekunde zu senden. Wenn man Pakete häufig versendet, sollte man auf ihre Größe achten und sie nicht unnötig verschicken. MIDP 1.0 enthält keine Unterstützung für UCP. MIDP 2.0 hingegen spezifiziert UCP Support, aber stellt es dem Hersteller frei, ihn mit zu implementieren.

Einsatz eines seriellen Kabels

Abb. 5: Kommunkation zwischen zwei Handys mithilfe eines seriellen Kabels

Der Einsatz eines seriellen Kabels erlaubt es zwei Spielern, miteinander zu spielen, vorausgesetzt, sie befinden sich am gleichen Ort. In MIDP 2.0 kann die Kommunikation über ein serielles Kabel zwischen zwei Handys durch das Interface SerialPortConnection unterstützt werden (Abb. 5).

Kommunikation per Infrarot

Abb. 6: Infrarotkommunikation zwischen zwei Handys

Der Einsatz von Infrarot (IrDA) erlaubt es zwei Spielern zusammenzuspielen, wieder vorausgesetzt, dass sie sich am gleichen Ort befinden. Die Handys müssen dazu still gehalten werden und die Infrarot-Ports aufeinander ausgerichtet sein. Dies kann ziemlich trickreich werden, sobald das Spiel beginnt, aufregend zu werden. Einige Handys haben einen Infrarot-Port oben, andere auf der linken Seite und wieder andere auf der rechten Seite. Dies kann es für zwei Spieler schwierig machen, eine komfortable Spielposition zu finden. In MIDP 2.0 kann die Infrarotkommunikation zwischen zwei Handys ebenfalls durch das Interface SerialPortConnection unterstützt werden (Abb. 6).

MIDP 1.0- und MIDP 2.0-Handys können verschiedene optionale Packages mit zusätzlicher Funktionalität enthalten. Im Folgenden wollen wir uns die Kommunikationstechnologien, die durch diese optionalen Packages bereitgestellt werden, einmal etwas genauer anschauen.

Bluetooth

Abb. 7: Kommunikation zwischen mehreren Handys per Bluetooth

Bluetooth ist eine Kurzstreckenfunktechnologie, die es bis zu acht Geräten erlaubt, über eine Reichweite von ungefähr zehn Metern miteinander zu kommunizieren. Bluetooth hat eine kurze Latenzzeit und ist für Multiplayer-Spiele sehr geeignet. Es wird extensiv von Multiplayer-Spielen auf dem Nokia N-Gage mobile Game Deck verwendet. Die Handys müssen nicht aufeinander ausgerichtet sein, da Bluetooth in alle Richtungen sendet. In MIDP-Handys kann Bluetooth durch das optionale Package Java API for Bluetooth (JSR 82) unterstützt werden (Abb. 7).

Geschrieben von
David Price und dem Forum Nokia Team
Kommentare

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht.