Ein Plotter ist ja beim Zeichnen wenig interaktiv. Wenn er mal fährt ist er unterwegs. Das heisst man muss als Designer* auf kleine Bewegungen setzen wie bei PotShot oder dann auch bei Tennis4Plot. Die andere Sache ist es, das ganze zu takten, also eine Art TilebasierteBewegung zu verwenden wie etwa in „Tron“Plot oder Mines. Hier korreliert die Bewegung mit den Tiles.
Bei Potshot könnte man die Zeit von A nach B aber auch nutzen, um den Pen Hoch und runter zu fahren, um eine Strichelinie (also analoger, weil der Stift immer weniger drückt bis er in der Luft ist und umgekehrt) zu generieren ohne die Probleme des Stottern bzw. Stop And Go.
Viele Plotter wurden ja oft gebraucht für Graphen, insofern materialisieren sie geradezu Graphen in der Zeit oder in X. Das einzige bekannte Plotterspiele PotShot tut genau dies.
Es ist interessant, das Spiel wieder zu spielen in seiner ‚Urfassung‘. Also in der Fassung bevor es zu einem Zerstörungsspiel von Hintergrund wurde mit einer ganz anderen Programmierung (Konkretes Zerstören von Arrayinhalten). Hier geht es um simple Formeln und Parametern. Das ist der Elearning-Teil des Spiels. Es ist ein Spiel (siehe Interview Luehrmann), das die Realität von Ballistischen Waffen ins Spiel bringt. Dabei ist es nicht wie Tennis4Two ein verkapptes Atomwaffenabwehrsystem oder verwendete Technik davon, sondern ältere Technik. Wenn auch das Orginal im Weltall spielt und dann wieder sehr viel mit Atomwaffen zu tun hat.
Die einfache Version von Potshot lebt geradezu manisch von Parametern. Es dynamisiert damit ganze Weltbilder, die davor eher Imagination oder Handarbeit waren (beim Graphenzeichnen). Hier könnte man tatsächlich berechnen, wie die Parameter sind! Also das Eingeben und Anwenden. Es gibt allerdings auch die Methode Try&Error. Die Eingabe und dann die Simulation, was im System passiert. Statt Zahlenreihen oder einem ‚Getroffen‘ oder ‚Nichtgetroffen‘ gibt es eine Spannung, etwas, was man Voraussieht und erwartet. Wobei man schon nach einigen Sekunden weiss, das wird was oder nicht. Aber man weiss der nächste Shot kommt bestimmt. Und dann ist da eben noch der Gegner* der zurückschiesst mit denselben Chancen. Die Entscheidung „hmm gehe ich noch ein Grad hoch oder nur ein Halbes?“ „Kann ich einen ähnlichen Winkel nehmen, wie meine Gegner?“
Im Orginalspiel gibt es noch den Wind. Und selbstverständlich verändert dies die Mechanik nochmals zusätzlich, indem es Unterschiede rein bringt und es schwieriger macht.
Plotshot schaut einfacher aus, als es ist. Das hängt vorallem an der Schussimulation oder anders gesagt der Physik-Visuellen-Darstellung. Dazu kommt, dass das Spiel recht optimiert werden muss, damit es schnell funktiert. A) Zeichnen der Pots direkt in einem Aufguss. (Unterschied wie es scheint zum Orginal) B) Die direkte Eingabe der Parameter im normalen PlotterScreen. C) Die langen Laufwege des Stifts. Darum: Eingabe der Werte nicht oben, sondern in der Nähe des Pots. Dann die Laufwege – nicht zurück zu Spieler 1, sondern gleich bei Spieler 2 beginnen. Dadurch spart man Zeit. D) Das Gameplay ist zudem gut für einen Plotter. Der Spieler spielt immer in Richtung Gegner*.
Es sollte versucht werden mit etwa dem Fumetto oder dem Museum für Narrative Kunst (Comic, Basel) ins Gespräch zu kommen. Gab es da früher schon solche Experimente? Wie geht man heute damit um.
Es ist eigentlich eine einfache Tatsache, hinlänglich bekannt. Das Digitale hat keine Spuren im Analogen. Das wird einem sofort klar, wenn man etwas mit einem DigitalenComputer und einem analogen Endgerät wie einem Plotter entwickelt. Hier gibt es immer einen Output, gibt es immer Abfall, Artefakte. Und ja diese müssen entsorgt werden, etwa verbrannt. Das ist anders als beim Digitalen, kein Abfall, kein sich erinneren, kein genutzter Platz. Es existiert nicht, wenn es nicht angeschaltet ist. Es ist vergessen (darum erinneren uns digitale Dinge auch immer an ihrer Existenz!) Das Digitale ist nicht analog manifest!
In den ersten Digitalisierungsphasen mit Disketten gab es zumindest noch die Lochkarten, Ausdrucke oder später die Kasetten, Disketten, die Raum einnahmen, die Getauscht wurden.
Clearscreen ist eine der wichtigsten Funktionen in Computergames. Sie ist wichtig, damit wieder ganz von neu angefangen werden kann. In der Demoscene auch wichtig, weil es oft darum geht, wie schnell kann man den Screen löschen oder indirekt gesagt: Wie schnell kann man ihn ganzflächig ‚überschreiben‘. Denn Clearscreen ist ja eigentlich nur ein Überschreiben des Screens mit einem Wert im Videomemory (sofern das System ein Videomemory hat).
Digitalität zeigt sich in diesem Sinn gerade darin, wie ClearScreen als Funktion funktioniert. Es zeigt sich an der Kontrolle über den Screen.
Papierne Zeichen(zeilen)displays: Teletype/Teleprinter – der Screen?
Beim Zeichendisplay der TelePrinter/TeleTypes gab es nicht direkt ein Clearscreen. Der Screen war ja zuerst eine Zeile und danach vielleicht das Blatt. Wobei das Papier nicht in Blättern organisiert war sondern endlos. In diesem Sinn ist hier die Frage: Was ist der „Screen“?
Wie gross der ‚angedachte‘ ZeilenscreenScreen war sieht man vielleicht noch heute an den BASIC101-Games oder den Shellprogrammen – wie weit Drucken sie Leerschläge bis sie beginnen mit dem Content. Mit dem Aufkommen der klassischen Drucker gab es natürlich dann auch hier das Blatt. Allerdings war der Drucker zu diesem Moment keine „println“ – Ein-/Ausgabemaschine mehr sondern halt analoger Output. Man sieht dann auch nicht mehr – anders als bei der Schreibmaschine – was man gerade drückt oder druckt.
Plotterdisplays: Endlos oder Flachbrett (A3,A4)
Bei den Plottern ist die ganze Sache komplizierter. Hier gibt es die Endlosplotter und die Flachbrettplotter. Beim ersten verhält sich das ganze wie beim TelePrinter/TeleType. Beim zweiten allerdings ist die Sache des Bildschirm’putzens‘ dann völlig manuelle Arbeit.
Hier der Vorgang des Clearscreenen.
Dabei ist klar. Hier gibt es auch Abfall, also eine Dokumentation. Diese Dokumentation fehlt bei digitalen Outputgeräten völlig. Maximal lassen sich noch eingebrannte Bildschirme als Artfefakte betrachten.
Erste Screens: Zeichnen und es bleibt stehen (Simulation des Analogen?)
Zur holistischen Analyse eines Games gehört auch die Programmierung und im besten Fall die Erfahrung der eigenen Programmierung.
Warum sollte neben dem interaktiven Display auch die Endkonstruktion des Games analysiert werden?
Bei der Analyse der technischen Realisierung aber noch viel mehr bei der konkreten Programmierung wird es möglich:
Games sind wie fast alle digitalen Medien gut darin den Nutzer*/Gamer* zu täuschen. Es gibt also meist einen tiefen Gap zwischen einer User*-Perspektive und einem Game (Programmierte Spielmechanik vs Gameplay) Dabei ist auch klar: Am Ende zählt die Perspektive des Users und deren Kultur.
Die maximale Interaktivität/Möglichkeitsraum/ wird erst in der techn. Analyse sichtbar. Anders als beim Text oder einem Film liegt der SourceCode für die menschliche Interaktion nicht sichtbar da. (Was allerdings nicht unbedingt die Meta-Konstruiertheit aufzeigt.
Technische Analysen können auch Versionen des Spiels und nicht genutzte Features aufzeigen (Diassembling oder sofern man Einblick hat etwa auf den SourceCode)
Die Komplexität eines Spiels zu verstehen, die drückt sich nämlich auch im Code aus. Das betrifft die Micro- wie die Macroebene.
Die Komplexität eines Spiels ist auch ein Aufwand. Dabei entstehen viele Effekte von Spielen als technische Lösungen von technischen Problemen. Hier gibt es teilweise eine grosse Varianz an Lösungen, die zur selben Spielmechanik/Gameplay führen.
In der Gameentwicklung ist die Parameterisierung wichtig. Was funktioniert wie, warum? Was ist die Schrittlänge. Dieses ‚Balancing‘ zeigt aber auch auf, wie das Spiel in seiner Mechanik funktioniert. Auf was es ankommt. Diese Dinge sind schwer ohne Experimente im Code sichtbar. Sind sie doch meist systemisch, das heisst änder man etwas, verändert sich alles.
Spiele/Spielmechaniken als Systeme verändern sich mit jedem Eingriff. Das heisst auch anders gesagt, erst im Rumspielen mit dem Spiel oder dem eigenen Prototypen werden Dinge sichtbar (erklärbar ist dann eine ganz andere Sache)
Durch die Programmierung eines Systems in der damaligen Hardware werden auch gewisse Konstrukte klarer: Was bedeutet es, keine Floats zu haben (wie bei 8/16Bit)? Wie ist das Verhältnis zur Hardware? Etwa in 3D-Spielen?
Wie lässt sich die Spielemechanik als Programmiertes Spiel umsetzen, welche Lösungen kamen zum Einsatz und welche Lösungen wählt man. All das ist letztlich das Framework unter dem Spiele entstehen.
Wie fakt man als Entwickler* Dinge? All das ist nur sichtbar in der Konstruktion von Spielen.
