Teil des Programmierjobs: das erwartete ist eine Linie des Characters „1“ auf der 3ten Linie des 8*8 Grids . stattdessen passiert da was ganz anderes. Irgendwie ist schon was da, aber auf jedem zweiten Tile und irgendwie schiebt sich die Grafik nach oben (fehlerhafte Bitverschiebung) – das würde auch die Falschfarben erklären.
Fazit: Es funktioniert überhaupt nicht, oder nur wie ich es bis anhin getestet habe.
Gesellschaftliches Fazit: Anders als eine reine Philosophie kann ich hier testen, was aus den Regeln wird, leider. Ok Philosophien können dann Gesellschaftlich weit gefährlicher sein, weil sie auf Menschen laufen als dieses Menu.
Als GameDev interessiert normalerweise das Spiel. Hier liegen die Herausforderung, das Management von Spielmechanik, Interaktion und Darstellung (Displays: Grafik, Music). Und dann muss man sich um das Drumherum kümmern also Titelbild und Menus. Das ist eine beschwerliche Sache. Aus Programmiertechnischer Sicht der 80er Jahre: Vorallem eine Statemachine, Textroutinen. Alles Dinge die eher mühsam sind – GUI halt. Dazu kommt das Fehlen von Frameworks für diesen Frame um Spiel herum. In diesem Sinn: Es darf nicht unterschätzt werden, wieviel Zeit damals auch für dieses „Drumherum“ genutzt werden musste und beim Betrachten von Games sollte auch dies Einfliessen.
Denn klar ist – das zeigt die Demoscene – hier wäre viel möglich gewesen, aber es findet sich sehr wenig selbst in den Menu dazu. Die Menus sind meist schlicht, funktional. Und dies hat noch einen anderen Grund: Wäre das Menu zu fantastisch würde es den Hauptteil ausstechen und das Spiel sähe ’noch‘ langweiliger aus.
Interessant ist eigentlich, dass die Cracker-Bewegung auch angefangen hat in Richtung Sammlung zu gehen. So entstanden zunehmend – auch dank dem zunehmenden Einbau von Komprimierungssoftware bei normalen Cracks, weil die Disks ‚randvoll‘ waren – Disketten mit 3,4 Spielen drauf. Neu musste natürlich auch Auswahlen angeboten werden. dadurch entstand dann wiederum ein Medium diese Sammelcracks, die wieder buchartiger waren. Dabei wurden diese Sammelcracks nummeriert, so dass man tatsächlich Games hätte sammeln können mit einer Gruppe. Anders gesagt: Es waren nicht mehr Einzelcracks sondern eine Art Cracker-Games Library spezifisch für bestimmte Crackersgroups.
Die Organisation des Atari ST mit 16 Pixel-Zeilen basierten Bitplanes begrenzt Fehler, während sie beim Amiga immer grossflächiger sind. Hier nun mal ein Bug, der fast schon an einen Amiga-Bug auf dem Atari ST erinnert.
Hier müssen 16 Bytes bewegt werden, um die Hintergründe der Softwaresprites auf dem Atari ST wieder herzustellen. Darum muss der alte (gesavte) Hintergrund wieder kopiert werden. Das sind 8×2 Bytes in Worten 2 Bytes (move.w) insgesamt 16 pixel in 16 farben. In der zweiten Version kopiert man 4 mal 4 Bytes per move.l – LongWords.
Eigentlich sind die meisten Homecomputerspiele das Gegenteil von analoger Welt bzw. „Natur“ (auch die Demoscene). Sie sind hochartifiziell. Ihr Sinn ist meist auch garantierter Spass und darum Wiederholbarkeit des Gefühls und keine Ohnmacht oder Glück, die typisch sind für das analoge „Leben“ – weil analoge Welt durch ihre Komplexität und Heisenbergs Unschärferelation unhintergehbar sind. In diesem Sinn sind Games eine der höchsten Kulturformen von Kontrollierbarkeit oder Kultur, sofern man Kultur als Kontrolle begreift des Unkontrollierbaren = Natur. Sie wären also damit eine höchste Form der interaktiven Ermächtigung.
In diesem Umfeld wird deswegen selten Zufall eingesetzt. Es sei denn man möchte die Regelmässigkeit oder eher Regelhaftigkeit durchbrechen, etwa, wenn es um den Sternenhimmel geht oder das Weltall. Das sind dann meiste Effekte, die nichts mit der Spielmechanik zu tun haben. Sie genieren aber trotzdem Natur im Sinne von Unkontrolliertheit, Einzigartigkeit, so wie uns meist die Natur uns entgegenkommt mit all den seltsamen Konstruktionen wie Schicksal oder Omen.
Es ist der Moment, wo unser Gehirn versagt und aufgibt vor der Komplexität und keine Muster mehr erkennen kann. Und genau hier benutzt man berechneten Zufall.
Eine Zufallszahl zu produzieren ist immer wieder ein interessanter Kristallisationspunkt in der Entwicklung von Games.
Braucht es überhaupt Zufall in Demos/Games?
Schaut man sich an, wie oft die Frage debatiert wird in Foren, so denkt man – hmm eher nein. Die Frage steht meist nicht im Fokus der meisten Debatten. Warum ist das so? Vielleicht schlicht und ergreifend, weil sie einfach niemand brauchte.
Demos
In Demos mag der Zufall noch eine Rolle spielen, weil man da ab und zu einfach ein paar Positionen für Objekte sagen wir Kugeln erschaffen möchte und vordefinierte Zahlen einen Haufen Platz benötigen. Insofern sind sie in Demos quasi die einfachste Möglichkeit Variant zu erzeugen. Verwendet man dabei keinen sich veränderden Anfang sind zugleich die Resutltate immer dieselben. Das ist dann auch gut, weil viele Demos ja nicht darauf aus sind, verschieden zu sein, also interaktiv, sondern immer dieselbe kontrollierte Erfahrung.
Games und Zufall
In Games ist die Sache – zumindest in der Homecomputerzeit noch viel restriktiver. Gerade in Games wollen die Leute Kontrolle, das heisst es soll sich nicht viel ändern. Dafür gibt es ja vordefinierte Levels und seien es 100 wie bei BubbleBobble. Dem Spielenden will immer dasselbe Vergnügen geliefert werden. Und dem stehen Zufälle im Weg. Ausnahmen sind vielleicht spezielle Gegner wie Oberbosse oder AIs – es geht dann mehr um Taktik statt um Auswendiglernen. Prinzipiell aber wird nicht wirklich mit dem Zufall ‚gespielt‘ im Design der Games. Es fehlen auch weitgehend noch die Spiele, die endlos funktionieren – wie heute Endlessrunners.
Hier virtuelle Noch-nicht-Sprites auf dem Atari ST. Virtutelle Sprites bedeutet ein Riesenaufwand an Aufwand für Storen des Hintergrunds, Zeichnen darauf, Darstellen, dann wiederum Löschen. Da das Ganze nicht ohne DoubleBuffering läuft, muss jedes Spriteposition beim Zeichnen abgespeichert werden im jeweiligen DrawScreen, dann wird es angezeigt im DisplayScreen und anschliessend muss es wieder gelöscht werden, wobei das akutelle Sprite schon weiter ist. Das war beim Amiga letztlich nicht anders neben den „spärlichen“ Sprites des Amigas. Dort machte das Speichern und Zeichnen dann der Blitter, der Administrationsaufwand war sonst derselbe. All dies machten sonst Hardwaresprites ohne irgendwelchen Aufwand: 0% Rechenzeit.
In diesem Sinn waren Consolen immer besser dran für Entwickler*. Die Kosten allerdings dort zu entwickeln waren astronomisch im Vergleich zum Preis eines Computers.
Und ja dann begann natürlich ab 92/93 die 3D Zeit und damit waren Sprites nicht mehr StateOfTheArt technisch.
Das Ganze funktionierend mit einem Darstellungsbug.
Der Code als These, die angewandt im Computer ganz was anderes tut. Eine stetiger These-Falsifizierungsprozess = Coding. Und die Frage: Wo liegt das Problem? Wo liegt das andere?
Der Code rechts sollte das links mit Streifenpixeln (%010101) überschreiben. Aber das sind keine Streifen! Auch nach 20 Minuten umschreiben nicht.
Debugging ein hässlicher Sozialisierungsprozess an eine Maschine – es ist ein anrennen gegen die Maschine: „Lerne deine Turingmaschine!“
