Es ist immer wieder interessant, was passiert bei Entwicklungsprozessen auf dem Amiga. Jeder Fehler (in Assembler – keine Boundaries, keine Checks) ist da irgendwie am Ende visuell und damit irgendwie erfahrbar. Als Entwickler* steht man da und versucht dann zu verstehen, was da wohl gerade wieder passiert.

Im diesem Fall scheint es, um die Bitplanes (Aufteilung der Farbwerte des Screens in unterschiedlichen Speicherbereichen) zu gehen. Diese scheinen verschoben zu sein oder die Screenbreite stimmt nicht.

Und auch hier: ewig ruft der Blitter…

Bauer/Suter(?)/Dave(?)/Larissa(?)

Zu Beginn der 80er Jahre ist Zürich ein Dampfkessel. Seit Jahren wird den Jugendlichen (also eher jungen Erwachsenen) versprochen, sie bekämen endlich einen Freiraum (zur Selbstverwaltung). Sie fühlen sich zu recht nicht wahrgenommen und abgeholt in dieser Stadt. Denn heute wie damals gibt es wenig, was man tun kann ohne dafür zu bezahlen wie die „Hochkultur“ Oper und Schauspielhaus. Zürich ist natürlich nicht irgendeine Stadt, sondern die Zwinglistadt, die noch viel radikaler als andere auf ihren Reformator setzt: auf Arbeit, Arbeit, Arbeit und Beten gesetzt hat und dies hat angehalten bis weit in 80er Jahre hinein. Züricht arbeitet und feiert nicht! Diese Nicht-Offenheit ist einer der Gründe warum Zürich sehr spät zu ihrer Universtität kommt. Und Zürich ist auch nicht eine Arbeiterstadt wie etwa Winterthur. Ihren Aufstieg verdankt sie auch unter anderem dem Zweiten Weltkrieg und den Geschäften – stille Geschäfte vorallem. In diesem Sinn: Nichts soll hier die Ruhe stören.

Dies schlägt sich auch in Liedern etwa von Georg Kreisler nieder mit Sätzen wie (Daneben hat er sich auch noch Max Frisch „vergangen“ – sein Theaterstück sei langweilig 🙂 Man ist in ZH nicht besonders ehrlich. ):

„Auch führ ich gern nach Zürich, aber da ist das Leben nach Mitternacht so still.“

Es wird dann am Rande der Stadt in der Roten Fabrik (sonst genutzt vom Opernhaus) ein jämmerlicher kleiner Raum für eine 300-400k Stadt freigeräumt.

Jugendkultur I: Eigene öffentliche Jugend-Kultur 1980+ [Analog]

Und dann kommt es zur Eskalation am Opernhaus (das das meiste Kulturgeld „frisst“ – was es bist heute tut – der Kanton zahlt das Opernhaus der Rest die Stadt Zürich) bei einer Demo. Anlässlich einer Abstimmung zum Opernhaus fordern die jungen Erwachsenen endlich ihre Bedürfnisse ernst zu nehmen und ! ein „Jugendhaus“. Es soll ihre Kultur sein und keine Elitekultur.

Die Kreativität in der Demoscene steckt zum einen in den Endprodukten den Demos. Aber das ist selbstverständlich nur die halbe Wahrheit. Denn der eigentliche kreative Prozess ist die Erarbeitung dieses Endproduktes als Programm für eine Maschine.

Und dies ist umso mehr der Fall je eingeschränkter die Umgebung ist. Mit der Verminderung der Möglichkeiten muss mehr investiert werden in die Umsetzung, in Ideen, in unkonventionelle Ideen die Ziele zu erreichen. In diesem Sinn ist SizeCoding ein Paradesbeispiel des Constraints-Meta-Game. Hier geht es darum in wenig Code Dinge zu realisieren, die es schon gibt und die teilweise überhaupt nicht komplex sind zu programmieren. Und dann muss optimiert werden, integriert und weitere 10 Varianten ausprobiert werden müssen. Gerade die Nanogames sind dabei ein besonders gutes Anschauungsbeispiel, da hier die Spielkonzept bekannt sind oder umgekehrt wie in der Geschichte der Games, Games halt mit diesen Mitteln erfunden werden müssen. Auf jeden Fall ist der Aufwand immens für ein gutes – zu bestaunendes – Endprodukt.

Und dennoch ist trotz all dem die Spiegelung des Codes im Endprodukt oder auch nur die Thematisierung des Prozesses der Codeentwicklung kein Thema in der Demoscene. Es ist eher so, dass möglichst gestaunt werden soll, möglichst Geniekult gelten soll: Wow das ist möglich. Selbstverständlich gibt es auch das umgekehrte, Effekte mit wenig Aufwand mit guter Hardware etwa (Ein Beispiel dafür wären sicherlich viele Amiga-Demos – hier ist eher das Endprodukt als die raffinierte Programmierung im Vordergrund).

Often you can cut things. because it is all the same.

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 >