Dev Log

Einblicke in die Werkstatt eines Indie-Entwicklers

Anpfiff1 2.2.2: eine Halbzeitansprache, die erst zu stark war, und ein Stadion, das 530 Millisekunden pro Bild brauchte

2.2.2 bringt Stadion, Halbzeitansprache und Terminkalender. Die erste Eichung der Ansprache hätte bis zu 2,5 Tabellenpunkte je Saison verschoben und wurde verworfen, und das Stadion brauchte 530 statt 31 Millisekunden je Bild.

Weiterlesen →

27. September bis 12. Oktober 2026:

Anpfiff1 2.2.2 liegt seit dem 12. Oktober bei Google Play, auf Steam und bei itch.io, der App Store folgt nach der Prüfung durch Apple. Anders als 2.2.1 hat diese Version Funktionen, mit denen man werben kann: ein neues Stadion, eine Halbzeitansprache und einen Terminkalender. In den zwei Wochen dazwischen sind rund 160 Commits entstanden. Hier steht, was sich messen ließ und was wir danach geändert haben.

Die Halbzeitansprache war zu stark

Die Idee kommt aus der WM Edition: In der Pause sagt man der Mannschaft etwas, und die zweite Halbzeit läuft anders. Bevor die Oberfläche gebaut wurde, kam die Messung. Eine Sonde spielte je Stufe 2000 Spiele zwischen gleich starken Bundesliga-Paarungen mit gleicher Zufallssaat und verglich nur das Team mit Ansprache.

Die erste Eichung (Moral plus Teamstärke mit 15 und 5 Punkten) ergab:

  • beste Ansprache: +2,50 Tabellenpunkte je 34 Spiele
  • schlechteste Ansprache: −1,84 Punkte je 34 Spiele

Das war das Ziel von zwei bis drei Punkten, auf dem Papier. Im Spiel hätte jede getroffene Ansprache eine Saison verschieben können. Die Moral allein war dagegen zu schwach: +0,27 Punkte je Saison bei bester Ansprache, im Bereich des Messrauschens von etwa ±0,2.

Die Eichung wurde am 8. Oktober ersetzt. Mit den endgültigen Werten (Teamstärke 1,5 und 0,5, Moral bis 10) sieht die Messung mit je 1000 Spielen je Stufe so aus:

  • Moral 5, beste Ansprache: +0,27 Punkte je 34 Spiele
  • Moral 5, schlechteste Ansprache: −1,05 Punkte je 34 Spiele
  • Moral 8, schlechteste Ansprache: −0,41, beste: +0,48

Das Rauschen liegt bei etwa ±0,3 je Saison. Die Ansprache ist also kein Hebel, der eine Meisterschaft entscheidet, aber eine falsche kostet spürbar mehr, als eine richtige bringt. Das ist gewollt: Wer nichts sagt, bekommt genau null, und ohne Ansprache ist das Spiel bitgleich zum alten Stand, geprüft an 160 Spielen.

Der Terminkalender und der falsche Haken

Die WM Edition kennt Tage, viele davon spielfrei. Anpfiff1 kennt Wochen, fast jede mit eigenem Spiel. Darum gibt es einen Termin je Woche, 36 zur Auswahl in sechs Gruppen zu je sechs. Kondition und Frische wirken nur halb so stark wie in der WM Edition, die Form nur bis zum bestehenden Deckel, Verluste ohne Deckel.

Gebucht wird nicht in der Wochenkette, wie zuerst gebaut, sondern in advance_week. Der Grund war ein Zeitfehler: Die Jugendkette läuft in einer Pausenwoche erst nach dem Weiterschalten, in einer Ligawoche davor. Ein Termin hätte je Wochenart zu anderer Zeit gewirkt. advance_week ist die eine Stelle, an der jede Woche genau einmal vergeht.

Damit nicht immer derselbe Termin gewinnt, nutzt er sich ab: Im Fenster von 8 Wochen kostet jede Wiederholung 0,35 der Wirkung, bei Terminen derselben Gruppe sind es 0,08 in 6 Wochen. Nie weniger als ein Viertel, und nur Gewinne klingen ab, Kosten nicht. Ein Wächter mit 39 Prüfungen sichert das, und eine davon fand beim Mutationstest eine Kommazahlen-Falle in der Liste der Winterpausen.

Das Stadion: 530 auf 31 Millisekunden

Aus acht Tribünen wurden 98 Blöcke plus ein fester Innenring aus 14 Blöcken, zusammen 150.000 Plätze im Ausbau. Die Summen je Typ bleiben beim Umrechnen alter Stadien bis 120.000 Plätze exakt erhalten.

Das Stadion lebt: Fans kommen zu Fuß, mit Rad und mit Kinderwagen, die Sprenger laufen über den Rasen. Das war zuerst zu teuer:

  • Figuren als Zeichenaufrufe: 585 je Bild, danach als gebackene Texturen 195
  • Figuren als Knoten, einmal gezeichnet und nur noch bewegt: 31 statt 530 Millisekunden je Bild

Ein Stadion, das beim Betrachten ruckelt, wäre auf einem schwachen Handy unbrauchbar gewesen.

Interviews mit Ergebnis

Ein Spieler meldete, dass das Interview nach dem Spiel das Ergebnis gar nicht zeigt. Jetzt steht vorher eine Ergebnistafel mit Wappen, Endstand, Torschützen und Karten. Fragen zum Spielverlauf kommen nur noch, wenn es den Ehrentreffer oder das Comeback wirklich gab. Dazu kamen 102 neue Ereignisse und 105 Korrekturen aus einem Prüfdurchgang.

Was nicht belegt ist

  • Die Halbzeitansprache wurde nur im Textmodus gemessen, im Sofortmodus gibt es keine Halbzeit.
  • Die Messwerte stammen aus Bundesliga-Paarungen, in anderen Ligen kann es abweichen.
Ein Hebel, den man nicht gemessen hat, ist eine Vermutung mit Knopf.

Vault Pure 24: Entsperren fünfmal schneller, und was die Zahl 600.000 damit zu tun hatte

Ein Nutzer fand die App seit einem Update zäh. Die Ursache war eine Rundenzahl, die wir in Version 20 erhöht hatten, ohne sie auf einem schwachen Handy zu messen. Was wir geändert haben, was es kostet, und was wir noch nicht belegen können.

Weiterlesen →

12. Oktober 2026:

Nach Version 23 meldete ein Nutzer aus Japan, die App sei „seit einem Update“ schwerfällig, vor allem bei der ersten Passworteingabe und beim Wischen durch Fotos. Ein Teil davon war hausgemacht, und der Fehler lag bei uns.

Die Ursache: eine Zahl, die nie gemessen wurde

In Version 20 haben wir die Rundenzahl der Passwort-Ableitung (PBKDF2) von 210.000 auf 600.000 erhöht. Die Zahl steht in den OWASP-Empfehlungen, sie gilt aber für Server. Im Code stand sogar der Hinweis, vor dem Release auf einem schwachen Gerät zu messen. Das ist nicht passiert.

Gemessen auf einem Moto E20 (ein bewusst schwaches Handy, Firebase Test Lab): 8,1 Sekunden für eine Ableitung mit 600.000 Runden. Betroffen waren neu angelegte Tresore und alte Tresore, die beim ersten Entsperren in das neue Format umgeschrieben wurden.

Was wir geändert haben

  • Schnellere Ableitung, gleiches Ergebnis: Eine eigene PBKDF2/SHA-256 ersetzt den Provider-Aufruf. Auf demselben Handy sind es 1,5 Sekunden statt 8,1, byte-identisch zum bisherigen Ergebnis (per Unit- und Gerätetest belegt, auch mit Umlauten und Emoji). Ein erster Versuch über die native HMAC-Schnittstelle war übrigens nicht schneller (9,6 Sekunden): Die Zeit ging in den Aufruf pro Runde, nicht in SHA-256.
  • Rundenzahl für neue Tresore wieder 210.000. Tresore aus den Builds 20 bis 23 behalten ihre gespeicherten 600.000, laufen mit der neuen Ableitung aber ebenfalls deutlich schneller.
  • Ehrlich dazu: 210.000 Runden bedeuten, dass jemand, der die Tresor-Datei in die Hände bekommt, Passwörter etwa 2,9-mal schneller durchprobieren kann als bei 600.000. Das schützt vor allem ein langes Passwort besser als jede Rundenzahl.
  • Ruhigere Animationen: Der Baum im Login und der Zweig in der Übersicht wurden bei jedem Bild komplett neu berechnet, mit Hunderten Blättern. Jetzt werden sie einmal im Hintergrund gezeichnet und schwingen nur noch als Ganzes. Im Energiesparmodus stehen sie still. Nebenbei: Die Zeitbasis lief mit Sekunden seit dem Neustart, und bei Handys mit mehreren Tagen Laufzeit ruckelte die Bewegung deshalb sichtbar.
  • Foto-Entschlüsselung: Ein Lesepuffer vor der Entschlüsselung. Auf dem Emulator bringt das etwa 15 bis 25 Prozent.

Wie wir es geprüft haben

Unit-Tests, die komplette Instrumented-Suite auf dem Moto E20 und auf einem virtuellen Gerät, und die Tests noch einmal gegen einen mit R8 verkleinerten Build, nachdem uns R8 in Version 19 schon einmal Daten verändert hatte. Das Entsperren bis zur Übersicht dauert auf dem Moto E20 danach 2,2 Sekunden.

Was wir nicht belegt haben

Das Wischen durch Fotos haben wir auf einem echten Gerät nicht gemessen. Der Lesepuffer ist plausibel, aber ob sich das Wischen spürbar bessert, wissen wir nicht. Wenn es weiter zäh bleibt, ist das der nächste Punkt.

Werkbank neu sortiert: zwei neue Projekte, zwei pausiert, und warum die letzten zehn Prozent so lang sind

In sieben Wochen entstanden HotBiz und Cargopolis, dazu die Rückkehr von 3D zu einer Vektorkarte. Was ruht, was zuerst fertig wird, und die Regeln für den Endspurt.

Weiterlesen →

22. August bis 11. Oktober 2026:

In sieben Wochen sind mehr Ideen zu Spielen geworden, als ein Ein-Personen-Studio fertig bekommt. Dieser Eintrag sortiert sie: was neu auf der Werkbank liegt, was ruht und was sich auf dem Weg geändert hat.

Warum es plötzlich mehr gibt

Neben Beruf und Familie war der Plan lange: ein großes Spiel und ein paar kleine Apps. Seit dem Frühjahr hat sich verschoben, was ein einzelner Mensch in einer Woche schafft. Planung, Prüfung, Testwerkzeuge, Auswertung von Unterlagen und Bildmaterial gehen mit den heutigen KI-Werkzeugen deutlich schneller. Deshalb sind zwei große Projekte in wenigen Wochen so weit gekommen, wie sie sind.

Dasselbe ist auch das Problem. Schneller bauen heißt nicht schneller fertig werden. Die letzten zehn Prozent bestehen aus Gerätetests, Store-Einträgen und Fehlern, die man nur am Handy sieht, und dafür hilft keine Beschleunigung beim Bauen.

Neu auf der Werkbank: HotBiz

Eine rundenbasierte Speditionssimulation für Android, der Neuaufbau eines Wirtschaftsklassikers von 1998. Der erste Commit stammt vom 1. September, seitdem sind es 186.

  • Vorbild und Eigenes: Das Original liegt als lesbare Daten vor. Übernommen werden Mechanik und Zahlen, alle Bilder, Klänge, Texte und der Titel sind neu.
  • Bilder: Sie entstehen bogenweise mit einem Bildgenerator, sechs bis acht Objekte je Lauf. Danach prüft ein Skript, und gesichtet werden nur die Durchgefallenen.
  • Stand: Das Spiel ist inhaltlich vollständig und hat zwei Prüfrunden hinter sich. Offen sind die Abnahme auf dem Gerät, das Gegenlesen der englischen Texte durch einen Muttersprachler und die Anlage in der Play-Konsole.

Neu auf der Werkbank: Cargopolis

Ein Transport-Aufbauspiel für Android und das größte Projekt im Studio: 298 Commits seit dem ersten am 22. August. Die wichtigste Entscheidung fiel am 6. Oktober, und sie war ein Rückzug.

  • Vorher: 3D mit Fremdmodellen. Es waren 650 Modelle aus vier Zeichenstilen, 71 MB Material, rund 300 Zeichenaufrufe auf der Karte, und auf dem Emulator brauchte der Aufbau 24 Sekunden, bis die App neu startete.
  • Die Probe: Dieselbe Karte als isometrische Vektorgeometrie kam mit 14 Zeichenaufrufen aus, bei rund einer Millisekunde Rechenzeit. Sie sah auch besser aus.
  • Danach: Seit dem 10. Oktober gilt als Projektregel nur noch 2,5D. Auf dem Papier kostet das rund 50 Arbeitstage zusätzlich (Schätzung, plus/minus 30 Prozent), spart aber Beschaffung, Lizenzen und Blender-Arbeit. Selbst der Luftverkehr wurde am 11. Oktober von Blender-Modellen auf Vektorformen umgestellt.

Cargopolis ist noch nicht auf einem echten Gerät gemessen. Bis das geschehen ist, gibt es keinen Termin.

Was ruht

Indy 500 Reloaded hat 20 Commits, der letzte stammt vom 5. September. Bei Sky Baron liegt die letzte Änderung am 23. Juli. Beide sind pausiert und nicht gestrichen. Imperium1 läuft nebenbei weiter, ohne Zeitplan. Wer die Seiten dazu sucht: Sie sind weiter da, nur nicht mehr auf der Werkbank.

Was zuerst fertig wird

Reihenfolge ist die Anpfiff1 WM Edition, danach Smiley Battle.

  • WM Edition (95 Prozent): 633 Commits seit dem 13. Mai, rund 150.000 Zeilen Spielcode, die Testsuite ist grün. Es fehlt kein Spielinhalt mehr, es fehlt der Gerätetest. Die Durchsicht am 23. September fand zwei Fehler, die am Rechner nie auffielen: Die Zurück-Taste beendete das Spiel ohne Nachfrage, und der Stromsparmodus fehlte.
  • Smiley Battle (85 Prozent): Die Vorregistrierung läuft, am 6. Oktober kam ein Spielroboter, der alle Szenen durchläuft, und mit ihm eine Reihe behobener Befunde.

Die Regeln für die letzten zehn Prozent

  • Höchstens zwei Projekte gleichzeitig: eines im Endspurt, eines zum Bauen.
  • Feature-Freeze ab dem Endspurt. Neues bekommt eine eigene Versionsnummer.
  • Gerät vor Politur. Ein Nachmittag mit zwei Telefonen bringt mehr als drei Wochen Feinschliff am Rechner.
  • Fertig heißt im Store, nicht perfekt.

Die Werkbank zeigt jetzt den Stand

Jedes Stück hat einen Balken und das Datum der letzten Arbeit. Die Prozentwerte sind Schätzungen. Das Datum ist ein Git-Eintrag und lässt sich nicht schönen: Wer seit September nichts mehr gehört hat, sieht es dort.

Recorder Pur 1.0: ein Diktiergerät, das Text auf dem Handy erkennt

Von der Umbenennung eines Forks bis Version 20 in sechs Tagen. Warum das Sprachmodell nicht im App-Paket steckt, die Erkennung in einem eigenen Prozess läuft, was wieder rausflog und warum Türkisch fehlt.

Weiterlesen →

5. bis 10. Oktober 2026:

Recorder Pur ist das erste Diktiergerät aus der Werkstatt. Es entstand als Fork von Fossify Voice Recorder (GPL-3.0) und ist in sechs Tagen von der Umbenennung bis zu Version 20 gewachsen. Diese Fassung kommt jetzt in die Produktion.

Ein Name, der das Versprechen trägt

Im Play-Titel darf nicht "ohne Werbung" stehen. Also trägt "Pur" das Versprechen: Diktiergerät & Recorder Pur, auf Englisch Voice & Audio Recorder Pure. Das Symbol ist ein Wachssiegel, der Aufnahmeknopf ebenfalls.

Sprache zu Text, ohne dass etwas das Gerät verlässt

Pro wandelt Aufnahmen direkt auf dem Handy in Text um. Dahinter arbeiten sherpa-onnx, ein Stimmerkenner (Silero VAD) und das Modell NVIDIA Parakeet TDT 0.6B v3 mit 25 europäischen Sprachen. Getestet haben wir Deutsch und Englisch, mehr sagen wir nicht zu.

Drei Entscheidungen waren wichtiger als das Modell selbst:

  • Das Modell steckt nicht im App-Paket. Sonst wäre jedes Update einige hundert Megabyte groß. Die App lädt die Dateien einmal von huggingface.co, nur auf Wunsch, mit Prüfsumme und Fortsetzen nach Abbruch.
  • Die Erkennung läuft in einem eigenen Prozess. Stürzt die native Bibliothek ab, endet nur dieser Prozess, die Aufnahme bleibt heil. Alle 30 Sekunden gibt es einen Zwischenstand, danach geht es dort weiter.
  • Leise Aufnahmen werden vor der Erkennung angehoben. Sonst hört die Spracherkennung bei leisen Stimmen nichts.

Eine Aufnahme darf nicht verloren gehen

WAV schreibt die Kopfzeile alle zwei Sekunden neu. Bei einem Absturz oder leerem Akku bleibt die Datei abspielbar, beim nächsten Start wird sie repariert. Bei m4a liegt der Index am Ende der Datei, dort wäre die Aufnahme weg. Das steht deshalb ehrlich so in der Beschreibung.

Was wieder rausflog

Hinter der App fielen eine Weile Schnipsel und Fähnchen. Sie hatten mit einem Diktiergerät nichts zu tun und lenkten ab, also sind sie weg. Genauso die Farbauswahl: Farben und Aussehen sind fest, das Wachsrot gehört zur Marke.

Version 20 bringt dazu eine Startseite mit allen sechs Funktionen auf einem Bildschirm und einen Schnitt-Tab, in dem man die Auswahl vor dem Speichern anhören kann. Der Absturz beim Start unter Android 12 und älter (eine fehlende Berechtigung für den Empfänger) ist behoben.

Warum nur diese Länder

Der Store-Eintrag geht in die Märkte, in denen eine Sprache des Modells Landessprache ist, 35 Länder: den ganzen deutschsprachigen Raum, die englischsprachigen Märkte und die übrigen EU-Sprachen des Modells. Türkisch fehlt, weil das Modell es nicht kennt. Ein Diktiergerät, dessen wichtigste Funktion dort nicht arbeitet, verkaufen wir dort nicht.

Ohne Werbung, ohne Tracking, ohne Konto. Das Netz nutzt die App nur für den Pro-Kauf und den einmaligen Modell-Download.

Vault Pure 1.0.8: neues Aussehen, und ein Fehler, den R8 eingebaut hatte

Sechs Fassungen in drei Tagen, seit heute in der Produktion. Der Release-Build hatte die Schlüsselparameter jedes Tresors unter verschleierten Namen gespeichert, und das hätte alte Tresore ausgesperrt. Dazu ein neues Aussehen in Marineblau und Gold.

Weiterlesen →

8. bis 10. Oktober 2026:

Sechs Fassungen in drei Tagen: versionCode 18 bis 23, der Name blieb 1.0.8. Seit heute läuft Version 23 in der Produktion bei Google Play. Zuerst der Fehler, der am längsten im Verborgenen lag, dann alles, was man sieht.

Der Fehler: R8 hat die Schlüsselparameter umbenannt

Jeder Tresor speichert neben dem Passwort-Schlüssel ein paar Parameter als JSON: Salz, Initialisierungsvektor, Verfahren, Rundenzahl. Gson schreibt dafür die Feldnamen der Klasse. Im Release-Build verkleinert R8 den Code, nennt die Felder a und b und wirft die heraus, deren Wert es als Konstante erkennt.

Das Ergebnis: Jeder Tresor, den ein Play-Build bis versionCode 18 angelegt hat, trägt nur {"a": Salz, "b": IV}. Verfahren und Rundenzahl standen nirgends im Tresor, nur im Code.

Aufgefallen ist es, sobald eine Änderung einen dieser Werte variabel machte. Das Feld war wieder da, im gespeicherten JSON stand nichts dafür, und das Entsperren scheiterte mit einer NullPointerException. Schlimmer noch: Die höhere Rundenzahl für neue Tresore hätte auch alte getroffen, die dann mit dem falschen Schlüssel geöffnet werden sollten.

Die Lösung hat drei Teile:

  • Ein eigener Adapter schreibt die Parameter mit festen, echten Namen. Wie R8 den Code verschleiert, spielt für das gespeicherte Format keine Rolle mehr.
  • Beim Lesen versteht er auch die alte a/b-Form und ergänzt, was die alten Builds fest eingebaut hatten: 210.000 Runden.
  • Keep-Regeln halten R8 von diesen Klassen fern. Das gilt auch für Backups, die dieselben Parameter tragen.

Tests lesen genau das alte Format ein. Ein Tresor aus einer früheren Fassung geht nach dem Update wieder auf.

Ein stärkeres Passwort-Verfahren

Neue Tresore leiten den Schlüssel mit 600.000 statt 210.000 PBKDF2-Runden ab. Auf älteren Handys kann das Entsperren mit Passwort deshalb ein paar Sekunden dauern, die App sagt das jetzt vorher. Auch die Sperre nach Fehlversuchen ist strenger geworden.

Das Aussehen

  • Version 18: Marineblau und Gold, vom App-Symbol abgeleitet. Im Hintergrund ein Schloss, in dem Fotos, Dokumente und Siegel treiben. Die App ist nur noch dunkel, die Einstellung für das Design ist weg.
  • Version 19 und 20: Die Übersicht bekommt Abschnitte, dann kleine Kacheln und eine untere Leiste. Einstellungen sind aufgeteilt: Alltägliches vorn, Schutz und Sperre unter „App-Einstellungen“.
  • Version 21: Goldene Kopfleisten mit App-Symbol, ein Orangenzweig als ruhiger Hintergrund und ein Augen-Knopf, der Vorschaubilder ausblendet.
  • Version 22: Im Login wächst ein Baum statt der alten Tresor-Animation. Das Zahnrad für die Einstellungen sitzt in jeder Leiste, „Schutz“ heißt „Verwalten“, der Tarn-Tresor ist in Karten gegliedert.
  • Version 23: Der Baum ist neu gezeichnet, mit einer Krone aus vielen kleinen Blättern und goldenen Früchten.

Für genau einen Build hieß die App übrigens „Tresor Pur“. Sie heißt wieder überall Vault Pure.

Wie die Store-Bilder entstehen sollen

Die Bilder im Store sollen aus der echten App kommen. Ein Test läuft dafür auf einem virtuellen Gerät bei Firebase Test Lab durch die Bildschirme und macht die Aufnahmen. Eine Hürde: Die App setzt FLAG_SECURE, normale Aufnahmen sind deshalb schwarz. Der Test schaltet vorher die App-eigene Einstellung „Bildschirmfotos erlauben“ ein.

Gemessen

  • Versionen: 6 in 3 Tagen
  • Rundenzahl neuer Tresore: 210.000 vorher, 600.000 jetzt
  • Release-Notizen: in 24 Sprachen geschrieben
Ein Tresor, der sich nach einem Update nicht mehr öffnen lässt, ist kein Tresor.

Anpfiff1 sieht jetzt aus wie das Spiel: das neue Design der Startseite

Weg mit Neongrün und Farbverlauf. Die Farben des neuen Designs sind aus den Store-Bildern gemessen, die Schrift ist die Spielschrift, und die Startseite wiegt 31 KB weniger. Was bleiben musste und was nicht hineinkam.

Weiterlesen →

23. bis 30. September 2026:

Die Startseite von Anpfiff1 sah aus wie hundert andere Spielseiten: dunkelblauer Grund, Neongrün mit Farbverlauf, eine riesige Pixelschrift. Mit dem Spiel hatte das nichts zu tun. Seit heute ist sie neu, auf allen drei Domains.

Wo die Gestaltung herkommt

Nicht aus einem Genre-Thema, sondern aus dem Spiel selbst. Aus den Store-Bildern wurden die Farben gemessen, statt sie zu schätzen:

  • Kopfband #1a482b mit Goldlinie #f2ce6b
  • Kommentar-Kästen #0d2614, Tafel #212529
  • Knöpfe #2e593d, Sprechblase #f8f5ea

Die Schrift ist die Spielschrift Unifont. Die Download-Liste ist wie das Hauptmenü gebaut, die Bilder sitzen in einem goldenen Fensterrahmen, und die Fragen klappen mit Plus- und Minus-Knöpfen auf, wie man sie aus dem Spiel kennt.

Was nicht hineinkam

Das Büro-Bild mit der KI-Illustration ist nicht mehr das erste Bild der Seite. Es zeigt nicht das Spiel, sondern einen Hintergrund. Der Hero zeigt jetzt den Live-Spielbildschirm mit dem Textkommentar. Auch die Leuchteffekte um Knöpfe und Karten sind weg.

Was gleich blieb

Ein Redesign darf nichts verlieren, was die Seite trägt. Deshalb sind Seitenleiste, Sprachumschalter, Bewertungen an den Knöpfen (20 von 25 auf Steam, 4,3 von 5 bei Google Play) und der Cookie-Dienst erhalten, und alle Texte kommen aus derselben Übersetzungsdatei wie vorher. Die Screenshots laden je Sprache in ihrer eigenen Fassung.

Die Reihenfolge der Plattformen hat sich geändert: Google Play, App Store, Steam, itch.io, zuletzt der Browser. Die Spieler kommen über die Stores, der Browser ist der Probierweg.

Gemessen

  • Startseite (HTML): 80 KB vorher, 49 KB jetzt
  • Stylesheet: 29 KB vorher, 13 KB jetzt
  • Schrift: vorher Press Start 2P und Inter, jetzt Unifont als Teilsatz mit 7 KB

Die Schrift ist auf die Zeichen von Deutsch, Englisch und Türkisch beschnitten, damit sie nur 7 KB wiegt.

Der Weg zum Bau

Eine Vorlage erzeugt die drei Startseiten. Sie liest die Texte aus den bisherigen Seiten und schreibt Deutsch, Englisch und Türkisch jeweils vollständig ins HTML, damit auch ohne JavaScript alles da ist. Drei Dinge mussten dafür erhalten bleiben: dieselben Element-IDs, dieselben Übersetzungsschlüssel und die Sprachumschaltung im laufenden Betrieb. Den Rest der Übersetzungslogik habe ich nicht angefasst.

Was noch kommt

Die Unterseiten (Changelog, Bestenliste, Rechtstexte, WM Edition) tragen noch das alte Design. Sie folgen, sobald die Startseite sich bewährt hat.

Eine Seite, die aussieht wie das Spiel, braucht keine Erklärung, was man hier bekommt.

Anpfiff2: warum zuerst ein Gerüst gebaut wird

Anpfiff2 kann man noch nicht spielen. Was seit dem 25. September steht: eine Inventur von 222.442 Zeilen Anpfiff1, ein Gerüst mit Regeln, die sich selbst prüfen, Messwerte zum Spielstand und Nationalmannschaften als erster Test der Bauweise.

Weiterlesen →

25. bis 30. September 2026:

Vorweg das Wichtigste: Anpfiff2 kann man noch nicht spielen und noch nicht ansehen. Es gibt kein Erscheinungsdatum und keinen Store-Eintrag. Seit dem 25. September liegt ein Projekt vor, das ein Gerüst ist, mit 105 Commits in vier Tagen. Dieser Beitrag beschreibt, was darin steckt und warum zuerst das Gerüst kommt.

Was es werden soll

Anpfiff2 ist ein Fußballmanager für einen Spieler, mit Highscore wie Anpfiff1, im Querformat, für Handy und PC, mit fiktiven Namen und einem Editor. Die Richtung: Vereinsleben statt Tabelle. Ein Vereinsheim, in dem man von Raum zu Raum geht, Entscheidungen als kleine Szenen, ein Zeitbudget je Woche. Die Grafik soll eigene Pixelart sein, aus Regeln gebaut: keine Fremd-Bilder und keine KI-Grafik. Davon gibt es noch kein Bild, weil erst die Grundlage steht.

Zwei Entscheidungen prägen alles Weitere:

  • Kein Schwierigkeitsgrad. Wie leicht es ist, bestimmt der Verein, den man wählt: Kader, Budget und was der Vorstand erwartet.
  • Gleiche Regeln für alle. Die KI bekommt keine Sonderrechte und der Spieler keine Boni. Gemessen wird gegen plausible Fußballwerte statt gegen Anpfiff1.

Warum nicht bei null anfangen

Die Grundlage sind die Funktionen von Anpfiff1. Die Inventur hat alle 184 Spielskripte mit zusammen 222.442 Zeilen eingeordnet:

  • Übernehmen: 13.095 Zeilen, 6 Prozent
  • Umtopfen (die Logik bleibt, die Ränder ändern sich): 110.186 Zeilen, 50 Prozent
  • Neu, mit den Formeln aus Anpfiff1: 99.161 Zeilen, 45 Prozent

Der größte Teil der neuen Zeilen liegt in der Oberfläche: 68.045 der 99.161 Zeilen.

Ein Gerüst, das sich selbst prüft

Das Projekt hat fünf Schichten, zusammen rund 50.000 Zeilen GDScript und 57 Testdateien. Wer gegen die Regeln verstößt, bricht den Test:

  • Der Kern ist rein. Er kennt keinen Szenenbaum, wartet auf nichts und zieht keine Zufallszahl aus dem Nichts. Zufall kommt immer als übergebene Zufallsfolge, damit dieselbe Saat dieselbe Saison ergibt.
  • Module rufen einander nie direkt auf. Sie reden über typisierte Ereignisse, dreißig Arten sind es bisher, und über Regeln.
  • Jede Formel steht genau einmal. Marktwert, Form und Tabellensortierung sind keine Kopien in drei Bildschirmen.
  • Es gibt höchstens einen Autoload, und ab 1.000 Zeilen je Datei ist Schluss.
  • Ein Prüfprogramm mit über einem Dutzend Regeln läuft vor jedem Commit. Nichts gilt als fertig, solange es nicht grün ist.

Dahinter steht eine Erfahrung: Ein Fußballmanager wächst in tausend kleinen Regeln, und jede zusätzliche Regel darf keine andere still verändern.

Zahlen zum Spielstand

Gemessen mit allen 15 Ländern, 40.516 Spielern und 1.771 Vereinen am PC:

  • Speichern: 3,4 Sekunden in der ersten Fassung (JSON), jetzt 0,8
  • Laden: 5,7 Sekunden, jetzt 1,8
  • Dateigröße: 1,5 MB, jetzt 1,6 MB

Das Ziel für das Speichern beim Wechsel in den Hintergrund liegt unter einer halben Sekunde. Am PC ist es erreicht, auf einem echten Handy noch nicht nachgewiesen. Beim Laden dominiert jetzt das Anlegen der 40.000 Spielerobjekte.

Ländern im Hintergrund reicht eine kompakte Detailstufe, die etwa halb so viel Rechenzeit je Spiel braucht wie die volle.

Länderspiele als Modul

Als Test für die Bauweise kamen Nationalmannschaften dazu, ohne dass sich der Rest bewegt hat. Verein und Auswahl sind beide ein Team, und nach dem Umbau ergibt dieselbe Saat bitgleich dieselbe Saison wie vorher. Es gibt Auswahlen mit Nominierung, Länderspielfenster ohne Vereinsspiele, Qualifikation, Europa- und Weltmeisterschaft alle vier Jahre und ein Nationaltrainer-Amt nach Ruf. Vereinfacht ist manches: die WM hat 32 statt 48 Teams. Eine Oberfläche dafür gibt es noch nicht.

Was schon läuft und was nicht

Es läuft eine schlichte Oberfläche für den Durchstich: Titel, neue Karriere, Büro, Kader, Aufstellung, Spieltag mit Live-Kommentar, Tabelle, Spielplan, Finanzen. Dazu Match, Wettbewerbe, Jugend, Transfers, Wirtschaft und 80 Erfolge.

Es fehlen die Pixelart, der Ton, das Vereinsheim, ein Termin und ein Test auf dem Handy. Die Reihenfolge ist festgelegt: erst Struktur und Funktionen, bis ein Spiel von der ersten bis zur letzten Woche spielbar ist, danach Inhalt und Design.

Wer ein Spiel baut, das viele Jahre laufen soll, fängt mit den Regeln an, die man später nicht mehr ändern will.

Anpfiff1 2.2.1: drei Sekunden Stillstand weniger und eine Statistik, die stimmt

2.2.1 hat keine Funktion, mit der man werben könnte, dafür Messwerte: Das Speichern friert nicht mehr ein, nach dem Laden gingen bei 591 Vereinen Kosten verloren, und eine Optimierung wurde gemessen und verworfen.

Weiterlesen →

20. bis 27. September 2026:

Seit dem 27. September liegt Anpfiff1 2.2.1 bei Google Play, auf Steam und bei itch.io, seit dem 28. September auch im App Store. Es ist ein Optimierungs-Patch, und diesmal ohne Funktion, mit der man werben könnte. Grundlage waren zwei Prüfdurchgänge über den ganzen Code, jeder Befund wurde einzeln nachgeprüft, bevor er in die Liste kam. Fast alles davon lässt sich mit einer Zahl belegen.

Erst messen, dann anfassen

Vor der ersten Änderung lief jede der 148 Prüfszenen dreimal einzeln, das Ergebnis steht als Ausgangsstand fest: grün, rot, wackelig oder hängt. Danach gilt eine Regel für jeden Schritt: Keine Szene wird schlechter, die Liste der roten wird nur kürzer. Wer an Pokal oder Tabelle dreht, lässt die Finanzprüfungen mitlaufen.

Dazu kommt die Pflichtprobe an echten Spielständen. Kein Schritt darf einen bestehenden Stand unladbar machen.

Drei Sekunden Stillstand nach jeder Woche

Das automatische Speichern nach jeder Spielwoche hielt das Spiel am PC gut 3 Sekunden an, mit einer frischen Karriere. Auf dem Handy ist es ein Vielfaches. Jetzt schreibt ein Hintergrundprozess die Datei, ein kleiner Hinweis „Speichere…“ erscheint, und Eingaben sind so lange gesperrt, damit der Spielstand sicher zusammenpasst.

Ein Zähler sorgt dafür, dass ein schnelleres, ausdrückliches Speichern das laufende Hintergrundspeichern überholt und nicht von ihm überschrieben wird. Geprüft ist das mit einer eigenen Szene, acht von acht Fällen laufen.

Weitere Zeiten, jeweils vorher und nachher gemessen:

  • Karrierestart: die Spielerlisten laden parallel, 3,9 auf 1,9 Sekunden, mit bitgleichem Ergebnis.
  • Erstes Interview nach dem Spieltag: die Daten laden im Hintergrund vor, von 1.054 Millisekunden auf 0.
  • Schrift: Chinesisch, Japanisch und Koreanisch teilten sich bisher eine Schrift in japanischen Zeichenformen. Jede Sprache hat jetzt ihre eigene, zusammen 13 statt 19 MB.

Was gemessen und dann nicht gebaut wurde

Geplant war ein Hebel, der die Hintergrund-Simulation beschleunigt: leere Minuten überspringen. Also wurden 200 Spiele profiliert, 27,5 Millisekunden je Spiel. Die Zeit steckt woanders:

  • Chancen einschließlich der Ereignisse: 36 Prozent
  • Aufbau des Spiels: 24 Prozent
  • Prüfung der KI-Wechsel: 15 Prozent
  • Disziplin: 11 Prozent

Leere Minuten kosten dank eines vorgezogenen Zufallswurfs fast nichts mehr. Der Hebel hätte unter 5 Prozent gebracht und dafür die Zufallsfolge verschoben, also die Ergebnisse. Er ist verworfen. Genauso eine Interviewdatei je Sprache: 49 mal 0,9 MB wären 45 MB gewesen statt 11.

Eine Statistik mit einer Quelle

Die Bestandsaufnahme hatte es in sich:

  • zwei getrennte Speicher für Spielberichte, mit verschiedenen Feldnamen für dasselbe
  • fünf Stellen, die Spiel-Kennungen bauen, in zusammen rund zehn Formaten
  • rund 50 Stellen in 12 Dateien, die die Berichte direkt durchlaufen
  • rund 20 Nebenzähler, die selbst mitzählen, sechs davon nie gelesen

Daraus kamen die Fehler, die Spieler gemeldet hatten: Eigentore für den Schützen, Gelb-Rot als Rot, Einwechsler als Startelf.

Jetzt hat jedes Spiel eine Kennung, unter ihr liegt ein Bericht, und jede Statistik fragt eine einzige Auskunftsstelle. Ein Prüfwerkzeug findet direkte Zugriffe, vorher waren es 75, jetzt sind es 0. Gemessen an einer ganzen Saison aller Länder (7.867 Berichte) kostet das 4,4 MB Arbeitsspeicher und 1,4 MB im Spielstand, dafür entfallen sieben Zähler. Ein kompaktes Speicherformat war damit gar nicht nötig.

Spielstände von 2.2.0 bleiben ladbar, auch umgekehrt: Ein Stand aus der neuen Zählweise lässt sich mit der alten Version öffnen. Eine einzige Lücke fand sich, 2.2.0 greift ohne Prüfung auf die Kartenzähler zu, und ein leeres Feld warf bei jeder Karte einen Skriptfehler, 79 in vier Wochen. Deshalb schreibt der Umbau das alte Gerüst weiter mit.

Nach dem Laden weiterspielen wie vorher

Eine Zahl, die nur Änderungen meldet, sagt nichts über Fehler. Also gilt eine strengere Regel: Das Spiel muss nach dem Laden exakt so weiterlaufen wie ohne Laden. Geprüft wird mit gleicher Zufallssaat, einmal mit Laden, einmal ohne, danach müssen beide Aufnahmen gleich sein.

Gefunden hat das fünf Speicherfehler:

  • Jugend- und Medizinkosten wurden nur für den eigenen Verein gespeichert. Nach jedem Laden zahlten 591 Vereine keine Medizinkosten und 104 keine Jugendkosten mehr, mit mehr Geld und anderen Transfers als Folge.
  • Die Ewige Tabelle räumte nach jedem Laden auf und nahm jedem Absteiger seine Erstliga-Geschichte.
  • Historische Tabellen kamen als Kommazahlen zurück, aus 5338 wurde 5338.0.
  • Der Bewertungsbildschirm am Saisonende war nach dem Laden eine Liste aus leeren Einträgen.
  • Der Auf- und Abstiegsbildschirm zeigte keine Aufsteiger.

Als Gegenprobe wurden acht echte Spielstände geladen und gespielt, aus Saison 1 bis 10 und sieben Ländern, fehlerfrei. Nebenbei stellte sich heraus, dass die Tests einen anderen Ablauf fuhren als das Spiel: Karrierestart und Saisonvorbereitung steckten nur in Bildschirmen. Jetzt rufen Bildschirm und Test dieselben Funktionen auf.

Zwei Dinge, die Spieler gemeldet hatten

Wappen. 654 von 1.771 Vereinen trugen ein Wappen, das dem eines anderen glich, vor allem nach den neuen Ländern. Jetzt sind es 1.771 von 1.771 verschieden. Kein einziges Trikot hat sich dabei geändert, und laufende Spielstände behalten ihre Wappen.

Kommentar und Spiellage. Kein Abseits mehr nach einem Einwurf, keine dünn besetzten Ränge bei 150.000 Zuschauern, kein Schnee in Südamerika, kein „Direkt Rot“ bei Gelb-Rot. Die Zuschauerzeile hatte die Zahl vor dem Anpfiff verloren und rechnete mit 0. Es ist eine lange Liste kleiner Widersprüche, jeder einzeln nachgestellt.

Sicherheit und Datenschutz

  • Ein manipulierter Spielstand mit eingebettetem Programmcode wird nie ausgeführt.
  • Käufe bei Google werden mit dem Lizenzschlüssel der App gegengeprüft, und der Kaufbestand ist versiegelt. Bereits gekaufte Inhalte bleiben erhalten.
  • Werbung erscheint erst nach Einwilligung.
  • Jedes Gerät meldet sich mit einem eigenen Geheimnis bei der Cloud an. Die Kennung allein reicht nicht mehr.
  • Der Server ist seit dem 23. September gehärtet.
  • „Konto löschen“ sagt ehrlich, ob auch die Online-Daten gelöscht wurden.

Unter der Haube

366 ungenutzte Funktionen mit rund 5.850 Zeilen sind entfernt, die Version steht nur noch an einer Stelle, und der Godot-Editor bleibt bei Builds offen, weil die Builds nur ihren eigenen Prozess beenden.

Was bewusst offen bleibt

Arabisch läuft jetzt von rechts nach links. 13 Bildschirme, die an Hintergrundbilder gebunden sind, bleiben bewusst ungespiegelt, ihre Texte laufen trotzdem von rechts nach links.

Ein Patch, in dem sich fast nichts anders anfühlt außer dem, was vorher hakte, ist ein gelungener.

Alle Beiträge