kuarepoti-dju - the josef multilingual blogosphere

Die Festplatte meines Backup-Rechners gibt mir bekannte Geräusche von sich und das gefällt mir nicht. Zwar sind die Backups nicht in Gefahr (wozu gibt es Redundanz?) aber es ist ja auch schon die zweite Festplatte. Getreu einem Sketch von Rüdiger Hoffmann (ham’ Sie wohl meinen Huuund geseh’n?) darf ich dann wohl eine Umtaufung vornehmen.

Somit bin ich nun ein rechnerloser Informatiker. Wenn ich jetzt zu den Theoretikern überlaufe, fällt das vermutlich gar nicht auf, aber so fehlen mir doch die Tasten.

Darüber hinaus bin ich aber auch Weltoptimist ™. Und da ich auf eine baldige Rechnerschenkung hoffe, habe ich mir schon einmal das jigdo-ISO von einer aktuellen Version des zukünftigen Debian/etch gezogen. Muss ja nicht immer Kubuntu sein.
Zwar ist jigdo als Ubuntu-Paket verfügbar, aber da ich mich bei der Suche vertippte, war das Paket schneller selbst gebaut als der Fehler korrigiert. Dabei ist das Quellpaket auch nicht fehlerfrei:

In Datei, eingefügt von glibcurl/glibcurl.c:28:
./glibcurl/glibcurl.h:34:23: Fehler: curl/curl.h: No such file or directory
In file included from glibcurl/glibcurl.c:28:
./glibcurl/glibcurl.h:45: Fehler: syntax error before »*« token

Jigdo hat dann allerdings auch brav alle Debian-Pakete heruntergeladen und in eine ISO-Datei umgewandelt. Irgendwie sollte man derartige Tools mit Konzepten wie Morphix zusammenführen, auf der interessanterweise mittlerweile auch die BSI-Sicherheits-CD beruht.

Nun warte ich also auf einen Rechner und dann gibt es auch brav mein Uni-Projekt Dynvoker 1.1 sowie GGZ 0.0.14 als neue Releases. Bis dahin erstmal frohe Weihnachten.

A week ago I mentioned some of the multiplayer plans. I deliberately left out any mention to ggzcomm, the code generator for abstract game protocol descriptions, mostly because the parts of it which are relevant to KDE games were not really implemented yet. This has changed!

The aim of ggzcomm is to declare that the networking code is not the business of the network game developer anymore. Crafting networking code by hand is nice and all, but it often leads to errors which go undetected, often resulting in security flaws which have to be fixed again and again.
Furthermore, especially in the world of GGZ a lot of games come with several frontends. Changing the protocol requires code changes to any of them.

Enter ggzcomm. It was born about four years ago as I could not find any similar tool (and I still haven’t found any for FLOSS development specifically while there are a lot of higher-level MDA thingies around).

Currently, opcode-based messaging can be generated for C+, C++, Python and Ruby, using a variety of networking libraries. Those will be run-time dependencies whereas ggzcomm itself (which is a couple-thousands-line-of-code ruby script) is not of course.
For Python and Ruby as target languages we could of course implement some cool runtime adaptation stuff once the development is stabilising a bit.

XML-based messaging can be switched on as an option at least for C++ and Python. This is a very new feature which is useful for debugging. Of course, for production use one switches back to opcode-based messaging. XML is nice, but huh, what about the performance penalty and TCP/IP traffic overhead? Interoperability is still ensured by having a source in XML, without falling into the SOAP/XML messaging trap.

Right now ggzcomm handles sequences, loops and conditions. A must-have features are safety code injections. For example, if a loop is iterating over all players in a Chinese Checkers/Halma game, the number of loops can be constrained to be no lesser than two and no more than six.

It might not be the solution to all games, and granted, auto-generated code always looks kind of ugly since taste differs. But my wish is that where it is possible to use auto-generated networking code, we should use it.

For a couple of months now the KDE Games Breeding Area has been surprisingly active again. One of the initial reasons certainly was the need to get something done for KDE 4, but then it all comes together and one idea follows the other pretty quickly. Several topics are being worked on in parallel and both regular meetings and casual talk happens on IRC (irc.freenode.net #kdegames).

While I better don’t contribute “fancy” self-drawn icons, there is something really missing from all of kdegames and this is a community-oriented gaming framework - one where you can simply chat up your friends to join you in slashing and ripping apart evil monsters (translation for kids: to roll a dice or two).
Now it happens that there was the kggzmod library dormant in GGZ SVN and I took the chance of finishing its implementation, which is for KDE 3. That being done, it not only was equipped with full API docs but also a KDE 4 port.

The example game (KConnectX) has also been ported to KDE 4. What still needs porting is the GUI framework around kggzmod, which includes a seats dialog for player management and statistics, maybe also a common chat dialog and for the future a connection dialog for individual games, for people who want to launch them from KDE’s menu instead of from GGZ core clients.

The long-term roadmap is to overhaul the ggzcore++ library as well so both the KDE core client (kggz) can be made more attractive and the games can run in the embedded ggzcore mode which allows them to have a connection dialog on their own in the first place. But this is rather targeted at KDE 4.1 I’d say, as I think I’ve got some other obligations.

More on that over the weekend…