Was zur Hölle funktioniert jetzt gerade nicht mehr. Ich arbeite am DoubleBufferedUpdaten der Tiles.
Archiv der Kategorie: Coding
Der neue digitale Raum und seine Szenen (GameDev, Cracker, Demoscene …) [wird upgedated]
Eine der interessantesten Fragen zur Homecomputerzeit und ihren Bewegungen ist sicherlich der teilweise gemeinsame Ursprung verschiedenster Szenen und die Ausdifferenzierung danach in verschiedenste Felder. Es stellt sich sogar die Frage, ob diese Ausdifferenzierung auch zur Differenzierung gegenüber anderen Bereichen geführt hat.
Versuch einer Einschätzung:
Category | Business | GameDesign | Crackerscene | Demoscene | Virendevscene | Art/MediaArt |
produkt | apps | games | crackerintros, trainer | demos | viren | kunst |
soz. produkt | firmen | comm. / firmen | crackergroups, metachallenge/game | demogruppen, metachallenge | ||
öffentlich | +++ | +++“ | +/- | +/- | – | + |
intern. öffentlichkeit | ++ | +++ | ++ (handles) | +++ (handles) | ? | |
visuell | gui | +++ | + | +++ | – | |
art visuell | anal. vorbilder | anal/abstract | +- abstract | – | ||
auditiv | – | +++ | +++ | – | + | |
interaktiv | + | +++ | – (trainer) | – | – | + |
coding | + | +++ | ++ | +++ | +++ | + |
unterhaltung | – | +++ | – | +++ | +/- | |
art unterhaltung | interakt. | interakt. spiele | linear | linear | – | |
scene (motivation) | markt | markt/challenge | „markt“/challenge | challenge | challenge | |
kompensation | geld | geld/ruhm, (symbl.) | symbolisches kapital, scene (geld) | symbolisches kapital, scene | symbolisches kapital, spass | |
quereffekte/learnings (findings) | coding, technologie lernen | coding lernen, reverse ingenieering | coding lernen, tricks | gefährlich, ungeliebt |
// ToDo: klare Trennung – Scene – Produzent – Produkt – Consumer
// ToDo: Add costs
Interessante Webseite zur Gameentwicklung etwa auf dem C64 oder Amiga
Es gibt im Netz angeblich unendlich viele Webseiten zur Homecomputerscene. Wenn es dann aber darum geht, Code zu sehen etc, herauszufinden, wie die Probleme in echt gelöst wurden, ist das Angebot dann fade oder man muss alles zusammensuchen. In diesem Sinn ist die folgende Webseite recht interessant, es gibt Interviews und auch Hintergrundinfos.
https://codetapper.com/amiga/diary-of-a-game/menace
Und das macht es speziell bis zur Erklärung vom Datenmanagement und Applicationsarchitektur oder eben auch Spritesheets und ihre Nutzung.
Assembler: jmp (jump)
Und man* tut es einfach: Man benützt den Jump-Befehl und springt irgendwo hin und macht da weiter – irgendwo im immer linearen Code. Hinein in die psychische Konstruktion des Code (und seinen Hierachien), die am Ende linear ist.
Es ist letztlich Anarchie, die immer noch Assembler als Option hat und die Lust daran. Es ist der Möglichkeitsraum, Dinge zu tun, die man eigentlich nicht mehr tut in den höheren Programmiersparchen. Wo man Dinge konstruiert in Verschachtelungen, in Hierarchien, die nicht überspringbar sind. Code also der letztlich, wie die Systemtheorie funktioniert. Systeme in Systemen – aber brich niemals aus! Dadurch ist auch hochintegrierter Code möglich. Letztlich nachhaltiger Code.
Es ist die Freiheit und Bürde von Assembler zugleich (Hängt da mein Code wieder in einer Endlosschleife?). In diesem Fall springt der Code „jmp next_level“ (ich springe, geistig beim Nachprüfen) über alle Hierarchien zum Code für den nächsten Level (nach oben). Kein Gequäle ist das durch die Hierarchien der Verschachtelungen mit {} – sondern einfach da hoch.
Eine Erfahrung die ab 1964 viele natürlich mit GoTo gemacht haben.
Anarchie muss ab und zu sein.
Extreme Programming avant la lettre – GameDev 1980+ zu Hause, in Clubs und an Demoparties
Extreme Programming ist eine Methode der agilen Entwicklung. Zwei Leute sitzen da und entwickeln gemeinsam.
Nach einem Gespräch mit Philip Jesperson (Entwickler von Supaplex) und auch zu sehen im „Capt der digitalen Hoffnung“ (SRF 1987) ist wieder klarer geworden: Extreme Programming, Developing und GameDesign war in der Gründerzeit der digitalen Revolution (Homecomputer) in Sachen Games vermutlich Teil des Alltags. Die Gründe sind dafür vielfältig aber auch klar: Computer waren rar. Also hatte nicht jeder einen, den richtigen (etwa einen Amiga) und schon gar nicht zwei. Notebooks waren sündhaft teuer.
Entwickeln war also oft nur zusammen möglich. Und so trafen sich die Entwickler* dann auch bei sich zu Hause oder im ComputerClub oder eben auch an Parties, die quasi viele Funktionen eben auch die soziale Komponenten per se mitbrachten. Dabei lernten die Personen – im Diskutieren von Code und „Wie machst du das“ – auch über diese persönlichen Kontakte, das gemeinsame Entwickeln. Dabei war vermutlich – so zumindest die Beispiele – die konkrete Nähe geografisch wichtig.
Dabei ist der Unterschied zwischen Cracking, Demoscene und GameDesign nicht riesig – den wie „man es“ technisch fertig brachte, waren ähnliche Challenges.
Demos – Einzelanfertigungen [Kurznotiz]
Demos sind letztlich – zumindest für 1980-1993 – spezialisierte Einzelanfertigungen. Sie sind mehrheitlich – so zumindest die Einsicht Einzelprogrammierungen, weil nur dadurch es möglich ist, das Maximum aus der Hardware herauszuholen oder anders gesagt: Es muss mehrheitlich Hardware nahe sein, um überhaupt mit Tricks das ganze Potential herauszuholen. Dadurch verschliesst sich eine gewisse Verallgemeinerung in Richtung komplexeren Frameworks.
Selbstverständlich ist dies im Crackerbereich nicht ganz so gelaufen, hier scheint es zumindest, dass so etwas wie Frameworks entstanden sind. Eine ähnliche Situation wie wir sie auch im Gamebereich dieser Zeit sehen bzw. etwas was noch genauer untersucht werden muss. Denn auch hier enstanden Frameworks für Games.
Ausstellung: Erfahrbarmachung von Assembler – Setzkasten
Ein Erfahrbarmachung, wie funktionieren Programmiersprachen in ihrer Komplexität wäre vielleicht mit einem Setzkasten und eine einfache Programmieraufgabe. Darin sieht man schnell wie sehr einschränkend etwa ein 6502 (oder weniger 6800) waren im Gegensatz zu einem 68000.
// ToDo: Nutzung von HumanRessources als Spiel dazu oder dann die DSP-Games
Hier das Puzzle zusammengesetzt für eine PrintNumber Routine
Demoscene 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
Jenseits der Konsumenten*perspektive oder die brutale Produktions- und Entwickler*perspektive
Wer sich Games anschaut eines Computersystems ist meistens erfreut, was es da alles gibt. Da denkt der Recipient: WOW – Unglaublich. Gerade wenn eine Selektion so visuell ist wie die Nachfolgende.
Dabei linearisiert natürlich das Medium Film die interaktive Erfahrung und die Spielmechanik oder das Gameplay spielt keine Rolle. Das ist letztlich die Sicht des Konsums, der Konsumenten. Und damit reproduziert sowohl die Fans, Interessierte Spieler und ganze Teile der Wissenschaft nur den Markt.Beziehungsweise nicht mal den Markt, denn da wäre auch zu nennen, wieviel die Spiele gekostet haben. Meist wird geurteilt ohne jeglichen Bezug einfach nur absolut. Selbst die Entsehungszeit wird oft gnadenlos ausgeblendet,
Die Produzenten*- und Entwickler*-Perspektive
Noch viel schlimmer ist allerdings nur das Betrachten des Endproduktes. Dies ist auch der Marktlogik geschuldet. Der Rezipient*/Spieler* ist ja der Käufer*, der Herrscher über das erstandene Produkt. Wie dieses entstanden ist und zu welchen Kosten auch menschlichen interessiert bis heute in der Gameindustrie niemanden. Das Produkt ist transparent im Informatik-Sinn: Es spielt keine Rolle wie. Deswegen fehlen bis heute im Gamebereich jegliche Labels. Dabei ist es essentiell unter welchen Bedingungen Games entstanden sind.
Dabei spielt es massiv eine Rolle unter welchen Bedingungen, Zeit, Geld, Teams ein Spiel entstand. Die Würdigung des Geleisteten ist nur so möglich und dies ist Teil vom Designprozess. Und hier zeigt sich denn auch bis heute von was Gamer* profitieren. Viele der oben genannten Spiele sind nur durch ausserordentliche Nutzung überhaupt möglich geworden. Das bedeutet letztlich – vermutlich anders als im Consolenbereich – unter massiven Anstrengungen und menschlichen Ressourcen. Teilweise vermutlich jenseits von irgendwelcher möglicher Rendite und angenehmen Arbeitsbedingungen. Nicht dass dies heute anders wäre, wo vorallem der Content so erarbeitet wird. Aber es ist auch diese Spur, die es offen zu legen gilt, um mit dem ’schönen‘ Spiel richtig umzugehen und es einordnen zu können.
Dabei muss jedem* klar sein, so einfach und lustig wie die Leute hier erzählen sind diese Tricks nicht zu implementieren. Auch dies gehört zum Habitus des Geniekults den Aufwand, die Irrungen nicht klar zu machen.
Hier ein paar Tricks ohne die viele Amiga Games etwa nicht möglich wären: