Die Tilebasierung ist ein mindestens 5faches mächtiges Designtool – es ist geradezu ein Designregelsystem gepaart mit Funktionalitätsregeln:

1. Das visuelle Design der einzelnen Tiles – visuelles Regelsystem
2. Das Design von grossen Flächen aus Tiles (proceduraler Anteil) – visuelle Flächenregeln
3. Das Designen von Übergängen – Intertile Regelsystem
4. Das funktionale Leveldesign
5. Die Möglichkeit jederzeit das gesamte Design zu ändern – Digitale Eigenschaft

Viele dieser Dinge gab es schon vorher etwa bei Kacheln, Fliesen. Neu sind allerdings die Instant-Veränderungsmöglichkeiten. Hier kann alles in Echtzeitgeändert werden: Das ganze visuelle Regelsystem. Es erlaubt geradezu in unsinnigerweise die visuelle Umgestaltung in Sekunden. Hier ist die Power von Regelhaften Design in den Fingerspitzen. Kybernetik Designtools in Höchstform.

ToDo: Mögliche gesellschaftliche Dimension: Letztlich werden hier visuelle Regeln geändert und da das gesamte aus diesen Regeln besteht ändert sich auch das System. Eventuell spiegelt sich hier ebenfalls kybernetisch, was in der Gesellschaft jener Zeit passiert. Mit einigen wenigen logischen Einheiten (die verändert werden), wird Gesellschaft gemacht. Man könnte die Globalisierung der 80er Jahre lesen als eine Durchsetzung von wenigen Tiles, die das ganze bestimmen. Dabei kann das Aussehen dieser Tiles jederzeit geändert werden.

Im Spiel gibt es einen Bug, das Restore der Sprites/animierten Blöcke funktionierte nicht. Deswegen überschreibt nun ein künstlicher Wert (Grünstreifen) das zu Restaurierende. Damit wird versucht herauszufinden, was da schief läuft und als erster Schritt, was passiert eigentlich. Das Ganze ist ästhetisch fast so interessant, wie das Spiel danach.

Die ersten Prototypen von Imp89 [Assemblerphase] versuchen Spiele zu sein, die den Ideen der ‚grossen‘ Spiele/Demos folgen. Sie versuchen also diese Spielmechaniken und Stile zu simulieren.

Konkret gibt es nicht soviel Einfluss aus anderen Bereichen. Es wird wenig versucht einen eigenen Stil zu entwickeln. Eventuell gibt es eigene Entwicklung in der Grafik bei Dingen wie Büchern etc. Vorlagen sind eher Arcade/Spielhallen-Games, die verkauften Homecomputespiele (Hits) und die Demoscene.

In Sachen Spiel gibt es vermutlich falsche Vorstellungen zu den benutzten Techniken. Dabei ist der benutzte Computer Atari ST nicht gerade hilfreich, da er kein „Videogame-Computer“ ist. Er bringt fast nichts mit wie Hardwaresprites, Scrolling, Musikroutinen (YM). Die Magazinartikel oder Bücher sind dürftig – etwa 1987. Anders gesagt: Es muss eigentlich alles selbst gemacht werden. Ein Fehlen von anderen Ressourcen und Programmierinteressierten (ausser meinem Bruder) in der Peergroup half dabei auch nicht. Die nächsten an Spielprogrammierung interessierten Kollegen war in der Kantonsschule. Dieser hatte einen PC (MS-DOS) und das war dann noch jenseitiger. Er programmierte mit einem Kollegen zusammen ein Tetris in PASCAL.

Deswegen basieren einige Prototypen auf Falschannahmen (In Technik und Konzept) und sind viel zu kompliziert im Vergleich zu den Lösungen in publizierten Games nach heutigem Wissen.

Was sind „dreckige“ Grafiken? Grafiken könnten Grafiken sein, die nicht versuchen „reine“ Übergänge zu haben, sondern ‚Dreck‘ simulieren – also ‚beschmutzte“ Grafiken im konkreten Sinn sind. Oder anders gesagt: Es werden Objekte dargestellt, die beschmutzt oder schon sehr benutzt aussehen.

Die Grafiken erwecken nicht die Idee von „Hell und Lustig“ – diesen typischen Biedermeierstil den man in vielen frühen Grafiken entdeckt.

Dieses Sprite hier macht den Eindruck – nicht „Hell und lustig“ zu sein. Die Frage ist nun: Liegt das daran, dass nur die Farben anders sind oder ist es ein Mix aus mehr genutzter Farbraum und grössere Auflösung.

Dagegen spricht, dass es schon früher „dreckige“ Grafiken gibt, etwa auf dem C64. Allerdings war da das „dreckige“ eher „brute“. Die Grafiken waren nicht detailliert genug. Siehe etwa erste Spiele.

// ToDo: Beispiele suchen für die Frage der „Schmutzgrafiken“
// ToDo: Konkreter Erarbeiten, was mit Schmutz gemeint ist
// ToDo: Vergleich 70/80er Jahre Filme ohne Schmutz und Benutztheit (Nutzungsspuren)
// ToDo: Ähnliches Problem bei Filmen der 70/80er Jahre – die Modell in Filmen waren echte Modelle, danach oft gerenderte Modelle – diese waren mehrheitlich Clean. Erst später wurde wieder Dreck und damit Gebrauch simuliert.

Gerade bei der Programmierung von virtuellen Sprites stellen sich Umstellungsprobleme. Aber sind virtuelle Sprites immer nur nachteilig? Eine Kurzanalyse zeigt ein detailiertes Bild

Eine wirklich wichtige Frage. Geht es doch um die Trennung zwischen Tool – dann lautet die Antwort sicherlich ja – und den digitalen Welten – dann lautet die Antwort vermutlich maximal Ja.

Als Linked-Post:

„Ist der Computer ein Medium?“
[Man könnte die Frage auch stellen: Ist die Taube ein Medium.]

– Als Tool sicher: Ja [auch bei der Taube]
– Als Digitale Welten-Holder: Ja indem es diese vermittelt. Vermutlich Nein als DigitaleWelt selbst. [Bei der Taube auch eher nein]

Die Frage scheint auch nach nach 55 Jahren Mainstream-Digitalisierung wieder aktuell viel offener den je.

Eigentlich ist der Effekt super, irgendwas an der Funktion für die Animation funktioniert nicht. Es flackert. Es wäre perfekt für ein Game – es würde die Gemachtheit dieser Welten zeigen und zwar bei den Objekten und nicht beim Gesamtbild. Es wäre keine Bildstörung.

Allerdings ist klar, für solche Brechungen und Fehler hat die Community kein Verständnis. Denn es haftet immer der perfekten Oberfläche der Fehler an und das „Das hat der Coder* nicht hingekriegt“. Das zeigt letzlich auch wie tief schöne und glattrasierte Oberflächen die Spielkultur verlangt.

Im folgenden Fall geht es auch darum, dass die Musik in Zusammenarbeit entsteht. Und wer will schon seine Musik in „Medienkunst“ haben. Insofern ist das Kapital „Credibility“ gerade in diesem Umfeld schon stark „gewichtet“. Nicht anders als in der Kultur. Der Fehler ist und bleibt ein Problem und ist nicht per se „Schön“ oder „Anders“. Dabei sieht man an ihm tief ins Innere. Hier zerreisst es das System.

Dabei ist auch nicht langweiliger als eine überdesignte Oberfläche.

// ToDo: A glitch game – vielleicht ein Shooter vgl. dazu auch der Glitch-Shooter von Daniel Z.
// ToDo: Glitch demo

Um schnell genug zu sein, werden auf dem ATARI ST vordefiniert (am Anfang des Spiels) all Sprites geshiftet (vorgeschoben 0-15 Pixel). Und hier lief anscheinend etwas schief. Es ist ein visuell interessanter Effekt, auch hinsichtlich der Frage, wie er entsteht.

Der simulierte = virtualisiert Atari ST im kleinen Fenster alias Käfig.

Vergleiche dazu der ominöse Amiga-Emulator auf dem ATARI ST.