Archiv für den Monat: August 2023

C64 Spritedesign – Color-Sudoku

Screenshot: Barry McGuigan (vermutlich je 2 Sprites/Mobs-Körper und 1 Sprite Fäuste genutzt fuer jede Figur)

Der C64 wurde ja bekanntlich als sehr billige Gameconsole geplant und entwickelt. Dabei hat man sich bei der Konkurrenz umgesehen (wie etwa der Intellivsion) und dann das ganze ‚weiterentwickelt‘. Hintergruende bzw. das Spielfeld wird of als eine Art Textmode-40*25-Playfield (vgl. dazu Playfield von Intellivision) erstellt. Die Regeln sind da einfach: Pro Zeichen/Tile 4*8 Pixel im Multicolormode-Text und dasselbe im Multcolormode-Graphic 3 gewählte Farben. Das hat Vor- und Nachteile – siehe andere Posts hier. Ist fuers Design aber noch einigermassen handelbar – Graphik Sudoku.

Sprites oder MOB (Movable Objects)

Bei den Sprites wird aber noch ein zusätzliches (Deisgn-)Spiel gespielt. Es gibt 8 Sprites, die man default-mässig verschieben kann und die nicht mit dem Rest des Memories wie Text oder Grafik interferieren. Die Sprites sind im Vergleich zu anderen Systemen (etwa später NES) recht gross 24*21 Pixel bzw. 12*21 Pixel im Multicolormode. Und sie sind auch sehr gross im Vergleichzu den Chars/Tiles von 4*8 Pixel im Multicolormode. Einige Spiele nutzen auch die Möglichkeit, dass man Sprites verschieben kann, nachdem die erste Hälfte gezeichnet wurde und dann kann man doppelt soviele reinstellen (Multiplexer). Wie sehr das ein Feature ist, das geplant wurde oder wie beim Atari 2600 einfach die Hardware gecheatet ist, lassen wir hier mal im Raum stehen. R. Werner meinte hierzu, dass das Feature von Anfang an so geplant gewesen sei. Interessant wäre hier, wann damit angefangen wurde – wie steht es bei den Arcades dazu? Sicher ist, dass auch das NES später damit arbeitete.
Prinzipiell stellt sich bei der Hardware, die Frage: Soll die Hardware möglichst viele eher wenig-farbige Sprites haben oder grosse, dafuer vielfarbige Sprites.

Sprite-Sudoku-Farben-Design

Richtig knifflig fuer die Designer* und letztlich auch fuer das Resultat wird es bei den Sprites in Sachen Farben. Hier gibt es einmal eine freiwählbare Farbe fuer jedes Sprite. Diese wird oft benutzt, als Hauptfarbe des Sprites. Aus diesem Grund scheinen viele Spiele auch recht flächig im Vordergrund (= bei den Sprites). Designer gleichen das natuerlich aus indem auch der tilebasierte Hintergrund animiert ist und der durchschnittliche Rezipient* den Unterschied auch nicht sieht bzw. sehen muss. Es ist ja der Gesamteindruck der zählt.

Es ist quasi die Signalfarbe des Sprites. Daneben gibt es noch zwei weitere Farben: Diese sind festgelegt fuer ALLE Sprites und es sind dieselben. Das bedeutet fuers Design: Die zwei Farben muessen clever ausgesucht werden, da sie alle Farbbereiche abdecken muessen.

Cases

In der BuggyBoy-Umsetzung sieht man die Nutzung der Sprites recht gut. Schwarz und Weiss sind die DefaultFarben und die dritte Farbe färbt dann die Sachen ein. Beispiel die Flaggen oder die Hindernisse. Natuerlich verwendet BuggyBoy wie die meisten Rennspiele die Möglichkeit des C64 Sprites horizontal bzw. vertikal zu „Strecken“. Ein Aspekt, der fälschlicherweise des Oeftern als 3D Fähigkeit angesehen wurde. Dabei war dieser Effekt nicht stufenlos.

Wie sehr die Designpraxis des Einfärbens mit Spritetemplate funktioniert sieht man vorallem in den Genres Kampfspiele (IK+), Sportspiele (Fussball), Autorennspiele etc. also ueberall da, wo auch im Analogen mit Templates und Trikots etc gearbeitete wird.

Hier als Beispiel ein Autorennspiel mit verschieden eingefärbten Autos:

Aber schon die Tech-Design-Analyse von folgendem Spiel (nur von der Oberfläche Spiel her) wird schwierig. Was sind jetzt hier diese Farben? Vermutlich Schwarz und die Hautfarbe links (Sie kommen fast ueberall vor). Basierend darauf wären dann das „Blau?“ links im Körper sowie die Handschuhe … Das kann allerdings auch nicht stimmen, es hat da eine Farbe mehr. Eventuelle wurde ein zusätzliches Sprite verwendet. Hier kann nur eine technische Analyse der Assets Abhilfe schaffen.

Eine andere Stragie sieht man bei Katakis: Hier ist es offensichtlich als Grundfraben nutzt man ein Hell und ein Dunkelgrau. Damit simuliert man ‚3D‘ und gleichzeitig auch mehrheitlich Technologie. Dann färbt man die ‚Objekte‘ quasi ein in der gewählten Farbe. Die Tiefe des Raumes ist damit quasi grau. Die Gestaltung funktioniert aber so gut, dass man mehrheitlich im Spiel vergisst, wie es design-technisch funktioniert. Aufgewogen wird die Sache, da der Hintergrund auch wieder farbig ist.

Aehnlich arbeitet auch Flimbos Quest. Allerdings wird auch hier klarer, was ein Problem ist: Teilweise sind bei nur 16 Farben und mehrfarbigen Sprites, die Sprites schlecht erkennbar. Da wird dann teilweise wirklich darauf gesetzt, dass Sprites sich bewegen und dadurch erkennbar bleiben.

// ToDo: Diskussion mit Graphikdesignern jener Zeit
// ToDo: Bennenung der verschiedenen Strategien, die aus den Restriktionen kommen (8Bit allgemein)
// ToDo: Mehr Experimente in eigenen Games
// ToDo:: Umbau des SpriteEditors
Aktueller SpriteEditor
// ToDo: Begriff fuer Technische-Design-Analyse
// ToDo: Begriff fuer Game-Technische-Architektur oder Game-Design-Architektur?

Game Factory (Intellivsion, 1983, Unreleased) – Game-Autorensystem 8Bit

Es darf nicht vergessen werden, dass es sie immer gab (in diesem Fall leider nie released). Die Meta-Autorensysteme und abstrakten Gameengines. Game Factory ist eine davon, die auch gerade zeigt, was so der Umfang und die Funktionalität sein konnte bzw. anders gesagt, mit was sich normalerweise Gamedesign hardcore auseinandersetzen musst.

Visuelles Levelstorytelling oder „Environmental Storytelling“ 1.0 in 8Bit/16Bit

Wie kann man Storytelling betreiben in Welten, die vor allem aus Blöcken bestehen (Speicher und CPU lassen nicht viel mehr zu) – aus wiederholbaren Blöcken? Und auch keine Zwischenbilder möglich sind (Benötigen viel zu viel Speicher) und schon gar keine Filmchen. Da hilft meist nur ein einfaches eingängiges Setting, Text ist nicht gerade sexy (da wollten ja alle raus). Erschwerend kommt hinzu, dass die Arcades (als Leitmedium) auch noch meist Action-lastig sind (Das ist als einfachstes monitarirsierbar und Spielzeit lässt sich relativ simple erhöhen im Gegensatz zu einer Story.).

Wie kann man nun Fortschritt oder sogar Storytelling betreiben in diesen Genres? Das Simpelste ist die Box und ihr Frame, eventuell noch der Arcadeautomatkasten oder bei Consolen/Games ein Booklet (> siehe B). Und dann?

Das Einfachste ist (und es wurde oft benutzt, vor allem in Action-lastigen Titeln). Die Entwicklung der Welt in eine Richtung und das Setting verändert sich dabei, etwa als Reise durch die Zeit. Dadruch entsteht ein „enviromental Storytelling“ während die Spielmechanik mehr oder weniger gleich bleibt.

Je allgemeiner das Thema ist, umso einfacher ist fuer die Entwickeler* es etwas einzupassen, Dinge zu erweitern oder Dinge wieder zu streichen.

Cases

Ein einfaches Beispiel ist etwa R-Type. Hier ist die Story eine zunehmende visuelle Alienisierung der Welt bist man im Kern angekommen ist. Die ‚Story‘ ist dabei visuelle einsehbar, die Welten werden immer komplexer, immer schneller und Detail reicher. Wobei hier die „Vorlage“ Aliens doch sehr hilft. Siehe auch andere Spiel wie Necronom.

In Xenon 2 geht es einer Art Evolution zur Technologisierung hin des Feindes.

// ToDo: Andere Beispiele aus verschiedenen Genres