Eine Frage mit offener Antwort. Zumindest machen viele Games genau das vor. Vorallem nach dem Videogamecrash.
Archiv der Kategorie: Uncategorized
Abstrakte visuelle Spiele und die Auflösung als Bedingung (Homecomputerbereich)
Abstrakte Spiele sind in Digitalen Spielen prinzipiell immer möglich. Seien sie abstrakt in ihrer Visualität oder auch in der Spielmechanik. Konkret sind allerdings die wenigsten Spiele im konkreten Sinn „abstrakt“. Meist haben sie ein Setting, das den Spieler in die Spielmechanik „hilft“ als eine Art Brille, die schon sehr viele Regeln mitgibt. De facto sind dann aber Spielmechaniken/Spielschematas (Jürgen Fritz) dann meist weit weg von Analogen Settings (und deren Regeln) und es erstaunt manchmal, wie wir als Spieler* diese Ungereimtheiten einfach akzeptieren. Der Magic Circle und vorallem unsere Abstraktionsmöglichkeiten (Kultur) richten es. Die Regelmaschine Mensch in Betrieb.
Settings und Abstraktion
Im Bereich der visuellen Abstraktion dagegen wollten die meisten Games aber sehr oft ins ‚analoge‘ hinaus. Vielleicht auch um mehr akzeptiert zu werden, vielleicht um so die Welt (Wille zur Macht) die Welt besser überschreiben zu können. Nichts scheint mächtiger als die analoge Welt.
Viele visuelle Abstraktionsleistungen in Computerspielen waren dann im Homecomputerbereich meist eher „Übergänge“ als selbst gewählte Stile. Sei es in der Abstraktion von ASCII-Grafik, später Vektorgrafiken, dann Polygongrafiken etc. Oder anders gesagt: Es wurde selten ‚obsolete‘ Technologie genutzt. Dabei ist gerade die Kunst der 60,70er und 80er Jahre voll von abstrakter Darstellung – falls es um Darstellung ging und nicht wie im Bereich der Computergrafik um die Kreation neuer Welten.
Auflösung oder die Diagonale
WeiterlesenDemoscene und/vs GameDesign 0.1 [Wird überarbeitet]
Bereich | Demoscene | Demo-&GameDesign | GameDesign |
Entwickler* Motivation | SeizeCoding (vorallem am Anfang 8Bit) Zeigen, was möglich ist Challenge / Konkurrenz Community Community um einen Computer herum (Idenität) Kontrolle Freizeitbeschäftigung unter Kollegen Credits | SeizeCoding SeizeDesigning | SeizeCoding (vorallem am Anfang 8Bit) SeizeDesidning (bis heute) Identitätsstiftend und Challenge gegen andere Platformen (Bsp. Atari ST vs Amiga) |
Produktinterne Motivation | Visuelle, technische Finesse, Tricks Challenge „Wie geht das?“, „Könnte ich das auch?“ Echtzeitberechnung | Visuals, Storytelling | Spielmechanik (Challenges) Interaktion Echt- und NIchtechtzeit |
Genutze Techniken | Visuell, Auditiv | Interaktion, Taktil | |
Visuelle Effekte | Massiv | ||
Kollisionen | Meist keine ausser vielleicht Physikdemo | Kollisionen extrem wichtig für die Spielmechanik | |
Darstellung wie gemacht | Flackereffekte, Aufbau | Meistens kein Metalayer eher verborgen, seltene Ausnamen | |
Zufall | Meist nicht vorhanden | Öfters genutzt | |
Interaktion | Meist nicht vorhanden | Hochinteraktiv, Inhalt abhängig vom Spieler | |
Outputs | Demos, Megademos, Diskmags | Games | |
Archivierung | Online (pouet.net, Demozoo.org etc) Videos (Linearisierung) Zines | keine | |
Events | Parties am Wochenende meist International | Arbeit, Treffen wenige für Entwickler heute GDC |
// Muss stetig aktualisiert werden
// Abgleich mit Interviews / Interviews nachfragen
Exhibition: Vergleich Dev-Perspektive [Wird upgedatet]
Für eine Ausstellung wäre es gut, die verschiedenen Aspekte vermutlich tabellarisch zu erfassen. Also wie haben sich die Dinge entwickelt.
Coding
Konstrukt | 8Bit (Assembler) 6502 | 16Bit(Assembler) 68000 | C# |
Möglichkeiten | 8 Datenregister zum Rechnen D0-D8 | 8 Datenregister (B,W oder L) | Diverse Datentypen: Bool Int Float Double String Objekte, Klassen |
Add/Sub | add #4,d1 Problem: über 255 sub #4,d1 Problem: unter 0 | add.b #1,d0 add.w #1,d0 add.l #1,d0 | d++ d=d+1 d+=1 Überfläufe werden kontrolliert. |
Multiplikation | nur mit Bitshifting > < *2 / 2 | nur mit Bitshifting > < *2 / 2 | Floating etc |
Vergleich | cmp #5,d0 bne not5 ; code not5: Problem: – Control bits – 2er oder 10er System – Max. Sprungweite! – Kein copy-paste ohne Anpassung >Fehleranfällig | cmp.l #5,d0 bne not5 ; code not5: Problem: – Kein copy-paste ohne Anpassung >Fehleranfällig | if (d==5) { } |
For-Next | move #0,d0 f010: inc d0 cmp #5,d0 bne f010 | move.l #5,d0 f010: dbra d0,f010 | for (int i=0;i<5;i++) { } |
Objekt-Verwaltung | Simulation von Objekten durch Listen ; objekt id,x,y dc.b 1,5,10 dc.b 4,30,90 Probleme: x>255 | Simulation von Objekten durch Listen ; objekt id,x,y dc.w 1,5,10 dc.w 4,30,90 | Class GObject { int id = 1; int x = 100; int y = 30; } GObject[] arrObs = new GObject[3]; Verwaltung der Objekte auch oft über die Objekte im Szenentree |
// Weitere Beispiele von Komplexität und Auswirkungen in der Praxis
Die fehlenden Gameengines auf Homecomputern oder das Problem, dass nur mit Tricks anspruchsvolle Spiele gemacht werden konnten [Kurznotiz]
Letztlich verhinderte die fragmentierte Hardware und die vielen nötigen Tricks in Assembler, um Games zu machen etwa beim Amiga, dass diese Systeme eine längerfristige Chance hatten. Diese Spezialisierung wirkte sich vorallem auf Investionen/Aufwand in die Technik aus, statt in Spielmechanik. So sehen wir (noch genauer zu erforschen) fast keine Gameengines, die sich entwickelt haben.
Der getriebene und geleistete Aufwand lässt sich bis heute (noch genauer zu erforschen) nur damit erklären, dass da auch eine Generation am Werk war, die sich ihre Träume verwirklichte und dabei keine Grenzen kannte. Die das Ganze als Metaspiel verstand gegen jede Wahrscheinlichkeit. Sicher auch mit der Idee dahinter mal Geld zu verdienen, aber realistisch konnte das nicht funktionieren.
Scrolling oder die Einführung der Kamera
OneScreen-Games
Die ersten Spiele waren grossmehrheitlich One-Screen-Games. Das bedeutet aus Sicht des Gamedesigns und auch in der Spielmechanik, alle Dinge sind sichtbar auf einen Blick. Selbstverständlich gibt es Möglichkeiten auch hier die Sicht einzugrenzen, Techniken wären etwa Fog of War oder noch nicht geöffnete Zimmer (die erst beim Eintreten gezeigt werden).
Es bedeutet aber auch, das die Spiele oft die TopDown-Perspektive oder die Seitenperspektive verwenden. Die Objekte sind dabei relativ klein bzw. müssen klein sein, damit wenigstens etwas auf dem Screen passieren kann – auch wenn das Spiel auf verschiedene Screens verteilt ist. Die Spielmechanik des Suchens kommt in diesem Fall auch anders zum Einsatz, die Objekte müssen eher in Dingen versteckt sein wie Kisten als dann später in 3D Welten.
Scrolling-Games
Mit der Einführung des Scrolling ändert sich das. Der Spieler muss bei den einen Spielen im Bild der Kamera bleiben (etwa beim ersten Scrollenden Spiel) oder später in vielen ShootEmUps oder er steuert aktiv den Bildausschnitt oder moderner gesagt: Die Kamera ist über dem Spieler. Da erstaunt es dann auch nicht, dass Parallax-Scrolling genutzt wird, um die Welt auch ins 3D zu erweitern. Die Komplexität der Spielsituation rund um den Avatar bleibt meist die gleiche. Aber der Avatar rückt mehr ins Zentrum und wird nun oft grösser. Und das Suchen durch Scrolling von Gegenständen wird zu einer beliebten Spielmechanik.
// Einsatz von Flöte und Harfe und Funktion einmal untersuchen (vgl. 8Bit-Sound)
Das Warten während des Compilierens – defiktionalisierte (Source-Code-)These
Es ist ein Moment, der eingepasst ist in den Iterationsprozess im Coding oder auch Gamedesign. Aus der These wie der Code funktionieren sollte wird ein Warten.
Beim Compillieren testet der Computer, ob alles zumindestesn formal korrekt ist. Der Entwickler* ist gespannt.
Einfach nicht das beim Compillieren:
Was ist falsch daran? Ein Hinweis vom Compiler. Aber gerade ist das nur die Idee, was sein könnte. Es geht weiter:
Ein erstes Entspannen folgt: „Ok es läuft“. Dann die zweite Anspannung: „Ok was läuft“. „Läuft das, was geplant war.“ Also die These von der Architektur, das was die Veränderung im Source-code nun im Resultat dem laufenden Programm, ist es das.
Dann das Warten beim Aufstarten und dann die Kontrolle, ist die These vom Konstrukt der Software korrekt, stimmt es mit dem laufenden Programm übereinander oder nicht?
Das ist ein Upchecken und ein oft sehr schnelles: „Ok, es läuft“ oder „Nein shit, es geht nicht. Warum nicht? Ist mein Gesamtkonzept falsch?“
Nächste Runde. Nächste Challenge. Nächstes Iteration: IDE. Changes > Kompillierung > Game.
Aus dem Leben eines Entwicklers: Ein Sprite konnte gerettet werden
Nachdem nur 6 Sprites kontrolliert werden konnten auf dem Amiga, konnte nun ein ‚weiteres‘ gerettet (kontrolliert) werden. Das eine aber hängt nach ausser ‚Order‘ oben am Rand. Keine Ahnung warum.
Was ist komplexer oder welche Arten von Komplexität unterscheidet die Demo- und die Gamedev-Szene? (Reminder)
Oder anders gefragt: Wie sah die Crack- und Demoscene das Gamedev und ihre Komplexität. Und wie sahen/sehen die Gamedev-Scene die Crack und Demoscene. Dies ist gerade im Schweizerumfeld eine interessante Frage, da diese Scenen sich überschnitten haben.
Das neue Interface: Die analoge Mouse – Bitte reinigen
Die Maus eingeführt in den Massenmarkt mit dem Macintosh kam bei der Masse dann an mit den 16/32Bit Homecomputern Atari ST und kurz danach Amiga. Die Mäuse machten GUI bedienbar und einige Game Genres wirklich attraktiv von Arkanoid-Games über Point-And-Click Adventures bis zu Strategiespielen.
Mäuse waren analog (im Gegensatz zu den optischen heute) und damit Maschinen, die Dreck ansammelten bei den Rollen, über die die Kugel „rollte“. Und wenn der Nutzer* sie nicht öfters reinigte, dann sprang der Zeiger oder bewegte sich ruckartig.
Hier ein Beispiel, wie man eine solche (kein Orginal) Maus reinigen musst. Es war eine recht grausige Sache, da der Nutzer* ja wusste, dass das alles Dreck von der – im besten Fall – Mausmatte war.