Scritchy Scratchy skalieren: ein Unity-Projekt, vier Plattformen

Scritchy Scratchy baute seine gesamte Identität rund um eine haptische Rubbel-Mechanik auf, die sich fast perfekt auf einen Finger übertragen lässt, der über Glas gleitet. Diese Designentscheidung zahlte sich auf Mobilgeräten schnell aus: Die Touch-Eingabe funktionierte praktisch out of the box, und das Rubbeln fühlte sich fast ohne Nachbearbeitung richtig an. Die eigentliche Bewährungsprobe begann, als das Team von Lunch Money Games und Funday Games beschloss, das Spiel für PC, Smartphones, Tablets sowie für aktuelle und kommende Nintendo-Hardware zu veröffentlichen – alles aus einer einzigen gemeinsamen Grundlage.

Die größte Reibungsquelle war ausgerechnet das, was das Spiel so befriedigend machte: die Eingabe. Das Spiel war für Maus und Touch konzipiert, sodass das Team von Grund auf entscheiden musste, wie sich das Rubbeln auf einem Gamepad anfühlen soll, statt einfach einen Cursor eins zu eins zu übertragen. In einem Workshop zerlegten sie die Interaktion bis ins Detail und bauten sie als Grundgerüst für andere Plattformen neu auf – die Eingabe „rastet“ in Richtung des Ticketbereichs ein, sobald ein Spieler zu rubbeln beginnt. Für die Nintendo Switch 2 stützten sie sich zusätzlich auf die Maus-Fähigkeit der Hardware selbst, und auf Mobilgeräten fügten sie haptisches Feedback hinzu – was deutlich nachjustiert werden musste, insbesondere auf Android, wo manche Geräte viel zu stark vibrierten.

Statt für jede Plattform einen eigenen Branch zu pflegen, entschied sich das Team für ein einziges Unity-Projekt und eine einzige Codebasis. Einzelne Branches neigen dazu, auseinanderzulaufen, und jede Korrektur muss in alle Ziele gemergt werden — eine lästige Angelegenheit, wenn man vier oder mehr Plattformen unterstützt. Dieser Ansatz kostet allerdings etwas: Über den Code verstreut finden sich bedingte Kompilierung und plattformspezifische Prüfungen, aber für ein Projekt dieser Größe hielt das Team sie in vertretbaren Grenzen. Der Gewinn liegt darin, dass jede Optimierung und jede Korrektur automatisch auf alle Builds übertragen wird und ein Entwickler, der PC-Bugs behebt, direkt auf mobile Probleme umsteigen kann, ohne sich in eine separate Codebasis einarbeiten zu müssen.

Die Performance war das wichtigste technische Ziel — ein nahtloses, sich „nativ" anfühlendes Erlebnis im Bereich von 60 Bildern pro Sekunde. Einer der schwerwiegenden Engpässe waren die Kratz-Partikel, die beim Kratzen die Texturfarbe auslesen; der ursprüngliche Ansatz lief auf dem PC hervorragend, war auf Mobilgeräten aber zu schwer. Der Ersatz durch GPU-Instancing wurde zur wichtigsten Optimierung des gesamten Ports. Den gesamten Ablauf steuerte der Unity Profiler — zuerst profiliert man, findet heraus, was tatsächlich bremst, und behebt es erst dann, statt zu raten.

Auflösung und Layout rundeten die Aufgabenliste ab. Ursprünglich wurde das Spiel für einen Breitbildschirm entwickelt, und obwohl die meisten Querformat-Smartphones natürlich darauf passten, erwies sich das Seitenverhältnis des iPad als schwieriger — Anzeige und Zoom mussten angepasst werden. Das Team legte Mindestversionen für Betriebssystem und API auf Mobilgeräten fest und testete das Spiel auf schwächerer Hardware, einschließlich iPhone X und XS, um sicherzustellen, dass alles flüssig bleibt. Am Ende verkaufte sich das Spiel mit über 1,25 Millionen Exemplaren auf Steam und 250.000 auf Mobilgeräten, bei 94 % positiven Bewertungen auf Steam.