ShootEmUps sind für Developer* schwierig und einfach zu gleich. (vgl. Zitat War Heli – „Das Einfachste … „). Die Zerstörung als Philosophie hilft auch in radikalster Mukokuseki-Manier nicht nur zu spielen, sondern auch Games zu entwickeln. Dass einige der grössten ShootEmUps aus Japan kommen ist dabei kein Zufall, sondern eher Weiterentwicklung der Idee von Kulturaneignung und historischen Erfahrungen gepaart mit Technologie (siehe Artikel zu Mukokuseki). Die 80er Jahre, ihre Postmoderne und ihre Kreativität im Angesichts der Auslöschung.

Schwierig weil sie technisch in den 80er Jahren die grösste Herausforderung waren: Viele bewegende Objekte, viele animierte Objekte, meist Interaktion Vorder- und Hintergrund, grosse Freiheit des Spielers, viele Extras und Waffen und meist scrollt auch noch der Bildausschnitt (frühere Verwendung oder Simulation einer Camera) und und und. Die Games waren quasi die Demoscene als Spielgenre, ohne das Problem der Demoscene nur Demo zu sein. Insofern ist es auch kein Wunder kamen 2 der ersten 16/32Bit Spiele aus der Schweiz aus dem ShootEmUp-Sektor: WAR HELI (Atari ST) und InsanityFight (Amiga) beide 1987.

Auf der anderen Seite einfach: Die Spielmechanik ist relativ banal: Es geht darum, das Ziel zu erreichen – alle Gegner zu zerstören/auszuschalten und/oder ans Ende zu kommen. Durch diese brachiale Spielmechanik ist es einfach das Spiel zu erweitern, neue Gegner*, Levels reinzuhängen oder eher noch wegzulassen. Und die Spielmechanik ist nicht narrative abhängig vom Ablauf. Designtechnische Narrativität wird meist kreiert durch die Steigerung der Gegner*, visueller Aktivität oder/und am Einfachsten die Reise ins Herz des Gegners zum ‚Gehirn‘ selbst. Die Kultur des Gegners nimmt zu, die Visualität (Maschinen, Tiere, Einfluss).

Es geht darum, das System zu reinigen. Eine Rolle spielen hier sicher auch die 80er Jahre (siehe Giger unten) und die Umweltverseuchung, atomare Vernichtung (Der atomare Holocaust (der ja auf alle abzielte)). Der Intertext ist meist irgendwo da, auch wenn viele Spiele ihr Setting in die Technozukunft verschieben. Interessanterweise läuft die Zeit der ShootEmUps als technologischer Treiber auch Mitte der 90er Jahre aus und wird vom Wettlauf um 3D überlagert. Die Themen bleiben natürlich auch wenn weit weniger ‚Atomarer Holocaust‘ inspiriert.

Visuelle und spielmechanisches Mukokuseki

All dies führt dazu, dass das Genre durchtränkt ist von Mukokuseki oder salopp gesagt der Postmoderne und zwar im Visuellen wie in der erweiterten Spielmechanik.

Die meisten ShootEmUps bestehen aus einem wirren Mix von visuellen Stilen, die ineinander gemixt werden und wo Neues entsteht bei der Systemschliessung des Designs. Oft ist ein Territorium besetzt worden, das Neue überwuchtert (vgl Giger und Artikel unten) die Welt. Es sind gleichzeitig beide Systeme sichtbar. Allein dieser Umstand macht visuell klar: Der Auftrag ist das Trennen dieser Kulturen bzw. die Zerstörung der neuen (kolonialen) Kultur.

Giger und Co im ShootEmUp-Genre

Dazu eignet sich inhaltlich wie visuell natürlich auch sehr gut das visuell mechanische Konzept von Gigers Werk. (siehe BlogEintrag hier: https://research.swissdigitization.ch/?p=32). Gigers Konzept, das etwa bei R-Type etc zum Einsatz kommt, verschränkt visuelle Regeln und Spielmechanik gerade zu perfekt und kommt deswegen auch so oft zum Einsatz.

ShootEmUp ist letztlich ein Genre, das eigentlich alles möglich macht. Und die 80er Jahre haben dem auch noch die Tiefe mit einer Welt am Abgrund gegeben. Hier scheint der Spieler* wirkungsmächtig (das Märchen von der Macht der Zerstörung in der eigenen nicht physischen bedrohten Existienz) oder es zeigt das sinnlose Aufbäumen als Antimärchen wie in Missile Command – US (siehe Artikel Beat Suter).

Todo:

• Suche nach einem Spiel, wo der Spieler* die die Durchsetzung vorantreibt

• Sinnsystem Shooter / Veränderungen seit 2010 etc.

Rechnen von Adressen ab und auf. Leben in Pointerwelten. Warum? Weil alles, nur Memory ist. Sei es Grafik, Sound oder Verwalten (Arrays), es geht mehrheitlich um das Rumrechnen, Suchen und Speichern an rumgerechneten Adressen.

Ein interessantes Kampffeld sind die Desktops der 16/32-Bit Computer. Das GUI mit Mouse (eingeführt von LISA und dem Macintosh) adaptierten die 16Bit Homecomputer und popularisierten (privatisierten) es. Der Homecomputer war nun für eine viel grössere Zielgruppe erreichbar. Interessant ist dabei auch die Gestaltung des GUIs.

Macintosh (Apple)

Konkreterweise müsste man hier auch noch die GUIS von Xerox daneben stellen.

Atari ST – GEM (Atari)

Der Atari ST kam als klassische Kopie der von Apple entwickelten Desktop Metapher. Allerdings nutze man hier die Wiese als (was mir bis heute nie aufgefallen ist) Settingmechanik. Auf dieser knutschgrünen Wiese fliegt dann auch folgerichtig eine Biene/Fliege (‚Busy bee‘) beim Warten. Das Grünn war so hell, dass es eher störte als half.

Amiga (Commodore)
Der Amiga kam ebenfalls mit einer grafischen Oberfläche und Maus. Dabei war die Oberfläche – anders als die meisten davor und danach (vielleicht mit Ausnahme des BEOS) farbig. Commodore bewarb dies auch. Diskurs technisch zeigt hier ein Hersteller, dass er auch in der Lage ist die Oberfläche farbig zu machen. Was an und für sich nicht unbedingt ein Riesending ist. Warum also? Wollte man zeigen, dass dies der Multimedia-Computer ex Console ist?

Leider wirkt das Ganze in der Farbkodierung nicht besonders konsistent und hilft der Lesbarkeit auch nicht. Es ist vielmehr so, dass man des öftern nicht weiss, was die Farben sollen.

Der Cursor ist klar. Rot – Signalfarbe und ‚3D‘.

Der Hintergrund ist dunkel. Der Fensterinhalt sind aber auch Blau. Dadurch ist schwer erkennbar, was nun vor- und was dahinter liegt. Eigentlich das wichtigste bei der Idee von Fenstern im GUI. Aufgewiegen wird dies mit grossen und farbigen (gestaltbaren) Icons. Die Farbkodierung ist dann aber auch bei den Systemicons unbedacht. So ist etwa das gefährlichste Icon der Trashcan Orange, aber auch sehr viele andere Dinge sind Orange, etwa der Diskettenslider, die Weltkarte oder Printer.

Hier hätte ein bisschen weniger Spielerei, dafür durchdachtes Design gut getan.

Todo:
– Recherche warum Atari auf die Idee kam, Grün zu verwenden
– Recherche warum Commodore ihren farbigen Desktop ins Spiel brachte.

Die Heim-Spielsituation Ende der 70er/80er Jahre ist fast nicht vergleichbar mit der heutigen. Wie in der gesamten Entwicklung der 8/16Bit Homecomputer/Consolen wurde existierende Hardware temporär umgenutzt. Angefangen vom durchschnittlich kleinen Fernseher bis hin zum Kassettengerät (Speichern/Laden) und nicht zu vergessen, die angeschlossene Stereoanlage – bei einigen kam die anschliessbare elektronische Schreibmaschine dazu. Insofern hat sich die Heimcomputerhardware (im Gegensatz zur Bürocomputersituation) eingefügt in die existierenden Möglichkeiten eines ‚Zuhauses‘.

ZX81-Box: Rot Lieferumfang, blau andersweitig beschaffbare Hardware (Umnutzung)
(Todo: Ersetzen eigenes Bild)

Anders war das auch nicht bezahlbar zu Hause und erklärt auch die teilweise horrenden teuren Komplettsysteme im Büro (Lisa und Mac müssen deswegen auch als eigentlicher Bürocomputer angesehen werden.). Eine Nische also, die die Homecomputersysteme schlossen und deswegen konsequent mit TV-Tunern oder später Video/Scart-Anschlüssen daherkamen.

Nutzungssituation / Spielsituation

Dabei aber (diese Doppelnutzung existiert bei den Konsolen bis heute) sich auch ein Problem eingehandelt: man kann nur je eines nutzen. Was anfangs (siehe Vortrag I. ) nicht weiter schlimm war, weil es nur einen mehrstündigen Block an Fernsehen gab in Europa meist Abends. Gerade auch darum wurden Telespiele gekauft und ausprobiert, um das Ameisenrennen mit anderem Content zu füllen. Es ist vermutlich auch kein Zufall, dass vorallem abstrakte Sportspiele (Pong, Eishockey, Basketball, Fussball) als erstes verkauft wurden. Ermöglichen diese „E-Sport“-Games ja das spielen des Inhalts auch des Medium Fernsehens. [Aus der Schweiz existieren damals soweit bekannt keine Sportspiele.]

Allerdings war diese Doppelnutzung natürlich nicht lange haltbar und war damit eine Übergangslösung. Schnell griffen die Leute auf spezialisierte Hardware zurück etwa spezielle Monitore von den jeweiligen Herstellern (nur so klappte es sicher) bzw. auf die Datasette und Diskettenlaufwerke. Dies auch alles, weil immer öfter der Computer auch für konkrete Anwendungen benutzt wurden (Textverarbeitung) und die Nutzungszeit da überlappten.

Anwendung und Nutzungssituation

Zudem funktioniert das Nutzen des Fernsehers allein fürs Spielen einigermassen gut, für einen Text schreiben etwa am Boden oder auf einem Tischchen nur sehr schlecht. Ein weiteres Problem kam hinzu, dass der Fernseher im Wohnraum stand. Darum bestand durchaus ein familiäres Interesse den Computer mitsamt allem irgendwo anders hinzubringen. Es entstanden die klassischen Computernischen auch in Zimmern von Jugendlichen oder dann der Raum fürs die Büroarbeiten wurde umgenutzt. Die Einführung von GUI und Maus beendete letztlich die Nutzung im Wohnzimmer endgültig und liess die Maus-losen Konsolen dort zurück. (Die neu enstandenen Computer-Nischen waren oft geradezu eine Orgie des (digital/elektronischen) Multimedialen.)

Kleine Screens und die Folgen

Die Kleinheit des Bildschirm nötigte die Spieler* relativ nahe an den Bildschirm heranzusitzen – gerade bei Texten oder Spielen (vgl Auflösung Teletext zu 16Bit Computerauflösungen von 300×200 Pixeln). Die Röhrenmonitore (CRT) taten ihr übriges, dass das Bild verschwommen bis sehr verschwommen war (das Alter der Röhren wirkt sich nicht besonders gut auf die Schärfe des Bildes aus). Ein Umstand den clevere Designer* natürlich einbezogen (verschmierte Farben beim C64 etc). Die Grösse der Monitore und die Auflösung waren aber insofern aufeinander abgestimmt, als dass spätestens mit dem Atari ST/Amiga nicht mehr wirklich ‚Pixel‘ zu sehen waren. Die Hardwarehersteller normierten das Ganze dann noch zusätzlich mit Normmonitoren für ihre Geräte.

Besser aufgestellt waren allerdings die Arcadekästen. Sie sind ja eigentlich spezialisierte Spielhardware mit Computer, Input und Output. Auch die Lichtsituation wurde hier per Arcadekasten designed (siehe dazu etwa alle die PeriskopSpiele). Dabei gibt es zwei System: Tischchen (nahe sitzen) und die Cabinets (kleine Screens inszeniert auf Kopfstehhöhe).

Folgendes interessantes – sicher gestelltes – Bild lässt auch weitere Diskussionen zur Frage der Spielsituationen aufkommen.

Computernutzungsituationen / Computerspielsituationen

Dies sollte auch weiter erforscht werden: Was gab es für typische Situationen. Wie lassen sich diese charakterisieren. Bis jetzt lassen sich folgende Typen feststellen:

– Bürosituation
– Bürospielsituation (vorallem wichtig bei LAN Parties)
– Büro: Laptops (transportierbare Computer vgl Macintosh mit Griff)- Privat: Wohnzimmer – Fernseher / Console / Computer
– Privat: Computernische (etwa im Schlafzimmer)
– Privat: Computerzimmer / Büronische oder -zimmer
– Arcades (diverse Arcadesituationen)

Todos:
– Konkretes Vermessen der Fernseher/Bildschirme über die Zeit – Daten der 80er Jahre.
– Bestimmen der Pixelgrösse Ende der 70er/80er Jahre > Text zur Erfindung des Pixels (als Fortschrittsseinheit)
– Diskussion mit M. der Themen
– Untersuchung durch Interviews und Umfragen bzw. Wiederspiegelung in den Medien
– Warum gibt es keine Sportspiele aus der Schweiz? (Emanzipation des Mediums?)

Publisher* und Marketinger* sind des Öftern gehasst von (Game)Designern. Die Sache ist klar: Publisher machen aus einem Spiel etwa ein Produkt. Und Marketing bewirbt dieses – vielleicht dann andere – Produkt. Und diese beiden Sachen sind dann nicht mehr unbedingt das Produkt, das der Designer* im Kopf hatte. Dazu kam in der Vergangenheit, dass viele Entwickler* & Designer* ausgenommen wurden. Un dabei muss man nicht mal die ganz üblen Fälle anschauen wie etwa bei Adventure (Atari 2600).

Der Grundkonflikt könnte aber neben diesen Eingriffen in die ‚Designfreiheit‘ und Ausbeutung aber auch darin liegen, dass die Designer* sich als Gestalter von Allem sehen, alles kontrollieren wollen und auch das Gefühl haben, sie könnten auch diese Gestaltung besser als die Leute vom Marketing.

// Interessant hierbei vielleicht auch die Stellung des Virendesigns, weil hier alles in einem passiert. vgl SCA etc.

BallRaider macht im ersten Moment nicht gerade viel her. Siehe https://spielkult.hypotheses.org/2977. So sind sich die Reviews relativ einig, dass dies nicht der grosse Wurf ist.

Dennoch enthält BallRaider beim genauren Hinsehen einiges an interessanten Neuerungen und auch das eine andere Feature regt zu Nachfragen an. Die meisten Neuerungen heben sich von der existierenden Kultur der Breakout eher Arkanoid Varianten ab.

Tilebasierung und freier Background als Innovation

Breakout und Arkanoid sind bekanntlich als Erstes eine Singleplayer Variante von Pong (Und kommen, zumindest die ersten aus der Küche von Atari – Breakout wurde zusätzlich von Steve und Steve umgesetzt). Der eine intelligente menschliche Gegner wurde durch viele sehr banale Gegner (NPCs) ersetzt (wie die Evolution vom Multiplayer Spacewar zum SinglePlayer Space Invaders). Klassische Spiele gegen den Computer entstanden. Und damit auch eine eigene spezifische Nerdkultur.

Breakout und Arkanoid sind zwei typisch tilebasierte Spiele. Das erste mit einem Type von Stone/Paddeln, das zweit mit verschiedenen und vorallem Extras. Dabei nutzt die Hardware das wenig vorhanden RAM mit Tilestrukturen aus für Hintergrund und Vordergrund – Spielfeld. Es entstehen Grafiken und Gestaltungsmöglichkeiten, die das abzuräumende Spielfeld zur Grafik machen etwa mit Arkanoid (Teilbasierte Grafiken oder Blockgrafiken, die im Spiel langsam zersetzt werden). Hier ist auch der vermutlich erste Space-Invaders-Intertext/Quote zu finden.

Rasterloser Background

Was tut nun aber BallRaider? BallRaider behält zwar die Art – wie die Steine angeordnet sind bei – verändert jedoch leicht (gridbasiertes 2 diemensionales Level), lockert sie wie Arkanoid auf aber führt anders als alle anderen (Vermutlich macht das viele RAM möglich) rasterlosen Backround alias ein Bild ein. Dies verändert die Art und Weise wie man es spielt. Es gibt nun zwei Arten von Grafiken. Im Vordergrund Raster und im Hintergrund freie Bilder, was zu ganz anderen kognitiven Herausforderungen führt. Selbst Kristall Hammer nutzt noch wie die meisten später auch im Hintergrund Tilebasierung. Teilbasierte Welten in Teilbasierten Welten. Wobei seltsamerweise fast keine verschiedenartige Typen von Steinen vorkommen. (Vgl auch Breakout)

Extras

Ein Alleinstellungsmerkmal – neben den Grafiken und Enemies – von Arkanoid waren die Extras. Diese finden sich auch hier, wenn gleich nicht per Typ arbiträr mit einem bestimmten Extra verknüpft. Dadurch wirken die Extras allgemein und müssen soweit erkenntlich auch nicht aufgefangen werden, was in Arkanoid zu einer weiteren Konkurrenzmechanik führt, die immer mit der Hauptmechanik ‚Zurückspielen des Balles‘ kollidiert.

Erzählung

Durch die Hintergrundbilder wird eine Story erzählt oder zumindest ein frühes zufälliges Enviromental Story Telling (was erst viel später benutzt wird) und einem Story Gesamtrahmen. Es geht darum – wenn man sich alle Bilder schon zurechtlegt um die Story von einem Angriff auf die Erde, den Flug in All, dem Kampf beim ‚Jupiter‘? Der Zerstörung dann die weitere Flucht, dann ein weiterer Kampf und schliesslich der endlose Endkampf. Siehe Analyse.

Graphikstil & ein diverses Game?

Der Grafik vom Spiel sprengt die Grenzen der 8bit Grafiken und arbeitet mit allen Möglichkeiten der 16 Bit Computer (Ganze BitmapBilder, das hätte niemals in einen 8bit Computer gepasst oder wenn dann nur sehr reduziert). Diese Befreiung ermöglicht erst die Möglichkeiten der Grafiken. Diese nutzen wenige „Farben“ aber viele Farbschattierungen. Gerade die Körper sind ausserordentlich eigen gehalten und erinneren an die Kultur der 80er Jahre mit ihren Körperdarstellung (angelehnt an Popgruppen, Bodybilderkultur , sind aber dennoch manuelle Digitalisierung und damit ein eigener Stil. Fast schon im Bereich Grafiti (siehe B. Untersuchung).

Betrachtet man die Bilder konkret so findet man heraus, das sie sehr Männlichkeitskörper betont arbeiten. Es kommt lediglich 1 Bild mit einer Frau vor – soweit ersichtlich.

Schaut man sich die Bilder länger an, kann man durchaus erkennen, dass es nicht nur eine Männlichkeitsbetonung sein könnte, sondern auch mehr. So wird in einigen Bildern massiv (auch mit Helligkeit) auf den Po fokusiert. Dies muss nun nicht zwingend ein „Diverses“ Spiel sein, aber dennoch kann es die Ambiguität der 80er Jahre durchaus spielen. Auch hier gilt es zumindest herauszufinden, was Design ist und was Teil der 80er Jahre Kultur war, in die auch eine neue Diversität einfloss. Erste Diskussionen haben hier schon stattgefunden. Die Bilder sind recht interessant und das bei fast allen Bildern mal mit Ausnahme des nicht-Space Fantasy Bildes.

Demoscene: Loading Screen

Der Loadingscreen ist direkt – so scheint es – an die Demoscene angelehnt und zeigt während des Ladens eine vielfarbiges Rasterbild, das eine deutliche Demo sowohl der Entwickler wie auch des Amigas. Der Amiga konnte nicht diese Anzahl von Farben gleichzeitig darstellen und über den Rand hinaus dargestellt werden. Zeigt aber auch, dass Rastergrafiken möglich waren während des Ladens.
Auch hier muss weiter nachgesehen und erfragt werden, was sonst noch im Spiel steckt, was heute nicht mehr nachvollziehbar ist in Sachen auch technische Innovation.

Sound/Effekte

Die Soundeffekte sind auf der Höhe der Zeit – wenn auch nicht gerade ausgeprägt und verwenden aber doch die Möglichkeit der Hardware. Das ist ein deutlicher Sprung zu früherer Hardware und zeigt wohin die Entwicklung ging. Vergleiche dazu auch Cristall Hammer. Das Ende der Wave-Sound-Generierung ist da. Nachfrage: Andere Art die Sound zu erstellen? Music via Tracker? Und wenn welcher Tracker.

Interaktion

Seltsam ist die Interaktion per Joystick. Diese ist zwar für 8Bit Standard, weil es nichts gab auf den 8Bit Spielconsolen als Kontroller (Gab es ein Paddle optional für den Amiga?) im Gegensatz zu den Atari 2600 Konsolen. Die Frage darum: Warum? Oder war dies einfach das schnellste?

Todo

– Konkrete Untersuchung der Story oder zumindest der Erzählwelt (Schon begonnen)
– Noch konkretere Untersuchung des Titelbildes: Warum der blaue auftauchende Stern? Der Gegner – korrespondierend zum Roten/Baluen Stern. Warum die Bildkomposition? Warum das Schwert? Schwert und die Zeit? etc. Welches Eniviromental Storytelling? Vorbilder?
– Konkreter Intertext zu anderen Games? Welche Games mit nackter Haut waren der Bezug/Intertext? Wie war das Verhältnis zu Barbarian I/II? Wie sahen sie sich als the Next Generation von Gamedevs?
– Wo kamen die Ideen her? Arcades? Und wenn welche Arcades?
– Klärung zwischen designten Intentionen und realer Wirkung (Wirkungsgeschichte) > H.
– Abklärung Amgibuität im Design des Spiels. Eines der ersten diversen oder zumindest absichtlich amgiguen gehaltenen Games?

Es ward Licht bzw. Kathodenstrahl. Und der Kathodenstrahl malte ins Schwarz. Ein Grund, warum frühes visuelles Design gerade für Computer und Computergames eigentlich immer auch sehr viel mit Glasmalerei zu tun hat – einfach invers. Das sieht man noch heute deutlich an den radikalsten Kathoden-Bildmalern den Vektorscreens in Arcades oder der Vectrex. Wo die Helligkeit eines CRT (Röhrenbildschirms) auf einen Punkt konzentriert sein kann. Zu sehen im Orginalarcade von Asteroids im Schuss.

CRTs als ein Schritt verteilt sein Licht über den ganzen Screen, Zeile für Zeile. Es bleibt aber weiterhin ein Malen ins Schwarz bei einer Refreshrate von 50/60Hz. Die Folgen sind klar: Die meisten Computer malten weiss auf Schwarz oder einer anderen dunklen Farbe. Die Gesamthelligkeit ist so niedrig, dass das Arbeiten oder Spielen eigentlich nur an nicht sehr hellen Innenräumen möglich war. Die Spielsituation ist deswegen auch meist eher dunkel als hell, besonders gut bis heute sichtbar in Arcades, die nicht nur wegen der Athmosphäre dunkel waren, sondern auch rein praktisch. Dies löst auch ein weiteres Problem, das Spiegelproblem vom CRTs etwa durch Fenster. Hier wird auch die Idee des Kinos aufgenommen, dass man in dunklen Räumen schon bei 25 Bildern/Sekunde eine Bewegung erkennt als flüssige Animation.

Konsequenterweise kommen in der Homecomputerzeit fast keine Computer auf den Markt, die Weiss als Defaulthintergrund haben. Die meisten 8bitter rendern auf etwas Dunkles, allein der ZX81 fällt aus dem Rahmen. Das Problem dann aber auch hier, angenehm Arbeiten ist etwas anderes.

Für die Spiele bedeutet es aber dann auch, dass Schwarz oder zumindest Dunkel, der Standardhintergrund wird. Un dies ganz im Gegensatz natürlich zu anderen Medien wie Papier! Das perfekte Schwarz ist geradezu eine technische Meisterleistung im Analogen/’Realen‘. Anders gesagt, das Medium positioniert sich schon von Anfang an anders. Vielleicht sogar als the Darkside, das Dreckige. Wie es die verrauchten Spielhallen als dunkle Höhlen schon früh nutzen. Hier wird das Schwarz der Bildschirme auch endlos dann im Raum fortgesetzt. Und viele Spielsituationen an Konsolen und Computern sind in den frühen Jahren ähnlich. Das Muster setzt sich sogar heute fort an LAN-Parties oder ESport-Events. Hier mischt sich wieder die Freizeitinszenierung mit einer ‚Tradition‘.

Fürs Design wichtig ist das Schwarze vorallem am Anfang etwa in den 8BitKonsolen, als der Hintergrund vor dem das neue Entsteht. Das Entstehen der Welt im Nichts des Schwarzen. Da hilft es natürlich auch, dass viele Spiele dunkle Settings nutzen konnten und sich so gegenseitig entwickeln. Von Breakout bis PacMan.

Todos:
– Suche von Spielen mit grosser Helligkeit im Design (als Konstrast)
– Überlegungen zur Farbgestaltung von Konsolen und Computern, die ja meist Grau waren (Verfügbarkeit, Grau als Statement gegen das Schwarz – grau als Zeitlos und selten Farben vgl. Alice, Indigo … iMac viel später mit der Einführung der Mode )
– Diskussion mit L. zum Thema Schwarz und Gestaltung
…

(Dieser Ausschnitt wurde in KickAssembler geschrieben. Es ist ein Assembler, der moderne Features mitbringt, die man aus höheren Programmiersprachen kennt wie etwa Kommentierung und das nutzen von Scripting im SourceCode).

Assembler bringt die totale Kontrolle in Ablauf, Speed, Zugriff. Diese totale Kontrolle führt auch zur Idee von „Totale Macht über“, etwas was noch weiterlebt in der Demoscene. Gleichzeitig ist dieser Vorteil aber auch der totale Nachteil. Wirklich alles ist maximal (sieht man mal von Brainfuck und anderen esoterischen Sprachen ab) komplex. Selbst triviale Management-Dinge wie etwa verschachtelte For-Schleifen, die schon bald zu einer Kontrollorgie werden. Es lauern überall die Möglichkeit die eigenen Werte in Registern oder im Speicher zu überschreiben etc.

Die manuelle Digitalisierung (siehe andere Blogeinträge) ist ein wichtiger Zwischenschritt gewesen und ist es weiterhin in der Digitalisierung. Es meint den Prozess, dass die Welt manuell in den Computer kommt. Es ist die Handarbeit, die jeder und jede vollführte um Dinge im neuen Medium Computer zu erschaffen.

Ein einfaches konkretes Beispiel aus einem OralHistory-‚Interview‘. Der Industriedesigner erklärt, dass sie anfangs Kreise nur aus vielen Punkten konstruieren musste. Es hätte keine Kreisfunktion gegeben. Anders gesagt, die Unterteilung musste manuell von Menschen erstellt werden. Dabei spielte der Mensch die Rolle den Kreis zu ‚digitalisieren‘. Und das bei etwas wie Kreisen, die fast kein grösseres mathematisches Konstrukt sein können.

Ein Gamedev* im technischen Bereich muss die Grundlagentechnik beherrschen (Basic Layer). Wird ein neues System angegangen geht es darum, grundlegendste Fähigkeiten zu erarbeiten. Praxis des Vorgehens etwa bei der Einarbeitung in ein unbekanntes System wie den C64 erfolgt oft wie folgt:

Coding-Layer:

Wie kann ich überhaupt auf einer Platform coden? Welche Sprachen sind möglich und sind akzeptabel für das Produkt/Game bzw. für die Entwickler.

Output-Layer: Displays – Gebräuchlichste Graphik & Sound

• Grafik: Darstellung von Objekten meist Grafiken später auch 3DModelle
  Die konkreten Fragen: Graphikmodelle, Abbildung RAM, Punkte Zeichnen. Auf diesem kann alles weiter aufgebaut werden. Grundlagentechniken.
• Grafik: Technische Machbarkeit von statischen Gameobjekten(Hintergrund) und Sich-bewegendem (Anfangs Sprites)
  Konkretes einbetten von extern erstellten Grafiken. Wie lädt man diese? Wie stellt man sie dar? Nächste Stufe: Wie kann man bewegende Objekte alias Avatar und NPCs darstellen und handeln.
• Sound: Wie kann Sound generiert werden als Grundlage? Wie funktionieren Soundeffekte, wie kann Music implementiert werden.

Input-Layer: Interaktivität – Gebräuchlichste Tastatur, Joystick, Maus

• Wie funktioneren diese technisch? Wie lassen sie sich einbinden?

Mangement-Layer: Management des Spiels

Spiele verfügen über Anforderungen, die sich zumindest in der Frühzeit der Computerspiel mehrheitlich bei den Spielen finden (Sie sind keine reinen Input-Output-Programme vgl hierzu auch Brainfuck vs Brainfuckconsole74).

Nebenläufigkeit/Scheinbare Gleichzeitigkeit

Nebenläufige Tasks: Games benötigen meist einen Loop (nur so sehen Ingamelebenswelten auch so aus, als würden sie ‚leben‘), der wiederholend auf Interaktivität ‚wartet‘ und gleichzeitig das Spiel prozessiert.

Objekt-Datenmanagement

Aufbauend darauf stellt sich die Frage, wie prozessiert man die alle die Einzelaktivitäten des Spiels wie Output/Input/Daten-Management. Das kann man eher die Datenverarbeitungskomponente des Spiels nennen und ähnelt in der Mehrheit der Fälle einem Excel-Sheet mit Gameobjekten.

Historische Entwicklung – Verlorene Spielmechaniken

Der dargestellte Prozess bezieht sich vor allem auf die frühe Gameentwicklung, wo die Gamedevs eigentlich die ganze Grundlage auf Basis der jeweiligen Hardware entwickelt haben. Damit haben sie selbst eigene Gameengines erstellt, in denen dann jeweils ein Spiel programmiert wurde – öfters Hardverdrahtet genau für dieses Spiel. Erst später (noch konkret zu erforschen) kommen vermehrt GameEngines auf, die Entwicklung heben und zu einer Art Betriebssystem (Jahrmann) werden für die Spielentwicklung. Dabei gehen interessanterweise Dinge auch wiederum verloren. So arbeiten heutige Engines fast alle mit Objekten (Objektorientierter Ansatz) und zwar auch im Display. Dadurch ist es heute viel schwieder Tile basierte Spiele oder gar Pixelbasierte Spiele zu entwickeln.

Komplexität – Konstanter Mainstream

Interessant is auch, dass die Spiele in ihrem Management oder dem ‚was-gehandelt‘ wird gar nicht soviel komplexer geworden sind. Meist sind es 1-6 Objekte die sich bewegen: Avatar und ein paar Gegner. Selbstverständlich gibt es seit den BulletHell-Shootern und Strategiespielen auch den Trend zu massig vielen, der gerade auch aktuell ein Trend ist.Aber im Grossen und Ganzen sind die 8 Sprites etwa des C64 immer noch das, was Spieler handeln können. Wobei das Handling in 3D Spielwelten eher weniger als 8 aktive handelbare Gameobjekte umfasst. Es scheint, als seien mehr zu kontrollierende Objekte nicht handelbar oder einfach zu stressig.