Archiv des Autors: admin

SinglePlayer-Spiele – der neue sich bewegende Mensch in der Welt [Kurzessay]

[ Siehe dazu auch „PacMan ist nicht (nur) TopDown!“ oder die Comic-virtuelle-symbolische-Sammel-Perspektive von PacMan ]

Mit der Erfindung der SinglePlayerSpiele löst sich der Mensch letztlich vom Brettspiel und kämpft fortan allein gegen die Technik. Er kämpft nicht mehr auf einem gemeinsamen Feld gegen andere Spieler wie in Pong sondern eben gegen Tiles oder radikaler: gegen Aliens. Er kämpft dabei – auch historisch – in einem ganz neuen Gebiet, einer digitalen Welt, dies es so gar nicht gab. Es wurde erste erfunden.

Dabei ist die Perspektive gleich radikal, statt einer gemeinsamen Perspektive (etwa TopDown) entstehen mehr und mehr Spiele mit komplexen – meist lokalen – Perspektiven. Etwa bei PacMan. Der Raum selbst verhält sich dabei nach lokalen Regeln. Er kann verschiedenste Winkel, Perspektiven haben. Fast radikal realisiert sich dabei die Erfahrungen der 80er Jahre und der Individualisierung.

Und hier spiegelt sich auch die Auflösung einer gemeinsamen Ordnung, einer TopDown-Ordnung. Diese Ordnung wird verschieden und das bis in die Perspektive hinein und die Regeln. Es entstehen auch neue Gegner – wie Aliens oder eben weitaus Familienfreundlicher die Geister in PacMan. Diese haben meist andere Handlungsspielräume als der Spielende*. Dabei ist der Spielende* immer in mindestens zwei Perspektiven unterwegs, seiner eigenen und der des Spiels.

Letztlich wird sich diese Art der Perspektive im Mainstream nochmals radikal ändern bzw. erweitert werden, wenn mit den 3D-Gameengines (und davor den Wireframe/Polygonespielen) meist radikal eine Perspektive durchgsetzt wird (natürlich mit der Ausnahme von Minimaps etc). Diese steht dann natürlich meist im Dienste davon, dass sich die Welt nur noch um den Avatar dreht. Dies kann natürlich auch wiederum gelesen werden an eine Anpassung der Konstruktionen von uns selbst in der Welt.

Eine Demo kreieren, die Suche nach dem (eigenen) Motivationsdesign und die Besonderheiten

Motivation hinter Crackintros

Das Motivationsdesign hinter der Crackerszene war divers. Von Personen, die einfach nur ein Spiel bis zu Ende spielen wollten (Trainer), über Personen die Spiel ‚befreien‘ wollten vom Kopierschutz bis hin zu Leuten, denen es vorallem um symbolisches Kapital in ihrer Community von anderen Cracker ging (siehe Artikel von Gleb). Die CrackIntros darin hatten diverse Funktionen – Messages zu den Endkunden (geteilt in direkten Messages übers Spiel, (Bewertung), Kommentare zum Spiel, zum Cracken und Adresse fürs Einschicken/Kontaktaufnahme, Mitgliederwerbung, Zeigen wie Cool man ist), Message an Kollegen (Crackprozess, Zeit des Crackens, Crackart, Gepose), Message an andere „böse“ Gruppen (Crackprozess, Zeit des Crackens, Crackart, Gepose, Erniedrigungen), meist keine politischen Messages und Message an ! die GameDesigner/Publisher (Wie einfach es war es zu cracken). Die GameDesigner haben ja auch ihre Message in den Programmen hinterlassen und so vor- bzw. zurückkommenuziert. Siehe BlogEintrag. Aber all diese Motivationen waren klar und Teil des Grafitti-Products „gekracktes Spiel“.

Metaspiel CSDB

Siehe dazu auch das Metacrackspiel csdb.dk heute auf lemon64.com, wo immer noch gecrackt, Trainer eingebaut werden, dafür gibt es nun aber Punkte und am Ende des Jahres hat jemand gewonnen. Eine Art Operationalisierung und Objektivierung des Wettbewerbs.

https://csdb.dk/release/?id=236312

Motivationsdesign hinter (eignen) Demos?

Ganz anders sieht es bei der entstehenden Demoscene aus – das Motivationsdesign ist viel diverser, weil auch weder das Produkt noch die Community noch die Endnutzer so klar definiert scheine. Sicher ist, dass das Medium Intro im Medium Demo viele ihrer ursprünglichen Funktionen verloren hat.

Weiterlesen

Metall, „Farbverläufe“ & Reflektionen in 16/32-bits-Demos&Games – eine (manuelle 3D-)Designtechnik

Wenn man sich fragt, warum benutzen so viele AtariST/Amiga-Demos so viele Reflektionen bzw. Farbverfläufe in kleinsten Abschnitten/Flächen, dann ist die erste Antwort: Damals hatte man endlich 16/32 Farben und Farbauswahl, deswegen konnte man hier protzen, handgerendertes 3D war endlich möglich. Sicherlich ist das einer der grossen Motivationsmechaniken, aber eine zweite Motivationsmechanik ist eben auch da (das bemerkt man spätestens wenn man selbst gestaltet: Es hilft zu vertuschen, dass man nur 16/32 Farben aus einer eigentlich spärlichen Palette 512 oder 4096 Farben zur Verfügung hat bei 320×200(256) Pixeln hat. Grossflächige von Hand geshadete Kugeln etc. ist das selbst bei einem ‚verchmierenden‘ CRT – einfach zu abgehackt und grosse Flächen mit „Treppenabstufungen“ (auch für Antialising benötigt man viele Farben) lassen sich damit verhindern. Hier einige kreative Beispiele. Weil Reflektionen immer auch zu „Weiss“ tendieren (direkte Reflektion) können hier auch immer die Graustufen/Gelbstufen wiederverwendet werden.

Selbstverständlich geht all dies auch Hand in Hand mit den Möglichkeiten von „Sprayen“ in den gängigen Malprogrammen oder eben im Analogen mit Sprayen (Grafitti) und Airbrush.

In Schriften und am Rand (gerade vo Schriften) immer gut nutzbar „Pseudo“-Metall. Im Innern dann wieder eine andere Farbe (als wäre es ein anderes Material) und das Gestaltungsspiel kann von neuem losgehen. Dabei braucht es hier nicht besonders viele Farben – so 2 * 4?

Schriften sind ein besonders beliebtes Anwendungsfeld. Die Gründe sind schnell klar: Die Buchstaben wiederholen sich oft und müssen dennoch abwechslungsreich sein. Unten mehrere Spiegelungen und Verläufe. Dadurch entsteht selbstverständlich ein 3D Effekt (aussen herum) und im Inneren ebenfalls eine interessante Beleuchtung bei „ZEALAND“.

Noch besser funktioniert das Ganze natürlich bei noch kleineren Schriften. Hier verschwimmen auf einem CRT die PixelFarben. Aber auch hier eine Beleuchtung von Oben und Spiegelung von unten?

Weiterlesen

Der Amiga und die (Fehler-)Entwicklungsästhetik

Es ist immer wieder interessant, was passiert bei Entwicklungsprozessen auf dem Amiga. Jeder Fehler (in Assembler – keine Boundaries, keine Checks) ist da irgendwie am Ende visuell und damit irgendwie erfahrbar. Als Entwickler* steht man da und versucht dann zu verstehen, was da wohl gerade wieder passiert.

Im diesem Fall scheint es, um die Bitplanes (Aufteilung der Farbwerte des Screens in unterschiedlichen Speicherbereichen) zu gehen. Diese scheinen verschoben zu sein oder die Screenbreite stimmt nicht.

Und auch hier: ewig ruft der Blitter…

VICE – C64 Emulator – Settings!

So sehr man den Vice-Emulator mögen kann. Er hat – zumindest auf dem Mac – keine Presettings. Es geht also nicht, einfach ein XYZ.PRG auf das Fenster zu ziehen und loszulegen.

Vorher muss das Ganze konfiguriert werden. Wer sich sowas ausdenkt und nicht mal die Cursor-Tasten per Default aktiviert. Ja der ist halt kein Menschenfreund.

Hier die notwendigen Schritte:

Weiterlesen

Hardware-Collision C64 – praktisch ohne Nutzen

// Alles in einem Byte – alle Kollisionen – untrennbar

Das es mit der Hardware-Collision nicht sehr weit her sein muss, zeigen eindrücklich die Hardware-Collisionsroutinen des C64. Hier gibt es die Routinen: Sprite-vs-Sprite und Sprite-vs-Background. Die Sprite vs Background fragt wirklich letztlich nur den Hintergrund ab. Die (pixelgenau) Sprite-vs-Sprite-Routine liefert einfach ein geflatetes Byte mit dem aktuellsten Collisionsstand. Also etwa (von links nach rechts zu lesen): 01011001

Das erste Sprite kollidiert gerade mit dem 4. oder das 4te und das 5te oder das Fünte mit dem ersten.

Das Ganze ist also maximal ambigue und deswegen auch nicht wirklich nutzbar und so – zumindest einige Blog-Artikel – auch nicht wirklich genutzt worden dann. Dabei ist auch hier die Frage – waren das Problem die Kosten? Ein Byte pro Kollision von Spritex mit allen anderen Sprites würde ja nur 7 Bytes mehr benötigen (1 verwendet man ja schon)! Der C64 ist ja bekanntlich eine auf Kosten optimierte Computerspielmaschine.

// Insofern schwierig zu verwenden etwa im Sizecoding, wo man dann nicht durch eine zweite Methode bestimmen kann, wer da mit wem kollidiert.

Die 80er Jahre und zwei Formen von Unterhaltung und Kultur: Jugendunruhen und Cracks-, Demo- Computerspielscene [Thesendiskussion]

Bauer/Suter(?)/Dave(?)/Larissa(?)

Zu Beginn der 80er Jahre ist Zürich ein Dampfkessel. Seit Jahren wird den Jugendlichen (also eher jungen Erwachsenen) versprochen, sie bekämen endlich einen Freiraum (zur Selbstverwaltung). Sie fühlen sich zu recht nicht wahrgenommen und abgeholt in dieser Stadt. Denn heute wie damals gibt es wenig, was man tun kann ohne dafür zu bezahlen wie die „Hochkultur“ Oper und Schauspielhaus. Zürich ist natürlich nicht irgendeine Stadt, sondern die Zwinglistadt, die noch viel radikaler als andere auf ihren Reformator setzt: auf Arbeit, Arbeit, Arbeit und Beten gesetzt hat und dies hat angehalten bis weit in 80er Jahre hinein. Züricht arbeitet und feiert nicht! Diese Nicht-Offenheit ist einer der Gründe warum Zürich sehr spät zu ihrer Universtität kommt. Und Zürich ist auch nicht eine Arbeiterstadt wie etwa Winterthur. Ihren Aufstieg verdankt sie auch unter anderem dem Zweiten Weltkrieg und den Geschäften – stille Geschäfte vorallem. In diesem Sinn: Nichts soll hier die Ruhe stören.

Dies schlägt sich auch in Liedern etwa von Georg Kreisler nieder mit Sätzen wie (Daneben hat er sich auch noch Max Frisch „vergangen“ – sein Theaterstück sei langweilig 🙂 Man ist in ZH nicht besonders ehrlich. ):

„Auch führ ich gern nach Zürich, aber da ist das Leben nach Mitternacht so still.“

Es wird dann am Rande der Stadt in der Roten Fabrik (sonst genutzt vom Opernhaus) ein jämmerlicher kleiner Raum für eine 300-400k Stadt freigeräumt.

Jugendkultur I: Eigene öffentliche Jugend-Kultur 1980+ [Analog]

Und dann kommt es zur Eskalation am Opernhaus (das das meiste Kulturgeld „frisst“ – was es bist heute tut – der Kanton zahlt das Opernhaus der Rest die Stadt Zürich) bei einer Demo. Anlässlich einer Abstimmung zum Opernhaus fordern die jungen Erwachsenen endlich ihre Bedürfnisse ernst zu nehmen und ! ein „Jugendhaus“. Es soll ihre Kultur sein und keine Elitekultur.

Weiterlesen

Kreativität in der Demoscene und der immer noch fehlende Code

Die Kreativität in der Demoscene steckt zum einen in den Endprodukten den Demos. Aber das ist selbstverständlich nur die halbe Wahrheit. Denn der eigentliche kreative Prozess ist die Erarbeitung dieses Endproduktes als Programm für eine Maschine.

Und dies ist umso mehr der Fall je eingeschränkter die Umgebung ist. Mit der Verminderung der Möglichkeiten muss mehr investiert werden in die Umsetzung, in Ideen, in unkonventionelle Ideen die Ziele zu erreichen. In diesem Sinn ist SizeCoding ein Paradesbeispiel des Constraints-Meta-Game. Hier geht es darum in wenig Code Dinge zu realisieren, die es schon gibt und die teilweise überhaupt nicht komplex sind zu programmieren. Und dann muss optimiert werden, integriert und weitere 10 Varianten ausprobiert werden müssen. Gerade die Nanogames sind dabei ein besonders gutes Anschauungsbeispiel, da hier die Spielkonzept bekannt sind oder umgekehrt wie in der Geschichte der Games, Games halt mit diesen Mitteln erfunden werden müssen. Auf jeden Fall ist der Aufwand immens für ein gutes – zu bestaunendes – Endprodukt.

Und dennoch ist trotz all dem die Spiegelung des Codes im Endprodukt oder auch nur die Thematisierung des Prozesses der Codeentwicklung kein Thema in der Demoscene. Es ist eher so, dass möglichst gestaunt werden soll, möglichst Geniekult gelten soll: Wow das ist möglich. Selbstverständlich gibt es auch das umgekehrte, Effekte mit wenig Aufwand mit guter Hardware etwa (Ein Beispiel dafür wären sicherlich viele Amiga-Demos – hier ist eher das Endprodukt als die raffinierte Programmierung im Vordergrund).