Archiv für den Monat: Juli 2024

Semiosekaskaden: Kontrolle der Semiose (Intertext) über Magazine, Box (Bild und Heft), Cartridge/Tape/Diskettengestaltung, Titelbild bis hin Setting, funktionalem Design Ingame und Interaktivem – Entwurf

Team ZHdK

Aus den mehrfachen Diskussion in Teilgebieten wird hier zusammengefasst, was bis anhin dazu vorliegt und wo weiter ‚verdichtet‘ werden könnte.

Die SemioseKaskade

Warum ist die Diskussion der Semiose bei Games interessant? Die Semiose ist in elektronischen (wie auch analogen) Games verzwickt und führt über verschiedeneste „Medienbrüche“. Auch und gerade wegen der anfänglichen ’schlechten‘ Auflösungen der Games. Man kann deswegen geradezu von einer Kaskade sprechen, die benutzt wurde, um in die Games ‚einzuführen‘ und das Lesen der Spiele zu beeinflussen. Selbstverständlich beeinflusst wiederum jeder Bereich wieder andere und kann auch zurückwirken im Sinne von: „Was genau hat das Analogartwork mit dem Game zu tun.

Arcades

Arcades wie auch Pinballs sind geradezu mit ihren „Arcadekästen“/Architektur defiktionalisierte Werbung und Einführung für das Spiels: Kasten, Sound, Aufmerksamkeitsmechaniken. Siehe dazu die Artikel von Bauer/Kato, Krummenacher (Pinball) und Suter (Missile Command).

Die Arcades besetzen dazu einen konkreten Raum in der analogen Welt und ein sozikulturelles Umfeld sind also Treffpunkte (Kocher, Ivo) – sind also ein Magic Circle für sich. Ein einzelner Kasten ist zudem ein Erlebnis – ganz im Gegensatz zu einer Konsole oder einem Computer (mehrere Spiele, Computer noch mehrfach nutzbarer). Die Universale Spielmaschine oder die Universale Turingmaschine lassen grüssen.
// Ausbau ++

Homecomputer/Consolen im Dilemma

Consolen wie auch Homecomputer verfügen nicht über diese analoge Verschmelzung von Nutzung und einem Setting. Sie sind also massiv mehr auf Inszenierung angewiesen. Gerade auch – wie bei den Arcades – wenn ganz am Anfang die Grafiken nicht gerade erkennbar sind. Darum spielen hier die Bereiche und verengenden semiotischen ‚Massnahmen‘ eine viel grössere Rolle.

Werbung und Magazin

Wie auch im Workshop vom Sommer 2023 (ZHdK) gut sichtbar – bei der Auslegeordnung – aller PowerPlay Magazine (galt damals als unabhängiges Magazin) wird schnell klar: Auf dem Titelbild wird meistens das Setting/Visualisierte Story der Spiele dargestellt und zwar für das Medium Druckmedium (100+ Dpi). Also nichts, was ein Spiel zu dieser Zeit auch nur annähernde bieten konnte (8Bit Homecomputer). Die Funktion ist dabei auch klar: So soll die Imagination des Gespielten aussehen. Sie soll also mehr sein als das Gespielte. Das Gespielte wird damit aufgeblasen und interpretiert in dem Sinne. Die Spielmechanik ist dabei minimal dargestellt im Bild (Konflikt) oder wird durch das Setting ableitbar aus dem Bild lesbar (etwa Krieg). Selbstverständlich kommen die Spiele anschliessend als Werbung (Finanzierung, Einfluss) oder als Berichte vor. Hier findet man dann auch oft den ersten Screenshot/Ingame Grafik. Da wird dann auf das Spiel eingegangen und textlich beschrieben, um was es geht, was das Gameplay/Spielmechanik ist. Und das wird in Kategorien bewertet. Dabei spielt dann hier auch eine Rolle, welche Platform wie gut aussieht etc.

Weiterlesen

These: Vielleicht verhinderte die ‚Zeig es all den anderen und denen davor‘ den Fokus aufs „Gamedesign“

In einigen Diskussion/Interviews kommt teilweise heraus, dass die einzelnen Entwickler*, es allen zeigen wollten und zwar vorallem im technischen Bereich. Also das Motivationsdesign war: Wir zeigen es ihnen! Killer und Achiever in einem Motivationspattern (vgl Demoscene). Dadurch wird natürlich nicht unbedingt auf das Spiel und seine Spielmechanik fokkussiert sondern auf das technisch Mögliche und damit verliert das klassische ‚Gamedesign‘ schon einen Teil des Reizes. Dies erklärt zumindest teilweise die schweizerische Blüte im Gamedesign und die Links zum Cracken und zur Demoscene und das Erlöschen der Gamedev-Szene danach.

// Technisch alles zeigen hat auch ein Problem:
// > Extreme Anpassung des Codes an die Hardware. Keine Flexibilität. Kein schnelles Produzieren von Games
// Mehr Aussagen und Ausddifferenzierung

Digitalisierung: Der Amiga und seine Audio- und Videoqualitäten fangen von der manuellen Konstruktion (8Bit Homecomputers) von Audio- und Video Richtung direkte Digitalisierung des Analogen zu gehen

Oder warum etwa WAR HELI (1987-CH) eine digitalisierte Stimme hatte im Intro.

Wer verstehen will, wie gewaltig die Digitalisierung zu Hause mit den Homecomputern gerade dem Amiga wurde, muss verstehen lernen, was hier auf konkreten und der Metaebene geschah.

Gerade noch wurde eine neue Welt geschaffen (ab 1976+), die der interaktiven Games und sie waren verschwommen, pixelig verschwommen, der Sound Hüllkurvensound in 4Bit(?). Diese Medien hatten noch keine Chance dem Medium Fernsehen und Film auch nur annäherend gefährlich zu werden, ausser sie setzen auf Interaktion, Immersion. Denn alles was man sah in 8Bit war konstruierte Welt im neuen Medium (meist manuell digitalisert, wenn überhaupt). Es war eine neu geschaffene Welt auf der Suche nach Content jenseits vom Rechnen und Textverarbeitung .

Anders der Amiga (1985+), er kam mit 8Bit-Audio und machte schon mal kristallklare Music möglich. Brachte den Beverlly Hills Song in den Computer (Rekonstruierte ihn bzw. nutze den Synthy).

Noch weiter ging allerdings die Nutzung analoger Realität als Sound etwa in der Digitalisierung (also keine manuelle Digitalisierung mehr) von Stimmen und so kommt auch nicht zufällig auch in Schweizer Games – Stimmen zum Einsatz und zwar kristallklar. Etwa bei WAR HELI oder InsanityFight. Unknackig wie im Fernsehen und schon fast auf dem Niveau einer CD (16Bit Music). Das Ganze sogar möglich interaktiv!

Auch der zweite visuelle Kanal neben Audio, das Visuelle hatte mit dem Amiga Sprünge gemacht. Zumindest in 2D und 16/32 oder gar „4096“-HAM Farben. Und das Bild, das sich ins kollektiv technische Gedächtnis als Ikone gebrant hat ist folgendes:

Weiterlesen

Blitter die Datenschleuder – das Beast, Herzstück des visuellen Amigas [wird upgedatet]

Der Blitter (https://de.wikipedia.org/wiki/Blitter_(Amiga)) ist einer der CustomChips, die den Amiga einzigartig gemacht haben im Homecomputerbereich. Das Herzstück des Amigas der 68000er Prozessor von Motorola ist zwar schnell und mächtig und einfach zu programmieren. Er ist aber – das zeigt der Atari ST – am Anschlag, wenn es darum geht Games mit vielen Objekten zu handeln.

Anders der Amiga – er hat neben peinlichen 8 Sprites – Sonderchips – wie später alle Computermodelle. Und der mächtigste unter ihnen ist der Amiga-Blitter.

Er ist in der Lage grosse Blöcke zu kopieren und zu kombinieren. Dabei meint man mit Blöcken nicht etwa rechteckige Blöcke auf einem Blatt sondern Speicherblöcke also hintereinanderliegender Speicher. Dies ist eine wichtige Einschränkung, was die Programmierung auf Hardwareebene (Assembler), sehr mühsam macht.

Der Blitter besteht prinzipiell aus 4 Kanälen (vgl. DMA), die kombiniert werden können. Die Kombinationsmöglichkeiten lassen sich hier ausprobieren:
http://deadliners.net/BLTCONCheatSheet/index.html

Im obigen Bild sieht man die Möglichkeit der sogenannten Blobs eine Art „HardSoftsprites“. Das heisst die Kombination eines Hintergrunds mit einer Maske und einem Objekt. Dazu braucht der ABlitter das gesamte Potential. Es gibt aber auch die Möglichkeit in der Kombination Dinge zu füllen, zu kopieren etc.

Die Möglichkeiten sind teilweise auch völlig unsinnig und in der Programmierung ist es denn auch schwierig genau zu verstehen, was passiert. Der Chip ist eine Art Black Box.

Weiterlesen

Sprites, DoubleBuffering oder der Amiga mit Blitter ohne DoubleBuffering und mit

(Interaktive) Echtzeitgrafik beginnt (vereinfacht) zu flackern, wenn die Hardware nicht mehr schnell genug ist, die Grafik schneller als der Rasterstrahl zu zeichnen.

Double-Buffering

In diesem Fall benutzt man zwei Screens, die man hin- und herzeigt, um auf dem nicht-gezeigten Screen zu zeichnen. Mehr dazu findet sich hier > Dies ist ein Verfahren, das bei einem Grossteil der Anwendungen eigentlich keine Rolle spielt, da vieles Tools sind.

Games und Double-Buffering

Anders im Gamebereich – hier gilt das Flackern als „Sünde“ (Todo: Gibt es Spiele, die mit grossflächigem Flackern arbeiten als Gamemechanik? Mission Impossible?). Denn – es zerstört offensichtlich die ‚Immersion‘ und deutet auf ein techniches System hin. Es wird als Störung gedeutet.

Weiterlesen

Devs/Publisher vs Cracker*: Hidden Messages in Amiga-Games

https://codetapper.com/amiga/random-rants/hidden-messages-in-amiga-games

Die meisten Gamedevs* und Publisher* adressieren in den Hidden-Messages bei Amiga-Games vorallem Cracker* und machen klar: Crackt uns nicht, wir haben viel Zeit in diese Games gesteckt. Es zeigt sich radikal wie das Verhältnis mehrheitlich war und betrifft die Schweizer-GameDev-Scene besonders, weil hier viele aus der Crackerszene stammten. Darum sollte man hier auch nochmals nachfragen bei Interviews.

Hier die Necronom (CH) Entwickler sind zwar nett (Obwohl sie es ’schreien‘ – alles in uppercase), aber auch klar: (Cracking ist für sie nicht ‚usefuls‘).


Ein interessanter Kommentar ist von Christian Haller (CH) – eine Herausforderung „Cracken/Crackerintro ohne Qualitätsverlust“. Es ist eine Art Metagame. Cracker* kürzten des öftern Spiele, um ihre Intros unterbringen zu können. Haller teilt hier indirekt mit: Bei uns schafft ihr das nicht. Da ist alles schon zu voll (Ob damals schon das Packen der Spiele* und dann im Memory entpacken üblich war, muss noch nachrecherchiert werden).

Kontrolle eines Homecomputersystems – Prozessor und Hardware-Spezifikas (Screen, Sprites, IO und spez Chips etc)

Das ‚Hässliche‘ oder die ‚Herausforderung‘ an Homecomputerprogrammierung (vorallem im Gamebereich oder Demoscene) ist eigentlich die Varietät neben dem Prozessor (der mehr oder weniger genormt ist). Es geht dabei um das ‚Verstehen‘ der Hardwarearchitektur, Besonderheiten. All dies zersplittere die Macht der Homecomputerscene massiv. Statt sich einfach auf den Prozessor konzentieren zu können – etwa beim Atari ST und Amiga – wird die Hardware darum zum grossen Zeitfresser und natürlich auch Möglichkeitsraum. Dies trifft natürlich gerade auf die Gameentwicklung oder die Demoscene zu. Anders gesagt, in anderen Bereich spielt der Speed zwar eine grosse Rolle aber nicht unbedingt diese massive Rolle. Hier lässt sich auch das Framework rundherum gemütlicher etwa in Basic oder C (ab 16bit) Programmieren und nur den nötigen Kern verschnellern oder anders gesagt: Schnell müssen nur die Unterroutinen sein. Wobei auch Computer wie hier der Amiga eigentlich den Weg vorgeben: Spezialchips erledigen das Aufwändige. Es ist deshalb auch kein Wunder hört die grosse Euphorie für Assembler nach dem Amiga auf. Zu divers sind die nun auftauchendem Erweiterungen als Grafikkarten oder Soundkarten.