Extreme Programming ist eine Methode der agilen Entwicklung. Zwei Leute sitzen da und entwickeln gemeinsam.
Nach einem Gespräch mit Philip Jesperson (Entwickler von Supaplex) und auch zu sehen im „Capt der digitalen Hoffnung“ (SRF 1987) ist wieder klarer geworden: Extreme Programming, Developing und GameDesign war in der Gründerzeit der digitalen Revolution (Homecomputer) in Sachen Games vermutlich Teil des Alltags. Die Gründe sind dafür vielfältig aber auch klar: Computer waren rar. Also hatte nicht jeder einen, den richtigen (etwa einen Amiga) und schon gar nicht zwei. Notebooks waren sündhaft teuer.
Entwickeln war also oft nur zusammen möglich. Und so trafen sich die Entwickler* dann auch bei sich zu Hause oder im ComputerClub oder eben auch an Parties, die quasi viele Funktionen eben auch die soziale Komponenten per se mitbrachten. Dabei lernten die Personen – im Diskutieren von Code und „Wie machst du das“ – auch über diese persönlichen Kontakte, das gemeinsame Entwickeln. Dabei war vermutlich – so zumindest die Beispiele – die konkrete Nähe geografisch wichtig.
Dabei ist der Unterschied zwischen Cracking, Demoscene und GameDesign nicht riesig – den wie „man es“ technisch fertig brachte, waren ähnliche Challenges.
Demos sind letztlich – zumindest für 1980-1993 – spezialisierte Einzelanfertigungen. Sie sind mehrheitlich – so zumindest die Einsicht Einzelprogrammierungen, weil nur dadurch es möglich ist, das Maximum aus der Hardware herauszuholen oder anders gesagt: Es muss mehrheitlich Hardware nahe sein, um überhaupt mit Tricks das ganze Potential herauszuholen. Dadurch verschliesst sich eine gewisse Verallgemeinerung in Richtung komplexeren Frameworks.
Selbstverständlich ist dies im Crackerbereich nicht ganz so gelaufen, hier scheint es zumindest, dass so etwas wie Frameworks entstanden sind. Eine ähnliche Situation wie wir sie auch im Gamebereich dieser Zeit sehen bzw. etwas was noch genauer untersucht werden muss. Denn auch hier enstanden Frameworks für Games.
„Auf der Suche nach Metaphern für das, was man als Designer, Coder auf Farb-CRTs so tut ist vielleicht die Glasmalerei, die adäquatischste.“ Ein Unbekannter
Nachdem und während die analogen Displays (Lochkarten, Lineprinter, Plotter) für Mainframes langsam immer Ende entgegenprinteten, entstanden die Display auf Oszilloskopen, nachher bekannter als CRTs (Cathode Raster Tube).
Digitalisiert man den Plotter oder den Lineprinter? Vektorgrafiken oder Rastern, das war hier die grosse Frage. Dahinter aber liegt dieselbe Art Grafiken zu erstellen, nämlich sie mit Licht auf einen flureszierenden Screen zu ‚malen‘. Dieses Malen ist ein wirkliches Malen und auch noch sichtbar in den Vektorscreen, da der ganze Strahl des Lichts manchmal in einen Punkt fällt, etwa bei Asteroids in den Schluss, der (vermutlich) zum Schluss gezeichnet wird.
Dabei fällt der Lichtstrahl wie bei der Glasmalerei durch eine gerasterte Lochkarte (meist) und dann eine Scheibe auf die Netzhaut. Also ähnlich wie bei der Glasmalerei, sogar die Effekte von Glas wie Spiegelungen sind dabei zu finden, da das Glas gebogen war/ist. Dazu kommen Verschmiereffekte und Nachglühen. Dies sind vielleicht dann doch neue Eigenheiten dieses „Materials“.
CRTs (Cathode Raster Tube) – der klassische Fernseh- und Monitorscreen
Die Entscheidung viel dann aber mehrheitlich für die Rasterung aus, da es früh Farbe gab und die Menschheit schon immer die Abbildung des Realen und die Macht der Überschreibung des Analogen liebte. Kurz und gut: Monitore rasterten sehr schnell ihre Welt in den CRTs von oben links nach rechts unten. Welten mit eigenen Ästhetiken.
Damit endet jedoch nicht die Wichtigkeit des Rasterstrahls (der nun gebändigte Kathodenstrahls des Oszilloskopes). Die Kontrolle des Rasterstrahls war weiterhin das Omen, um überhaupt Spiele zu machen. Gerade im Homebereich, wo es billig sein musste und wo der Fernseher die erste Anlaufstelle war und die Games das Fenster rund um das 3h Fernsehprogramms füllen müssten.
Die Atari 2600-Konsole einst gebaut 1977 um Pong (Zur gleichen Zeit war Fairchild 1976 schon weiter) nach Hause zu bringen, war geradezu die Hölle für Programmierer* in Sachen Beam. Das Programm muss dem Beam folgen (immer testen), um dann zur richtigen Zeit = richtiger Ort die Sprites zu zeichnen. Mehr dazu findet sich hier >
Ein Horror für Entwickler* – da die Mechanik des Spiels in den Zwischenräume dieses Displays ‚gemacht‘ werden musste.
Abstrakte Spiele sind in Digitalen Spielen prinzipiell immer möglich. Seien sie abstrakt in ihrer Visualität oder auch in der Spielmechanik. Konkret sind allerdings die wenigsten Spiele im konkreten Sinn „abstrakt“. Meist haben sie ein Setting, das den Spieler in die Spielmechanik „hilft“ als eine Art Brille, die schon sehr viele Regeln mitgibt. De facto sind dann aber Spielmechaniken/Spielschematas (Jürgen Fritz) dann meist weit weg von Analogen Settings (und deren Regeln) und es erstaunt manchmal, wie wir als Spieler* diese Ungereimtheiten einfach akzeptieren. Der Magic Circle und vorallem unsere Abstraktionsmöglichkeiten (Kultur) richten es. Die Regelmaschine Mensch in Betrieb.
Settings und Abstraktion
Im Bereich der visuellen Abstraktion dagegen wollten die meisten Games aber sehr oft ins ‚analoge‘ hinaus. Vielleicht auch um mehr akzeptiert zu werden, vielleicht um so die Welt (Wille zur Macht) die Welt besser überschreiben zu können. Nichts scheint mächtiger als die analoge Welt.
Viele visuelle Abstraktionsleistungen in Computerspielen waren dann im Homecomputerbereich meist eher „Übergänge“ als selbst gewählte Stile. Sei es in der Abstraktion von ASCII-Grafik, später Vektorgrafiken, dann Polygongrafiken etc. Oder anders gesagt: Es wurde selten ‚obsolete‘ Technologie genutzt. Dabei ist gerade die Kunst der 60,70er und 80er Jahre voll von abstrakter Darstellung – falls es um Darstellung ging und nicht wie im Bereich der Computergrafik um die Kreation neuer Welten.
SizeCoding (vorallem am Anfang 8Bit) Zeigen, was möglich ist Challenge / Konkurrenz Community Community um einen Computer herum (Idenität) Kontrolle Freizeitbeschäftigung unter Kollegen Credits
SizeCoding SizeDesigning
SizeCoding (vorallem am Anfang 8Bit) SizeDesidning (bis heute) Identitätsstiftend und Challenge gegen andere Platformen (Bsp. Atari ST vs Amiga)
Produktinterne Motivation
Visuelle, technische Finesse, Tricks Challenge „Wie geht das?“, „Könnte ich das auch?“ Echtzeitberechnung
Visuals, Storytelling
Spielmechanik (Challenges) Interaktion Echt- und NIchtechtzeit
Genutze Techniken
Visuell, Auditiv
Interaktion, Taktil
Visuelle Effekte
Massiv
Kollisionen
Meist keine ausser vielleicht Physikdemo
Kollisionen extrem wichtig für die Spielmechanik
Darstellung wie gemacht
Flackereffekte, Aufbau
Meistens kein Metalayer eher verborgen, seltene Ausnamen
Letztlich verhinderte die fragmentierte Hardware und die vielen nötigen Tricks in Assembler, um Games zu machen etwa beim Amiga, dass diese Systeme eine längerfristige Chance hatten. Diese Spezialisierung wirkte sich vorallem auf Investionen/Aufwand in die Technik aus, statt in Spielmechanik. So sehen wir (noch genauer zu erforschen) fast keine Gameengines, die sich entwickelt haben.
Der getriebene und geleistete Aufwand lässt sich bis heute (noch genauer zu erforschen) nur damit erklären, dass da auch eine Generation am Werk war, die sich ihre Träume verwirklichte und dabei keine Grenzen kannte. Die das Ganze als Metaspiel verstand gegen jede Wahrscheinlichkeit. Sicher auch mit der Idee dahinter mal Geld zu verdienen, aber realistisch konnte das nicht funktionieren.
Die ersten Spiele waren grossmehrheitlich One-Screen-Games. Das bedeutet aus Sicht des Gamedesigns und auch in der Spielmechanik, alle Dinge sind sichtbar auf einen Blick. Selbstverständlich gibt es Möglichkeiten auch hier die Sicht einzugrenzen, Techniken wären etwa Fog of War oder noch nicht geöffnete Zimmer (die erst beim Eintreten gezeigt werden). Es bedeutet aber auch, das die Spiele oft die TopDown-Perspektive oder die Seitenperspektive verwenden. Die Objekte sind dabei relativ klein bzw. müssen klein sein, damit wenigstens etwas auf dem Screen passieren kann – auch wenn das Spiel auf verschiedene Screens verteilt ist. Die Spielmechanik des Suchens kommt in diesem Fall auch anders zum Einsatz, die Objekte müssen eher in Dingen versteckt sein wie Kisten als dann später in 3D Welten.
Scrolling-Games
Mit der Einführung des Scrolling ändert sich das. Der Spieler muss bei den einen Spielen im Bild der Kamera bleiben (etwa beim ersten Scrollenden Spiel) oder später in vielen ShootEmUps oder er steuert aktiv den Bildausschnitt oder moderner gesagt: Die Kamera ist über dem Spieler. Da erstaunt es dann auch nicht, dass Parallax-Scrolling genutzt wird, um die Welt auch ins 3D zu erweitern. Die Komplexität der Spielsituation rund um den Avatar bleibt meist die gleiche. Aber der Avatar rückt mehr ins Zentrum und wird nun oft grösser. Und das Suchen durch Scrolling von Gegenständen wird zu einer beliebten Spielmechanik.
// Einsatz von Flöte und Harfe und Funktion einmal untersuchen (vgl. 8Bit-Sound)
Es ist ein Moment, der eingepasst ist in den Iterationsprozess im Coding oder auch Gamedesign. Aus der These wie der Code funktionieren sollte wird ein Warten.
Beim Compillieren testet der Computer, ob alles zumindestesn formal korrekt ist. Der Entwickler* ist gespannt.
Einfach nicht das beim Compillieren:
Was ist falsch daran? Ein Hinweis vom Compiler. Aber gerade ist das nur die Idee, was sein könnte. Es geht weiter:
Ein erstes Entspannen folgt: „Ok es läuft“. Dann die zweite Anspannung: „Ok was läuft“. „Läuft das, was geplant war.“ Also die These von der Architektur, das was die Veränderung im Source-code nun im Resultat dem laufenden Programm, ist es das.
Dann das Warten beim Aufstarten und dann die Kontrolle, ist die These vom Konstrukt der Software korrekt, stimmt es mit dem laufenden Programm übereinander oder nicht?
Das ist ein Upchecken und ein oft sehr schnelles: „Ok, es läuft“ oder „Nein shit, es geht nicht. Warum nicht? Ist mein Gesamtkonzept falsch?“
