a) In den Crackerintros gab es das auch nicht.
b) Wäre zusätzliches Design gewesen, dafür gab es keine Zeit.
c) Es ging um Effekte und so eine klassische Animation holte niemand hinter Ofen hervor
d) Gute Designer*/Grafiker waren Mangelware.
e) Zuviel Aufwand in der Verwaltung
f) …
Ja eine interessante Frage.
// Bemerkung: Viele der Demos verwenden sehr oft einzelne eher grossen Grafiken, fast keine Tiles – mit der einzigen Ausnahme von Buchstaben.
[ 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.
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
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.
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?
WeiterlesenEs 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…
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:
WeiterlesenWenn es nur um die Kleinheit der Dinge geht. Geht es immer um hochintegrierte System. Jede Veränderung ändert alles und jede Lösung auf dem Papier ist nichtig in der Ausführung, wenn sie zuviele Zeichen braucht.
Kompiliert funktioniert alles, auch die Mechanik geht.
// 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.
