Geht es um den Versuch plastisch zu gestalten, ist das Medium C64 im Multicolor-Mode und bei den Sprites schwierig. Die einfachste Sache: Verwenden der 2 Fuer-Alle-Gleich-Farben als eine Art Lichtschattierungradient und die Zeichenfarbe als die Hauptfarbe. Dadurch ergeben sich zumindest zwei mögliche Designstrategien, die zu unterschiedlichen Eindruecken fuehren.
Front-Farbe-Konzept: Die wählbare Farbe ist zu vorderst und erscheint damit als Hauptfarbe. Die meist Graustufen, erzeugen dann den Hintergrundeffekt.Selbstverständlich lassen sich die Graustufen dann auch fuer technische Sachen etc. nutzen.
Sandwich-Farb-Konzept: Die nicht-wählbaren Farben decken, die dunkelste und die hellste Farbe ab. Die wählbare Farbe ist dann zwischen diesen zwei Farben.
Im besten Fall erscheint dann das Ganze sehr kontrastreich und kann Comics-Aesthetik annehmen. Im schlechtesten Falls ist dann alles viel zu hell und eintönig.
Hier ein eigene Designbeispiel aus dem entstehenden Spiel „Holy Cube“. Wobei hier auch noch zusätzlich auf den Rotationseffekt gesetzt wird.
Selbstverständlich lassen sich diese beiden Techniken auch kombinieren. Sie sind auch nicht die einzigen, die man in der freien Wildbahn sieht.
„Coden“ war oft ein Navigieren in einem stetig wachsenden und komplexer werdenden Source-Code. Der Code war mehr oder minder ein Plaintext. Meist die einzige Möglichkeit nicht muehsam scrollen zu muessen (Scrollen per Mouse war anfangs nicht vorhanden und ist sehr ineffizient bei viel Code), sondern direkt hinzuspringen war die Suche. Was kann man suchen?
– Sprungmarken oder Funktionen (was in Assembler dasselbe ist) – Variablen-Namen – Spezieller Code – Kommentare
Das war und ist egal ob es Spaghetti-Code war oder nicht.
// Code completion war selbstverständlich auch nicht vorhanden.
Powerplay entstand als Sonderbeilage fuer die Video- bzw. vorallem Computergames im HappyComputer und wurde dann spezialisiert ausgegliedert. Das heisst: Games waren als Medium und Community-bildend wichtig genug (auch finanziell), um als eigenes Medium eigene Besprechungsorgane zu haben. Damit endet auch ein Teil der All-In-Computermagazine.
Geschätzt wurde das „PowerPlay“ auch wegen seiner unabhängigen Art Spiele zu besprechen (anders als andere Magazine, die eher (gekaufte?) PR machten) und zu bewerten. Es gab jeweils zwei Personen, die das Spiel textlich bewerteten und dies floss in eine Gesamtbewertung ein. Da diese unterschiedliche Profile abdeckten, konnte man mit der Zeit sehen, welche Einschätzungen „man“ teile. Ein „Gut“ war ok, ein „Super“ war dann auch meist ein Knueller. Aus heutiger Sicht muss man auch sagen, dass die Spielmechanik meist im Fokus der Analyse lag. Wie das Magazin – anders als heute – so unabhängig sein konnte, erklaert sich vermutlich mit der Abhängigkeit vom Publikum (Kioskverkäufe) und wenig Werbung.
Besonders bekannt wurde auch der Comic Starkiller, der eine Art MetaCritic der Gamebranche war und auch immer die Designerperspektive ‚diskutierte‘ und hinterfragte: Starkiller – Die Geißel der Galaxis
// ToDo: Businessmodell vom PowerPlay vs ander Magazine wie ASM.
Letztlich ist die Digitalisierung nur eine Untermenge eines viel grösseren gesellschaftlich technologischen Prozesses: Der Virtualisierung oder Cyberspacisierung. Dabei geht es nicht nur darum, Dinge zu virtualisieren sondern auch neue Dinge zu ermöglichen. Dies wird gerade anhand des GameDesigns und der Spielgeschichte deutlich. In diesem Bereich geht es letztlich endlich auch um Kontrolle und kontrollierbare Spaces. Also Spaces, die man nutzen kann, um Spiele zu entwickeln und produzieren. Optional ist ja Interaktion immer dabei in Games. Dabei sind die Spiele natuerlich nur ein Teil des Trends. Dieser Trend lässt sich auf einer Metaebene so zusammenfassen: Mehr Kontrolle und dies erreicht man am einfachsten durch kontrollierbare Regeln. Damit setzt sich eine Bestrebung fort von Sklaven bis zur Digitalisierung bis hin zu Tools wie AI (wobei kontrollierbaren Regeln hier gerade nur die Trainingsdaten sind – Kybernetik pur) und etwa GenEditing.
Aus heutiger Perspektive vergisst man diesen Grosstrend, weil zu sehr die Digitalisierung im Vordergrund steht und alles nur im Rahmen der Digitalisierung gesehen wird, dabei zeigt gerade die Entwicklung der Spielewelten, dass viel mehr da war, ueberschrieben wird (The medium is the message) und vieles weiterhin existiert. Die ‚Verluste‘ dieser Virtualisierungen werden dabei wenig bis gar nicht diskutiert. Es geht ja um Kontrolle und damit verlagert man den Diskurs in diesen neuen Space. Radikal kommt bei den rein virtuellen Games hinzu, dass sie fast keinen analogen Space mehr benuetzen und darum auch nicht um diesen Kaempfen muessen. Der Nachteil ist auch bekannt: keine wirkliche Anerkennung als Kulturgut.
[Interessanterweise waren die ersten (=analogen) Arcades mehrheitlich sehr plastisch, weil sie als Display reale Gegenstände benutzten. Siehe dazu auch: https://www.gamelab.ch/?p=448. Nur langsam setzten sich flache Displays durch wie etwa der Duellfilmarcade beim Nintendo Aracde oder beleuchtete flache Objekte etc. Die Vorteile sind dabei klar (die Nachteile auch): Virtualisierung und mehr analoger Cyberspace im Sinne von Kontrolle der Oberfläche. Dadurch war es möglich mehr darzustellen und spielbar zu machen. Es waren nicht mehr klassische ‚Spielwelten‘. Diese neuen flachen Spielwelten sind auch spielbar in den analogen Consolen siehe Gamelab-Archiv. ]
Betrachtet man die ersten Spiele (Arcade wie auch Homecomputer), so sind diese mehrheitlich „flach“. Die Gruende dafuer sind vielfältig wie kleine Sprites, Farbpalette, wenig Farben fuer Hintergruende und Sprites und damit wenig Möglichkeiten zur Codierung von Spielmechanikfunktionen (vgl. visuelle Regeln). „Flach“ ist in diesem Sinne einfarbig in Sachen Sprites etwa, was fast zwangsläufig zu einer flächigen Struktur fuehrt.
Es entwickelten sich dadurch auch eigene Stile wie etwa flächige-tilebasierte Spiele (vgl. Space Taxi) oder dann als Platformmerkmal etwa beim ZX Spektrum ein eigener Stil.
Beim C64 sind die ersten Spiele auch mehrheitlich flächig (graphisch) und entwickeln sich dann zunehmend ‚plastischer‘ (wie die ganze Branche insgesamt – siehe auch Arcades).
Mit mehr und mehr Grafikmöglichkeiten und grösseren Gameobjekten, wurde es auch möglich Licht und Schatten im Hintergrund wie in den Gameobjekten zu platzieren und damit wurde auch 3D abbildbar.
Hier das Beispiel von Arkanoid – einer Arcade-Umsetzung. Zusätzlich nutzen die Spiele dann auch Animation in den Raum und simulieren 3D visuell. Dadurch verändert sich durchgehend die Form und die Farben.
Im Heimcomputerbereich damals legendär der Drache von Great Giana Sisters. Dieser wurde als ‚3D‘ wahrgenommen. Interessant dabei: Das Sprite ist gross und 3D animiert. Das meint: Die Animation geht in den Raum hinein – aus der Bildschirmebene hinaus (Fluegel). Er war in der Wahrnehmung damals ‚lebendig‘ und ging damit weit ueber 3D-Rotationsobjekte hinaus vieler ShootEmUps.
Als Vergleich hier noch die Amiga-Version von Great Giana Sister (das in Vielem ein Clone von Super Mario war und in vielen Bereichen darueber hinaus ging – ein Meilenstein des (deutschen) Gamedesigns).
Durch die Einschränkung in Sachen Farbpalette und Auswahl daraus, ist die Blink-Farbe oder die sich wechselnde Farbe sehr oft benutzt in 8bit. Man verwendet sie im Einfachsten Fall als On/Off. Da existiert ein Objekt und auch wieder nicht. Eine klare Erfindung des Digitalen. Gesteigert wird es genutzt fuer Funktionalitaeten wie Shield, Extraleben etc. Hier besteht das Objekt immer aber in allen möglichen Farben. Es ist damit so quasi alles Mögliche: Der All-Farbquantor. Interessanterweise wird dabei meist die Form beibehalten und nicht auch noch durchgeloopt.
// ToDo: Vgl. Durchloopen in möglichen Extras (MarioKart) ausgeborgt von den Slotmaschines (vermutlich) // ToDo: Einblick in Nutzung von Farbverläufen/Raster um viele Farben zu ’simulieren‘
Das Morgengrauen der deutschsprachigen Fussballmanager
Starbyte Super Soccer ist eines dieser frühen Fussball Management Spiele (Genre: Strategie). Der Name musste so gewählt werden, weil es andere Produkte mit demselben Namen Super Soccer gab, zum Beispiel von Nintendo. Starbyte selbst hatte bereits mit Soccer Manager Plus (1989) ein anderes Fussball Strategie Spiel im Angebot. Zwei Jahre später wurde fürs neue Fussballmanager Spiel ganz auf die deutsche Bundesliga gesetzt, die möglichst akkurat umgesetzt sein sollte.
Die Atari ST Version von Starbyte Super Soccer kam zu Weihnachten 1991 in die Läden. Die PC Version ebenfalls. Die vom Schweizer René Straub programmierte Amiga Version ein paar Tage später.
Das Spiel ist eindeutig ein deutsches Spiel. Starbyte hatte es aus der Public Domain geholt und zuerst von Atari ST auf Amiga portiert. Dirk Weigand hatte am Vorgänger Kicker gearbeitet und seinen Fussballmanager 1990/91 unter dem Label PolarSoftware herausgebracht. Kicker war einer der ersten deutschsprachigen Fussballmanager. Der in Troisdorf (nördlich von Bonn) lebende Weigand war inspiriert vom 1984 erschienenen Footballmanager auf dem ZX Spectrum und hatte von 1987 an seinen eigenen Fussballmanager entwickelt, der sich mit neuen Features von anderen vergleichbaren Spielen absetzen sollte. Dirk Weigand besass einen Atari 600XL und kam damit bald an die Grenzen des Möglichen, da der Computer lediglich 16 Kilobyte Speicher besass. Er verdankt die Fortschritte in der Entwicklung seinen «reichen Pateneltern aus der Schweiz», die ihm zur Konfirmation die Anschaffung eines Atari ST ermöglichten. Programmiert wurde das Spiel mit GFA-Basic 2.0 Das Basic ermöglichte auch das Kompilieren der Software zu einem eigenständigen Programm. Bruder Frank und Stiefvater Bernd halfen zumindest konzeptuell und beim ständigen Testen mit. 16-farbige Sprites wurden von Oliver Merklinghaus beigesteuert. Und Dirk Weigand gewann das Listing des Monats im Atari Magazin für den Monat Januar 1989.
Startbild von Dirk Weigands Fussballmanager KICKER, der als Shareware 1990 herauskam.
Das 1990 fertiggestellte Kicker wurde zuerst nur unter Bekannten und Freunden verteilt und gespielt. In der ASM 8+9/90 wurde das Spiel dann in einer neuen Kolumne vorgestellt und bei Weigand meldete sich die Firma Micropartner, die das Spiel vertreiben wollte. Da die Firma aber das Programm nicht portieren konnte, sah Weigand nur noch den Weg der Selbstpublikation. Man konnte das Spiel dann als Shareware für 30 DM bei ihm bestellen. Weigand hatte insgesamt etwa 100 Bestellungen. Kicker war ebenfalls auf einigen Shareware-CDs mit vertreten.
Zu Beginn von 1991 meldete sich Starbyte Software bei Weigand. Neben der Atari ST Version sollte das Spiel auf Amiga, PC und C64 portiert werden. Ende 1991 kamen denn auch die Atari ST, die PC und die Amiga Version heraus. Die C64 Version erschien erst ein Jahr später. Starbyte gab dem Fussballmanager den Titel Starbyte Super Soccer, was Weigand nicht gefiel. Ergänzt wurde es durch eine neue Grafik zum Programmstart, Musik und Stadiongeräusche. Der Rest blieb sich gleich.
Die Amiga Version wurde vom Schweizer René Straub programmiert, der bereits andere Portierungen für Starbyte erarbeitet hatte.
Startscreen von Starbyte Super Soccer
Die Aufstellung des eigenen Teams und die Matchtaktik für jedes Spiel ist das Herz des Fussballmanager Spiels. Die Spiele selber werden in Starbyte Super Soccer visuell nicht gezeigt.
In Starbyte Super Soccer darf der Spieler sowohl die Rolle des Managers als auch die des Trainers übernehmen. Und es können bis zu sechs Spieler gleichzeitig eigene Teams übernehmen, es wird einfach etwas eng vor dem Computer. Weigand war zumindest stolz auf die Kritik des beliebten Spieleredaktors Heinrich Lenhardt, der im Powerplay Sonderheft von 1991 das Spiel unter die 100 besten Spiele einreihte und mit ausgezeichneten 80% bewertete. Doch der Erfolg liess auf sich warten, denn fast zeitgleich erschienen zwei weitere Fussballmanager mit Bundesliga Manager Professional (1991) und Anstoss – der Fussballmanager (1993). Und dann kam natürlich noch die Pleite von Starbyte hinzu, so dass die vertraglich vereinbarten Zahlungen 1992 ausblieben. Das Spiel wurde dann ab 1993 von der neugegründeten Firma Starbyte Software weiter vertrieben. Viel Geld brachte es Weigand aber nicht ein. Er hatte das Spiel bereits abgeschrieben und konzentrierte sich fortan lieber auf sein Studium.
Kein gutes Spiel der Würzburger Kickers … – Aufstellungen und Resultate werden auf dem Hintergrund des Spielfeldes gezeigt, danach folgt die Tabelle.
Nach über 30 Jahren hat sich Dirk Weigand von einem Interview zur Videospielgeschichte nochmals motivieren lassen. 2021 hat er sich nochmals hingesetzt und den wieder gefundenen Source Code des alten Spiels KICKER durchgesehen und dabei auch noch einen wichtigen Bug im in GFA Basic 2.0 korrigiert, der den Start des Spiels im Emulator behindert hatte. Die Geschichte von Dirk Weigands Entwicklung ist in einem Interview von Denis Roters auf „Videospielgeschichten“ ausführlichst aufgeabreitet worden. Dazu kann man heute auf der gut dokumentierten Website von Frank und Dirk Weigand ein neu erarbeitetes Disk Image für Atari ST sowie Emulationen für verschiedene zeitgenössische Plattformen finden.
KRAKOUTs Title/Menuscreen zeigt vielleicht indirekt auch das Verhältnis von Demoscene/Crackkultur und ihren Einfluessen im GameDesign auf. Nicht alle fanden das Zeigen von Effekten und sei es auch nur Scrollschriften mit Messages eine gute Sache (Aufwand) – denn um was geht es in einem Game? Mehrheitlich um Spielmechanik und dem ist alles unter zudordnen – so eine GameDesign-Perspektive. „SORRY THERE IS NO SCROLLY MESSAGE BUT WE DECIDED TO GIVE YOU AN AMAZING GAME INSTEAD“ weist darauf hin, dass Games eben nicht aus schönen Scrolligmessages besteht. Allerdings muss auch gesagt werden, dass natuerlich die Visuals/Audio immer ein Teil der Belohnungsstruktur von Games waren und sind.
Interessant wäre sicherlich zu wissen, ob der Name auch eine Anspielung ist.
// Krackout nimmt die ArcadeHardware sehr ernst, dort war es ja bekanntlich auch ein Hochkant genutzter Screen. Wieviel wohl ihren Screen hohen Weg hingestellt haben .-)
// Update: Ob das Paddle hier ‚bat‘ links oder rechts ist, kann eingestellt werden in den Settings.
// ToDo: Herausfinden, ob die Leute noch erreichbar sind
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?
