Archiv für den Monat: Juni 2023

Punkte als optionales Motivationsdesign

Meistens sind Vorwärtskommen und die Anzahl Punkte eher lose miteinander verbunden. Sicher ist, wer weiter in einem Spiel kommt hat durchschnittlich mehr Punkte. Aber eben nicht immer. Es ist öfters eher so, dass die Punkte ein AddOn sind.

Punkte sind eine Art zusätzliche Motivationsmechanik neben dem möglichst weit kommen. Interessanterweise gibt es sogar Arcades, die im Highscore unterscheiden zwischen Punkte und erreichtem Level. Da kann man sich dann selbst entscheiden, was man selbst höher gewichtet.

Überlegungen: Genre Jump & Run in 8bit

Das Motivationsdesign von Jump&Run ist eigentlich – so die erste Idee – springen und immer luftigere Höhen zu erreichen.

Das Problem dabei – es gibt gar nicht so viele Spiele bei denen man in immer höhere Sphären springt. Eher das Gegenteil ist der Fall: Die meisten bekannten Jump&Run Spiele im 2D bewegen sich eher nach rechts oder links in einem vorgegeben Bereich in der Höhe (meist ein Bildausschnitt) – siehe bis heute etwa Super Mario Bros oder so.

Geschichte

Zuerst einmal sind „Springspiele“ gar nicht so beliebt. Sie haben ein Handicap: sie brauchen viel Platz bei wenig vorhandenem Platz. Es dominieren teilbasierte Einzelräume – technisch wie auch inhaltlich. Die Kamerafahrt durch Räume muss erst noch technisch erfunden (auf den Consolen zumindest) und möglich gemacht werden (Hardwarescrolling etc).

Und so dominieren auffallend viele Spiele (Platform Games), die den einen Raum mehrfach nutzen. Es sind Spiele „in“ mit Treppen, Leitern (Lode runner) oder dann Liften (Mission Impossible) und Springen ist dabei ein Mittel, über Lücken aber aber meist hinunter. (Ausnahme vielleicht hier Donkey Kong – wobei man auch hier sieht wieviel Platz benötigt wird fürs Hochspringen.)

Springmechanik

Die Spiele, die mit „Springmechaniken“ arbeiten nutzen dann auch nicht den realen analogen Raum (reale Physik – anstossen des Kopfes) sondern eher einen gefakten, um Sprünge zu ermöglichen – also etwa nach oben ‚bespringbare‘ Platformen (IceClimber und co). Die Platformen sind in einer Art vorne offen und man springt so hoch (falls man westlich eine physikalische Erklärung bräuchte).

Wie man fantastisch gute Single-Screen Jump&Runs machen kann, zeigte sicherlich auch N und N+ in Flash Jahrzehnte später. Allerdings war auch dies nur Möglich, weil die Auflösung viel höher war. (Todo: Gibt es ein Pixel 8bit Jump&Run?)

Scrolling und „SpringSpiele“ – Jump & Run

Mit der Einführung von Scrolling kommen erstmals richtig grosse Jump & Runs überhaupt ins Spiel und das aus mindestens zwei Gründen: 1. gibt es nun genug Platz zum Springen und 2. kann es trotzdem vorwärts oder aufwärts gehen – es gibt also Progress (ohne verschiedene Challenges im Raum zu definieren). Das ist eigentlich recht gut ersichtlich in Spielen wie Ice Climber oder Super Mario.

Ice Climber – der ständige Abgrund

Bei Ice Climber ‚haut‘ man sich den Weg frei nach oben. Das Bild scrollt weiter nach vorne. Das Problem dabei im Design und im Spiel, was passiert, wenn man runterfällt. So ist potentiell immer das schon Erreichte gefährlich. Ab und zu eingezogene Platformen helfen da nur begrenzt. Die Angst ganz zu fallen – den tiefen Fall im Spiel nehmen sie nicht wirklich. Allerdings ist genau das dann auch mit ein Grund, warum dieses Genre sehr bei „Endlosrunnern“ wie DoodleJump so beliebt ist.

Hier sichtbar am radikalen Beispiel des digitalen analog Spiel NS-Tower (Mac, 1997):

Super Mario und Co

Super mario und Co lösten das Problem ja bekanntlich, indem es gar nicht nach oben geht, sondern immer wieder nach oben (im Screen) und vorallem horizontal. Dies löst sehr viele Probleme auf einmal. Das Wichtigsten: Die gefährliche untere Seite von Ice Climber und Co ist weg und die Bewegung ist in jedem Screen von neuem: Jump und Run! Dadurch wird es die Welt des Jump&Runs in der heutigen Art möglich.

Anbei die interessanteste Variante von Super Mario – Great Giana Sisters 1987 mit der Punk „Sister“ Giana. Europäisches Mukokuseki vs. japanische Super Mario Mukokuseki.

Die Überlegungen sind konkret aufgekommen in der Auseinandersetzung mit dem Jump&RunGenre und dem Nachbau von NS-Tower (Endless Runner) auf dem C64.

Nachfolgend ein Screenshot des OneButton Jump and Runs (In Entwicklung)

VR und Alien(s)

Der Ausschnitt aus dem SRF Beitrag mit dieser überdimensionierten VR-Brille und den Kabeln hinten raus aus einer Schweizer Spielhalle (Anfang 90er Jahre), zeigt auch noch einen interessanten visuellen Link. VR und Gigers Alien scheinen auf einmal ganz nahe und verschmolzen: Form und Funktion.

Letztlich ist die Mensch-Maschine eine Art Alien von der Form her. Dann amputiert die Brille die Augen, um sie durch etwas Neues zu ersetzen (vgl. McLuhan eine Auge für eine Brille). Ähnlich verhält es sich beim Alien, das per se keine Augen hat, weil es – so Giger – so gierig und Überlebens ausgelesen ist, dass es keine Augen im klassischen Sinne mehr braucht.

Zeit zu Spielen nach innen statt nach aussen.

Tiles, Sprites & die Grösse der Gameobjekte

8Bit Computer und Consolen implementieren meist ganz konkret eine Differenz zwischen Spielfeld (Tilebasiert) und den darüberliegenden bewegbaren Objekten. Das tilebasierte Spielfeld wird dabei genutzt als Hintergrund (Backgroundelemente) und/oder als interaktives Spielfeld (etwa Labyrinth). Die Tilebasierung macht es möglich schnell, selbst mit Arrays Spielfelder zu erstellen und ist als erstes einmal Ressourcen (RAM – teure Ressource) sparend.

Schablonenartig werden hier letztlich Objekte wiederverwendet. Dabei ist das erkennen von Wiederholung aber dann auch das Problem. Es wirkt nicht dynamisch (Warum muss es eigentlich dynamisch, einzigartig wirken? Unsere Welt ist es acuh nicht. Aber vermutlich liegt hier das Problem. Das künstliche Computerspiel darf nicht zu künstlich aussehen. Das würde die Künstlichkeit und den Fakismsm verstärken).

Darüber liegen die Sprites oder MOB beim C64. Diese werden darüber gerechnet (Hardware) vor dem Zeichnen und ermöglichen damit das Auflösen der normalen Blockstruktur (1 Pixel ist nicht 1 Pixel). Interessanterweise ist damit auch das Nutzen von DoubleBuffering nicht nötig (vgl. Amiga vs Atari ST).

Interessant wird nun im Design- wie im Rezeptionsprozess die Grösse dieser zwei Strukturen und ihr Verhältnis. Ältere Konsolen tendieren – zumindest auf den ersten Blick – zu 1:1 Grössen. Das heisst der Raster wird zumindest Aesthetisch beibehalten und damit schon per Default eine gewisse Aesthetik und Lesbarkeit gewahrt.

Allerdings setzt mit dem C64 schon ein, dass die Sprites grösser werden und die Tiles kleiner (Zeichensatzidee beim C64) und dass die Tiles dann ganz verschwinden bzw. von den GameDevs* simuliert werden, quasi Tile-Virtuelle-Maschines. Das führt dann auch zu neuen anderen Spielmechaniken. Dabei spielt die zunehmende Verfügbarkeit von RAM etwa in den 68000er Homecomputern eine entscheidende Rolle (vgl dazu MS-DOS 640kb Grenze auch etc.)

Für die Entwickler* müsste das eigentlich als Befreiung empfungen worden sein, bei gleichzeitigem Problem was diese Freiheit vom Raster nun für neue Probleme bringt – designtechnisch. Ein Dilemma, dass bis heute erlebbar ist im Gamedesign.

Die Frage, wie gross dürfen Avatare sein und wie gross die NPCs dazu, ist bis heute virulent, denn es geht letztlich um die Frage, wieviel Fläche darf, was, warum einnehmen.

Todo:
– Konkrete Analyse über die Zeit der Grösse der Avatare und NPCs.
– Technologische Abhängigkeiten – Grosse Sprites als Zusammensetzungen etc
– Anwendung: Spiel mit einem riesigen Avatar – Bildschirmfüllend

Manuelle versus automatisierte visuelle Digitalisierung: Dithering

Bilder entstehen in einem ersten Schritt in der entstehenden – vor allem privaten – Computerindustrie meist als Images mit Tools des Computers, also im Medium selbst. Dadurch ist jeder Computertyp selbst ein Medium (siehe anderer Blogeintrag) und lebt von dessen Eigenheiten.

Dieser manuellen Digitalisierung steht sehr früh schon die automatisierte Digitalisierung gegenüber. Hier wird versucht aus analogen Bildern (oder einem Abbild) ein digitales Bild herzustellen. Die einfachste Technik bei wenigen Farben ist das Dithering (von Schwanken, Zittern). Bekannt ist das Digthering letztlich auch aus dem Druck. Mehr zum Verfahren wie immer auch auf Wikipedia.

Es handelt sich hier also meist um statistisches Verfahren, um technisch nicht existente Farben oder Graustufen als Pixelstrukturen abzubilden.

Historisch – scheint mir zumindest – hatte Digthering gerade in der Homecomputerscene keinen allzu guten Ruf, war die Anzahl der Pixel nicht all zu hoch und meist gerade im 8Bit Bereich auch keine Farben wirklich so abgestimmt, dass es gut aussah.

Deswegen waren eher genuin hergestellte Bilder gefragt. Nicht desto trotz gab es immer die Bemühungen, das analoge Bildmaterial zu erschliessen. Eine besondere Rolle spielt hier sicherlich die Pornografie, die sehr von der direkten Abbildung ‚lebt‘. Erste Versionen kamen meines Erachtens (neben dem Print) deswegen früh in Games auf, wo man mittels Spiel (Konzept Volfied) nakte Personen aufdecken musst. Und so gab es denn auch und man findet noch heute versteckt auf Ebay gekauften Computern Soft- bis Hardcore-Porno-Bilder. Die Ästhetik dabei ist meist grenzwertig, erweckt sie doch den Eindruck, dass es immer irgendwie ‚dreckig‘ ist bzw. schwarz-weisse Überwachungskamera-Ästhetik.

Interessanterweise scheint – falls es sie je gab – kulturelle Gebundenheit heute nicht mehr da zu sein, so dass Dithering vermehrt eingesetzt wird und auch als romantische Artefakte gesehen werden können. Es wäre damit eine weitere Technologie die an ältere Zeiten erinnert. Aber all dies sollte genauer untersucht werden.

Digthering wird heute auch vermehrt in Fantasy-Consolen eingesetzt (auch manuelles Dithering). Gerade im Bereich von 3D Darstellung.

Todo:
– Texte zum Phänomen suchen
– Umfrage unter Usern
– Umfrage unter Entwicklern

Mögliche Ausstellung: GameFake oder GameCode

Nach diversen Diskussionen: Ausstellen des Hintergrunds des technischen Gamedesigns.
Möglichkeiten:
– Displaying per zweitem Monitor oder Beamern des Logfiles in ‚Echtzeit‘ (Varianten: Extra entwickelte Games erstellen, die Kommentare abgeben auf dem zweiten Display oder sogar ein Metaspiel ausgeben)
– Displaying per zweitem Monitor gleichzeit der Szene in der es spielt. Dekonstruktion
– Ausgedruckter Code
– Code an der Wand mit QR-Code – Ausführung auf dem Browser als Link
– OT mit Code

Grundfrage: Was fehlt da?

Eine der Grundfragen im Bereich von kultureller Forschung muss auch immer sein: Warum ist XYZ nicht vorhanden?

Diese Frage und deren Antworten stellen eigentlich die Frage nach den Aussengrenzen des Systems, nach dem Ausgeschlossenen und Verdrängten. Was macht das System aus? Wie funktioniert der Übergang, das Übertreten der Systemgrenze (vgl Derrida).

Diese Frage kann und wird meist innerhalb des Systems beantwortet. Die Antworten sind da naheliegend, es gibt Artefakte aus der Systemreproduktion. Das ist aber nur die Hälfte die Wahrheit. Das System hält – und das ist keine Neuigkeit – auch das zusammen bzw. markiert es, was ausgeschlossen wird (siehe Luhmann und Systemdiskussion, Reentry).

Schwierig wird es mit Dingen, die nicht explizit ausgeschlossen durch Texte, Entscheide, Gerichtsurteile werden. Sondern Dinge, die schlicht und ergreifend verschwiegen und totgeschwiegen werden oder Dinge, die in der konkreten Praxis einfach nicht ‚existieren‘.

„8bit swiss“ – eine mögliche Ausstellung

Eine Ausstellung zur Schweiz und 8bit bzw. zur Schweiz damals in der 8bit Zeit und heute in Retro-/Vintage 8bit wäre sicherlich eine interessante Sache. Unterthema könnte auch sein, die manuelle Digitalisierung dieser Zeit.

Diachron Ausstellungsobjekte:

– 8bit Politik (Politik, mit wenig Auflösung?)
– 8bit Wecker und Co
– 8bit Grafiken
– 8bit Sound/Music
– 8bit Konsolen (inklusive Game&Watch mit 256 Gegenständen)
– 8bit Computer
– 8bit Computertools
– 8bit Computerspiele (auch aus der Schweiz)
– 8bit Development: Basic – Assembler – Logo

Synchrone Ausstellungsobjekte:
– 8bit Devs heute vgl. Roman Werner
– Fantasy Consolen
– …

Also alles was so obsolet ist heute


Assembler (C64): Fehler, Rumprobieren, Analyse, Konzeptfehler, neu anfangen?

Warum nur kopiert es die Color- und die Multicolorfarben nicht richtig rein in die entsprechenden Speicherbereiche?

Coding in Assembler ist Hardcore-Arbeit (vergleichbar mit Brainfuck-Coding). Beim Coden entsteht ein Konstrukt, das ausgeführt wird und etwas tut. Tut es das Richtige? All das ist in Assembler noch eine Runde schwieriger, da der Output nicht so simple ist, da die Möglichkeiten klar sind und Heisenbergsche Fehler (Unscharfe Fehler) gerade im unendlich oft vorkommen.

Fail

Funktioniert etwas nicht, probiert man rum, versucht es systematisch mit Ausgaben, Annahmen, Analysen.

Ist alles wie es sollte vom Code her?
Im Code gibt es keine Probleme? Und doch funktioniert es nicht?
Ist es ein Modellfehler? Funktioniert die Grafikrepräsentation anders? Habe ich falsche Vorstellung von der Sprache? Der Maschine?
Gibt es einen Konzeptfehler?
Ein Problem mit überschriebenen Registern? Soll ich neu anfangen?

Die Unsicherheiten mit Assembler – obwohl im Einzelnen so klar – sind gross. Und ja Brainfuck funktioniert tatsächlich ähnlich.