Pocket Inventors: Bauen statt Steuern

Ein Spiel, in dem man nichts direkt steuert#

Bei den meisten Puzzle-Spielen für Kinder steuert man eine Figur und löst damit ein Problem. Bei Pocket Inventors ist es umgekehrt: Man baut, und dann schaut man zu.

Ein Level ist eine kleine Szene mit Boden, Lücken und Plattformen. Der Spieler zieht Bauteile aus einer Leiste in die Szene, drückt START und sieht zu, wie Bolt läuft, springt, rutscht und vielleicht das Ziel erreicht. Vielleicht nicht.

Diese Trennung war von Anfang an die wichtigste Entscheidung im Projekt. Sie nimmt einem Sechsjährigen die motorische und zeitliche Last des Reagierens und lässt ihn stattdessen das tun, was Sechsjährige tatsächlich gut können: schauen, vergleichen, ausprobieren.

Und das Scheitern kostet nichts. Kein Leben, keine Energie, kein Timer, keine Strafe. Ein RESET-Knopf und freundliches Feedback – mehr nicht.

Die Physik, die sich beneimmt#

Hinter dem Spiel steckt eine vereinfachte 2D-AABB-Physik mit festem Zeitschritt (1/60 s), achsenweiser Auflösung und Sub-Stepping, damit nichts durch dünne Böden tunnelt.

Die interessanten Entscheidungen sind die bewussten Regelbrüche:

Jede dieser Entscheidungen ist gegen die Engine und für das Kind gemacht. Ein Level, in dem ein sechsjähriger Spieler fünfmal an derselben Stelle scheitert, ist kein schwieriges Level. Es ist ein kaputtes Level.

Bauteile, die keine Erklärung brauchen#

Die Bauteiliste ist bewusst kurz und chaque Teil hat eine klare Aufgabe:

Plattform · Rampe · Kiste · Rad · Feder · Seil · Magnet · Schalter · Hebel · Ventilator · Förderband · Trampolin · Portal · Gewicht · Fahrplattform

Schalter, Portal und Fahrplattform sind über eine Zahl verbunden – Teile derselben Gruppe werden gemeinsam geschaltet. Die Zahl steht als farbiges Abzeichen am Bauteil. Ein Sechsjähriger muss dafür nichts lesen und nichts verstehen, er beobachtet nur die Farbe.

Jedes Bauteil rastet auf halbe Kacheln und wird automatisch innerhalb der Szene gehalten. Ein Teil, das halb vom Bild fällt, wäre unsichtbar und nicht mehr zu entfernen – das wäre ein Fehler, kein Feature.

Der Test, der Level-Korrektheit garantiert#

Jedes LevelDefinition trägt eine referenceSolution – eine bekannte gute Konstruktion. Ein Test startet dafür eine echte Simulation und verlangt, dass Bolt das Ziel physisch erreicht:

./gradlew :app:testDebugUnitTest --tests "*LevelSolvableTest*"

Ein Level kann deshalb nicht unsolvierbar ausgeliefert werden. Ein zweiter Test lässt alle 35 Level ohne jede Konstruktion laufen und verlangt 35 Mal ein freundliches Scheitern, ohne dass irgendetwas verbraucht wird.

Beim Durchspielen auf einem echten Gerät (Samsung Galaxy S10+, Android 12) kamen eine Reihe von Fehlern heraus, die kein Test gefunden hätte – zwei pointerInput-Detektoren am selben Knoten heben sich gegenseitig auf, die Pixel-zu-Kachel-Umrechnung ignorierte den Canvas-Ursprung, die Spielzeit zählte im Hintergrund weiter. Die Liste ist lang, und sie ist der eigentliche Wert des Tests: nicht, dass nichts kaputtgeht, sondern dass ich weiß, was kaputtgeht.

Sterne, die nichts versperren#

Sterne sind rein motivierend. Sie lassen sich nicht kaufen, nicht ausgeben, und sie sperren nie ein Level. Der Fortschritt zählt „geschafft", nicht „drei Sterne". Bei Spielen für Kinder ist das keine Detailfrage, sondern die zentrale.

Drei Hinweisstufen pro Level sind optional, und keine davon löst das Level automatisch. Stufe eins ist eine weiche Formulierung („Eine Lücke ist da."), Stufe drei eine konkrete Platzierung. Ein Hinweis senkt die Sterne-Obergrenze auf zwei – und beschämt nie.

Offline, gemessen am Binary#

Für ein Kinderpiel ist „läuft offline" keine Marketingzeile, sondern Voraussetzung. Hier ist sie am fertigen Release-APK nachgewiesen, nicht nur im Manifest der Quelle:

AUDIT: app/build/outputs/apk/release/app-release-unsigned.apk
size:   1.92 MB
  ok    permissions: none (offline is enforced by the platform, not by us)
  ok    libraries: no ads / analytics / billing / webview / http client
  ok    dex strings: no endpoints
  ok    assets: none - levels, art and audio are all generated in code
RESULT: PASS - the app runs fully offline

Das Manifest enthält kein einziges <uses-permission>. Die Leveldaten stehen im DEX, nicht auf einem Server. Wer im Flugmodus spielt, verliert nichts – weil es nichts nachzuladen gibt.

108 Tests in fünf Gruppen#

Der Content-Audit liest den Code ohne Kommentare. Sonst würde er an eigenen Kommentaren anschlagen, die genau das Gegenteil versprechen.

Was ich dabei gelernt habe#

Ein Level ist eine Behauptung über Physik. Erst mit einer Referenzlösung und einem Test ist die Behauptung belegt. Ohne das wäre „35 Level fertig" nur eine Zahl in einer Readme-Datei.

Barrierefreiheit beginnt bei den Konstanten. Touch-Ziele ab 56 dp, feste Schriftgrade, Kontraste nach WCAG AA, Farbe nie als einziger Informationsträger, und „Weniger Bewegung" als echter Schalter. Das ist wenig Aufwand, wenn man es von Anfang an einbaut.

Ein später Fehler in der Rendering-Kette kostet mehr als die Architekturentscheidung. Die Entscheidung „Simulation ohne Android-Typen" war richtig und hat zehn Stunden gespart. Die Fehler in der Canvas-Umrechnung und im Gesture-Handling haben mehr gekostet.

Grenzen und offene Punkte#

Ehrlich gesagt: Von den 6 vorgesehenen Welten sind 3 leer. Wolken, Maschinenfabrik und Mond existieren als Palette und Beschreibung, die Karte zeigt „wird gerade gebaut". Von der Eiswelt sind 5 der 15 Level fertig. Die Seil-Mechanik ist implementiert, aber die unzuverlässigste im Spiel – deshalb in den Leveln als Alternative, nicht als Lösung.

Sprache ist Deutsch, Sprachausgabe fehlt komplett, und die instrumentierten Tests wurden mangels geeignetem Gerät nur kompiliert, nicht ausgeführt. Für die Zielgruppe ist genau das die wichtigste offene Baustelle: die kann noch nicht lesen.

Die Referenz auf haasarts.de zeigt das Projekt im Zusammenhang. Wenn du ein ähnliches Android-Produkt für Kinder bauen willst – ruhig, offline, ohne Dark Patterns – schreib mir über den Kontakt.