• Pac-Man spielen.
• Zur Diskussion bei GitHub.
• Jüngster Tweet zum Thema.

Entstanden ist das Spiel im Rahmen von 140byt.es, einer Art Wettbewerb, bei dem es darum geht, nützliche JavaScript-Funktionen auf Tweet-Größe, also auf maximal 140 Bytes zu schrumpfen. Das Ganze erinnert sehr an meinen 256b.htm-Wettbewerb von 2002, hat aber nicht direkt etwas damit zu tun, auch wenn p01 bei beidem zu den Führenden gehört.

Zwei Dinge haben mich an meinem kleinen Pac-Man-Projekt fasziniert:

• Das Spiel besteht fast ausschließlich aus Elementen, die 140 Bytes oder kleiner sind. Das betrifft die GIF-Grafiken, vor allem aber den JavaScript-Quelltext. Es klingt vielleicht seltsam, aber aus Sicht des Programmierers steht hier tatsächlich die Schönheit des Quelltextes im Vordergrund.
• Aus Sicht des Spieleentwicklers war die Entwicklung der Gegner-KI (selbstverständlich auch in 140 Bytes) am interessantesten. Ich hatte mit zufälligen Bewegungen experimentiert und war damit sehr unzufrieden. War die Bewegung komplett zufallsgesteuert, zappelten die Gegner nur wild auf der Stelle herum. Konstante Vorwärtsbewegung mit zufälligem Abbiegen an Kreuzungen war auch nicht viel besser. Die Gegner sprangen viel zu häufig zwischen zwei Kreuzungen hin und her und bewegten sich zu selten von dort weg. Es war einerseits zu leicht, ihnen aus den Weg zu gehen, andererseits entstand schnell Frust, wenn sich ein Gegner unerwartet plötzlich doch umentscheidet und die Spielfigur tötet. Die Lösung: Gar kein Zufall. Jede Bewegung ist streng deterministisch: Die Gegner bewegen sich stur geradeaus, bis es nicht mehr geht, und dann biegen sie links ab. Das ist alles, und das macht erstaunlicherweise am meisten Spaß, sowohl beim Spielen als auch beim Konstruieren der Levels. Denn man kann dank dessen Levels konstruieren, in denen jede Gegnerbewegung genau festgelegt ist. Man kann Ruhezonen konstruieren, in die sich garantiert nie ein Gegner verläuft. Man kann mehrere Gegner auf verschiedenen Pfaden durcheinander laufen lassen, so dass alles völlig chaotisch wirkt, obwohl es das in Wirklichkeit nicht ist. Der Spieler kann Tastenkombinationen einüben und wird dafür belohnt, da sich der Level auch beim nächsten Versuch mit den selben Handgriffen lösen lässt.

Bei der Weiterentwicklung von Glow 1.5 zu Glow 1.666 habe ich dieses erstaunlich wirkungsvolle Prinzip ein wenig missachtet: Die Gegner laufen verschieden schnell und drehen auch mal um. Allerdings ist Glow auch wesentlich komplexer als Pac-Man und kann etwas mehr Komplexität gut vertragen. Zumindest, wenn sie nicht zu Frust führt. Deshalb ist das zufällige Umdrehen inzwischen auch wesentlich entschärft: Es passiert nur noch sehr selten und wird dem Spieler klar angekündigt. Der Gegner wird sichtbar langsamer, bleibt stehen, dreht um, wartet noch kurz und läuft erst eine Sekunde später wieder los. Und so sind die Gegner am Ende doch wieder genauso deterministisch und vorhersehbar wie die Geister in Pac-Man. Hauptsache, es macht Spaß.

Die genannten Werkzeuge stecken unheimlich viel Rechenaufwand in die Analyse einer PNG-Grafik und versuchen, ein globales Minimum für den komprimierten Datenstrom zu finden. Das Ergebnis kann trotzdem weiterhin mit jedem Webbrowser oder Bildbetrachter geöffnet werden.

Krishty wirft diese Zwänge über Bord und eröffnet sich damit zwei interessante Lösungsmöglichkeiten:

1. Er analysiert die PNG-Grafik nur, findet den perfekten Vorfilter und speichert die PNG-Datei völlig ohne Kompression ab. Die Kompression überlässt er anschließend 7-Zip. Das lohnt sich vor allem bei vielen gleichartigen Grafiken. Diese werden nicht mehr einzeln betrachtet sondern 7-Zip hat die Möglichkeit, ein „solides“ Archiv über alle Dateien zu bilden.
2. Er tauscht den Datenblock innerhalb der PNG-Dateien durch einen eigenen aus, der eine wesentlich aufwändigere Kompressionsmethode nutzt. Diese PNG-Dateien sind dann mit keinem anderen Programm mehr lesbar, nur innerhalb des Spiels, für das sie gemacht wurden.

Für Glow kommt nichts davon in Frage. Interessant ist es aber allemal.

Zum Vergleich fasse ich einmal meine wichtigsten Erkenntnisse zusammen, die ich während der Arbeit an unserem Spiel gewonnen habe. Daraus wollte ich schon lange einen eigenen, extralangen Artikel machen. Das ist er also.

• Ich benutze nur noch PNGOUT, keinen anderen Optimierer mehr. OptiPNG liefert auch ganz gute Ergebnisse, aber im Vergleich habe ich festgestellt, dass PNGOUT unsere 32-Bit-RGBA-Rendergrafiken meist effektiver eindampft. Deshalb spare ich mir den Aufwand, mehrere Tools durchlaufen zu lassen, jetzt ganz.
• Ich lassen PNGOUT immer mit mindestens zwei verschiedenen Filtern durchlaufen. Einmal mit der Automatik /f5, bei der PNGOUT versucht, eine optimale Filtermethode für jede Bildzeile zu finden. Und einmal mit /f0, das heißt ganz ohne Vorfilter. Und eventuell noch einmal mit /f1, dem Filter, der immer das jeweils vorhergehende Pixel zum Vergleich heran zieht. Meist produziert /f5 die besten Ergebnisse, aber bei manchen Bildern sind Durchläufe ohne Vorfilter noch ein paar Prozentpunkte besser. Die Filter 2, 3 und 4 lohnen sich meiner Erfahrung nach dagegen so gut wie nie.
• Wir arbeiten sehr viel mit 32-bittigen Bildern, also mit 24 Bit Farbtiefe und einem 8 Bit Alphakanal. Dort, wo der Alphawert Null ist, ist von den 24 Farbbits nichts zu sehen. Dummerweise speichern manche Programme trotzdem etwas dort ab, obwohl man es überhaupt nicht sehen kann. Aufgefallen ist mir das einmal, als in einer linear interpolierten Grafik plötzlich weiße Pixel an den Rändern aufflackerten. PNGOUT lässt diese unsichtbaren Daten bewusst intakt. Meine Lösung: Ich habe mir ein kleines Tool geschrieben, dass eine PNG-Datei pixelweise durchgeht und überall dort, wo A=0 ist, auch R=0, G=0 und B=0 setzt. Das hat manche Grafiken, die ganz merkwürdigen Datenmüll in ihren transparenten Bereichen enthielten, noch einmal auf die Hälfte reduziert.
• Beim Lesen des ZFX-Beitrags fiel mir noch etwas ein: Man sollte Sprite-Animationen mit vielen gleichartigen Animationsphasen gemeinsam in einem großen PNG-Bild speichern, nicht einzeln, wie wir es bei Glow machen. Das hat mehrere Vorteile: Verringerte Zugriffszeiten auf die Festplatte, schnelleres Laden durch weniger Fragmentierung. Und der Kompressionsalgorithmus kann sein Wissen über die vorhergehende Animationsphase auf alle folgenden anwenden. Ein paar einfache Tests zeigen aber, dass diese eigentlich offensichtliche Idee in vielen Fällen erstaunlich wenig bringt. Teils werden lange Bildstreifen sogar ein paar Bytes größer als die einzelnen Dateien zusammen genommen. Bei sehr vielen, sehr kleinen Dateien kann das aber durchaus noch einmal 20 % einsparen. Wie man die Bilder anordnet (als horizontaler oder vertikaler Streifen oder als Rechteck), ist meinen schnellen Tests zufolge ziemlich gleichgültig.

TTF-Schriftart Shatterboxx Extended herunterladen (42 KB).

Das Original, das man an vielen Stellen im Web findet, sah so aus:

Die wichtigsten Unterschiede:

• Ich habe alle Kleinbuchstaben durch Kopien der Großbuchstaben ersetzt. Nur so sieht der Text vernünftig und einigermaßen lesbar aus, ohne dass man wirklich alle Texte in Großbuchstaben wandeln muss (so wurde es noch in Glow 1.0 gemacht).
• Ich habe versucht, die Umlaute und alle gängigen Zeichen des Zeichensatzes ISO 8859-1 bzw. des zweiten Unicode-Blocks Lateinisch-1, Ergänzung zu ergänzen. Damit ist die Schrift für die meisten westeuropäischen Sprachen brauchbar geworden, einschließlich Französisch, Spanisch, Portugiesisch, Norwegisch usw.
• Der Zeichenabstand, also die Lücken zwischen den Buchstaben, ist etwas höher. Das macht den Text noch einmal etwas besser lesbar. Vor allem die Satzzeichen heben sich nun deutlicher vom restlichen Text ab.
• Der Zerstörungseffekt war bei einigen Buchstaben etwas übertrieben. Dort fehlten ganze Teile. Diese Lücken habe ich aufgefüllt.

Diese Mühe habe ich mir hauptsächlich deshalb gemacht, weil wir Glow in viele andere Sprachen übersetzen wollten. Theoretisch lässt sich unser Spiel sogar ins Japanische übersetzen. Sogar ein komfortables Online-Tool gibt es dafür. Nur gemeldet hat sich leider niemand.

Die wichtigsten Änderungen in Kürze:

• Bildschirmauflösung und Sprache werden beim Start automatisch erkannt.
• Der Spieler startet komplett ohne Waffen ins Spiel.
• Das Einsammeln von Items wird klarer animiert.
• Nach dem Benutzen eines Zauberspruchs wird immer zurück zur vorigen Waffe gewechselt.
• Man kann einfacher kämpfen, während man an einer Leiter hängt.
• Der Spieler wird nicht mehr so einfach von Fahrstühlen zerquetscht.
• Die Gegner drehen nicht mehr ruckartig mitten auf ihrem Weg um sondern bleiben kurz stehen.
• Die Helligkeit einiger Gegner und andere grafische Feinheiten wurden verbessert.
• Das Trigger- und Event-System wurde weiter verbessert und flexibler gemacht.

Von den neuen Gegnern und vor allem Bossgegnern sieht man in dieser Demo absichtlich noch nichts. Das heben wir uns für das fertige Spiel auf.

Hier geht es zum Download (ZIP, 55 MB).