Comet – Server Push auf den Browser

Spiele waren schon immer die Königsdisziplin der Softwareentwicklung: Man benötigt eine gute Story, tolle Grafik, knackigen Sound, und flüssige Animationen. Die Programmierung geht dabei meistens bis an die Grenze des technisch machbaren. Letzte Woche habe ich mich über den aktuellen Stand bei Browsergames informiert und einen Blick auf einige Projekte von Bigpoint, Gamesforge und Konsorten geworfen. Browsergames – sind Multiuserspiele, die ohne Softwareinstallation gespielt werden können, da sie nur einen aktuellen Webbrowser voraussetzen. Die Rede ist hier aber nicht von irgendwelchen 5min-zwischendurch-Flash-Spielchen, sondern von ausgewachsenen Strategie- oder Simulationsspielen. Das ist übrigens eines der wenigen Felder, wo Deutsche Entwickler seit Beginn an ganz an der Spitze mitmachen.

Das letzte Mal, als ich mir dieses Genre bewusst angesehen habe, war so ungefähr 2002, als ich auf der Suche nach einem neuen Betätigungsfeld war. Damals hatten die Spiele noch ungefähr den Charme einer aufgeborten Excel-Tabelle. Sie waren damals auch fast ohne Ausnahme Hobbyprojekte. Die alten Spiele waren alle rundenbasiert. Das bedeutet, die Spieler geben alle ihre Spielzüge ein und der Server berechnet dann nach einer bestimmten Zeit den neuen Spielzustand. Diese sogenannten “Ticks” konnten wenige Minuten oder auch mehrere Stunden dauern. Das ist im Vergleich zu normalen Computerspielen zwar sehr ungewöhnlich, für Strategiespiele oder Wirtschaftssimulationen aber völlig O.K.

Mittlerweile sieht man die Professionalisierung der Branche sehr deutlich. Die Spiele, die ich neulich sah, hatten nicht nur gute (2D-) Grafiken und Animationen, sondern verblüfften mich dadurch, daß ich die Raumschiffe mehrerer Spieler gleichzeitig durch das All fliegen sah – ganz wie bei normalen Spielen.
“Ja und? Was ist daran so aussergewöhnlich?” mag jetzt der Eine oder die Andere fragen.

WOW – oder: Der Ausbruch aus dem HTTP Frage-Antwort-Schema

Die Beschränkung der alten Spiele auf rundenbasierte Spieltypen hatte einen guten Grund: Die Beschränkung der Browser auf das Hyper Text Transfer Protocol (http). Dieses sehr einfache Protokoll wurde Anfang der 90er Jahre ursprünglich nur dazu entwickelt, Dokumente – meist HTML-Seiten – zu übertragen. Dementsprechend simpel funktioniert es. Etwas vereinfacht:

Der Browser öffnet eine Verbindung zum Server, schickt die Anfrage nach einem bestimmten Dokument, der Server schickt das Dokument zurück und schließt die Verbindung – Ende.

An diesem grundlegenden Verfahren ändert auch das in den letzten Jahren gehypte AJAX nichts. Der einzige Unterschied liegt darin, daß nun nicht mehr das gesamte Dokument auf einmal angefragt wird, sondern nur einige zu ändernde Teile quasi im Hintergrund. Das Prinzip “Browser fragt, Server antwortet, Ende der Kommunikation” bleibt dabei bestehen. Das führt zu einer einfachen Frage:

How to push: “Wie kann der Server den Browser über eine Zustandsänderung unterrichten?”

Wenn Mitspieler Ihre Raumschiffe bewegen, ändert sich der Spielzustand. Darüber müssen nun alle Beteiligten möglichst ohne (spürbare) Verzögerung unterrichtet werden. Wie geht das aber, wenn die Anfragen immer vom Browser ausgehen? Der Browser weiss ja nichts davon, daß eine neue Nachricht für ihn bereitliegt. Eine theoretische Möglichkeit liegt darin, daß die Browser in sehr kurzen Zeitabständen den Spielstand abfragen. Das ist in der Praxis allerdings keine gute Idee. Einerseits würden auf diese Art bereits wenige Spieler ausreichen um den Server in die Knie zu zwingen und zweitens wären die Verzögerungen noch immer deutlich spürbar. Es wird eine Art Server-Push benötigt.

Alte Handwerkerregel: Was nicht passt wird passend gemacht.

In der Spiel-Programmierung gibt es einen alten Trick: Wenn etwas technisch nicht geht, mach etwas anderes, das genauso aussieht. ;-)

Wir wollen, daß der Server den Browser genau zum richtigen Zeitpunkt eine Nachricht sendet. Wenn der Server nun den Browser nicht von sich aus ansprechen kann, machen wir es eben genau andersherum. Der Browser fragt nach dem neuen Spielzustand und der Server lässt sich mit der Antwort genau solange Zeit, bis der neue Spielzustand erreicht ist. Daß das theoretisch möglich ist, wusste ich zwar schon länger, und daß zumindest Bigpoint so etwas bereits programmiert hat auch. Zum ersten Mal die konkrete Umsetzung zu sehen hat aber schon etwas. Und weil ich ein neugieriger interessierter Mensch bin, möchte ich auch wissen, wie man so etwas macht. Dabei bin ich heute über den Befriff “Comet” für diese Technik gestolpert und musste auch gleich mal ein bischen rumprobieren.

Dem interessierten Leser kann ich zum Einstieg die folgenden Websites empfehlen:

• News rund um Browsergames bei Galaxy-News
• Comet Daily – ein Blog, zu der Pseudo-Push-Technik Comet
• Ein kleines praktisches Beispiel zum Einstieg gibt der Artikel “How to implement COMET with PHP” auf dem Blog Zeitoun.net – auch wenn ich ehrlichweise zugeben muss, daß ein Java Application Server wesentlich besser für diese Technik geeignet ist, als PHP.