Gamedesign-Sizecoding ist eigentlich ein Genre (Untergenre von Sizecoding) f\u00fcr sich: Es geht darum in m\u00f6glichst wenig Bytes m\u00f6glichst viel zu verpacken und dies war selbstverst\u00e4ndlich ein Muss in den Zeiten des 8Bit-Homecomputings. Da wurden Basics abge\u00e4ndert, dass sie in 8Kb-Cartridges passten und daf\u00fcr noch ein paar Grafik-Routinen reinpassten (Atari), da wurde in Games ROM-Code als Sound gespielt, weil der ROM-Speicher f\u00fcr den Sound fehlte und und…. Selbstverst\u00e4ndlich war Sizecoding mit m\u00f6glichst viel Effekten auch wichtig in der Crackerszene aus der sich die Demoszene entwickelte.<\/p>\n\n\n\n
Eine Ausstellung zu diesem Thema findet sich online here ><\/a><\/p>\n\n\n\n Size-Coding-Revival im Gamebereich: Nanogames<\/strong><\/p>\n\n\n\n Eigentlich ist Size-Coding nicht mehr n\u00f6tig und gerade deswegen erlebt es als Challenge \/ Metaspiel in der Demoscene ein weiteres ungeahntes Revival. Besonders interessant sind dabei Nanogames. Diese meist 256 byte grossen Games sind eine wirkliche Herausforderung. Dabei spielt auch eine Rolle, welche Programmiersprache\/Framework\/Platform verwendet werden. BASIC etwa macht es schwierig gr\u00f6ssere Projekte zu machen (zu viel Code), Assembler ist schwierig im Handling (viel Knowhow n\u00f6tig, schwieriges Debuggen) und Fantasy-Consolen helfen teilweise mit Packern weiter sind aber bei weitem nicht so kompakt wie Assembler (ein Byte kann ein Befehle sein, daf\u00fcr viele Befehle). Alles in allem ist die Challenge aber enorm. Games sind leider auch auch eine Verwaltungsaufgabe von Objekten, Inputhandling (Interaktivit\u00e4t), Darstellen – ein Haufen Loops und If-Bedingungen. Gamedesgin halt. Und damit – so zumindest die Ansicht von Gamedesignern* – noch einen Tick schwieriger als „nur“ Demos mit Effekten (auch wenn gerade geraytraced wird in wenigen Bytes.<\/p>\n\n\n\n