Archiv der Kategorie: Coding

Warum fasziniert mich der Cyberspace? [Erfahrungsbericht in Arbeit]

Im Nachfolgenden wird die Geschichte der Faszination ‚rekonstruiert‘. Dabei ist klar, dass diese Geschichte die Vergangenheit umschreibt und fokkussiert.

?1981 SportTelespiel mit Pong und Co bei einer Tante am Fernseher (Kirchberg)
1983 Intellivision bei Cousins im Tessin (Teserete)
1985 Erstkontakt mit Computern an einem Computercamp in Rohrschach oder Romanshorn – Apple II (Basic Kurs) & Macintosh (Mac freundlicher Computer und UI)
???? Ausstellung im Technorama (vgl. dazu Roger Sieber Interview

1986 Papierprogrammierung und Suche nach einem Computer, Finanzierung
1987 Geschwister kaufen einen Computer: Atari ST

Faszination 1987

  • Neu
  • Grafische Oberfläche
  • Man kann ihn bedienen (Er reagiert)
  • Man kann ihn programmieren
  • Dinge laufen selbst (Exe)
  • Es gibt Dinge, die gehen und anderes scheint möglich
  • Offener Raum / Möglichkeitsraum
  • Es sind nicht existierende Welten – sie werden erschaffen
  • Es wird nichts verdrängt im Realen (Steht nur im Kinderzimmer)
  • Teilen mit Geschwistern
  • Konkurrenz (was haben andere, eher was hast du auch?)
  • Kleine Communities (Atari ST)
  • Besser zu Hause als in der Schule/Kanti
  • etwas auf eignem Computer haben und es kontrollieren
  • Experimentieren können (geht nichts kaputt, keine speziellen Ressourcen)
  • Dinge können Rückgängig gemacht werden (anderer Raum)
  • Man kann Dinge machen, die es noch nie gab – erforschen
  • Man ist Gott über das eigene Land, das man allerdings erschaffen muss
  • Es ist interaktiv Games (vs Demos)
  • Es ist nur Sprache
  • Es gibt Werkzeuge
  • Alles ist in einem Gerät drin, es ist Konsum und Werkzeug
  • Es ist ein interaktives Zeichen
  • Es gibt Limits, die haben alle
  • Es ist ein faires Ding (niemand hat „mehr“)
  • Im selben gemacht
  • Man könnte das auch Schaffen

BBS und das erste mal gehört von Telnet
Gegeneiner Spielen …

Weiterlesen

Virtualisierung: Amiga – Blitter 1988

„Wie setzt man Sprites vom C64 um die 25×21 Pixel gross sind, der Amiga aber nur 16*x Pixel als Sprites zulässt? Die Grösse bringt man ja hin aber sonst (16×21 Pixels)?“

Die Antwort von einem bekannten Portierer von damals paraphrasiert: „Da benutzt Du den Blitter“.

Und ja so hart kann man es aussprechen. Mit dem Amiga und seinen Customchips endet auch ein Teil der direkt Hardware basierten Idee von Sprites und der Hardware basierung und Spezialisierung im Allgemeinen.

Der Amiga ist damit auch Teil der sich langsam fortsetzenden Virtualisierung der Digitalisierung ab Mitt der 80er Jahre.

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:

CategoryBusinessGameDesignCrackersceneDemosceneVirendevsceneArt/MediaArt
produktappsgamescrackerintros, trainerdemosvirenkunst
soz. produktfirmencomm. / firmencrackergroups, metachallenge/gamedemogruppen,
metachallenge
öffentlich++++++“+/-+/-+
intern. öffentlichkeit+++++++ (handles)+++ (handles)?
visuellgui+++++++
art visuellanal. vorbilderanal/abstract+- abstract
auditiv+++++++
interaktiv++++– (trainer)+
coding+++++++++++++
unterhaltung+++++++/-
art unterhaltunginterakt.interakt. spielelinearlinear
scene (motivation)marktmarkt/challenge„markt“/challengechallengechallenge
kompensation
geld
geld/ruhm,
(symbl.)
symbolisches kapital, scene
(geld)
symbolisches kapital, scenesymbolisches kapital, spass
quereffekte/learnings
(findings)
coding, technologie lernencoding 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]

BereichDemosceneDemo-&GameDesignGameDesign
Entwickler*
Motivation
SizeCoding (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
SizeCoding
SizeDesigning
SizeCoding (vorallem am Anfang 8Bit)
SizeDesidning (bis heute)
Identitätsstiftend und Challenge gegen andere Platformen (Bsp. Atari ST vs Amiga)

Produktinterne MotivationVisuelle, technische Finesse, Tricks
Challenge „Wie geht das?“, „Könnte ich das auch?“
Echtzeitberechnung
Visuals, StorytellingSpielmechanik (Challenges)
Interaktion
Echt- und NIchtechtzeit
Genutze TechnikenVisuell, AuditivInteraktion, Taktil
Visuelle EffekteMassiv
KollisionenMeist keine ausser vielleicht PhysikdemoKollisionen extrem wichtig für die Spielmechanik
Darstellung wie gemacht Flackereffekte, AufbauMeistens kein Metalayer eher verborgen, seltene Ausnamen
ZufallMeist nicht vorhandenÖfters genutzt
InteraktionMeist nicht vorhandenHochinteraktiv, Inhalt abhängig vom Spieler
OutputsDemos, Megademos, DiskmagsGames
ArchivierungOnline (pouet.net, Demozoo.org etc)
Videos (Linearisierung)
Zines
keine
EventsParties am Wochenende meist
International
Arbeit, Treffen
wenige für Entwickler
heute GDC

// Muss stetig aktualisiert werden
// Abgleich mit Interviews / Interviews nachfragen