SizeCoding ist der Versuch Dinge in so wenig Code bzw. compilierten Code wie möglich zu bringen. Damit folgt die Methode auch dem menschlichen Bestreben „Viel in Wenig“ zu verpacken, und es trotzdem noch kontrollierbar zu halten. Also kleines Modell grosse Aussagekraft. Aber auch die Wissenschaft singt ihr Lied von möglichst einfachen Formeln mit viel Mächtigkeit damit. Zusätzlich ist das Ganze heute auch noch eine Nachhaltigkeitsfrage – etwa in der Diskussion um BigData-AI und Lernen.

Oder anders gesagt: Es geht um Macht und Kontrolle. Je weniger Zeichen gebraucht werden, umso magischer/mächtiger ist der „Code“. Hier wird natürlich auch der Maschine und dem entkörperten „Selbstläufigen“ gehuldigt. Darum natürlich auch die Verbindung zur Demoscene und ihrer Entstehung als Intro Crack Demos.

Früher war SizeCoding natürlich auch ein Muss im GameDesign. Wieviel „Game“ bringt man in ein 8K-Modul etc. Heute ist es eher obsolet, SizeCoding zu betreiben – denn meist kommt die Lesbarkeit und damit die Wartbarkeit zu kurz.

Sizecoding-Methode

Aber SizeCoding ist auch eine Erkenntnis- und damit Wissenschaftsmethode.

Warum? Weil SizeCoding in der Realisierung iterativ immer wieder Fragen stellt, die beantwortet werden müssen auf der Suche zum kleinstmöglichen Programm für ein Spiel/Software/Aufgabenstellung. Und das führt automatisch – mit Schweiss – zu Erkenntnissen auch über die einzelnen Games.

Zum kleinstmöglichen Programm/Game kommt man über folgende Fragestellungen:

1. Frage der Spielmechanik: Kernmechanik?
   Was ist das Spiel, was ist der Kern? Was ist das Minimalste? Was muss als Minimalstes implementiert werden? Anders gefragt: Was macht Spiel X zum Spiel X?
2. Welche Implementation?
   Wie wird das Spiel implementiert? Die Implementation eines Games kann verschieden sein. Es gibt also verschiedenste Ansätze ein Spiel zu realisieren.
3. Kleinstmögliche Implementation?
   Die nächste Frage ist, wie gross sind die Implementationen? Was lässt sich wegsparen, was nicht? Muss man bei 2 weiter und das Ganze ganz anders lösen?

Alle 3 Fragen sind ineinander verwoben und lassen sich damit nicht einfach so trennen. Und der Vorteil eines Konzeptes ist meist auch gleichzeitig sein Nachteil.

Approaches

Es gibt mindestens 2 Approaches für SizeCoding:
Im TopDown-Approach gibt es ein bestehendes Problem A. Diese möchte in so wenig Zeichen wie möglich gelöst werden.
Im zweiten Approach Bottom-Up. geht es darum mit den Möglichkeiten möglichst viel zu machen.

Das Motivationsdesign ist bei beiden im ersten Moment verschieden. Es lässt sich aber feststellen, dass Motivationsdesign im ersten Top-Down-Approach auch vorkommt, gerade wenn noch Zeichen übrig sind oder Zeichen gespart werden konnten.

Oft wechseln Coder* auch von A nach B, wenn es bei A nicht geklappt hat und nutzen ihr Wissen dann in die entgegengesetzte Richtung. Oder es wird ein oszillierende Methode angewendet – vermutlich oft in der Demoscene beobachtbar: TopDown und dann wieder BottomUp und dann wieder TopDown etc.

Hier soll das Phänomen des Top-Down-Approaches genauer betrachtet werden, weil hier am Meisten (?) gelernt werden kann über die existierenden Spiele. Selbstverständlich ergeben sich auch aus dem Bottom-Up-Verfahren Erkenntnisse. Aber es handelt sich dort eher um einen XYZ Ansatz.

Approach: Top-Down – Zielgame vorhanden

Gibt es etwas, was erreicht werden soll, wie etwa ein Tetris oder ein Breakout wieder zu erschaffen. Dann wird meist versucht, es mit dem klassischen/üblichen Ansatz das Spiel zu programmieren.

Der erste Ansatz ist damit meistens der Ansatz in der Genese des Spiels, also quasi die Standardimplementation. Nach der Implementation wird dann versucht, den Code schlanker zu machen. Dinge zu integrieren: Wie etwa Schleifen mehrfach zu benutzen, weniger Variabeln zu verwenden etc.

Scheitert diese Implementation trotudem – weil das ganze nicht implementierbar ist und die Optimierung hoffnungslos: Der Code ist etwa das 4fache der möglichen Menge (etwas bei einem Nanogame für 256 Bytes) dann gibt es nichts anderes als ein neues Konzept zu finden. Und es nochmals zu versuchen.

Dabei können dann ganz abstruse Implementationen entstehen, die wirklich kleiner sind nun Eigenarten etwa von Umgebungen nutzen.

Erkenntnisgewinne

Je länger Sizecoding als Erkenntnismethode angewandt wird, umso klarer schält sich das minimalste Konzept eines Spiels heraus – gerade weil hier immer mehr weggenommen werden muss bis nur noch das Kernkonzept spielbar ist. Und immer wird auch etwas weggenommen, was das Spiel ‚zerstört‘ und es zu etwas anderem macht. Es ist also eine Art Bonsai-Game (Auch wenn der Vergleich massiv hinkt). Vielleicht könnte man sogar dann von der Idee des Games sprechen.

Die angewandte Auseinandersetzung verschiebt auch schnell den Fokus auf die technische Bedingtheit von Spielkonzepten. Was ist minimal nötig, wieviel Code braucht es, um das umzusetzen oder jenes. Wenn X entfernt wird, was fehlt dann – auch im Motivationsdesign. Sizecoding zwingt deswegen auch Spiele nochmals anders anzusehen: Um was geht es da eigentlich?

Im ganzen Prozess dieser angewandten Forschung entsteht natürlich auch Knowhow direkt beim angewandt Forschenden*, die danach wiederum eingebracht werden in klassische Entwicklungsprozesse von Games.

Oft wird Sizecoding über Wettbewerbe ausgetragen. Dadurch entstehen viele verschiedene Ansätze, wie Spiel programmiert und realisiert werden können. Es entsteht also auch eine Art Variationswelt verschiedenster Ansätze.

Zur Frage der Kreativität in diesem Prozess siehe hier >

Case: Breakout

Hier angewandt die Diskussion am Beispiel eines Breakouts in einer FantasyConsole & Co >