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.
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…
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.
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
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).
Die ist auch ein Case für die Idee Sizecoding als Designmethode zu diskutieren. Siehe dazu hier Sizecoding [DesignMethode] >
Wer das erste Mal ein Breakout programmiert denkt: Kein Problem. Da gibt es ja nur einen Schläger, einen Ball und Steine (Playfield). Die Grafik verwundert, ist sie doch in einer Zeit der monochromen Monitore entstanden. Das Problem löst sich dann, wenn man liest, dass es sich um eine Farbfolie handelt. Aber Farbe ist heute ja auch kein Problem mehr.
Das Spiel selbst ist letztlich ein auf den Kopf gedrehtes Pong-Arcade (auch physisch) und aus dem einen Gegner wurden statische AIs alias Blöcke. Aus einem Spiel mit 3 Sprites, die dieselbe Technologie benutzten (Sprites) wird ein Spiel mit Vordergrund 2 Sprites und einem Playfield und einem Hintergrund. Aus einem Multiplayerspiel wird ein Singleplayerspiel mit ganz anderer Motivationsmechanik und viel höherer Reichweite.
Die klassische Implementation setzt auf einen Hintergrund mit zwei movable Objects. Wie die genau Implementation des Orginalautomaten von Wozniack/Jobs (Atari Arcades) tatsächlich ist, wurde hier nicht genauer betrachtet.
Die klassische Programmierung findet man im folgenden Spiel „imagoBreakout“ in Aktion:
Mehr zum Spiel – bei dem das Visuelle zunehmend ausgeblendet wird – hier >
WeiterlesenDies hier sind einige Notizen zu einem Cafe-Gespräch rund um den C64 und Amiga. Damals wie heute. Die Gesprächsnotizen sind anonymisiert, weil das Gespräch weder aufgenommen wurde und es liegt auch keine Bestätigung zur Veröffentlichung vor. All dies wird in einem zweiten Gespräch nachgeholt werden. Dennoch sind die einzelnen Punkte gewichtig genug, sie als Fragen festzuhalten.
Einige, der diskutierten Themen:
Es geht darum, wie komplex es heute ist ein neues C64-Game zu machen. Gerade wenn es sich noch an einen Klassiker anlehnt. Was darf übernommen werden, was nicht? Durch den Kontakt zu den Urhebern wird klar, die Rechte sind immer noch da und werden noch benutzt, etwa für RetroKonsolen.
Interessante Diskussion zur Frage, wie das Artwork des Titelbildes entstand und wie hier zuerst das analoge Bild entstand und erst danach die C64 Version erstellt wurde. Allgemein die Frage, wie arbeitet man heute zusammen – direkte Instant-Kommunikation, Emails.
Kurz vor dem Release wurde klar: Das Spiel ist zu Nahe am Orginal. Praktisch alles muss überarbeitet werden (Font bis Figur und Name) – in einem Monat.
Es geht auch um die Frage, der höheren Programmiersprachen. Wann und wo kommt und kam Basic zum Einsatz. Welche Basics gab es. Dies ist umso wichtiger, als dass der Gesprächspartner noch heute im Bereich Basic-Games unterwegs ist. Auch fürs nächste Projekt für den C64 arbeitet der Gesprächspartner wieder mit Basic als Grundlage, weil einfach Assembler für Management-Spiele nicht machbar ist oder zumindest masochistisch ist. Die Diskussion dreht sich auch noch darum, dass es Entwickler gab (vor allem grosse Entwickler?), die auf schnellen PCs kompiliert haben und das Ganze dann auf dem C64, Amiga ausprobiert haben.
Es gibt eine Diskussion darüber wie der Übergang von C64 zu Amiga lief. In der CHLudens Experimentellen Archeologie wurde klar, dass dies nicht ein einfacher Übergang war. In den Berichten von Damals wird es als „Befreiung“ – ein neuer „Möglichkeitsraum“ gesehen – die Probleme kommen eher nicht vor. Der Amiga hat – mit dem 68k – Dinge sehr vereinfacht: „endlich“ Rechnen mit Zusammenzählen, Multiplikation, Division. Das sei schon fantastisch gewesen. Wir sind uns auch einig, dass die 256er Grenze in den Bytes aufgehoben wurde, und das viel vereinfacht hat.
Weiterlesen
