Motivation hinter Crackintros

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

Motivationsdesign hinter (eignen) Demos?

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.

Das ist am Anfang der Scene noch nicht so. Hier gibt es noch Scrolltexte und Botschaften. Das scheint sich dann alles zu verflüchtigen, als die Scene immer mehr zu einer PartyDemoscene wird (Treffen, Riesenveranstaltungen) und sich nach den BBS das Internet (Email) und dann das WWW durchsetzt. Die Message etwa als Text kommt heute sehr selten vor. Das heisst als erstes einmal – es geht nicht mehr so sehr um die direkte Kommunikation über die Produkte Demos.

Diese Kommunikation läuft – falls – wohl eher direkt in den Demoscenen-Parties. Da trifft man sich und kann direkt miteinander reden. Und es gibt Wettbewerbs- wie auch Archivierungsplattformen wie etwa pouet.net oder Demozoo. Auch hier kann kommentiert und gewertet werden.

In diesem Sinn ist das indirekte Ansprechen der Anderen kein allzu grosses Thema mehr (allein die Textmenge ist verschwindend quantitativ). Gegrüsst scheint auch nicht mehr wirklich zu werden über die Demos. Die Demos sind also keine eigentlicher Kommunikationskanal mehr. Geblieben sind welche Gruppe, wann und teilweise wo, sowie minimale Kontaktmöglichkeiten (die sonst eh schon auf pouet zu finden sind). Auch hat die Virtualisierung (während Corona, teilweise nur noch Online-Parties) zu mehr Online-Übertragungen und live-ChatDiskussionen während der Präsentationen geführt. All dies nimmt selbstverständlich viel Kommunikation aus den Demos als Träger heraus.

Die Demo kommt – so lässt sich stark vermuten und es deutet auch nichts auf was anderes hin – von Demonstrieren, also etwas zeigen. Aber was? Betrachtet man die Anfänge der Intros wie dann der Demoscene, so ging es sicher immer darum zu zeigen, was man mit Computern in Echtzeit so machen kann bzw. was die eigene Entwicklercommunity so konnte. Und darum erstaunen dann auch nicht die „Identitätskriege“ wie Atari ST vs Amiga und co. Hier geht es um Messages und Unterhaltung an eine Community. Und sei es später auch einfach die DemoscenenParty-Scene.

Die Scene hat sich auch automatisch weiterentwickelt – ähnlich wie klassische Forschung – ist etwas entdeckt worden, so war dies quasi unkommentiertes Open-Source-Wissen. Denn in dieser Tech-Scene ist alles diassembliert lesbar und reproduzierbar.

Insofern scheint die Grund-Motivation am meisten hinter den Tech-Demos, klar zu sein: Sie zeigen, was möglich ist, je verrückter desto besser und hat das ganze noch Stil ok. Das wird auch genommen. Es geht ja immer um den Zusammenhang von Code und Resultat. In meinem Fall wären das Size-Coding. Hier steht die Mächtigkeit von Code im Vordergrund.

Allerdings und hier liegt vermutlich ein digitaler Hund begraben überwog vermutlich immer das Technische dahinter ohne, das Technische allerdings in den Demos wirklich zu thematisieren. Code scheint weiterhin ein Tabuthema zu sein in der Scene. Code scheint etwas für die Vieraugengespräche, für die Workshops aber eher selten fürs Alle. Mal abgesehen von den direkten LifeCode-Sessions/Battles. Man glaubt anscheinend nicht so recht an die Macht der Codes beim Machen, an einem interessanten Code-Designprozess.

Was aber tut man jenseits davon. Demos für die Parties – lustig witzige Dinge. Was soll man für Demos machen? Was ist die Motivation? Das bleibt weitgehend unklar. Was soll ich demonstrieren wollen, dass ich soviel wie möglich mit Code machen kann? Prozedural? Ohne Content nur mit Code? Ist das nicht wieder der klassische Ansatz?

Oder geht es ums Erzählen? Etwas Politisches?

Im vorliegenden Fall wurde nun ein Thema gefunden mit einer Message: Eine OldSchool-Demo (Forschungsfrage: Wie funktionieren die?) zum „Wunder“ der Schweizer Homebrew Digitalisierung & Thematisierung der verschiedenen Unterhaltungsspiele: Von Cracker, Virenproduzenten, DemoDevs bis zu GameDevs. Quasi ein Dankeschön.

Gamedesign vs. Demodesign und seine Eigenheiten

Erste Erkenntnisse bei der Umsetzung

Im Gamedesign gibt es einen Rahmen: Titlescreen, Menu.Viel Code rund um diese kulturell entstandene interkative Rahmenhandlung. Viel Aufwand für keinen Effekt bzw. wenig Ertrag, der aber auch gestaltet zum Rest passen muss. Dies entfällt bei der Demo (ausser es ist eine Megademo) dennoch. Im Gamedesign muss sehr schnell eine Verallgemeinerung gesucht werden (1 Avatar viele NPCs, ein Playfield). Es gibt viele Bedienungen, Zustände und auch meist mehrere verschiedene Techniken, die im selben Spiel zum Einsatz kommen: Sprites vs Hintergrund und das muss alles aneinander vorbei gemanged werden. Der interkative Spielspass (und damit viel Testing) steht im Vordergrund.

Die Demos hingegen sind meist getrieben von dem, was ich sehe. Es gibt keine gefährlichen Ausfälle, die nicht aus dem Code kommen, weil die Interaktion mehrheitlich fehlt. Der Code ist meist einem oder zwei Dingen zugewendet, aber diese beiden beeinflussen sich nicht mehrheitlich. Sind also meist trennbar machbar – ausser natürlich es geht um Rechenzeit etc. dann kann nur eine erhöhte Integration helfen.

Der Designprozess scheint beim Demodesign offener zu sein, da gar nicht klar ist, was der Nutzer*/Betrachter* erwarten kann. Es kann immer so gedreht werden, dass es halt das ist und nicht mehr. Die Ansprüche scheinen grundsätzlich anders. Es geht – so zumindest der Eindruck – mehr um die eigene Credibility, was man da „macht“. Der „Spass“ an einer Demo ist auch nicht in Spielspass messbar, er ist eher ähnlich zu werten wie ein eben Echtzeitfilm. Sein Aufwand, seine Effekte.

Und was ihn mit dem klassischen Film verbindet, es ist absolut planbar im Gegensatz zum Game. Diese totale Kontrolle macht es aber auch geradezu unheimlich. Denn der Coder* ist damit auch für alles verantwortlich. Es gibt keine Ausreden wie „Ja der Spieler“. Das unabhänige Entertainment-Produkt läuft einfach ab – in Echtzeit.

Hier feiert sich letztlich der Entkörperte Algorithmus, die Power von Computern. Wobei immer gesagt werden muss: Es geht nicht um den Code. Höchstens im Fall von SizeCoding wie 512b, 1k oder 4k etc. wird klarer, worin die Restriktionen beginnen und kann gestaunt werden.

Im Prozess ist es aber auch befreiend, weil alles, was ist, ist auch an der Oberfläche. Es kann uninteraktiv betrachtet werden ohne Aufwändiges interaktives Testing. Es braucht wenig Code (wenige ifs, die man Testen muss), eher wenig Verwaltung, eher einfache Datenstrukturen. Im grossen und Ganzen und dies muss noch genauer untersucht werden, sind die Projekte deshalb auch deutlich kleiner. Dadurch sinkt auch die Bereitschaft, wieder einmal eine Demo anzufangen, während ein Spiel „anzufangen“ immer ein mühsamer Schritt ist, denn es wartet so viel, was funktionieren muss. Das Scheitern ist dabei eher weniger nett, das zu erstellende Gebilde riesig.Anders sind viele Demos sie sind eher wie kleinere Experimente, schnell angefangen, vielleicht schnell fertig.

Eine erste Annäherung im Machen. Gedacht ganz ohne die abschliessende und bewertende DemosceneParty.

// ToDo: Angefangene Spiele vs. angefangene Demos