Ein Spiel bauen,
ganz allein.

01 Was für ein Spiel soll es werden

Der häufigste Grund, warum ein Hobbyspiel nie fertig wird, ist nicht fehlendes Können. Es ist ein zu grosser Plan. Ein Rollenspiel mit offener Welt braucht tausend Entscheidungen, und die neunhundertste fällt niemand mehr.

Such dir deshalb ein Spiel, dessen Regeln du in fünf Sätzen erklären kannst. Am besten eines, das es als Brett- oder Papierspiel schon gibt: Schiffe versenken, Vier gewinnt, Memory, Minesweeper, Schere-Stein-Papier. Die Regeln sind erprobt, du musst sie nicht erfinden – deine Arbeit ist das Drumherum.

Genau das war der Ansatz bei SempiSplash. Schiffe versenken, aber auf dem Sempachersee: statt Kriegsschiffen ein Stand-up-Paddler, Pedalos, ein Ruderboot, Fischerboote und eine Gänseschar. Statt Kanonen fliegen Wasserballons. Die Regel „Treffer, du darfst nochmal" musste ich nicht ausdenken, die kennt jedes Kind. Die Arbeit lag darin, dass es sich nach Ferien anfühlt.

Zwei Fragen, die alles Weitere bestimmen

Wer spielt gegen wen? Zwei Menschen am selben Gerät ist mit Abstand am einfachsten – kein Netzwerk, kein Server, kein Computergegner. Das Gerät wandert zwischen den Zügen hin und her, ein Übergabebildschirm sorgt dafür, dass niemand die Karten des anderen sieht. Ein Computergegner ist der nächste Schritt, Mehrspieler über Funk der übernächste und ungleich aufwendiger.

Hoch- oder Querformat? Klingt nebensächlich, entscheidet aber den gesamten Bildschirmaufbau. Ein 10 × 10-Raster mit Infospalten links und rechts braucht Querformat. Das legst du besser am Anfang fest als nach zwanzig gebauten Bildschirmen.

Schreib die Antwort auf beide Fragen auf ein Blatt und häng es an die Wand. Jedes Mal, wenn dir mitten im Projekt eine grossartige Zusatzidee kommt, prüfst du sie gegen dieses Blatt. Die meisten fallen dann von selbst weg.

02 Die Regeln aufschreiben

Bevor eine Zeile Code entsteht, schreibst du die Regeln vollständig auf. Nicht in Programmiersprache – in normalen Sätzen, so wie du sie einem Kind erklären würdest. Dieses Dokument wird später deine wichtigste Datei.

Der Grund ist einfach: Du wirst den Code nicht selbst schreiben, sondern beschreiben. Und eine Beschreibung, die du selbst nicht eindeutig formulieren kannst, wird niemand richtig umsetzen – weder eine KI noch ein Mensch.

Wie so eine Beschreibung aussieht

Das hier war bei SempiSplash die allererste Nachricht, mit der alles anfing – unverändert, so getippt:

Kennst du das Brettspiel "Schiffe versenken"? Kannst du mir daraus
eine Sempachersee-Version als Android-App bauen? Kleinste Boote
sind in meiner Version 1er-Felder. 2x Standup Paddler (1er),
2x Pedalos (2er), 2x Fischerboot (3er) und 1x Gänseschar (4er).
Lustiger Comicstil. Player 1 setzt seine Objekte (verschieben und
drehen oder zufällig platzieren), bestätigen, Natel Player 2
übergeben, dieser setzt seine Objekte, bestätigen, Spiel startet.
Übliche Schiffe-versenken-Regeln, ausser dass Objekte auch direkt
nebeneinander liegen dürfen.

Kein Fachbegriff, keine Programmiersprache – und trotzdem lässt sich daraus sofort etwas bauen. Vier Dinge machen den Unterschied:

• Ein bekanntes Spiel als Ausgangspunkt. Damit sind neunzig Prozent der Regeln geklärt, ohne dass ein Wort darüber fällt.
• Die Flotte vollständig aufgezählt, mit Anzahl und Feldergrösse. Keine Rückfrage nötig.
• Der Ablauf als Kette: setzen, bestätigen, übergeben, setzen, bestätigen, starten. Daraus werden direkt die Bildschirme.
• Die Abweichung ausdrücklich benannt – „ausser dass". Genau die hätte man sonst übersehen.

Und trotzdem: Regeln kippen

Ausgerechnet die eine ausdrücklich benannte Abweichung hat später gedreht. Heute gilt in SempiSplash das Gegenteil: Um jedes Objekt bleibt ein Feld frei, auch über Eck. Beim Spielen zeigte sich, dass aneinandergeklebte Boote ein Ratespiel ohne Taktik ergeben – wer einen Treffer landet, weiss nichts.

Das ist kein Planungsfehler, sondern normal: Manches merkt man erst beim Spielen. Wichtig ist nur, was daraus folgt. Diese eine umgedrehte Regel steckte am Ende an sechs Stellen im Programm – beim Aufstellen, beim Zufallsaufbau, beim Verstecken der Fundstücke, beim Umsetzen eines geretteten Boots, bei der Prüfung auf gültige Positionen und in den Tests. Hätte sie nur im Kopf gesteckt statt im Regeldokument, wäre garantiert eine davon vergessen worden.

Woran man merkt, dass eine Regel noch nicht fertig ist

Eine Regel ist fertig, wenn sie keine Rückfrage mehr auslöst. „Objekte dürfen sich nicht berühren" klingt vollständig, ist es aber nicht: Gilt das auch diagonal? Bei SempiSplash lautet die Fassung deshalb: Um jedes Objekt bleibt ein Feld frei, auch über Eck. Diese eine Präzisierung hat später an sechs verschiedenen Stellen im Programm gesteckt.

Weitere Beispiele aus demselben Dokument, jeweils in der Fassung, die keine Frage mehr offenlässt:

• Ein Treffer erlaubt einen weiteren Wurf. Ein Fehlwurf beendet den Zug sofort.
• Ein Objekt wird erst aufgedeckt, wenn alle seine Felder getroffen sind – nicht beim ersten Treffer.
• Auf dasselbe Feld darf nicht zweimal geworfen werden.
• Die Partie endet, sobald alle Objekte eines Sees versenkt sind.

Sonderfälle gehören ins selbe Dokument

SempiSplash hat versteckte Fundstücke: Wer darauf wirft, löst etwas aus. Drei davon helfen, eines schadet – der Storch, der einen Klecks über einen Viertel des Bildschirms setzt. Genau bei diesen Sonderfällen entstehen die meisten Fehler, weil sie mit allem anderen zusammenspielen.

Die Fragen, die man vorher beantworten muss, klingen kleinlich und sind es nicht: Zählt der Fund als Treffer, darf man also nochmal werfen? Was passiert, wenn beide Spieler denselben Effekt gleichzeitig auslösen? Läuft der Zähler in Runden oder in Würfen?

Bei mir blieb genau eine dieser Fragen offen – was passiert, wenn der zweite Spieler den Storch findet, während der erste Klecks noch liegt. Das Ergebnis war ein unsichtbarer zweiter Klecks, der stumm mitzählte und die Anzeige durcheinanderbrachte. Gefunden habe ich das erst beim Spielen mit den Kindern.

Die Spielanleitung mitführen

Wenn du eine Regel änderst, ändert sich zweierlei: das Programm – und der Text, der die Regel im Spiel erklärt. Das Programm meldet sich, wenn etwas nicht passt. Der Text nicht.

In meiner Anleitung stand monatelang, die Ballonparty verzeihe zwei Fehlwürfe. Sie verzieh längst drei, und einen Treffer kostete sie auch nicht mehr. Nichts war kaputt, nichts stürzte ab – es stand einfach etwas Falsches da, und keiner merkte es, weil niemand die Anleitung liest, der das Spiel schon kennt.

Nimm dir vor jeder Veröffentlichung fünf Minuten und lies deine eigene Spielanleitung gegen das, was das Spiel wirklich tut. Es ist die einzige Stelle im Projekt, die niemals von selbst auffällt.

03 Der Werkzeugkasten

Fünf Werkzeuge, mehr braucht es nicht. Vier davon laufen im Browser.

Dazu ein Android-Gerät zum Testen – ein altes Tablet reicht und ist sogar besser als ein neues, weil du dann merkst, wo es ruckelt.

Android Studio einrichten

Lade Android Studio von developer.android.com/studio und installiere es mit den Voreinstellungen. Beim ersten Start lädt es ein paar Gigabyte an SDK-Komponenten nach; das dauert und ist einmalig.

Danach aktivierst du auf deinem Testgerät die Entwickleroptionen: Einstellungen öffnen, „Über das Telefon" suchen, siebenmal auf die Build-Nummer tippen. In den nun sichtbaren Entwickleroptionen schaltest du USB-Debugging ein. Steckst du das Gerät jetzt per Kabel an, erscheint es in Android Studio oben in der Geräteliste und du kannst das Spiel mit einem Klick draufspielen.

Der Emulator ist für Spiele nur bedingt brauchbar. Er zeigt dir Layoutfehler, aber Ton, Vibration und die tatsächliche Bildrate beurteilst du nur auf echter Hardware. Zwei Personen an einem Emulator sitzen zu lassen, funktioniert ohnehin nicht.

04 Zuerst die Regeln, dann das Bild

Die Versuchung ist gross, mit dem Schönen anzufangen. Tu es nicht. Baue zuerst die Spiellogik – ohne ein einziges Bild, ohne einen einzigen Ton.

Dafür gibt es einen handfesten Grund, der nichts mit Disziplin zu tun hat: Nur die Logik lässt sich prüfen. Ein Programm kann automatisch tausendmal nachrechnen, ob zwei Objekte je aneinandergrenzen. Ob ein Knopf schön sitzt, kann es nicht beurteilen – das siehst nur du, von Hand, jedes Mal neu.

Die Trennung, die alles einfacher macht

Halte den Teil, der die Regeln kennt, streng getrennt von dem Teil, der etwas anzeigt. In SempiSplash liegen die Regeln in zwei Ordnern, die nichts über Android wissen: Sie kennen keine Bildschirme, keine Farben, keine Knöpfe. Sie kennen nur Felder, Objekte, Würfe und Treffer.

Das klingt nach akademischer Ordnungsliebe, hat aber eine sehr praktische Folge: Dieser Teil lässt sich in Sekunden prüfen, ohne die App überhaupt zu starten. Achtundzwanzig automatische Tests laufen bei jeder Änderung durch und melden sofort, wenn eine Regel verletzt wurde.

Für 200 zufällig aufgestellte Flotten gilt:
  Kein Objekt berührt ein anderes – auch nicht über Eck.
  Jedes Objekt liegt vollständig im 10 × 10-Raster.
  Die Flotte ist vollständig: 1 Paddler, 2 Pedalos,
  1 Ruderboot, 2 Fischerboote, 1 Gänseschar.

Formuliere solche Sätze für jede Regel aus Kapitel 2 und lass sie in Tests übersetzen. Du wirst sie nie wieder anfassen – aber sie fangen ab jetzt jeden Fehler ab, den du beim Umbauen versehentlich einbaust.

Die Reihenfolge, die sich bewährt hat

1. Spielfeld, Objekte, Aufstellen mit allen Abstandsregeln
2. Werfen, Treffer, Fehlwurf, Versenken, Sieg
3. Tests für alles davon
4. Erst jetzt: Bildschirme, Knöpfe, Abläufe – noch mit einfachen Farbflächen statt Bildern
5. Bilder und Ton
6. Sonderfälle wie die Fundstücke

Nach Schritt 4 hast du ein hässliches, aber vollständig spielbares Spiel. Das ist der wichtigste Moment im ganzen Projekt: Ab hier kannst du es mit jemandem spielen und merkst, ob es überhaupt Spass macht. Alles davor ist Vermutung.

Der Zwischenstand ist nicht für die Tonne

SempiSplash lief in dieser Phase komplett ohne Bilddateien. Boote, Wasser, Wellen und Spritzer waren direkt im Code gezeichnet – einfache Formen mit dicker Kontur. Sah nach Kinderzeichnung aus, war aber vollständig spielbar, und die ersten Partien mit den Kindern fanden auf genau diesem Stand statt.

Erst danach kamen die erzeugten Bilder dazu. Und hier kommt der Teil, den ich vorher nicht bedacht hatte: die gezeichnete Fassung wurde nicht weggeworfen. Sie liegt bis heute im Spiel als Rückfallebene. Fehlt eine Bilddatei, erscheint automatisch die gezeichnete Form.

Das hat sich zweimal ausgezahlt. Erstens konnte ich die fertigen Bilder über Wochen einzeln nachliefern, ohne dass das Spiel zwischendurch je kaputt war. Zweitens gibt es keinen Zustand, in dem ein Boot einfach unsichtbar ist – im schlimmsten Fall sieht es schlichter aus.

Wenn du also in Schritt 4 Farbflächen statt Bilder verwendest: bau sie so, dass sie bleiben dürfen. Es kostet fast nichts extra und erspart dir die Phase, in der nichts funktioniert, weil die Hälfte der Bilder noch fehlt.

05 Grafiken mit DALL·E

Hier entscheidet sich, ob dein Spiel nach Bastelei aussieht oder nach etwas Ganzem. Der wichtigste Punkt ist nicht die Qualität der einzelnen Bilder – es ist, dass sie zusammen aussehen wie aus einer Hand.

Zuerst den Stil festlegen, dann erst die Motive

Schreib einen Stilsatz auf, der bei jedem Bild wortwörtlich mitgeschickt wird. Nicht sinngemäss, nicht abgewandelt – identisch. Für SempiSplash lautet er sinngemäss: fröhliche Comic-Sticker-Illustration, kräftige dunkle Konturen, flache Farbflächen mit sanfter Schattierung, freundliche Sommerstimmung, Schweizer Seeufer.

Jede Abweichung rächt sich. Fügst du bei einem Bild „mit realistischen Details" hinzu, fällt es später aus der Reihe, und du merkst es erst, wenn alle acht Objekte nebeneinander im Spiel liegen.

Aufbau eines Prompts

Ein brauchbarer Prompt hat vier Teile, immer in dieser Reihenfolge:

1. Motiv – was genau zu sehen ist
2. Stilsatz – dein festgelegter Wortlaut, unverändert
3. Technische Vorgaben – Hintergrund, Ausschnitt, Blickwinkel
4. Verbote – was auf keinen Fall drauf soll

[MOTIV: ein Tretboot mit zwei Sitzen, von schräg oben gesehen]

[STIL: cheerful comic sticker illustration, bold dark outlines,
flat colours with soft shading, friendly summer mood,
Swiss lakeside theme]

[TECHNIK: game asset on a clean, isolated pure white background,
mobile game UI element, high resolution, professional digital art,
centred, full object visible, no cropping]

[VERBOTE: no text, no letters, no numbers, no watermark,
no shadow on the ground, no background scenery]

Die vier Verbote sind keine Schikane. DALL·E setzt gern Schriftzüge ins Bild, die aussehen wie Sprache, aber keine sind – im Spiel wirkt das billig. Und ein Bodenschatten macht das Freistellen in Kapitel 6 unnötig schwer, weil er weich in den Hintergrund ausläuft.

Weisser Hintergrund statt durchsichtiger

Bitte immer um einen reinweissen Hintergrund, nie um einen durchsichtigen. Durchsichtige Ergebnisse sind unzuverlässig; reinweiss bekommst du praktisch immer, und du kannst es anschliessend sauber und kontrolliert entfernen.

Varianten, damit es nicht nach Schablone aussieht

Ein Spiel mit zwei Pedalos, die exakt gleich aussehen, wirkt tot. Lass von jedem Objekt vier Fassungen erzeugen – gleicher Stil, gleicher Blickwinkel, andere Farben oder andere Personen darin. Im Spiel wird dann pro Partie zufällig gewählt.

Damit nicht beide Spieler dasselbe Pedalo bekommen, sorgt eine kleine Regel im Code dafür, dass sich die Fassungen auf den beiden Seen unterscheiden. So sehen zwei Partien nie ganz gleich aus, obwohl es nur vier Bilder sind.

Was schiefgeht und wie du es abfängst

06 Bilder freistellen

Aus dem weissen Hintergrund muss ein durchsichtiger werden, sonst schwimmt jedes Boot auf einem weissen Kasten. Das klingt nach einem Klick und ist die Stelle, an der ich mir am meisten Ärger eingehandelt habe.

Wie es funktioniert

Ein kleines Programm geht jeden Bildpunkt durch und macht ihn durchsichtig, wenn er heller ist als ein festgelegter Schwellwert. Alles, was dunkler ist, bleibt stehen.

Für jeden Bildpunkt:
    Ist er heller als der Schwellwert?
        Ja  -> durchsichtig machen
        Nein -> unverändert lassen

Der Fallstrick, der mich Wochen später eingeholt hat

Der Schwellwert ist heikler, als er aussieht. Setzt du ihn zu streng, bleibt ein grauer Saum rund um jedes Objekt. Setzt du ihn zu grosszügig, verschwindet nicht nur der Hintergrund – sondern auch jede helle Fläche im Bild.

Genau das ist bei meiner Wurf-Figur passiert. Sie steht auf einem hellen Holzpodest. Das Podest war heller als der Schwellwert und wurde mitgelöscht – übrig blieben ein paar blasse Konturreste. Im Spiel schwebte die Figur, und ich habe es monatelang für Absicht gehalten. Die Bilddaten waren zu dem Zeitpunkt unwiederbringlich weg; die Fläche musste aus den überlebenden Konturen rekonstruiert werden.

Bewahre die Originaldateien auf. Freistellen ist nicht umkehrbar. Leg die unbearbeiteten Bilder in einen eigenen Ordner und fass ihn nie wieder an. Der ganze Ärger oben wäre ein Zweiminutenproblem gewesen, wenn ich das gemacht hätte.

So gehst du sicher vor

1. Original wegkopieren, bevor irgendetwas passiert.
2. Freistellen mit einem strengen Schwellwert – lieber ein Rest zu viel als ein Loch im Bild.
3. Jedes Ergebnis auf farbigem Grund anschauen, nicht auf weissem. Auf Weiss siehst du ein weisses Loch nicht.
4. Erst wenn alle Bilder auf Blau richtig aussehen, ins Projekt übernehmen.

Schritt 3 ist der entscheidende und wird am häufigsten übersprungen. Ein Bild mit einem herausgefallenen weissen Podest sieht auf weissem Grund völlig unauffällig aus.

07 Bilder ins Projekt bringen

Android legt Bilder in Ordnern unter app/src/main/res/ ab. Für Spielgrafik, die ohnehin frei skaliert wird, ist drawable-nodpi der richtige Ort: Android lässt die Bilder dort in Ruhe, statt sie für verschiedene Bildschirmdichten umzurechnen.

WebP statt PNG

Wandle alle Bilder verlustfrei in WebP um. Gleiche Qualität, deutlich kleinere Dateien. Android Studio kann das direkt: Rechtsklick auf den Ordner, Convert to WebP, verlustfrei wählen.

Dateinamen sind wichtiger als man denkt

Halte dich an ein festes Schema und weiche nie davon ab. Bei SempiSplash:

obj_pedalo_1.webp      obj_pedalo_2.webp
obj_ruderboot_1.webp   obj_ruderboot_2.webp
obj_gaenseschar.webp
pu_storch_icon.webp    pu_moewe_icon.webp
char_thrower_idle.webp char_thrower_windup.webp

Nur Kleinbuchstaben, Ziffern und Unterstriche – Android verweigert alles andere. Grossbuchstaben oder Bindestriche führen zu einer Fehlermeldung, die den eigentlichen Grund nicht nennt.

Der Kniff, der spätere Arbeit spart

Bilder werden im Spiel nicht fest verdrahtet, sondern über ihren Namen gesucht. Der Vorteil: Du kannst ein Bild ergänzen oder weglassen, ohne eine Zeile Code anzufassen. Fehlt eine Datei, zeichnet das Spiel eine einfache Ersatzform.

Das klingt unscheinbar und war in der Praxis Gold wert. Ich konnte mit gezeichneten Platzhaltern anfangen und die fertigen Bilder über Wochen nachliefern – jedes einzelne wurde beim nächsten Start automatisch verwendet.

Eine Falle bei dieser Technik: Android entfernt beim Erzeugen der fertigen App alles, was scheinbar niemand benutzt – und Bilder, die nur über ihren Namen gefunden werden, sehen für Android unbenutzt aus. Es braucht deshalb eine kleine Ausnahmeliste. Wenn deine Bilder in der Testfassung erscheinen, in der fertigen App aber fehlen, ist das der Grund.

Einfärbbare Teile

In SempiSplash hat jeder Spieler eine eigene Trikotfarbe. Dafür liegt neben jedem Figurenbild eine zweite, gleich grosse Datei, die nur die Trikotfläche enthält. Sie wird eingefärbt und passgenau darübergelegt.

Wichtig ist dabei nur eines, und es ist leicht zu übersehen: Beide Dateien müssen exakt gleich gross sein. Schon zwei Bildpunkte Unterschied, und die Farbe sitzt sichtbar daneben.

08 Musik mit Suno

Hintergrundmusik ist der billigste Weg, aus einer Anwendung ein Spiel zu machen. Suno erzeugt aus einer Textbeschreibung fertige Stücke mit Melodie, Begleitung und Abmischung.

Dabei arbeitest du auf zwei Ebenen, und das zu trennen hilft enorm: Zuerst formulierst du einen ausführlichen Auftrag – was die Musik leisten soll, für wen, in welcher Situation. Daraus destillierst du dann die knappe Stilbeschreibung, die Suno tatsächlich verarbeitet.

Der ausführliche Auftrag

Das hier ist der vollständige Auftrag für die Spielmusik von SempiSplash. Er ist bewusst lang: Er zwingt dich, jede Anforderung einmal auszusprechen.

Instrumental background music for a cheerful, child-friendly water
balloon naval battle game with cute animated animals. Playful, warm,
lighthearted and adventurous, but calm enough to stay in the
background during long gameplay sessions.

Create a loop-friendly video game soundtrack around 100 BPM with a
gentle, steady groove. Use soft marimba, kalimba, muted xylophone,
pizzicato strings, light acoustic percussion, subtle woodblocks,
soft plucked instruments and warm airy pads. Add occasional tiny
musical responses and playful details that suggest curious animals
and splashing water.

The melody should be simple, friendly and memorable without becoming
an earworm. Use short melodic motifs with plenty of variation, pauses
and changing instrumentation. Avoid constant repetition. Keep the
harmonic progression smooth, positive and slightly adventurous. Let
instruments enter and leave gradually so the track evolves naturally
over several minutes without obvious sections.

Integrate subtle natural ambience into the music: gentle water
movement, small splashes, distant birds, soft leaves in the wind and
occasional subtle animal sounds. Keep all nature sounds quiet and
musical, never distracting or realistic enough to dominate the
soundtrack.

Maintain low to medium energy with controlled dynamics. No dramatic
build-ups, no drops, no loud transitions and no sudden changes.
Avoid overly bright high frequencies and repetitive percussion that
could become tiring during repeated gameplay.

Mood: playful exploration, friendly competition, summer afternoon,
water, animals, curiosity, light tactical thinking.

Style: polished modern casual-game soundtrack, organic acoustic
textures mixed with subtle soft electronic ambience, charming and
colourful without sounding childish or silly.

No vocals, no singing, no spoken words, no choir, no aggressive
drums, no heavy bass, no EDM drops, no epic orchestral music, no
cinematic tension, no military march, no circus music, no comedy
sound effects, no repetitive four-bar melody.

Designed to remain pleasant and unobtrusive after many minutes of
continuous gameplay and to work naturally as looping background
music.

Zwei Absätze daraus verdienen besondere Beachtung, weil sie den Unterschied zwischen brauchbarer und unbrauchbarer Spielmusik ausmachen.

„Memorable without becoming an earworm." Das klingt widersprüchlich und ist genau richtig. Musik, die man mitsummt, wird nach der zwanzigsten Partie zur Qual. Der Auftrag verlangt deshalb ausdrücklich kurze Motive mit viel Abwechslung, Pausen und wechselnder Besetzung – und verbietet die stur wiederholte Viertakt-Melodie.

Die Liste der Verbote am Ende. Sie ist fast so lang wie der Rest, und das ist kein Zufall. Suno neigt von sich aus zu Gesang, zu Steigerungen und zu dramatischen Wendungen – alles Dinge, die in einem Spiel, das eine halbe Stunde läuft, unerträglich werden. Was du nicht willst, musst du aussprechen.

Was davon in Suno landet

Der Auftrag oben ist die Denkarbeit. In Suno steht am Ende eine kompaktere Stilbeschreibung. So sehen die drei Stücke aus, die tatsächlich in SempiSplash laufen:

Playful instrumental pop with light bouncy rhythm and finger-snapped
percussion, bright marimba and plucky synths carrying a simple
looping motif; verse section stays sparse and cheerful, chorus lifts
with glockenspiel accents and soft clap layers, then a short break
adds water-drop sparkles before the loop returns, Gentle
phone-friendly mix, clean and compact, bright and unobtrusive

[Instrumental]

Ambient pop with playful 100 BPM loopable groove; verse-like sections
evolve through soft marimba motifs, kalimba arpeggios, muted
xylophone accents, pizzicato strings, light acoustic percussion, and
subtle woodblocks, Arranged in gentle arcs: sparse opening pads and
water textures, a mid-loop lift with brighter counter-melodies, then
a softer reset for seamless looping, Breathy vocal-like air swells
and tiny bell responses add ear candy, Polished modern mix, organic
and warm, airy and controlled, marimba, light, playful, dynamics,
electronic, soft, warm, soundtrack, gentle

[Instrumental]

Ambient acoustic beach soundscape with gentle ocean waves, birdsong,
and soft brushed percussion in a slow floating pulse; verse-like
sections drift on sparse ukulele and airy pads, then widen into a
breezy middle with woodwind flourishes and distant seagull calls; ear
candy includes wave crashes, gull passes, and reversed swell
transitions; intimate, sunlit, natural mix, soft, beach music

[Instrumental]

Die Bauteile einer guten Stilbeschreibung

Vergleicht man die drei, taucht dasselbe Gerüst auf. Wenn du deine eigene schreibst, arbeite es der Reihe nach ab:

1. Genre und Puls – „ambient pop with playful 100 BPM loopable groove". Tempo gehört dazu, sonst würfelt Suno es aus.
2. Instrumente, namentlich – Marimba, Kalimba, Xylophon, Pizzicato-Streicher, Woodblocks. Je konkreter, desto verlässlicher das Ergebnis. „Fröhliche Instrumente" bringt nichts.
3. Der Verlauf als Bogen – dünner Anfang, Aufhellung in der Mitte, sanfte Rückführung. Ohne diese Angabe erzeugt Suno ein Stück mit Anfang und Ende statt eines Kreises.
4. Ear Candy – die kleinen Details: Wassertropfen, Glöckchen, Möwenrufe. Sie machen den Unterschied zwischen Fahrstuhlmusik und einem Stück, das zum Spiel gehört.
5. Die Abmischung – „gentle phone-friendly mix, clean and compact, bright and unobtrusive". Der wichtigste und meistvergessene Punkt: Deine Musik läuft aus einem Handylautsprecher, nicht aus Studiomonitoren.
6. Der Vermerk [Instrumental] – ohne ihn kommt fast sicher Gesang.

„Softer reset for seamless looping" ist die Formulierung, die aus einem Musikstück eine Spielschleife macht. Ein normales Stück endet. Ein Schleifenstück muss so aufhören, dass der eigene Anfang unauffällig anschliesst – und das musst du verlangen, sonst hörst du bei jedem Durchlauf die Naht.

Drei Stücke statt eines

Ein einzelnes Stück in Dauerschleife wird schnell lästig – die Wiederholungsstelle prägt sich ein. Erzeuge drei bis vier Stücke und lass das Spiel eines davon zufällig beginnen und dann der Reihe nach weiterspielen.

Die drei oben zeigen dabei eine Feinheit: Sie sind verwandt, aber nicht gleich. Zwei teilen sich dieselbe DNA aus Marimba und hellem Anschlag, das dritte ist eine ruhige Strandaufnahme mit Ukulele und Möwen. Genug Gemeinsamkeit, dass es nach einem Spiel klingt – genug Unterschied, dass der Wechsel auffällt und Abwechslung bringt.

Rechtliches, kurz und ehrlich

Die Nutzungsbedingungen von Suno hängen davon ab, mit welchem Konto du erzeugst; kostenlose und bezahlte Stufen unterscheiden sich bei der kommerziellen Nutzung. Wer sein Spiel veröffentlichen will, sollte vorher nachlesen, was für die eigene Stufe gilt. Ich bin kein Jurist und kann dir keine verbindliche Auskunft geben – aber es ist eine Frage, die man vor dem Hochladen in den Store stellt und nicht danach.

09 Geräusche von Freesound

Für einzelne Geräusche – Platschen, Aufprall, Fanfare, Möwenschrei – ist freesound.org die beste Quelle. Zehntausende Aufnahmen, von Menschen eingespielt, kostenlos.

Nach Lizenz filtern, und zwar zuerst

Freesound-Dateien stehen unter verschiedenen Lizenzen. Stell den Filter auf Creative Commons 0, bevor du überhaupt suchst. CC0 bedeutet: freie Verwendung ohne Namensnennung, auch kommerziell.

Die anderen Lizenzen sind nicht verboten, aber sie verlangen eine Nennung des Urhebers an sichtbarer Stelle. Wenn du das machen willst, brauchst du eine Liste im Spiel – und musst sie pflegen. Für ein Ferienprojekt ist CC0 der Weg mit den wenigsten Fallstricken.

Notier dir zu jeder heruntergeladenen Datei Nummer, Titel und Urheber, auch bei CC0. Nicht weil du musst, sondern weil du in einem Jahr nicht mehr weisst, woher die Datei kam – und dann fängst du bei null an.

Aufnahmen sind fast nie sofort brauchbar

Was du herunterlädst, ist Rohmaterial. Drei Dinge musst du praktisch immer anpassen:

Länge. Eine Aufnahme von zwei Sekunden für ein Geräusch, das nach einer halben Sekunde vorbei sein soll, überlappt sich mit dem nächsten. Bei SempiSplash gilt: Nach einem Treffer darf sofort wieder geworfen werden – ein zu langer Trefferton läuft also in den nächsten Wurf hinein. Meine Trefferklänge liegen alle zwischen 0,3 und 1,0 Sekunden.

Ausblenden. Schneidest du eine Aufnahme hart ab, knackt es hörbar. Leg über die letzten ein bis zwei Zehntel eine kurze Ausblendung.

Lautstärke. Das ist der Punkt, der am meisten ausmacht und am ehesten vergessen wird. Aufnahmen verschiedener Urheber sind völlig unterschiedlich ausgesteuert. Zieh alle Geräusche einer Gruppe auf denselben Spitzenpegel – bei mir liegen sämtliche Trefferklänge exakt bei −0,6 dB. Ohne das ist ein Geräusch dreimal so laut wie das nächste, und du drehst später mühsam an einzelnen Reglern herum.

Format

Wandle alles in OGG um. Es klingt gleich, braucht aber einen Bruchteil des Platzes: Eine meiner Dateien schrumpfte von 1,1 MB auf 51 KB. Bei zwanzig Geräuschen entscheidet das darüber, ob die fertige App zehn oder dreissig Megabyte gross ist.

10 Ton einbauen

Android hat zwei getrennte Wege, Ton abzuspielen, und die Wahl ist keine Geschmacksfrage.

Nimmst du MediaPlayer für Geräusche, hörst du das Platschen einen Sekundenbruchteil nach dem Aufprall – und das fällt sofort auf. Nimmst du SoundPool für Musik, lädst du ein Drei-Minuten-Stück komplett in den Arbeitsspeicher.

Zwei Schalter, die dazugehören

Gib den Spielenden zwei getrennte Schalter für Musik und Geräusche. Nicht einen. Viele wollen die Geräusche behalten, weil sie zum Spiel gehören, aber die Musik abstellen, weil im Hintergrund schon etwas anderes läuft.

Wo Tonfehler wirklich entstehen

Der hartnäckigste Fehler in meinem Projekt war kein Tonfehler, sondern ein Zeitfehler. Die Siegesfanfare sollte einsetzen, sobald der Versenkungsklang des letzten Objekts ausgeklungen ist – bis zu zwei Sekunden nach dem Treffer.

Sie kam nie. Der Grund: Die Wartezeit hing am Spielbildschirm, und der verschwand nach einem Drittel dieser Zeit, weil der Endbildschirm erscheint. Mit dem Bildschirm verschwand auch die wartende Fanfare.

Die Lehre ist allgemein: Ein Ton, der einen Bildschirmwechsel überleben soll, darf nicht an diesem Bildschirm hängen. Er gehört auf die Ebene der App. Wenn bei dir ein Ton „manchmal" fehlt, ist fast immer genau das die Ursache.

Wartezeiten messen, nicht schätzen

Damit die Fanfare weiss, wann sie einsetzen darf, muss sie wissen, wie lange der Versenkungsklang dauert – und der ist bei jedem Objekt anders. Es liegt nahe, das grob zu schätzen. Tu es nicht: Lies die tatsächliche Länge jeder Datei aus und trag sie ein.

Bei mir sind das Werte zwischen 0,7 und 2,8 Sekunden. Geschätzt hätte ich überall „ungefähr zwei" gesagt – und die Fanfare wäre dem Fischerboot ins Wort gefallen und hätte beim Pedalo anderthalb Sekunden Stille erzeugt. Beides fällt sofort auf, aber eben nur in genau der einen Partie, in der das betroffene Objekt als letztes drankommt. Solche Fehler findet man kaum durch Zufall.

11 Mit Claude arbeiten

Der ganze Programmcode von SempiSplash stammt aus Gesprächen mit Claude. Ich habe keine Zeile Kotlin selbst geschrieben. Das funktioniert – aber anders, als die meisten erwarten, und mit klaren Grenzen.

Deine Rolle ist die des Auftraggebers

Du bist nicht Programmierer, sondern derjenige, der weiss, wie das Spiel sein soll. Deine Arbeit besteht aus drei Dingen: genau beschreiben, was du willst; auf dem Gerät prüfen, ob es das tut; und präzise sagen, was nicht stimmt.

Der dritte Punkt ist der wichtigste und der am meisten unterschätzte. „Geht nicht" hilft niemandem. „Wenn ich den Storch finde, während der erste Klecks noch liegt, verschwindet die Anzeige" führt direkt zur Ursache.

Ein Bildschirmfoto ersetzt zehn Sätze

Bei allem Sichtbaren: fotografiere den Bildschirm. Der lehrreichste Fall aus meinem Projekt ging so:

Ich schrieb, das Spiel laufe „nicht im Vollbild". Das klang eindeutig, war es aber nicht – und wurde als Zuschnittproblem verstanden. Es kamen zwei Anläufe, das Bild anders zu skalieren. Beide brachten nichts, weil beide das falsche Problem lösten.

Dann schickte ich einen Screenshot. Darauf war zu sehen, dass mein Tablet quer lag, die App aber ins Hochformat gezwungen wurde – und dabei nicht gedreht, sondern in ein kleines hochkantiges Fenster mitten auf dem Bildschirm gequetscht wurde. An den Rändern schaute das Hintergrundbild des Geräts hervor. Es war nie ein Skalierungsproblem, es war ein Ausrichtungsproblem. Ein Bild, eine Minute, Sache geklärt.

Der Satz, der beide Fehlversuche gespart hätte, wäre gewesen: „Das Spiel läuft in einem kleinen hochkantigen Fenster, obwohl mein Tablet quer liegt." Aber darauf muss man erst kommen – das Foto kommt einem von selbst.

Was die KI nicht kann, und was das für dich bedeutet

Claude kann in seiner Umgebung kein Android bauen und kein Spiel starten. Was du bekommst, ist ungetesteter Code – plausibel, aber nicht bewiesen. Zwei Fehlerarten kommen dabei immer wieder durch:

• Fehlende Verweise. Der Code benutzt einen Baustein, ohne ihn oben angemeldet zu haben. Sieht tadellos aus, lässt sich nicht bauen.
• Regelverstösse der Oberflächen-Bibliothek. Bestimmte Bausteine dürfen nur an bestimmten Stellen stehen. Auch das sieht man dem Text nicht an.

Beides fiel bei mir erst in Android Studio auf. Das ist kein Beinbruch – die Fehlermeldung nennt Datei und Zeile, du schickst sie zurück, und die Sache ist in einer Minute erledigt. Aber du solltest damit rechnen und nicht erschrecken.

Deshalb die Trennung aus Kapitel 4

Hier zahlt sich aus, dass die Spielregeln in einem Teil liegen, der nichts von Android weiss: Diesen Teil kann Claude tatsächlich übersetzen und die Tests laufen lassen. Bei mir sind es 28 Tests, die vor jeder Auslieferung wirklich durchlaufen – nicht „sieht richtig aus", sondern nachgewiesen.

Für die Oberfläche geht das nicht. Dort bleibt nur: bauen, aufs Gerät spielen, anschauen.

Gespräche kurz halten, Änderungen bündeln

Zwei Angewohnheiten, die dich spürbar weniger Zeit und Kontingent kosten.

Fang rechtzeitig ein neues Gespräch an. Ein Verlauf schleppt alles Bisherige mit, und jede neue Nachricht arbeitet den ganzen Berg noch einmal durch. Ab einer gewissen Länge wird jede Kleinigkeit teuer, und irgendwann bricht mitten in der Arbeit etwas ab. Besser: Projekt als ZIP hochladen, Übergabedokument dazu, neu anfangen.

Sammle Änderungswünsche. Sechs Punkte in einer Nachricht sind deutlich günstiger als sechs einzelne Nachrichten – die Dateien müssen nur einmal angefasst werden, und Widersprüche zwischen den Punkten fallen sofort auf statt erst beim vierten Durchgang. Bei mir sah das dann schlicht so aus: „Folgende Änderungen:" und darunter eine Liste.

Ein Übergabedokument führen

Ein Gespräch wird irgendwann zu lang. Führe deshalb von Anfang an eine Datei – ich nenne sie HANDOFF.md – in der steht, wie das Projekt aufgebaut ist, welche Entscheidungen gefallen sind und welche Fehler schon vorkamen. Bei einem neuen Gespräch lädst du sie hoch, und es geht ohne Reibungsverlust weiter.

Schreib dort besonders die Dinge hinein, die schiefgingen. „Der Schwellwert beim Freistellen frisst helle Bildteile" ist nach drei Wochen vergessen – und genau dann passiert es wieder.

Ehrlich bleiben, was Aufwand angeht

Die KI schreibt den Code, nicht das Spiel. Die Regeln, die Prüfung auf dem Gerät, die hundert kleinen Entscheidungen über Farben, Abstände, Lautstärken und Formulierungen – das bleibt bei dir. Rechne für ein Spiel dieser Grösse mit zwei bis drei Wochen nebenher, nicht mit einem Wochenende.

12 Testen, bauen, veröffentlichen

Auf dem Gerät testen

Gerät per Kabel anstecken, in Android Studio oben auswählen, auf den grünen Pfeil drücken. Nach ein bis zwei Minuten läuft das Spiel. Jede weitere Änderung braucht nur noch Sekunden.

Teste unbedingt auf einem echten Gerät und wenn möglich auf einem schwächeren. Und teste mit jemandem, der das Spiel nicht kennt: Du weisst, wo man tippen muss. Deine Kinder wissen es nicht – und legen in fünf Minuten offen, was unklar ist.

Eine Prüfliste, die Ärger erspart

• Spiel drehen, während eine Animation läuft
• Mitten im Zug auf den Startbildschirm zurück und neu beginnen
• App in den Hintergrund schicken und zurückholen – läuft die Musik weiter?
• Beide Tonschalter aus, eine Partie spielen, wieder ein
• Alle Sonderfälle bewusst auslösen, auch zweimal hintereinander
• Eine Partie bis zum Ende spielen und den Endbildschirm prüfen

Der zweitletzte Punkt hat bei mir den Storch-Fehler gefunden. Sonderfälle zweimal hintereinander auszulösen ist unwahrscheinlich – aber bei genug Partien passiert es garantiert.

Die App bauen

Für den Versand an Freunde reicht eine APK: Build → Build Bundle(s) / APK(s) → Build APK(s). Die Datei liegt danach unter app/build/outputs/apk/debug/ und lässt sich direkt aufs Gerät kopieren.

Für den Play Store brauchst du ein signiertes App Bundle (AAB) über Build → Generate Signed Bundle / APK. Dabei erzeugst du einen Signaturschlüssel.

Diesen Schlüssel und sein Passwort musst du sichern. Ohne ihn kannst du nie wieder eine Aktualisierung derselben App veröffentlichen – auch Google kann das nicht rückgängig machen. Leg beides an einen Ort, den du in fünf Jahren noch findest, und niemals in dasselbe Verzeichnis wie den Code, falls der einmal öffentlich wird.

Was der Store sonst noch verlangt

Ein Entwicklerkonto kostet einmalig 25 US-Dollar. Dazu kommen ein App-Symbol in 512 × 512, eine Funktionsgrafik in 1024 × 500, mindestens zwei Bildschirmfotos, eine Beschreibung, eine Inhaltseinstufung und ein Formular zur Datensicherheit. Sobald deine App Daten speichert – und sei es nur eine Bestenliste auf dem Gerät – brauchst du zusätzlich eine Datenschutzerklärung unter einer erreichbaren Adresse.

Rechne dafür einen ganzen Abend. Es ist keine schwere Arbeit, aber es sind viele kleine Formulare, und der Store gibt sich mit halben Antworten nicht zufrieden.

Verteilen ohne Store

Für ein Spiel, das nur im Familien- und Bekanntenkreis laufen soll, ist der Store gar nicht nötig. Eine APK auf deine Website legen, einen QR-Code danebenhängen, fertig. Die Spielenden müssen einmal bestätigen, dass sie eine App aus fremder Quelle installieren wollen – mehr nicht.

Für SempiSplash war das ernsthaft die naheliegendere Lösung: Die Zielgruppe sass fünfzig Meter weiter auf demselben Campingplatz.

→ Und dann?

Wenn dein erstes Spiel läuft, ist der schwierige Teil vorbei. Nicht weil du jetzt programmieren kannst – sondern weil du weisst, wie die Teile zusammengehören und in welcher Reihenfolge man sie anfasst. Das zweite Spiel geht deutlich schneller.

Naheliegende nächste Schritte, grob nach Aufwand sortiert: ein Computergegner (gut machbar, liegt ganz im prüfbaren Teil des Codes), ein Statistikbildschirm, Bestenlisten, mehrere Schwierigkeitsstufen. Mehrspieler über Funk ist um ein Vielfaches aufwendiger, weil plötzlich zwei Geräte sich über denselben Spielstand einigen müssen.

Und der wichtigste Rat zum Schluss ist derselbe wie am Anfang: Fang klein an. Ein fertiges kleines Spiel ist mehr wert als ein grosses, das nie läuft.

§ Datenschutz

Wer eine App in den Play Store stellt, braucht eine öffentlich erreichbare Datenschutzerklärung – auch dann, wenn die App gar keine Daten erhebt. Genau das ist bei SempiSplash der Fall: keine Internet-Berechtigung, keine Konten, keine Werbung, keine Analyse. Die Bestenliste bleibt auf dem Gerät.

Die vollständige Erklärung, auf die auch der Eintrag im Play Store und der Link im Spiel zeigen, steht auf einer eigenen Seite.

Datenschutzerklärung öffnen →