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.
• ….

Was ist der innerste Kern, das transzendentale Signifikat der Demoscene?

„Was ist eine Demo (in der Demoscene)? Extensional natürlich alle Demos, historisch ein Produkt von einer rein digitalen Community? Und intensional? Oder Kann eine Plotterdemo eine Demo sein. Die Community gibt eine Antwort.“ Es ist fast so, als hätte die Scene Angst dazu etwas zu schreiben, weil sie sonst nicht mehr existierte.

Diese Frage ist interessant, weil sie nicht wirklich diskutiert wird. Es ist eher einfach so, dass die Demoscene ist und lebt, sich entwickelt und vielleicht von 1000 verschiedenen Ideen getrieben wird. Vielleicht ist sie einfach eine Praxis. Vermutlich lässt sich rein individualistisch klären, warum Teilnehmer* der Demoscene dabei sind, aber nicht, was das Ziel ist. Das Ziel wird ja auch jedes Jahr neu verhandelt anhand des Wettbewerbs etwa.

Dennoch noch einmal die Frage, was, wenn die Demoscene ein System wäre, was ist ihre Motivationsmechanik? Was steckt hinter diesem anerkannten UNESCO-Tradition? Was ist Ihr Glaubenssatz? Wie kompliziert das Ganze ist findet sich etwa hier:

80erJahre Homecomputer als Idee/Grundlage der Demoscene

Weiterlesen →

Vielleicht geht es dem Mainstream der Demoscene echt nur um Quod erat demonstrandum! Oder eher: „Was zu beweisen war und von dem man noch nicht wusste“ oder „Was damit bewiesen wäre“ Zusatz: Dass das geht!

Wer Spiele für einen Computer macht etwa mit einem Atari ST und den Joystick verwendet, fühlt sich seltsam, wenn er dann da nur den Knopf verwendet. Völlig anders sieht es bei einer Tastatur aus. Hier ist es voll ok, ein Spiel nur mit der Space-Taste zu machen. Auf einer Maus nur die Maustaste zu drücken fürs Spielen erscheint dann irgendwo zwischendrin.

Beim Joystick etwa CompetitionPro fühlt sich ein OneButtonGame strange an, der Joystick hat aber viel mehr Möglichkeiten. Ja das hat die Tastatur auch – aber und da ist der Unterschied: Eine Tastatur wurde gar nicht fürs Gamen entwickelt. Sie kann viel mehr. Der Joystick dagegen ist nur fürs Gamen entwickelt worden, konkret fürs Arcade-Gamen (er löste die reinen Tastengames oder Potentiometersteuerungen ab). Und hier geht es oft in 8 verschiedene Richtungen und ums Drücken.

Die 4 Richtungen auf der Tastatur, die es am Anfang gar nicht gab (es war ja ein Eingabe-Return) entstanden als WASD vermutlich auf dem PLATO-SYSTEM (doppelt benutzte Tasten). Aber auch hier: Es war optional. Jede Taste ist auf einer Tastatur eher optional in der puren Masse von Knöpfen.

Anders der Joystick er schränkt massiv ein und macht damit auch die Kontrolle sehr einfach. Er ist quasi eine Eingabediktatur. Ein Interface für die ArcadeGameWelt.

Insofern war die Tastatur als Kontroller danach geradezu eine Auflösung dieser auf einen Zweck ausgerichtetes Interface. Dasselbe gilt natürlich auch für die Maus. Zwar gibt es Spiele wie RockNRoll oder andere im 16/32Bit Zeitalter (gibt es diese Art der Spiele noch?) aber sehr schnell wurde die Maus dann eben als Zeige/Richtung (DOOM etwa) oder GUI-Element (Dungeon Master) gebraucht.

Insofern ‚fühlt‘ man sich als Gamer* und Designer* nur bei einem Joystick schlecht, wenn man nicht alles ausnutzt und freiwillig sich handikäpiert, auf einer Tastatur ist das schon von Anfang an sinnlos. Allerdings zeigen die heutigen Joypads auch, dass hier versucht wird jeden Knopf auszunutzen. In diesem Sinn ist das heutige Joypad eigentlich ein Joystick-Keyboard.

// Siehe dazu auch: Siehe dazu auch: Atari ST/Amiga-Version von TheHolyCubeDeluxe

Ein kurzer Versuch einer Einordnung von Input und Output.

Input

Siehe dazu auch: Von der Turnbased-Input-Informatik (Stop&Go) zur/und Optionalen-Input-Informatik (und die Auswirkungen auf Games) [Diskussion]

1. Param-Control (Total-Control): $gamex left

Der Input ist nur ein Parameter wie in einer Shell. Das Programm startet dann. Interessant daran, von diesen Spielen gibt es nicht besonders viele. Oder es sind nicht besonders viele bekannt. Die Interaktion wäre auch hier in der Shell. Laufen lassen, was passiert, nächster Try. Prinzipiell ist die Shell natürlich an und für sich so ein Game.
Befehl: args
Experimente Dazu: (ZureichOregonTrail) https://editor.p5js.org/t00cg/full/87uRdidyi
Used heute: OregonTrail, Autobattler
Controllers: Lochkarten, Knöpfe, Tastatur (TypeWriters)
Gesellschaft: Ein Input, Output. Regeln am Anfang an gesetzt. Das System läuft, kein Einfluss, es zeigt Ergebnisse.

2. „Input“-Control (TurnTake-Control): Jahr?

Das Programm ist interaktiv. Die Parameter sind ins Programm verschoben. Das Programm kann aktiv nachfragen. Allerdings ist es ein StopAndGo. Dadurch sind Turn-basierte-Games gut machbar. Vieles aus dem Alltag etwa von Spielen kann integriert werden. Vorallem BASIC fördert massiv diese Art von Spielen. Es wird eine Art Dialogisierung möglich. Input ist aber zwingend!
Learning: Sehr gut nutzbar.
Befehl: Input „Jahr?“ a$
Case Plotshot: Lührmann: FORTRAN war nicht interaktiv, BASIC interaktiv!
Buch: BASIC 101 GAMES
Spiele: Oregon Trail, BASIC 101 GAMES
CH: Alexander Hahn „Leiterlispiel“ am ETH-Terminal
Computer: Mainframes mit Terminals (Telnet), BBS
Controllers: Typewriters, Tastatur only
Gesellschaft: Es werden Veränderungsmöglichkeiten im Fortgang eingebaut. Diese sind klar eingebaut und benötigen das OK der Personen. Falls diese nicht erfolgt, stoppt der Prozess. Alle müssen einverstanden sein.

3. „Optional-Control“ (Bedingungs-Control): >>>>?>>>

Das Programm wird nun als total interaktiv wahrgenommen. Es ist möglich scheinbar „nebenläufige“ Welten zu kreieren. Der Nutzer wird zum Mitkontrolleur (neben dem Coder/Programm selbst) und das in Echtzeit. Dies ermögicht alle Arcade-Games und Echtzeitstrategiespiele. Dabei spielt nun ‚gegen die Zeit spielen‘ eine Rolle. Davor nicht möglich
Befehl: If ($key==13) { }
Spiele: PacMan etc
Digitale Archäologie/Experimente: BASIC-Dialekte, LineJewels (mit Typewriter mögliche), PlotArcadez, C64-Games, AtariST/Amiga-Games
Computer: Consolen, Homecomputer, AllInOne, Kontrollierbar
Controllers: Joystick, Tastatur, Maus
Gesellschaft: Echtzeitkommunikation, Vermutlich allgemeine Regeln und darunter eigene kleine Programme

Output (Displays)

Die Displays wie Sound etc. werden hier nicht behandelt.

// ToDo

1. Leuchten (Lämpli)

2. TeleType-Writer

3. Plotter

4. Screens: Draw&Clear

5. Analog Screens

6. Digital Displays

• Zuerst eine Demo
• Er ist besoffen.
• sprayt ab und zu
• knalle zufällig gegen Dinge
• demonstration
• 80er jahre talk …
• Geht im kreis ‚haee???‘
• uhh
• spray oder sagt Code
• trifft Kollegen (gewirr umeinander)
• blut? ohne blut bis zu einem (immer weniger blut, bis wieder in was reingelaufen?
• brüllt
• brain/alcatraz …
• zu Hause: wieder demo …
• what a fucking demo
• teapot … i love it …
• pascal … assembler forever …
• rauchen
• piss
• Greetings to: Warja Lavatar

Weiterlesen →