Pixelor

Ich habe die letzten Tage immer mal wieder (endlich!) an dem Spiel weiter programmiert, welches ich als Artikel-Serie hier auf Pixelor.de entwickle (siehe hier: Retro Game Programming). So langsam nimmt das Ganze Gestalt an. Die ganzen Routinen für Treffer, Score und so weiter funktionieren alle schon. Völlig überrascht bin ich, dass ich jetzt erst bei 1,5 KByte bin. Meine selbstgesteckte Grenze von 4 KByte für das komplette Spiel könnte ich also tatsächlich einhalten.

Ein wenig Respekt habe ich noch vor den Sound-Routinen, die da auch noch hinein müssen. Und dann habe ich ein paar Ideen, wie das Spiel interessant wird (im Moment ist es nicht mehr als einfach nur eine ziemlich dröge Machbarkeits-Studie). Ich bin guter Dinge, dass ich in Kürze mal was zeigen kann.

Ich bin auch gespannt, wie es wird. In meinem Kopf ist das Spiel inzwischen fertig designet. Ich weiß also inzwischen ziemlich genau, was es mal werden soll. Ob es dann allerdings auch Spaß bringt und den Nervenkitzel erzeugt, den ich beabsichtige - soweit das bei einem Spiel komplett in 4 KByte möglich ist - das weiß ich natürlich nicht.

Es wird auf jeden Fall sehr »arcadig«, wie Acrid bereits einmal anmerkte.

Mit »Berzerk« und »Yar's Revenge« liegst Du, Gunlord, sogar sehr richtig. Das habe ich in dem ersten Artikel auf dem Portal (siehe der Link oben) auch so beschrieben. Allerdings ist die Idee nicht, diese Spiele nun zu kopieren. Es war eher so, dass ich labyrinthartige Spiele liebe, von daher war das Design von »Berzerk« schon fast zwangsläufig. Mir ging es eher darum, das »Spielgefühl« dieser Spiele wiederzuerwecken. Wenn das einen Sinn ergibt.

Soundroutine
Meine Fresse: Ich habe am Wochenende die Soundroutine programmiert, so dass man mal ein paar Schussgeräusche und Einschläge in die Wänden hört und so weiter ... und ich weiß schon, warum ich das für einen ruhigeren Moment aufgespart habe: Das ist echt gar nicht so einfach. Der Atari hat zwar vier identische Soundkanäle, aber die ertönenden Geräusche muss man trotzdem irgendwie intelligent verteilen. Zudem habe ich mir die Aufgabe gestellt, für die Geräusche nur einen Kanal zu verwenden. Dann kann ich nämlich später leichter mal eine Musik auf den restlichen drei Kanälen laufen lassen. Dieses Spiel wird zwar keine Musik haben (so ist zumindest im Moment der Plan), aber dann habe ich das Problem für spätere Spiele schon mal erledigt. Außerdem habe ich so im Gefühl, dass eine dynamische Verteilung von Geräuschen auf mehrere Kanäle noch einmal komplizierter ist, als wenn man nur einen Kanal verwendet.

So, und trotzdem ich mich am Wochenende einmal wirklich völlig vergaloppiert habe - sprich: es ging gar nichts mehr - funktioniert das jetzt sehr gut. Bei Assembler-Programmierung ist es allerdings auch ziemlich einfach, so richtig Chaos zu programmieren. Es wundert mich sowieso, dass nicht zwischendurch schon mal eine Katastrophe passiert ist. Und ehrlich gesagt habe ich auch ein klein wenig Schiss, dass mir zum Schluss der Entwicklung noch ein Bug mit Anlauf in den Popo tritt, den ich bisher übersehen habe und/oder der bisher einfach nicht auftrat.

Im Moment ist das Programm genau 1911 Byte lang:


Ich bin jetzt also knapp bei der Hälfte der von mir gesteckten 4-KByte-Grenze. Wenn ich bedenke, was noch alles dazu kommen soll ... es wird knapp.


Score und HiScore
Nebenbei bemerkt ist auch schon die Score- und HiScore-Routine enthalten. Das ist auch so ein Ding: In einer Hochsprache macht man sich nicht einmal im Ansatz Gedanken darüber, wenn eine Zahl auf dem Bildschirm erscheinen soll. Aber in Assembler? Da darf man die Umrechnung von Binär auf Dezimal alles per Hand machen. Zum Glück kennt der 6502-Prozessor einen sog. »Decimal Mode«, den ich dann auch nutze (was bedeutet, dass das Spiel auf der 6502-Variante des NES von Nintendo nicht laufen würde, denn der Prozessor kennt den »Decimal Mode« nicht; aber das sei nur am Rande bemerkt). Ich bin dann mal auf die Idee gekommen, dass der Score gar nicht als Binärzahl verarbeitet wird, sondern gleich als BCD (also immer zwei Dezimalzahlen pro Byte). Und dann ist der Rest gleich deutlich einfacher. Geht jedenfalls auch schon.


Es fehlt nicht mehr viel und dann ist der (zugegeben ziemlich dröge) Prototyp fertig.

Wenn das Spiel dann fertig ist, dann werde ich den SourceCode sogar komplett veröffentlichen. Das macht in der heutigen Zeit eigentlich keinen Sinn mehr, so etwas zu verheimlichen. Und so viele geniale Kniffe sind da nun auch nicht enthalten. Und die Serie hier soll ja auch einen Lernanreiz bieten.

Mit der Serie auf dem Portal bin ich deshalb noch nicht weiter, weil ich erst einmal diese Version 0.10alpha fertig haben möchte. Die soll dann spielbar sein und das Spielprinzip verdeutlichen. Dann geht es mit der Serie auf dem Portal von Pixelor weiter, weil ich dann genauer schreiben kann, was ich wie gemacht haben und vor allem warum ich das so gemacht habe. Das wird dann auch detaillierter.

Der Forums-Beitrag hier soll eigentlich nur ein kleiner Status-Bericht sein.

Soundroutine (2)
Am Wochenende habe ich die Soundroutine(n) fertig programmiert, und das läuft gut. Im Prinzip ist jedes Geräusch im Spiel ein eigenes kleines Programm, welches im Takt der Bildschirmfrequenz (50/60 Hz) die Soundparameter zur Verfügung stellt. Über ein kleines Interface werden die Routinen dann aufgerufen: Ich sage im Spiel also »Spiele Sound 2« und die Routine baut das um in »Rufe Programm an Adresse xxxx auf«.

Nachdem ich das programmiert hatte, spuckte mir der Assembler folgende Zusammenfassung aus:


Also war ich jetzt schon dicke über der Hälfte meines selbst gesteckten Ziels der 4 KByte an maximaler Programmgröße.

Da die ganze Programmierung noch frisch im Kopf war, wusste ich aber ein paar Stellen, die ich noch optimieren konnte, ohne dabei irgendwie die Funktionalität zu beeinflussen (unter anderem hatte ich noch »alten« nicht mehr genutzten Code mit assembliert). Nach der Optimierung gab es folgendes Ergebnis:


Gegenüber dem unoptimierten Code hatte ich also noch einmal 65 Byte eingespart. Gut, klar, in Zeiten der GByte großen Programme klingt das völlig lächerlich. Das ist es aber nicht, wenn ich insgesamt nur 4096 Byte zur Verfügung habe. Da können 65 Byte schon einen Level mehr oder weniger ausmachen.

Ich bin ein wenig stolz.

Es ist wirklich nicht mehr viel, und dann kann ich die v0.10alpha mal online stellen. Das ist dann wirklich seeeeeehr alpha, wird aber keine Bugs haben (natürlich nur die nicht, die mir aufgefallen sind), zumindest aber zeigen, wo die Reise hingeht.

Der Screenshot im Eingangs-Posting zeigt noch einen völlig leeren Raum. Der wird aber später mit Wänden gefüllt - Spielprinzip ist unter anderem, dass die Spielfigur keine Wände berühren darf - so dass das schon mal schwierigen und abwechslunsreicher wird. Die Räume werden aber komprimiert, und zwar in einer Form, dass ein Code verwendet wird, um die Wände zu »malen«. So nach dem Motto: PositionXY anfang, vier Felder nach unten, und so weiter. Das braucht pro Wand dann nur zwei bis drei Byte. Und da sind 65 Byte dann wirklich schon was.