{"id":9194,"date":"2026-08-26T18:20:54","date_gmt":"2026-08-26T16:20:54","guid":{"rendered":"https:\/\/www.wegneronline.com\/blog\/?p=9194"},"modified":"2026-08-27T18:00:21","modified_gmt":"2026-08-27T16:00:21","slug":"3-d-ultra-spannend-digitale-archaeologie-in-3-d-ultra-pinball-creep-night","status":"publish","type":"post","link":"https:\/\/www.wegneronline.com\/blog\/2026\/08\/26\/3-d-ultra-spannend-digitale-archaeologie-in-3-d-ultra-pinball-creep-night\/","title":{"rendered":"3-D Ultra spannend: Digitale Arch\u00e4ologie in „3-D Ultra Pinball: Creep Night“"},"content":{"rendered":"\n
English version here!<\/a> \/ Extractor Tool<\/a> \/ Zur kompletten Infosite<\/a><\/pre>\n\n\n\n
Manchmal beginnt eine technische Untersuchung v\u00f6llig ungeplant – und enden damit, dass man nicht nur eine Engine auseinanderbaut, sondern dabei auch unbekannte Eastereggs und Cheats entdeckt.<\/p>\n\n\n\n
In meinem Fall wollte ich eigentlich nur 3-D Ultra Pinball: Creep Night<\/em> von Sierra aus dem Jahr 1996 auf einem emulierten Windows-98-Rechner wieder spielen. Das Spiel ist f\u00fcr mich seit meiner Kindheit so eines der Games, deren Abl\u00e4ufe man Jahrzehnte sp\u00e4ter erstaunlicherweise immer noch im \u201eMuscle Memory\u201c hat.<\/p>\n\n\n\n
Beim Spielen fiel mir diesmal allerdings etwas auf, \u00fcber das ich als Kind selbstverst\u00e4ndlich nie nachgedacht hatte: Trotz seines Namens ist 3-D Ultra Pinball<\/em>  kein 3D-Spiel im heutigen Sinne.<\/p>\n\n\n\n
\n
\"\"\n\t\t\t\n\t\t\t\t\n\t\t\t<\/svg>\n\t\t<\/button>
Die drei Fake-3D-Tische: „The Castle“…<\/figcaption><\/figure>\n\n\n\n
\"\"\n\t\t\t\n\t\t\t\t\n\t\t\t<\/svg>\n\t\t<\/button>
…dann „The Tower“ (wobei Labor eher passen w\u00fcrde)…<\/figcaption><\/figure>\n\n\n\n
\"\"\n\t\t\t\n\t\t\t\t\n\t\t\t<\/svg>\n\t\t<\/button>
…und dann „The Dungeon“.<\/figcaption><\/figure>\n<\/figure>\n\n\n\n
<\/p>\n\n\n\n
Die Tische sehen dreidimensional aus. Figuren, Kugeln, Rampen und Animationen ebenfalls. Aber es gibt keine in Echtzeit gerenderte polygonale 3D-Welt. Stattdessen arbeitet das von Dynamix entwickelte Spiel mit vorgerenderten 2D-Grafiken.<\/p>\n\n\n\n
Das war der Beginn einer kleinen Reise in die Innereien der Engine. \ud83d\ude0a <\/p>\n\n\n\n\n\n\n\n
\u201e3-D\u201c ohne 3D<\/h2>\n\n\n\n
Das Grundprinzip ist aus heutiger Sicht ebenso einfach wie clever: Die Spieltische wurden offenbar mit 3D-Werkzeugen gestaltet und anschlie\u00dfend als fertige Bilder gerendert. Im Spiel selbst liegt f\u00fcr jeden Tisch ein vollst\u00e4ndiger Hintergrund mit einer Aufl\u00f6sung von 640 \u00d7 480 Pixeln vor.<\/p>\n\n\n\n
Dar\u00fcber zeichnet die Engine kleinere Sprites f\u00fcr bewegliche Elemente wie Kugeln, Figuren, Bumper und Animationen.<\/p>\n\n\n\n
Vereinfacht sieht das Rendering damit ungef\u00e4hr so aus:<\/p>\n\n\n\n
Vorgerenderter 640\u00d7480-Hintergrund\n                +\n        animierte Sprites\n                +\n             Kugel\n                +\n      Flipper \/ Targets \/ Effekte\n                =\n         fertiges Spielbild\n<\/code><\/pre>\n\n\n\n
Das \u201e3-D\u201c beschreibt also vor allem die optische Gestaltung der Assets. Zur Laufzeit arbeitet das Spiel weitgehend mit 2D-Grafiken.<\/p>\n\n\n\n
F\u00fcr einen Windows-PC von 1996 war das eine ausgesprochen sinnvolle L\u00f6sung: Die aufwendige 3D-Arbeit wurde vorab erledigt, w\u00e4hrend der Rechner des Spielers nur noch vorbereitete Pixelgrafiken zeichnen musste.<\/p>\n\n\n\n
Ein Blick in RESOURCE.001<\/h2>\n\n\n\n
Auf der CD befindet sich im Spielverzeichnis unter anderem das Dateipaar:<\/p>\n\n\n\n
RESOURCE.MAP\nRESOURCE.001<\/code><\/pre>\n\n\n
\n
\"\"<\/figure>\n<\/div>\n\n\n
RESOURCE.MAP<\/code> dient dabei als Inhaltsverzeichnis. RESOURCE.001<\/code> enth\u00e4lt die eigentlichen Daten.<\/p>\n\n\n\n
In meiner Version des Spiels befinden sich darin insgesamt 854 einzelne Ressourcen:<\/p>\n\n\n\n
430 \u00d7 WAV\n275 \u00d7 BMP\n109 \u00d7 ANM\n 19 \u00d7 ITF\n  7 \u00d7 PAL\n  4 \u00d7 TBL\n  4 \u00d7 TBM\n  4 \u00d7 RES\n  2 \u00d7 PFT\n<\/code><\/pre>\n\n\n\n
Die Dateiendungen sind dabei etwas irref\u00fchrend. Eine Ressource namens GHOST0.BMP<\/code> ist beispielsweise keine normale Windows-BMP-Datei. Der Inhalt beginnt stattdessen mit einem Dynamix-eigenen Header BMP:<\/code>. \u00c4hnliches findet man bei Animationen (ANM:<\/code>) und weiteren Datenformaten.<\/p>\n\n\n\n
Die Ressourcen selbst sind in RESOURCE.001<\/code> hintereinander abgelegt. RESOURCE.MAP<\/code> enth\u00e4lt zu jedem Eintrag einen Hash und einen Offset. An diesem Offset findet man wiederum einen DOS-kompatiblen Dateinamen, die Gr\u00f6\u00dfe und anschlie\u00dfend die eigentlichen Daten.<\/p>\n\n\n\n
Was macht die \u201eLarge\u201c-Installation?<\/h2>\n\n\n\n
Auch eine kleine Frage aus dem damaligen Setup lie\u00df sich damit beantworten.<\/p>\n\n\n\n
Creep Night<\/em> bietet bei der Installation eine \u201eLarge\u201c-Variante an. Dabei wird die Datei ENGLISH\\LARGE\\OVERRIDE.DAT<\/code> auf die Festplatte kopiert. Der Installer erkl\u00e4rt, dass anschlie\u00dfend praktisch nur noch Audio von CD gelesen werden muss.<\/p>\n\n\n
\n
\"\"<\/figure>\n<\/div>\n\n\n
OVERRIDE.DAT<\/code> enth\u00e4lt Index und Ressourcendaten gemeinsam und ist damit im Wesentlichen eine lokale Variante des RESOURCE.MAP<\/code>\/RESOURCE.001<\/code>-Systems.<\/p>\n\n\n\n
W\u00e4hrend RESOURCE.001<\/code> 854 Ressourcen enth\u00e4lt, befinden sich in OVERRIDE.DAT<\/code> 817 davon. Die fehlenden 37 Dateien sind:<\/p>\n\n\n\n
SX_4000.WAV\n...\nSX_4036.WAV<\/code><\/pre>\n\n\n\n
und das sind tats\u00e4chlich ausschlie\u00dflich lange Audiodateien. Zusammen ergeben sie rund 34 Minuten Audio und etwa 90 MB Daten.<\/p>\n\n\n\n
Damit l\u00e4sst sich gut zeigen, was \u201eLarge Installation\u201c 1996 bedeutete: Fast s\u00e4mtliche Grafiken, Animationen und kurzen Sounds wandern auf die schnelle Festplatte – nur die gro\u00dfen Audio-Tracks bleiben aus Platzgr\u00fcnden auf der CD.<\/p>\n\n\n\n
GHOST0.BMP: Vier Geister in zwei Kilobyte<\/h2>\n\n\n\n
Besonders interessant wurde die Datei GHOST0.BMP<\/code>. Sie ist gerade einmal ca. 2 KB gro\u00df, enth\u00e4lt aber nicht ein, sondern vier verschiedene Sprite-Frames:<\/p>\n\n\n\n
Frame 1: 56 \u00d7 38 Pixel\nFrame 2: 56 \u00d7 64 Pixel\nFrame 3: 64 \u00d7 62 Pixel\nFrame 4: 64 \u00d7 51 Pixel<\/code><\/pre>\n\n\n\n
Jeder Frame besitzt einen kleinen Header mit Breite, H\u00f6he, einem Encoding-Byte sowie komprimierter und unkomprimierter Gr\u00f6\u00dfe.<\/p>\n\n\n\n
Beim ersten Frame sieht das beispielsweise so aus:<\/p>\n\n\n\n
38 00          Breite: 56\n26 00          H\u00f6he:   38\n83             Encoding: 0x83\n61 01 00 00    komprimierter Block: 353 Bytes\n50 08 00 00    unkomprimiert: 2128 Bytes<\/code><\/pre>\n\n\n\n
Und hier findet sich bereits ein entscheidender Hinweis:<\/p>\n\n\n\n
56 \u00d7 38 = 2128<\/code><\/pre>\n\n\n\n
Nach der Dekompression existiert also genau ein Byte pro Pixel. Die Grafiken sind klassische palettenbasierte 8-Bit-Bilder.<\/p>\n\n\n\n
Was bedeutet 0x83?<\/h2>\n\n\n\n
Genau diese Kennung war zun\u00e4chst das gro\u00dfe R\u00e4tsel. F\u00fcr das Encoding gibt es keinerlei Dokumentation, nur ein paar Hinweise im Internet von anderen Menschen, die bereits versucht haben, die Dynamix-eigene Kompression zu reverse engineeren. Aber durch Analyse der originalen PINBALL2.EXE<\/code> lie\u00df sich schlie\u00dflich der entsprechende Codepfad finden.<\/p>\n\n\n\n
Der Originalcode liest das Encoding-Byte und f\u00fchrt zun\u00e4chst sinngem\u00e4\u00df Folgendes aus:<\/p>\n\n\n\n
encoding = encoding & 0x7F<\/code><\/pre>\n\n\n\n
Aus 0x83<\/code> wird also 0x03<\/code>. Anschlie\u00dfend erfolgt ein Sprung zum Decoder f\u00fcr Kompressionstyp 3. Dieser lie\u00df sich aus dem x86-Code rekonstruieren.<\/p>\n\n\n\n
Der Dynamix-Type-3-Codec<\/h2>\n\n\n\n
Der Algorithmus ist eine kompakte Form von LZ-Kompression. Der Datenstrom enth\u00e4lt zun\u00e4chst die Anzahl der folgenden Tokens. Danach kommt ein Block aus Flag-Bits und anschlie\u00dfend die eigentlichen Tokendaten.<\/p>\n\n\n\n
F\u00fcr jedes Token gibt es zwei M\u00f6glichkeiten:<\/p>\n\n\n\n
Flag = 0\n\u2192 n\u00e4chstes Byte ist ein echter Pixelwert\n\nFlag = 1\n\u2192 kopiere bereits dekomprimierte Pixel erneut\n<\/code><\/pre>\n\n\n\n
Eine R\u00fcckreferenz ben\u00f6tigt zwei Bytes beziehungsweise 16 Bit.<\/p>\n\n\n\n
Diese teilen sich sinngem\u00e4\u00df folgenderma\u00dfen auf:<\/p>\n\n\n\n
DDDDDDDD DDLLLLLL<\/code><\/pre>\n\n\n\n
Die unteren sechs Bits kodieren die L\u00e4nge:<\/p>\n\n\n\n
length = value + 3<\/code><\/pre>\n\n\n\n
Die oberen zehn Bits kodieren den Abstand:<\/p>\n\n\n\n
distance = value + 1<\/code><\/pre>\n\n\n\n
Damit kann die Datei beispielsweise ausdr\u00fccken:<\/p>\n\n\n\n
\u201eNimm die Pixel von vor 56 Bytes\nund kopiere davon noch einmal 42 St\u00fcck.\u201c<\/code><\/pre>\n\n\n\n
Gerade bei Sprites mit gro\u00dfen gleichf\u00f6rmigen oder leeren Bereichen spart das enorm viel Platz.<\/p>\n\n\n\n
Der erste Ghost-Frame ben\u00f6tigt unkomprimiert 2.128 Bytes, sein komprimierter Datenstrom dagegen nur ungef\u00e4hr 350 Bytes.<\/p>\n\n\n\n
Mit dieser Kompression sind alle Animationen, Overlays, Buttons und so weiter in der Datei RESOURCE.001<\/code> gespeichert, eine nach dem anderen als fortlaufender Stream. Korrekt extrahiert kommt man so an alle Sprites und Grafiken des Spiels – und k\u00f6nnte so quasi ein Daumenkino aus diesen machen.<\/p>\n\n\n\n
\"\"\n\t\t\t\n\t\t\t\t\n\t\t\t<\/svg>\n\t\t<\/button>
Man kann quasi ein Daumenkino aus den extrahierten Dateien machen (mehr zum Extrahieren siehe unten)…<\/figcaption><\/figure>\n\n\n\n
Und wie funktioniert die Transparenz?<\/h2>\n\n\n\n
Hier wird es aus heutiger Sicht besonders charmant, weil man mit den Limitationen der damaligen Technik arbeiten musste. Moderne Grafik kennt Alpha-Kan\u00e4le. Ein Pixel kann beispielsweise zu 25, 50 oder 80 Prozent transparent sein und wird entsprechend mit dem Hintergrund verrechnet.<\/p>\n\n\n\n
Davon konnten die Entwickler von Creep Night<\/em> nur tr\u00e4umen.<\/p>\n\n\n\n
Nach der Dekompression besteht ein Sprite ausschlie\u00dflich aus 8-Bit-Palettenwerten. Beim ersten Frame von GHOST0.BMP<\/code> gibt es beispielsweise 2.128 Pixel. Davon besitzen 1.425 Pixel den Wert 0.<\/p>\n\n\n\n
Das Bild enth\u00e4lt damit sehr gro\u00dfe Bereiche, die quasi so aussehen:<\/p>\n\n\n\n
0 0 0 0 0 0 0\n0 0 0 X X 0 0\n0 0 X X X X 0\n0 X X X X X X\n0 0 X X X X 0\n0 0 0 X X 0 0<\/code><\/pre>\n\n\n\n
Alles deutet darauf hin, dass Palette Index 0 als Color Key behandelt wird:<\/p>\n\n\n\n
Pixel = 0\n\u2192 vorhandenen Hintergrund nicht \u00fcberschreiben\n\nPixel != 0\n\u2192 Sprite-Pixel zeichnen\n<\/code><\/pre>\n\n\n\n
Das ist keine Alpha-Transparenz. Ein Pixel ist entweder vollst\u00e4ndig sichtbar oder \u00fcberhaupt nicht vorhanden.<\/p>\n\n\n\n
Die Grafikdaten selbst sprechen sehr deutlich f\u00fcr dieses Verfahren. Die genaue Blit-Routine der Engine m\u00fcsste f\u00fcr einen endg\u00fcltigen Beweis allerdings noch vollst\u00e4ndig auf Instruktionsebene nachvollzogen werden. (Freiwillige vor!)<\/p>\n\n\n
\n
\"\"\n\t\t\t\n\t\t\t\t\n\t\t\t<\/svg>\n\t\t<\/button>
Sogar die Licht-Inserts auf dem Spielfeld (an\/aus) werden \u00fcber den eigentlichen statischen Hintergrund gelegt.<\/figcaption><\/figure>\n<\/div>\n\n\n
GHOST0, GHOST1 und GHOST2<\/h2>\n\n\n\n
Direkt hintereinander befinden sich drei interessante Ressourcen:<\/p>\n\n\n\n
GHOST0.BMP\nGHOST1.BMP\nGHOST2.BMP\n<\/code><\/pre>\n\n\n\n
Sie enthalten:<\/p>\n\n\n\n
GHOST0:  4 Frames\nGHOST1:  9 Frames\nGHOST2: 12 Frames\n<\/code><\/pre>\n\n\n\n
Insgesamt liegen dort also 25 einzelne Bilder verschiedener Geisteranimationen.<\/p>\n\n\n\n
Beim Export sieht man sehr sch\u00f6n, was hinter dem Namen \u201e3-D Ultra\u201c steckt: Die Figuren haben eindeutig den Look vorgerenderter 3D-Modelle \u2013 im Spiel selbst sind sie jedoch kleine 2D-Sprites mit palettierten Farben und Color-Key-Transparenz.<\/p>\n\n\n\n
\"\"\n\t\t\t\n\t\t\t\t\n\t\t\t<\/svg>\n\t\t<\/button><\/figure>\n\n\n\n
Das ist kein Makel, sondern ein sch\u00f6nes Beispiel daf\u00fcr, wie geschickt Entwickler Mitte der 1990er-Jahre mit den verf\u00fcgbaren Ressourcen gearbeitet haben.<\/p>\n\n\n\n
\u00dcbrigens handelt es sich bei dem Typ um den Geist, der um die T\u00fcrme des „The Castle“-Tischs schwebt. \ud83d\ude09 <\/p>\n\n\n
\n
\"\"
Der kommt auch an anderer Stelle vor, daher die unbenutzten Animationsframes oben im Sheet.<\/figcaption><\/figure>\n<\/div>\n\n\n
Der merkw\u00fcrdige \u201eWobbel\u201c \u2013 wie erzeugt die Engine r\u00e4umliche Tiefe?<\/h2>\n\n\n\n
Genau diese Frage war urspr\u00fcnglich der Ausl\u00f6ser f\u00fcr die ganze Untersuchung: An einigen Stellen f\u00e4llt auf modernen Displays ein merkw\u00fcrdiger grafischer Effekt auf. Wenn die Kugel hinter einem Objekt verschwindet, wirkt dessen Rand pl\u00f6tzlich leicht ver\u00e4ndert – fast so, als w\u00fcrde ein St\u00fcck des Hintergrundbildes nochmals dar\u00fcbergelegt, dabei aber nicht hundertprozentig deckungsgleich positioniert.<\/p>\n\n\n\n
Ein Vergleich zweier unmittelbar aufeinanderfolgender Screenshots macht den Effekt deutlich:<\/p>\n\n\n\n
\n
\"\"\n\t\t\t\n\t\t\t\t\n\t\t\t<\/svg>\n\t\t<\/button>
Screenshot 1<\/figcaption><\/figure>\n\n\n\n
\"\"\n\t\t\t\n\t\t\t\t\n\t\t\t<\/svg>\n\t\t<\/button>
Screenshot 2<\/figcaption><\/figure>\n<\/figure>\n\n\n\n
<\/p>\n\n\n\n
Screenshot 1:<\/strong> Die Kugel befindet sich nicht hinter dem Vordergrundobjekt. Passt so.<\/p>\n\n\n\n
Screenshot 2:<\/strong> Die Kugel befindet sich dahinter. Gleichzeitig erscheint an dem dar\u00fcberliegenden Objekt ein sichtbarer Saum beziehungsweise eine leichte Ver\u00e4nderung der Pixel. Bei den Screenshots am besten sichtbar, wenn man zwischen den beiden hin und her wechselt, oder wenn man es im Spiel in Bewegung sieht. <\/p>\n\n\n\n
Interessant ist dabei, dass sich zwischen beiden Bildern nicht nur die kleine Fl\u00e4che der Kugel ver\u00e4ndert. Die abweichenden Pixel erstrecken sich \u00fcber einen deutlich gr\u00f6\u00dferen, ann\u00e4hernd rechteckigen Bereich des Vordergrundobjekts.<\/p>\n\n\n\n
Das legt eine weitere Technik nahe, die bei einem rein zweidimensionalen Spiel sehr sinnvoll w\u00e4re: Occlusion Sprites beziehungsweise Vordergrund-Layer.<\/p>\n\n\n\n
Die Engine k\u00f6nnte zun\u00e4chst Tisch und Kugel zeichnen und anschlie\u00dfend \u2013 sobald sich die Kugel \u201ehinter\u201c einem Bauteil befindet \u2013 einen vorbereiteten Ausschnitt dieses Bauteils nochmals dar\u00fcberzeichnen:<\/p>\n\n\n\n
Tischhintergrund\n      \u2193\nKugel zeichnen\n      \u2193\nLiegt Kugel hinter einem Objekt?\n      \u2193\nVordergrund-\/Occlusion-Sprite\nnoch einmal dar\u00fcberzeichnen\n<\/code><\/pre>\n\n\n\n
Damit l\u00e4sst sich eine Kugel problemlos hinter Rampen, Rohren oder anderen Tischteilen verschwinden lassen, ohne dass hierf\u00fcr echte 3D-Geometrie oder ein Z-Buffer ben\u00f6tigt wird.<\/p>\n\n\n\n
Der sichtbare \u201eWobbel\u201c k\u00f6nnte dann durch die Vordergrundgrafik selbst entstehen. Bereits eine minimal andere Dithering-Struktur, eine abweichende Palette oder eine Positionierung um nur einen Pixel w\u00fcrde auf einem modernen LCD als feiner Rand auffallen.<\/p>\n\n\n\n
Das gleiche gilt auch, wenn wir uns mal das Geister-GIF von oben genauer anschauen: Achtet mal auf die Steinstruktur des Turms. Sobald der Sprite des Geistes angezeigt wird, verschieben sich die Hintergrund-Pixel ein wenig. Es scheint also, dass der Palette Index 0 (= zeichne den Hintergrund hier nochmal) nicht ganz perfekt funktioniert:<\/p>\n\n\n
\n
\"\"
Der Effekt ist am deutlichsten, wenn das GIF endet und sich wiederholt – dann wird der Hintergrund quasi „zur\u00fcckgesetzt“.<\/figcaption><\/figure>\n<\/div>\n\n\n
Auf einem CRT-Monitor der 1990er-Jahre wurden solche Unterschiede durch das analoge Signal, die Loch- beziehungsweise Streifenmaske und die allgemeine Charakteristik der Bildr\u00f6hre wesentlich st\u00e4rker optisch vermischt.<\/p>\n\n\n\n
Ein modernes Display zeigt dagegen jeden einzelnen emulierten 640\u00d7480-Pixel gnadenlos exakt.<\/p>\n\n\n\n
Fundgrube Resourcen-Datei<\/h2>\n\n\n\n
Ich liebe es ja, durch solche Dateien zu st\u00f6bern, von denen die Entwickler dachten, niemand Externes wird sie je sehen. Da findet man manchmal echt spannende \u00dcberbleibsel oder Eastereggs. (Gr\u00fc\u00dfe an The Cutting Room Floor!<\/a>)<\/p>\n\n\n\n
Ein paar spannende Dinge sind mir noch aufgefallen:<\/p>\n\n\n\n
\n
\"\"\n\t\t\t\n\t\t\t\t\n\t\t\t<\/svg>\n\t\t<\/button>
Das Sierra-Maskottchen ist inkl. aller Animationsframes vorhanden, wie im Intro zu sehen<\/figcaption><\/figure>\n\n\n\n
\"\"\n\t\t\t\n\t\t\t\t\n\t\t\t<\/svg>\n\t\t<\/button>
Bei Bedarf einfach selbst Highscores  auf dieses Bild eintragen \ud83d\ude09<\/figcaption><\/figure>\n\n\n\n
\"\"\n\t\t\t\n\t\t\t\t\n\t\t\t<\/svg>\n\t\t<\/button>
Der traurigste Bildschirm von allen \ud83d\ude41 Die Buttons sind eigene Sprites!<\/figcaption><\/figure>\n\n\n\n
\"\"\n\t\t\t\n\t\t\t\t\n\t\t\t<\/svg>\n\t\t<\/button>
Wer Zweifel hatte, dass Dynamix der Entwickler war: Das Logo befindet sich ebenfalls in der Ressourcendatei (und im Intro nat\u00fcrlich)<\/figcaption><\/figure>\n\n\n\n
\"\"\n\t\t\t\n\t\t\t\t\n\t\t\t<\/svg>\n\t\t<\/button>
Der wichtigste Sprite von allen \ud83d\ude42<\/figcaption><\/figure>\n\n\n\n
\"\"\n\t\t\t\n\t\t\t\t\n\t\t\t<\/svg>\n\t\t<\/button>
Die Einstellungen sind alle als Grafiken hinterlegt, die Kerzen (an\/aus) sind eigene Sprites.<\/figcaption><\/figure>\n\n\n\n
\"\"\n\t\t\t\n\t\t\t\t\n\t\t\t<\/svg>\n\t\t<\/button>
Irgendwo muss es ein Easteregg im Spiel geben, das die Goblins durch K\u00fche ersetzt. Hm!<\/figcaption><\/figure>\n<\/figure>\n\n\n\n
<\/p>\n\n\n\n
Das mit den K\u00fchen muss ich mir irgendwann genauer anschauen. K\u00fche sind eine merkw\u00fcrdige, aber beliebte Tradition f\u00fcr Eastereggs bei echten Flipperautomaten<\/a>, das w\u00e4re also eine sch\u00f6ne Anlehnung daran. Ich w\u00fcrde sowieso sagen, dass die Entwickler durchaus die „richtigen“ Flipperautomaten kannten, denn im Hilfe-Men\u00fc gibt es ein extra Kapitel f\u00fcr Buchtipps rund um das Flippern, mit B\u00fcchern von z.B.  Roger Sharpe<\/a> – eine sch\u00f6ne Referenz an das Hobby!<\/p>\n\n\n\n
Nun… schauen wir uns das doch mal an! \ud83d\ude0a <\/p>\n\n\n\n
Neue Cheats und Easter Eggs<\/h2>\n\n\n\n
Soweit ich wei\u00df, sind die folgenden Infos bisher undokumentiert und neu. Ein bisschen stolz bin ich ja jetzt.<\/p>\n\n\n\n
Wenn man die Highscore-Tabelle \u00f6ffnet, einfach „data“ eingeben. Einfach ins Leere tippen und man h\u00f6rt eine Stimme „Excellent!“ sagen. Das bedeutet, dass der Cheat- bzw. Debug-Modus ist nun aktiviert (die Variable DYNAMIX<\/code> ist auf 1<\/code> gesetzt worden).<\/p>\n\n\n\n
Und jetzt wird es spannend:<\/p>\n\n\n\n
Wenn man nun im Spiel „cows“ eingibt, h\u00f6rt man eine Kuh muhen. Das best\u00e4tigt, dass der Flag cow_mode<\/code> nun gesetzt ist. Wenn man das Shooter-Bonusspiel nun startet, werden alle Sprites durch K\u00fche ersetzt – manche laufen, manche rennen und eine Kuh f\u00e4hrt auf einem Quad durch’s Bild. Um dieses Bonusspiel zu starten, m\u00fcssen beim Tisch „The Castle“ alle Modi gespielt worden sein und die Kugel dann erfolgreich ins Portal geschossen werden.<\/p>\n\n\n\n
Ein weiterer hilfreicher Entwicklercode ist an der Stelle „fin“. Wenn man diesen w\u00e4hrend eines Spiels eingibt, werden alle Modi automatisch als erledigt markiert und man kann zum finalen Boss des Tisches \u00fcbergehen. Das scheint eine Abk\u00fcrzung f\u00fcr Tests der Entwickler zu sein (vermute ich mal?). Der Code funktioniert auch nur, wenn als Spielmodus „Alle Tische“ gew\u00e4hlt wird. Wenn man das Spiel nur mit explizit einem Tisch startet, ist er wirkungslos.<\/p>\n\n\n\n
Es gibt au\u00dferdem noch einen Status mcow<\/code> mit der dazu passenden Animation:<\/p>\n\n\n\n
\"\"\n\t\t\t\n\t\t\t\t\n\t\t\t<\/svg>\n\t\t<\/button><\/figure>\n\n\n\n
Ich konnte bislang aber nicht herausfinden, wie man dieses Easteregg triggert. Klar ist nur anhand des Codes, dass die K\u00fche in allen drei Tischen die Goblins im jeweiligen Modus ersetzen w\u00fcrden: Anstatt die Golbins \u00fcber sieben verschiedene Positionen zu verfolgen und mittels Flipperkugel platt zu machen, w\u00fcrde die Kuh anscheinend auf der Position im Kreis laufen. Es scheint aber, als w\u00e4re der dazugeh\u00f6rige Trigger nie eingebaut worden. Schade.<\/p>\n\n\n\n
Also habe ich einfach ein kleines Patch-Tool geschrieben, welche die Flag cow_mode<\/code> einfach auf auf dieses Easter Egg anwendet. Einfach herunterladen, PINBALL2.EXE<\/code> patchen und ausprobieren (bei den Highscores „DATA“ eingeben und im Spiel „COWS“ eingeben). Mehr Infos in der README.MD<\/code>.<\/p>\n\n\n\n
\n
Download MCOW Patch Tool (6KB, ZIP)<\/a><\/div>\n<\/div>\n\n\n\n
Und so sieht das dann aus <\/a>– ziemlich cool, finde ich! \ud83d\ude0a <\/p>\n\n\n\n
Es gibt \u00fcbrigens noch ein undokumentiertes Extra: Die Boss-Taste „U“. Wenn auf der Tastatur im Spiel „U“ gedr\u00fcckt wird, minimiert sich das Fenster und bekommt den Titel „New Text Document“ in der Taskleiste. <\/p>\n\n\n
\n
\"\"\n\t\t\t\n\t\t\t\t\n\t\t\t<\/svg>\n\t\t<\/button><\/figure>\n<\/div>\n\n\n
Solche Boss-Tasten waren ziemlich popul\u00e4r in den 90ern, als man Spiele oft noch auf den Arbeitsrechnern zocken konnte. <\/p>\n\n\n
\n
\"\"<\/figure>\n<\/div>\n\n\n
Creep Night Resource Tool<\/h2>\n\n\n\n
Aus der Untersuchung ist ein kleines Python-Tool entstanden, das die Ressourcen selbst\u00e4ndig lesen und die Dynamix-Bitmapdateien dekodieren kann.<\/p>\n\n\n\n
Es kann unter anderem:<\/p>\n\n\n\n