Die Phasen der Aneignung eines Computersystems sind eine Art Metapspiel mit Macromechanik und Micromechanik.

Macromechanik

Die Makromechanik ist eigentlich simple: Lerne das System kennen, lerne es zu beherrschen und dann mache eine Demo oder ein Spiel oder ein schon davor ein Framework für beides. Dabei ist meist schon klar, was man alles erreichen könnte, kennt man ja schon Demos oder Games.

Micromechanik

Hardcore ist die Micromechanik, also das lernen, wie die Hardware (oder Software) programmiert wird. Dieser Weg ist steinig und besteht aus sehr kleinen Aufgaben, die man zu lösen versucht. Wie printe ich etwas auf den Screen. Allein das ist schon grosses Ding in Assembler. Dann geht es weiter. Wie ist der Assembler aufgebaut. Was kann etwa der 68k. Aha ok.

Gestern entwickeln vs Neo-Entwicklung

Langsames abtasten. Dieser Vorgang ist heute fast schwieriger als zur Entstehungszeit, hatten die Assembler damals eine Art CommandLineShell, wo man rechnen und Dinge einfach ausprobieren konnte auf dem Rechner. Heutige IDEs hingegen haben das nicht und benötigen schon ein feststehendes Setup, sonst geht gar nichts. Das ist manchmal extrem schwierig, ein Setup zu haben in gerade dem Assembler in dem man selbst arbeitet.
Das Gegenteil damals, da gab es schon was, das lief, etwa der konkrete Assembler. Und in dem drin, wurden Dinge ausgeführt.

Assembler

Das Einfachste ist noch das Verstehen des Assembler selbst. Was gibt es für Befehle wie funktioniert das. Hier gibt ja es auch auch nicht soviel Auswahl gerade bei den Homecomputern. Aber auch hier – 8Bit Computer sind echt mühsam – etwa immer über die 255-Grenze rechnen etc. Was bei Games oft vorkommt, Grafikspeicher etwa. Hier funktioniert auch schnell vieles. Die Herausforderungen sind klar, das Erwartbare ist klar. Das Ergebnis klar. Die Belohnung: Es funktioniert und mehr Kontrolle. Einfache Spielmechanik

Videomemory & Spezialchips

Schwieriger wird es beim Videomemory. Dieses ist fast immer seltsam (gerade bei Bitplanes). Wie funktioniert das Memory, hat man schon mal mit einem ähnlichen System gearbeitet.

Spezialchips sind dann das richtig hässliche Ding. Sie helfen zwar viele Dinge zu lösen – von Scrolling bis zu Klipping oder Music. Aber sie sind eben auch ganz anders zu programmieren als der Hauptchip und das hat es in sich. Beim Amiga etwa programmiert man einen Hauptchip, Clipper und etwa den Blitter. Das sind 3+ verschiedene Ansätze.

Hier kommt man teilweise sehr langsam vorwärts, weil man andere Vorstellung hat, wie diese Spezialfunktionen ‚funktionieren‘. Das Erlangen von Wissen geht entsprechend langsam von statten. Hier lohnt sich fast mehr ‚Geduldig Hintergrund zu lesen‘ statt auszuprobieren. Gerade etwa beim Amiga kann man da sehr frustieerte Wochen erleben, ohne Fortschritt. Das ist dann eher „episch“. Fail, um Fail. Ah das geht und dann die Enttäuschung. Viel Democode der angeblich geht nur nicht bei einem selbst im Projekt.

Funktioniert es dann langsam und man „versteht“ = kann es anwenden ist es eine sehr cooles Gefühl.

Dann kommt schnell die Frage, was kann ich damit machen? Wie mächtig ist es? (Was sind die Grenzen?) Etliche Stunden mit Ausprobieren bis zum Stocken wartet.

Nach der Party

Allerdings ist der Afterparty-Effekt auch dann hart: Hat man es dann richtig unter Kontrolle ist der Rest nur noch Fleissarbeit und das motiviert – zumindest mich – dann nicht mehr. Denn dann ist es keine Challenge mehr. Dies scheint auch ein Problem gewesen zu sein im Gamedesign (lange Entwicklungszeiten) während viele Demos dies nicht haben. Hier kann mit allem eine Demo gemacht werden.