Dirk Ollmetzer | Monday, 15 December 2008 |
DevelopmentSpiele 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.
Das Lustige an den ganzen aufkommenden Microblogging-, Messaging- und Lifestream Diensten ist die Frage, wie man alles unter einen Hut bekommt. Eigentlich muss jeder (Dienst) mit jedem anderen kommunizieren können. Für solche Aufgaben gibt es in der “echten” IT (Banken, Versicherungen usw…) richtig teure Middleware, z.B. von Tibco.
Und was machen wir armen Web2.0-Schmuddelkinder? Wir können jetzt auf Services wie Gnip zurückgreifen. Marco hatte mich neulich bei einer Recherche schon mal daruf hingewiesen, aber da war ich nicht so recht aufnahmefähig. Heute ist auf Golem dazu ein Artikel (“Gnip 2.0 verteilt Daten via Push in XMPP“) erschienen.
Mir stellt sich dabei natürlich wieder die Frage, ob ich Lust habe, alle meine Lifestream-Daten und die meiner Freunde über solch einen Dienst zu routen, der wie die Spinne im Netz sitzt und sich die ganzen leckeren Datenhäppchen anliefern lässt.
Es ist schon witzig: Macht man viel, ist es zuviel, macht man wenig, ist es zuwenig. So langsam verstehe ich, wie MS Office zu der Bloatware verkommen konnte, die es heute ist.
Mehr?
Da entwickele ich noch während des Studiums 2006/2007 ‘ne Software für Kurzmitteilungen im Web und auf dem Handy mit ziemlich vielen Features. Der Grund für die Features war die Erkenntnis, daß mobile Kommunikation vor allem für die folgenden Zwecke verwendet wird: Tratsch, Verabredungen treffen und Verabredungen ändern. Daraus habe ich abgeleitet, daß vor allem Funktionen notwendig sind:
– Kurze Nachrichten (Unterwegs fasst man sich kurz.)
– Gruppenbildung (Mit einer Info gleich der ganzen Clique Bescheid sagen.)
– Ortsangaben (Wo ist die coole Party?)
– Zeitangaben (Wann wollen wir uns zur Party treffen?)
– Informationen zur Situation (So toll sieht es hier aus.)
Ich baue also einen solchen Prototyp, der auch schon leidlich funktioniert, doch es stellt sich heraus, daß die Bedienung zu kompliziert ist – die Leute nutzen so gut wie keines der Features.
Oder weniger?
Dann kommt Twitter und bietet ausschließlich 140-Zeichen Nachrichten an. Der Dienst wird populär, gerade weil er fast nichts kann.
Oder was?
Nach eineinhalb Jahren wird den Leuten scheinbar doch langweilig und sie bauen um Twitter herum eine Menge Funktionen um z.B. Bilder hochzuladen (twitpic), Links weiterzugeben (tinyurl) und ich habe neulich sogar irgendwo ‘nen Service gesehen, mit dem man Musik posten konnte. Jetzt fordert Don Reisinger auf TechChrunch (“Why Twitter Needs to Do More“) auch noch Gruppen für twitter. Damit sind wir jetzt auf dem Stand, auf dem ich vor eineinhalb Jahren schon mal war – nur noch komplizierter, weil alles von verschiedenen Services kommt.
Und was folgern wir nun daraus?
Über meine Arbeit an zzap schreibe ich seit kurzem ja auf einem eigenen Produkt-Blog in englisch. Damit meine werten Leser hier davon überhaupt noch etwas mitbekommen, möchte ich kurz auf die bisher erschienenen Artikel hinweisen:
Microblogging as IM or Webservice? (22.08.2008)
Ein kurzer Vergleich zweier möglicher softwarearchitekturen für Microblogging.
Features of zzap – whats common, whats unique? (15.09.2008)
Ein Überblick, weshalb ich welches Feature in zzap einbaue
zzap.de just updated to version 0.4.127 (14.09.2008)
Kurze Hinweise zur neuen Onlineversion.
Why just another microblogging software? (11.09.2008)
Meine Motivation für die Entwicklung von zzap.
Das offizielle Blog zur MBC09, die am 23. und 24.01.09 in Hamburg stattfinden wird, ist gestartet.
=> MBC09 Blog
Es werden noch Anregungen, Vorschläge und Aktive für Sessions und Workshops gesucht.
Seit heute morgen ist mein Server bei Hosteurope mit allen drei Domains platt. Leider kann ich zur Zeit nichts dagegen unternehmen, da ich hier in Hamburg natürlich keine Unterlagen für den Service zur Hand habe. Echt toll. Ich hoffe, daß sich das mit den Fehlern nicht einschleift.
Ich möchte zwei Neuheiten die zzap betreffen vorstellen:
Zunächst gibt es jetzt für zzap einen eigenen Blog – auf englisch. Ich hoffe, daß mir das die “native speakers” verzeihen können ;-) Alle Neuheiten, die zzap betreffen, werde ich daher nicht mehr hier, sondern dort bekanntgeben:
http://www.zzap.de/blog/index.php.
Zudem ist ab heute abend eine neue Version online, deren wichtigste Neuerung ein Pluginsystem ist. Alle Funktionen für die Kommunikation mit anderen Diensten sind ab nun in separaten Modulen zu finden. Zur Zeit gibt es zwei: Eines für Twitter und eines für die Anbindung von Blogs. Weitere sollen natürlich folgen.
Nachdem twitter gezeigt hat, daß Kurznachrichten auch dann sinnvoll sein können, wenn sie nicht an ein bestimmtes Handy, sondern “einfach so in die undefinierte Allgemeinheit” im Internet gesendet werden, fängt der ganze Bereich an, so richtig spannend zu werden. Es wird viel experimentiert und programmiert. Ich bin mit meinem Projekt zzap ja beileibe nicht der Einzige, der in diesem Bereich unterwegs ist.
Sehr interessant ist der Dienst identi.ca, bzw. die dahinterstehende Open-Source-Software laconi.ca. Beide sind von den Digerati recht begeistert aufgenommen worden. Genauso wie bei twitter zeigt sich nun, daß in rasanter Geschwindigkeit Erweiterungen rund um diesen Service entstehen wie man auf dem Wiki von laconi.ca sehen kann.
…und wie geht’s jetzt weiter?
Einige Gedanken dazu hat sich Sean Carmody in dem Artikel “The Future of Microblogging” gemacht, der am Wochenende in den einschlägigen Blogs zitiert wurde.
Bei uns in Deutschland macht sich u.a. Cem Basman nicht nur sehr viel Gedanken zum Thema Microblogging, wie man auf seinem Blog nachlesen kann, sondern er hat auch noch spontan die MBC09 Microblogging Conference (Hamburg, Fr 23.1./ Sa 24.1.2009) organisiert.
Maßgeblich für den weiteren Erfolg werden meines Erachtens vor allem zwei Dinge sein:
- Ein offenes Protokoll zum Austausch zwischen verschiedenen Diensten. Kommunikationsdienste müssen immer interoparabel sein um wirklich Erfolg zu haben, wie z.B. Telefon und E-Mail zeigen. Laconi.ca hat da mit seinem offenen Protokoll schon mal einen guten Grundstein gelegt.
- Neue sinnvolle Dienste und Anwendungen auf der Basis dieses offenen Protokolls sprechen immer mehr ‘normale Menschen’ an (und nicht nur uns Info-Junkies).
Ich wette, daß wir gerade beim zweiten Punkt in der nächtens Zeit sehr viele neue und gute Ideen sehen werden. Microblogging wird immer spannender…
Seit heute Mittag funktioniert zzap endlich wieder. Die Ursache waren völlig verstellte Dateiberechtigungen, so daß der Webserver nicht mehr an die richtigen Dateien herankam. Wie sowas von einer Sekunde auf die Andere passieren kann, ist mir aber immer noch schleierhaft. Noch seltsamer finde ich aber, daß ich die entsprechenden Verzeichnisse selber zunächst gar nichts angerührt hatte und mir bei der Fehlersuche sogar die richtigen Berechtigungen angezeigt wurden. Der Support sah aber etwas anderes und hat es wieder korrigiert. Danke!
Bei der Gelegenheit möchte ich noch auf eine Neuerung hinweisen: Neue Blogeinträge werden nun auch auf meinem zzap-Konto mit Link angekündigt.
Seit heute abend sind zwei meiner Domains nicht mehr per Browser erreichbar: dirk-ollmetzer.de und zzap.de.
Das Problem erschließt sich mir nicht auf den ersten Blick und auf den zweiten auch nicht.
Jetzt kann ich nur auf den Support hoffen und warten. Das Ticket ist geschrieben und ich gehe jetzt nach zwei Stunden Fehlersuche mit schlechter Laune ins Bett.
« Previous Page — Next Page »