// Aus der „Dokumentation „The Art of … “ siehe unten
Die Demoscene soll sich also durch Nummern ausdrücken?
Am Anfang des Prozesses stehen Algorithmen, diese werden meist in einer Programmiersprache geschrieben und dann in Exes, ausführbaren MaschinenCode übersetzt. Dieser wird dann ausgeführt vom Computer und generiert in der Sprache der Mathematik Geometrie oder anders gesagt Grafik.
Auch vom Macintosh her kommen, aber irgendwie brutaler (nicht gefangen in einem Window) sondern einfach über den Inhalt geschrieben – die ATARI ST Bomben. Oft folgt dann noch ein Reset danach.
Aber eines ist klar als AssemblerEntwickler*: Das war dein Fehler!
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
Aspekte
HardwareSprites
SoftwareSprites (inkl. Grafikprozessoren wie Blitter)
Entwicklungsaufwand
Kein
Hoch. Verständnis des Bildmemoryaufbaus, Verstehen des BlitterChips falls vorhanden
Initialisierung
Teilweise aufwändig
Keine, ausser Vorberechnung dann Aufwand hoch
An/Auschalten
Teilweise aufwändig
Nicht vorhanden, werden einfach nicht mehr gezeichnet
Clipping
Kein Aufwand
Grosser Aufwand
Rechenzeit-Kosten Zeichnen (CPU)
Keine
Hoch Varianten: Vorberechnet vgl. Atari ST
Management
x/y vorhanden
Hoch (Retten des Speicherbereichs – 2x Onscreen/Offscreen/Restore)
DoubleBuffering
unnötig mehrheitlich
zwingend, grosser Aufwand Verwaltung, Objekte und Positionen
Collision
Meist vorhanden
Nicht vorhanden, manuelle Lösung, aber auch nicht so wichtig, da mehrheitlich Rechteck-Kollisionen verwendet wird
Anzahl
HardwareDefiniert (meist 8)
Rechenzeit abhängig
Nutzbar in Effekten wie Wasser (exotisch)
Nein
Ja
Im der freien Wildbahn
Meisten Consolen, TI-99 (sehr viele sprites), C64 (8 Sprites), Amiga (8 4 Farbensprites),
BBC Micro, Atari ST (Amiga mit Blitter, Atari ST mit Blitter)
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