Die ist auch ein Case für die Idee Sizecoding als Designmethode zu diskutieren. Siehe dazu hier Sizecoding [DesignMethode] >

Wer das erste Mal ein Breakout programmiert denkt: Kein Problem. Da gibt es ja nur einen Schläger, einen Ball und Steine (Playfield). Die Grafik verwundert, ist sie doch in einer Zeit der monochromen Monitore entstanden. Das Problem löst sich dann, wenn man liest, dass es sich um eine Farbfolie handelt. Aber Farbe ist heute ja auch kein Problem mehr.

Genese – Spielemechanik & Technologie

Das Spiel selbst ist letztlich ein auf den Kopf gedrehtes Pong-Arcade (auch physisch) und aus dem einen Gegner wurden statische AIs alias Blöcke. Aus einem Spiel mit 3 Sprites, die dieselbe Technologie benutzten (Sprites) wird ein Spiel mit Vordergrund 2 Sprites und einem Playfield und einem Hintergrund. Aus einem Multiplayerspiel wird ein Singleplayerspiel mit ganz anderer Motivationsmechanik und viel höherer Reichweite.

Klassische Implementation

Die klassische Implementation setzt auf einen Hintergrund mit zwei movable Objects. Wie die genau Implementation des Orginalautomaten von Wozniack/Jobs (Atari Arcades) tatsächlich ist, wurde hier nicht genauer betrachtet.

Die klassische Programmierung findet man im folgenden Spiel „imagoBreakout“ in Aktion:

Mehr zum Spiel – bei dem das Visuelle zunehmend ausgeblendet wird – hier >

Übliche Umsetzung

Der Ball besteht nicht nur aus der Position, sondern auch aus der Bewegung. Es muss also zumindest noch zwei Variablen für Speed in X- und Y-Achse geben (Fürs Sizecoding schon 2 Bytes zuviel .-).
Den Ballkoordinaten werden also einfach das VX/VY hinzugezählt in jedem Frame. Der Ball ist rasterlos unterwegs auf dem Spielfeld.
// Dies ist natürlich in Systemen ohne +/- oder dann durch die Einschränkung auf 128 Byte nicht so einfach

Den Rahmen bilden 3 Wände links, recht, und oben. Diese lassen sich am Einfachsten per if-Bedingung lösen. Dabei wird entweder absolut die Richtung des Balles bestimmt oder per *-1 (falls dies der Prozessor zulässt).

Dasselbe gilt für das Paddle. Dies ist Input abhängig und muss jeweils auch upgedatet werden. Im Orginal ist es per Potentiometer gesteuert und hat eine absolute Eingabe (im Gegensatz später zum Joystick oder der relativ/absolut benutzen Maus. Das Paddle ist ebenfalls rasterlos unterwegs. Trifft der Ball auf den Schläger kann dies auch per If-Bedingung abgefragt werden. Der Ball kann im Orginal aber auch noch anders abprallen – Spitzer vorne am Schläger und Flacher am hinteren Ende. Dies sind Features, die sich auch in vielen Spielen gar nicht mehr finden lassen und auch oft weggespart werden.

Überschreitet der Ball die Linie hinter dem Schläger – Realisierbar per if-Bedingung. Dann ist das Leben verbraucht.
// Mit Sprites eine einfache Sache. Wenn es direkt gezeichnet werden muss komplizierter. Vgl. Bitplanes etwa C64, Amiga

Der komplexe Teil von Breakout, ist da wo die Neuerungen sind (das was den oberen Schläger in Pong ersetzt): Die Steine. Die Steine sind an einem Raster ausgerichtet und überlappen sich im Orginal nicht.

Die Steine werden mehrheitlich als Tiles oder als Playfield abgelegt.

Das Herausfordernde ist nun diese beiden Ebenen miteinander zu managen: Rasterlose bewegende Objekte und die statischen Blöcke in grosser Anzahl. Es ist auch das, was einiges an Code erfordert und das Spiel deswegen schwierig macht für Nanogames.
// Zum einen weil man die Paddles und den

Trifft der Ball auf einen Stein, so reflektiert der Stein den Ball und verschwindet. Was hier einfach klingt ist in der einfachsten Implementation eine 2 fache Bewegung und eine 2fache Abfrage. Es muss nacheinander getestet werden, ob der Ball in Y-Richtung in den Stein fährt oder/und in X-Richtung. Je nachdem muss nur die eine Richtung invertiert werden. All das braucht einfach Code, ob man will oder nicht und essentiell für ein Breakout-ähnliches Spiel.

Normalerweise wird zweifach getestet.

Selbstverständlich gibt es einen Score. Dieser muss upgedated werden. Dies ist gerade in 8Bit/16Bit Konsolen ein Stück Arbeit.

Gewinnbedingung bzw. LevelUp ist, wenn alle Steine gelöscht sind. Das benötigt entweder eine Durchzählen oder ein Abzählen beim Auflösen. Dann müssen wieder alle Steine gezeichnet werden.

Diese Umsetzung braucht sehr viele Ifs (wie jedes Spiel) und ist fast nicht zu leisten in 256Bytes. Selbst auf alten Computern wie C64 (1 Befehl 2 Bytes) und schon gar nicht auf 16/32Bittern (4Bytes pro Befehl und kein nutzbares Playfield, Amiga: Init. Sprites schwierig.)

„Optimierungsmöglichkeiten“

Dennoch kann man natürlich im grafischen Bereich streichen und der Ball bewegt sich zwar rasterlos aber wird nur im Grid dargestellt. Dasselbe kann selbstverständlich auch mit dem Paddle gemacht werden.

Aber meist hilft alles nicht – es ist einfach nicht machbar mit diesem Ansatz.

Alternative Umsetzung

// Gefunden für den Wettbwerb love.byte 2023 nanogames – 256 Bytes

Levelbasiert?

Eine erste Frage muss sein: Braucht es die Levelfixiertheit oder liesse sich Breakout auch endlos spielen, indem immer wieder Steine entstehen. Dadurch wäre man doch einen Teil des Codes los.

Angewendet wurde das etwa in EndlessBreakoutFever, hier ensteht der Level permanent – als eine Art Endlessrunner.

https://demozoo.org/productions/319267

Einfachere Abfragen Ball-Steine

Liesse sich die Ball-Steineabfrage vereinfachen?

Im Spiel BreakoutForever wurde genau dies gemacht. Statt der komplexen obig vorgestellen Version wurde nur der Abstand gemessen, vom Ball zu jedem Block. Es ist quasi die Bruteforce-Version die diese schnellen Fantasy-Consolen möglich machen. Dann wird verglichen, ob irgendwo ein Abstand kleiner als der Abstand was ist Grösser die Distanz in X oder Y-Richtung dann wird beim Kürzeren invertiert und der Block gelöscht. Dadurch entsteht ein phänotypisch ähnliches Verhalten des Balles und der Blöcke.

Das Ganze sieht dann folgendermassen aus in Aktion.

Findings

Breakout ist letztlich ein recht komplexes Game. Die Komplexität in der Programmierung kommt vorallem aus dem Verhalten des Balles. Zudem sieht das Verhalten des Balles im ersten Moment gleich aus wie bei den Blöcken/Tiles. Aber das ist nicht so. Das eine ist Sprite-Hintergrundverhalten, das andere Sprite-Sprite verhalten. Es ist damit auch anders als bei Space Invaders – das auch als Vorbild ein 1:1 Spiel hat und dann daraus ein 1:n macht.

Gesellschaft

Die Frage ist hier: Was programmiert man da eigentlich?

Gesellschaftlich bricht Breakout mit Pong, wo die Hauptmotivation die Konkurrenz war. Hier spielt man gegen ganz viele ganz dumme andere „Schläger“. Diese Bewegen sich nicht und sind allein gefährlich, weil sind und der Ball davon abprallt.

Der Spieler* kämpft also gegen das statische System, indem er langsam abträgt oder anders gesagt, indem er seine ‚dummen‘ Gegner langsam beseitigt. Er kämpt dabei – wie einst bei Pong – dagegen, dass sich der Ball nicht mehr kontrollieren lässt. Der Kontrollverlust bleibt also auch hier bestehen.

Das Spiel könnte damit auch gelesen werden, als die nächste Stufe nach der direkten Konkurrenz im kapitalistischen System: Nun geht es gegen die namenlose Masse und nicht mehr den persönlich bekannten Gegner wie bei Pong. Man setzt sich nicht mehr zusammen, man spielt nun gegen das System und das besteht aus einfachen „Spielern“ alias NPCs. Diese Gegner sind aber auch namenlos, in einer Reihe gleich aussehend. Ähnlich wie nicht viel später Space Invaders einsetzt. Aus der Kugel wird allerdings ein Schuss.

Weiterentwicklung

In der Weiterentwicklung via Arkanoid 1986 wird der Tileraum gestaltbarer, werden dann auch aus den namenlosen Blöcken richtige Gegner, die abgetragen werden müssen und nicht zu vergessen- die Blöcke haben nun richtig konkrete andere sich bewegende – recht abstrakte – NPCs. Die erschwerte Schwierigkeit wird mit Extras versüsst. Diese wiederum machen aber auch die Sache komplizierter, weil der Spieler* sich entscheiden muss – will er* das Risiko mit dem Extra eingehen?

// ToDo: Vergleich mit Schweizerischen Breakouts/Pongs
// ToDo: Diskussion mit den Schweizer Breakout-Entwicklern.