Eine Möglichkeit, die Geschichte der Digitalisierung darzustellen und zu vermitteln, ist die der asynchronen Porträts. Aus der Statistik wird damit eine nachvollziehbare Realität durch die verschiedenen Zeiten hindurch und damit zu einer nachvollziehbaren Story. Gleichzeitig zeigt es auf, wo sich Gemeinsamkeiten und Clusters befinden – wo sich also gleiche Entwicklungen vollzogen haben – also im Fall des Gamedesign, wo gleich Nischen vorhanden waren. // ToDo: Porträt-Stories
Nichts funktioniert mehr seit heute Morgen. Es werden keine .o-files mehr erstellt. Es geht sehr lange bis man denkt: Ok, es ist etwas kaputt mit dem Tool (Hat ja bis anhin ohne Probleme funktioniert)
Bei der Installation fehlt der Assembler (wird nicht downgeloadet). Jetzt wird er wieder downgeloadet (nach 3h).
Der Entwickler scheint an der VSCode-Erweiterung „Amiga Assembly“ zu arbeiten. Das neuste Update ist von heute morgen. Jetzt tritt ein noch wirrer Fehler auf – sie Bild oben.
Ein Tag danach: Problem war nicht der Entwickler, sondern das gesetzte Property direkt für den Einzeluser.
Was Assembler so schwierig macht, ist auch die (nicht existierende) Kapselung. In höheren Programmiersprachen kann ich meist sehr einfach Beispielcode nehmen und ausprobieren. Die Abstraktion dabei hilft immens.
In Assembler das Gegenteil. Selbst das Setup für einfachere Dinge ist in jedem Beispiel anders (Wo liegt das Videomemory ?) etc. Und das macht ein Nachvollziehen von Code oder ein Einbauen unendlich schwierg. Copy-Paste Fehlanzeige. Auch sicherlich ein Grund, warum viele in diesem Bereich auch, immer wieder ihr eigenes Setup machen, ihre eigenen Routinen.
Die Nutzung höherer Programmiersprachen war spätestens nach dem Amiga im Alltag unumgänglich. Allein der Mehraufwand, der entsteht in Assembler ist bis heute ungeschlagen. Es fragt sich deswegen auch ein Bisschen, wie rentabel auch die grossen Spieletitel auf dem Atari ST und Amiga waren, wenn man bedenkt wieviel Aufwand darin steckte (Immer vorausgesetzt man zieht den Aufwand ab, den Leute geleistet haben, um jemanden zu zeigen, was so geht!).
Im Bereich des Codings gilt natürlich wie überall sonst auch beim Lernen: Aneignung und damit das Anschliessen und Anpassen des Neuen beim Lernen an die eigene existierende Psyche (System) ist das A und O. Schliesslich geht es ja auch darum ein oft kleineres System (das Neue) mit dem älteren und meist grösseren System zu verschmelzen. Das ist selbst dann nötig, wenn das neue System (die Daten, Modelle) perfekt schon ins existierende System passen.
Und da waren sie da, die Elemente in HTML-Seiten, die man programmieren konnte: Java-Applet. Ungeheuerlich. Statt statischem Inhalt (Javascript damals 1995+ .-) konnte man hier richtig programmieren und zwar alles: von Grafik bis Sound.
Die ersten Schritte aber sind frustrierend, warum funktioniert das Ganze nicht wie gedacht. Man erstellt einen Loop und will darin animieren. Keine Chance, irgendwas Komisches passierte.
Die Herausforderung Games zu machen ist in den 8/16Bit-Zeiten, überhaupt einmal die Basalfunktionen zum Laufen zu bringen. Zum Beispiel etwas auf dem Screen darzustellen, was bei der Organisation des Videomemories etwa als Bitplanes gar nichts Trivales ist.
Wie enervierend das sein kann, ist kaum zu beschreiben und so ist man „Gotten“-froh, wenn am Ende wenigstens irgendwas auf dem Screen sichtbar ist – etwa der Fehler hier im unteren Teil des Bildes. „Ahh es passiert was“, auch wenn es das Gegenteil von ‚das Richtige‘ ist. Aber es ist einen kleinen Schritt vorwärts. Es ist eine kleine Challenge gewonnen Gamedevspiel und damit im Motivationsdesign von „Create a game“ aber davor brauchst du die Grundfunktionen wie Display und Interaktion, dann Sound.
Der Fehler als grosse Belohnung, der Level der Frustrationstoleranz. Der Code dazu:
Das ist typischer Fehlercode – so oft abgewandelt, dass nichts mehr auch nur irgendwie „Sinn“ ergibt. Der Code der Hoffnungslosen. All dies ist vergessen, wenn das Spiel einmal läuft und die Konsumenten darüber herfallen können.
Vielleicht sollte man in einem Museum für Games penetrant 8/16Bit Music laufen lassen etwa von kohina.com. Als Alternative böte sich noch an Alltagsgeräusche von damals abzuspielen.
Entwickelten sich gerade längere Vektor- und Polygongrafiken vorallem auf den Homecomputern (vs Consolen)?
Anfänge auf Mainframes und Arcades
Die ersten Polygongrafiken als Spiele entstanden sehr früh. Als erstes müsste man sicherlich Tennis4Two nennen, das auch eine Art Vektorgrafik bestitzt, später kamen erste 3D-Spiele dazu auf dem Plato System dazu – fliegen in 3D und vorallem Dungeon Scroller. Dann nahm sich auch die Arcade den Vektorgrafiken an, die bis heute modern wirken, weil abstrakt (vgl. (konkrete) Kunst 70er und 80er Jahre. Angefangen bei Space Wars, Asteroids, Battle Zone, Black Widow, Tempest bis hin zu Star Wars (Technologie und Abstraction als Rekonstruktion der Welt wieder von 0 auf in 3D). Interessant auch hier, wie etwa bei Asteroids Deluxe (1980) mit Underlays und Overlays versucht wurde, doch noch mit klassischer Grafik zu arbeiten. Ein interessanter Mix, den sich ja auch etwa bei Spaceinvaders finden lässt.
Eine beachtliche Liste, die auch in Pixelgrafik übersetzt wurde auf den Homeconsolen. Nur einige dieser Spiele schafften es auf einer Vektorkonsole – der einzigen – der Vectrex umgesetzt zu werden.
Selbstverständlich ging es dann in den Arcades weiter mit VirtuaRacer, VirtuaFighter etc. alles Polygonspielen.
Homecomputer Area – Langzeitspiele für Zuhause
In der Homecomputer-Area entstanden beachtlich viele komplexe Spiele in Vektorgrafiken. Spiele, die so nie den Arcades möglich gewesen wären: Komplexität, lange Spielzeit. Spiele gemacht für viele (unterbrochene) Spielstunden zu Hause. Die Liste ist lang und es finden sich viele Experimente darunter wie etwa OpenWorlds etc!
Elite 1984 Micro BBC – Vektor
Ein sehr früher Vertreter davon: Elite. Prozedurale Welten (was inhaltlich = abstrakt auch zu Vektoren passt).
