Die echte Engine ausliefern, nicht eine Nachbildung
Beweist es mehr als jede Screenshot-Galerie, wenn man einen Besucher das tatsächliche Spiel spielen lässt — dieselbe Engine, die in der App läuft?
·
Studioseiten zeigen Produkte meist als Standbilder. Ein Standbild kann kein Gefühl vorführen, und das Gefühl ist der größte Teil dessen, was ein Spiel ist. Die Alternative ist normalerweise eine Nachbildung: eine vereinfachte Browserversion, die dem Produkt nahekommt. Wir halten eine Nachbildung für das Schlechteste aus beiden Welten, weil sie teuer zu bauen ist und nicht die Sache selbst ist.
ZUPI erwies sich als der Fall, in dem keiner der Kompromisse nötig war. Seine Physik und Levelerzeugung leben in einem in sich geschlossenen Modul ohne Laufzeitabhängigkeiten von Dritten, geschrieben gegen einen schlichten Koordinatenraum von 390×600. Dieses Modul ist dieselbe Quelle der Wahrheit, die die iOS- und Android-Builds ausführen. Die Demo auf dieser Seite kommt ZUPI also nicht nahe — sie importiert die Engine von ZUPI, die Levelerzeugung, die Schwierigkeitskurve und die Drei-Sekunden-Stillstandsregel und zeichnet sie mit einem für das Web geschriebenen Renderer.
Das Experiment ist, ob diese Unterscheidung die Entwicklungsarbeit wert ist und ob sie sich verallgemeinern lässt: wie viele unserer Produkte eine echte Engine-Grenze haben, die wir so offenlegen könnten, und wie viele eine Nachbildung bräuchten, von der wir schon entschieden haben, dass wir sie nicht bauen wollen.
Beantwortet, 3. Oktober 2026, und nicht so, wie die Frage es erwartete. ZUPI hörte auf, dieser Fall zu sein: die App im App Store wurde am 30. September zu ZUPI: Pulse Shield, einem anderen Spiel, also ist das Modul, das diese Demo importierte, das des vorherigen. Die Übernahme ist nie abgedriftet — der Hash stimmte bis zum Schluss — und genau das ist der Befund. Ein Hash beantwortet, ob eine Kopie dem Repository treu ist, aus dem sie stammt. Niemand hatte gefragt, ob dieses Repository noch das Produkt ist. /try/zupi ist jetzt eine Nachbildung, gebaut aus dem öffentlichen Store-Eintrag: genau das, was dieses Experiment zu vermeiden suchte, und die ehrliche Antwort, sobald die Quelle der Wahrheit fort ist.
Was wir gelernt haben
Erkenntnisse bis jetzt.
- 01
Eine übernommene Kopie braucht ihre Quelle neu identifiziert, nicht nur neu gehasht. Der Hash beantwortet, ob die Kopie vom Repository abgedriftet ist, aus dem sie stammt. Er kann nicht beantworten, ob dieses Repository noch das Produkt ist, und das ist die Frage, die hier tatsächlich versagt hat.
- 02
Die Engine ließ sich ohne eine einzige Änderung an ihrem Quellcode übertragen. Eine klare Grenze zwischen Regeln und Darstellung, aus den eigenen Gründen der App gebaut, erwies sich als genau das, was eine Web-Demo braucht.
- 03
Determinismus zählt mehr als erwartet: Weil Levels sich aus einem Seed pro Level ableiten, erzeugen die Demo und die ausgelieferte App identische Bretter, sodass das, was ein Besucher spielt, wirklich Level 1 ist und kein Doppelgänger.
- 04
Es verallgemeinert sich nicht umsonst. Produkte, deren Logik mit einer nativen UI-Schicht verflochten ist, lassen sich so nicht offenlegen, und das macht „gibt es eine Engine-Grenze?“ zu einer Frage, die es sich lohnt, während eines Builds zu stellen und nicht danach.
In Aktion sehen
Eine Nachbildung, für diese Seite geschrieben. Sie ist nicht ZUPIs Code und behauptet das auch nicht: der Quellcode des ausgelieferten Spiels liegt nicht im Repository des Studios, also wurde sie aus dem öffentlichen App-Store-Eintrag gebaut — der Pulse Core, die Drei-Sekunden-Regel, Abwehren, die den Pulse aufladen, sechs davon je Pulse, panzerplattierte Bedrohungen, die nur der Pulse bricht, Splitter, Tracker und Guard Bands. Die Zahlen und Verhaltensweisen stammen aus diesem Eintrag und seinen Screenshots; die Level, die Schwierigkeitskurve und das Gefühl gehören dieser Seite, nicht dem Spiel. Bis zum 3. Oktober 2026 lief auf dieser Seite die Engine des vorherigen Spiels, und sie wurde als die ausgelieferte ausgegeben.