Das Recording ist Realtime aufgenommen worden anhand einem konkreten Problem im DevProzess der GameEngine und des Spiels (Port vom Amiga) HolyCube (Orginal C64 Game).

zeigt meine persönliche Arbeitsoberfläche. Diese besteht aus:

0. MacOS X
1. Compiler in der Shell
2. Editor (Sublime)
3. Atari Emulator: Hatari
4. eigenes GrafikTool für Tile-Design

Das anstehende Problem hier: Die Textroutine für kleine Texte (drawSmallText) scheint überhaupt nicht zu funktionieren. Dahinter liegt das Problem der Routine drawSmallBlock. Das normale System in der Engine ist 16×16 Pixel gross. Für die Darstellung von kleineren Texten (Lauftext) wurde zusätzlich ein 8×8 Font erarbeitet. Die Blöcke sind alle nacheinander abgelegt in 2 Bytes (16Pixel) * 16 Linien.

Dieser 8×8 Font findet sich im Tiledesign-tool in den Blöcken 2+.

Der Screen des Atari ST ist aufgebaut nach Linien. Eine Linie besteht aus jeweils 16 Pixeln in 2 Bytes*4 Ebenen. Die Bitplane-Anordnung ähnelt damit mehr dem C64 als dem Amiga, wo die Bitplanes pro Wert auf 4 verschiedene Bereich verteilt ist.

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.

http://maettig.com/?page=Software/DOS/Demoscene
// Search the pattern !

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 der wenigen Tools, die nie irgendwie fetischiert wurden war Code. Warum?

// ToDo: Zu wenig insider*? Zu schlimm basis?

// https://www.atari-forum.com/viewtopic.php?t=1910

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.