Archiv der Kategorie: Uncategorized

PlotArcadez: Potshot – Spielmechanik – Optimierungsmechanik [Notiz]

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.

Weiterlesen

PlotArcade: POTSHOT – optimizing

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*.

Weiterlesen

Das Digitale existiert nicht analog oder das Digitale ohne Abfall

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.

Weiterlesen

CLS Clearscreen abhängig von der Technologie

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?)

Weiterlesen

Holistische Analyse eines Games: Technische Analyse und Programmierung des Games inbegriffen (Experimentelle Archäologie) [Notiz]

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

Demoscene: 80erJahre Homecomputer als Idee/Grundlage der Demoscene [Kurzdiskussion]

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