Make: Block – Neue Hard- und Software

In Make 04/16 haben wir aus 300 RGB-LEDs, einem Ikea-Bilderrahmen und dem Arduino ein Spiel der besonderen Art gebaut. Obwohl wir damals das Spiel kräftig aufgebohrt hatten, waren von den 32 Kilobyte Speicher des Arduino nur knapp 50% benutzt. Wir haben uns ein paar Gedanken gemacht, wie sich die zweite Hälfte sinnvoll nutzen lässt. Das Ergebnis steht auf Github zur Verfügung (erreichbar über den Kurzinfo-Link) und kann mit der Arduino-IDE auf den Mikrocontroller im Make:Block beziehungsweise im neuen Game­Frame-Bausatz (siehe Kasten auf der nächsten Seite) übertragen werden.

Dabei sind wir ein weiteres Mal in der Retro-­Kiste fündig geworden und haben uns den Superklempner Mario näher angeschaut. Auch wenn das Original aus dem Pixel-Mittelalter der Konsolengrafik stammt, liegt die Auflösung mit 256 × 240 = 61440 Pixeln doch schon deutlich über den 300 Pixeln unserer Hardware. Mit ihren 300 einzeln mit 24-Bit-Farbtiefe ansteuerbaren LEDS übertrifft sie aber immerhin die Farbfähigkeiten des Originals mit seinen 16 aus 52 gleichzeitig darstellbaren Farben.

Minimalismus

Hätten wir die Mario-Grafik in voller Pracht beibehalten, dann würde die Spielfigur allein den Bildschirm bereits vollständig füllen, wie ein Screenshot des Splash-Screens zeigt 1.

Daher mussten wir die Grafik so weit wie möglich reduzieren. Um das ganze Spielfeld auf den Ikea-Rahmen beziehungsweise den neuen Bausatz GameFrame (siehe Kasten auf der nächsten Seite) zu bekommen, musste jedes der aus Tiles und Sprites aufgebauten Grafikelemente des Spiels maximal vereinfacht werden: Jeweils nur noch ein Pixel durften sie groß sein und selbst aus Mario wurde nur noch ein einzelnes rotes Quadrat. Die Frage ist, ob mit soviel Minimalismus noch ausreichend Mario-Spielspaß übrig bleibt. Wir haben es ausprobiert. Wie beim Tetris wollten wir auch bei Mario möglichst viel des Origi­nallooks erhalten. So haben wir durch Einschrumpfen des ersten Mario-Levels 2 auf 1/16 seiner Auflösung und ein wenig manueller Nachbearbeitung einen insgesamt nur 212 × 13 Pixel großen Level mit überraschendem Wiedererkennungswert geschaffen 3.

Datensparsamkeit

Mit der Reduzierung der Auflösung verringerte sich auch die Datenmenge. Auf diesen Umstand waren wir bei gerade mal 16 Kilobytes verfügbarem Programmspeicher dringend angewiesen, schließlich wollten wir ja auch auf unser Tetris nicht verzichten. Trotzdem wurde es sportlich. Der Level aus 212 × 13 Pixel zu je 24 Bit hätte über 8000 Bytes benötigt, wenn wir ihn direkt gespeichert hätten. Ohne eine einzige Zeile Spiellogik wäre dadurch schon die Hälfte des zur Verfügung stehenden Speichers verbraucht. Die Daten mussten also noch weiter reduziert beziehungsweise komprimiert werden.

Zur Lösung dieser Aufgabe schrieben wir das kleine Analysetool png2level. Es nahm sich das 212 × 13-Bild vor und suchte darin nach Wiederholungen und mehrfach verwendeten Mustern. Findet es zum Beispiel eine horizontale Reihe aus braunen Blöcken, merkte es sich lediglich, wo diese Reihe beginnt und wie lang sie ist. Ähnliche Informationen sammelte es über alle anderen Objekte und nur diese Informationen wurden auf dem Arduino gespeichert.

Das Resultat: wenige hundert Bytes ab­strakter Informationen, die in der Datei mario_lvl.ino liegen. Erst zur Laufzeit baut der Arduino daraus wieder die aktuelle Sicht des Levels zusammen. Bei der Analyse des Level-Bildes am PC wurden auch Eigenschaften der einzelnen Grafikteile bestimmt und gespeichert. So weiß der Arduino nun auch, welche Bestandteile des Levels reine Deko sind (etwa Wolken oder Grünzeug) oder feste Sub­stanz haben und unseren Mario am Fallen beziehungsweise Weiterlaufen hindern (wie Steine, Treppen, Röhren, …).

Nur über die Farbgebung einzelner Pixel zwischen den diversen Spielelementen zu unterscheiden, ist nicht ganz einfach. Zur Erleichterung flackern daher zum Beispiel alle Objekte zusätzlich, die Mario sammeln sollte (wie Münzen oder Pilze). Der RAM-Speicher von nur 2kByte im Arduino stellt übrigens keine zusätzliche Beschränkung dar. Seine Nutzung hat sich sogar gegenüber der reinen Tetris-Variante verringert, da wir die meisten Speicherbereiche nun mehrfach nutzen und der gleiche Speicher vom Titelbild und den beiden Spielen genutzt wird. Es läuft schließlich immer nur eines davon zur Zeit.

Der größte Unterschied zum Originalspiel ergibt sich aber aus der Tatsache, dass wir nur einen Spiel-Level implementiert haben. Während selbst die besten Spieler über 20 Minuten brauchen, um einmal durch das gesamte Original-Spiel zu hetzen, ist man bei uns schon nach wenigen Sekunden am Ziel. Da unser Spielerahmen sowieso eher im Partykeller hängt und auf kurzen Spielspaß ausgelegt ist, passt hier der maximale-Punkte-in-kürzester-­Zeit-Ansatz sehr gut. Ziel ist es, möglichst viele Münzen zu sammeln und Goombas in möglichst kurzer Zeit zu plätten.

Apropos Party: Musik bietet unser Spiel natürlich auch. Wie bereits beim Tetris lässt es sich aber zur Ohren- und Nervenschonung im Setup abschalten. Zur Erinnerung: Das Setup erreicht man, wenn beim Einschalten des Gerätes die Feuertaste gedrückt ist. Dort lässt sich dann die Lautstärke und die Bildhelligkeit ändern.

Die Wahl zwischen Tetris und Mario erfolgt erst am Start-Bildschirm. Hier kann man durch die Bewegung des Joysticks nach links oder rechts zwischen beiden Spielen wählen.

Die HiScores werden für jedes Spiel separat gespeichert, so dass ein gegebenenfalls bereits vorhandener Tetris-HiScore durch das Firmware-Update nicht überschrieben wird.

Stromhunger

Da Mario sehr viel mehr Pixel einschaltet als Tetris, ist der Stromverbrauch deutlich höher. Hier hilft wieder unsere Linux-Simulation aus (siehe Mehr zum Thema in der Kurzinfo). Sie sagt für Mario bei maximaler Helligkeit einen Strom von maximal 8,8 Ampere voraus. Betreibt man den Make:Block also wie wir an einem 4A-Netzteil, so sollte man die Helligkeit im Setup-Menü höchstens auf etwas unter 50 Prozent einstellen. Im GameFrame-Bausatz ist ein entsprechend stärkeres Netzteil enthalten.

Trotz des zweiten Spiels haben wir übrigens immer noch mehr als 7 Kilobytes beziehungsweise 25 Prozent Flash-Speicher frei. Ein paar Optimierungen zum Beispiel bei der Speicherung des Titel-Bildes könnte uns vielleicht nochmal ein gutes Kilobyte verschaffen. Einem dritten Spiel steht daher prinzipiell nichts im Wege. Wer weiß, was noch kommt … —hgb