🎮 Vibe coding deel 2: Boombaland, een game gebouwd met een team van AI-agents

💡 Dit is deel 2. Deel 1 gemist? Lees dan eerst Vibe coding: web en mobiele apps bouwen met AI.

In deel 1 vertelde ik over Oddsprey, mijn site die met AI voetbalwedstrijden voorspelt. Die staat inmiddels live, en is van begin tot eind vibe-coded. Daarna wilde ik iets groters proberen. Iets waar je niet mee wegkomt met een paar slimme prompts: een echte game.

Dat is Boombaland geworden: een kleurrijke 3D-game voor iPhone en Android waarin je bommen legt, wegrent en het speelbord ziet ontploffen. Gebouwd in mijn avonden en weekenden, met een team van AI-agents dat de code schrijft en een andere AI die de beelden tekent. Een paar maanden geleden was het nog een schets en een document. Nu speel ik het 's avonds op mijn telefoon, en eind november verschijnt het in de App Store en Google Play.

Benieuwd naar de game zelf? Kijk op boombaland.com. En ja, ook die site is met AI gebouwd. 😉

Wat is Boombaland?

Kort gezegd: het tactische spel van Bomberman, maar dan op zwevende eilanden boven de wolken, met een bord dat niet stil blijft liggen. Je speelt 25 levels, van een zwevend bos tot de kasteelweg, met puzzels, valstrikken en eindbazen die je flink op de proef stellen.

• Zes helden met elk een eigen superkracht. Blom, Gusto, Frosta, Zappy, Ember en Banshee. Ember vecht zelfs naast je mee.
• Eindbazen die terugvechten. Zoals de Thorn Guard, een levende boom die woedend wordt terwijl de vloer onder je voeten breekt.
• Puzzels in het kasteel. Duw kratten op hun plek en race tegen de zandloper.
• Vier moeilijkheidsgraden. Van ontspannen tot echt pittig.

Van idee naar plan

De grootste valkuil van vibe coding is niet slechte code, maar complexiteit die groeit zonder plan. Bij een game is die valkuil nog groter. Daarom begon Boombaland niet met code, maar met een gesprek met AI over wat de game moest zijn, en met concept art.

Uit dat gesprek kwamen twee documenten. Het GDD (Game Design Document) beschrijft wat de game is: de regels, de helden, de levels, wat het leuk maakt. Het TDD (Technical Design Document) beschrijft hoe hij gebouwd wordt: de architectuur en de regels die nooit gebroken mogen worden. Bijvoorbeeld dat de spelsimulatie volledig los staat van Unity en altijd hetzelfde potje oplevert bij dezelfde invoer. Alle balanswaarden staan in één bestand, BALANCE.md, en niet verspreid door de code.

Dit is misschien wel de belangrijkste les: een AI-agent die een goed plan meekrijgt, maakt veel minder eigen keuzes. En elke keuze die overblijft, kun je toetsen aan iets wat op papier staat.

Wat daarbij enorm helpt: goede mockups. Een schets van het startscherm, het menu of een level laat de AI zien wat je bedoelt, in plaats van dat hij moet raden. Eén plaatje van waar de knoppen moeten staan, zegt meer dan een alinea tekst. Ik plak mockups gewoon in het gesprek en verwijs ernaar vanuit het GDD.

Werken met AI-agents: geheugen, agents en skills

Ik ben klein begonnen: één AI-sessie, één taak tegelijk. In mijn setup is dat vooral Claude Code, maar dezelfde ideeën vind je inmiddels ook in andere tools, zoals Codex van OpenAI. Het eerste wat ik leerde: een AI-agent is net zo goed als de context die je hem geeft. Daarvoor zijn er drie bouwstenen.

Projectgeheugen (bij Claude heet dat CLAUDE.md, bij Codex AGENTS.md) bevat de werkafspraken die de agent bij elke sessie inleest. Elke keer dat er iets misging, werd dat een regel in dat bestand. Zo leert het team van zijn fouten, ook als de sessie zelf alles vergeten is.

Agents zijn specialisten met een eigen rol, eigen instructies en een eigen model. Boombaland heeft er elf: een scrum master, lead architect, simulatie-engineer, AI-engineer, QA-engineer en code reviewer op Opus, en presentatie-, UI-, data-, performance- en build-engineers op Sonnet. Elke agent werkt in een eigen git worktree, een aparte kopie van de code, zodat ze tegelijk kunnen bouwen zonder elkaar in de weg te zitten. En niemand controleert zijn eigen werk: QA en de code reviewer draaien de tests zelf opnieuw. Het schema hieronder laat de basis zien, met een echt voorbeeld.

Skills zijn pakketjes kennis en scripts die een agent inlaadt zodra ze relevant zijn. De agent ziet eerst alleen een korte beschrijving en laadt de rest pas als de taak erom vraagt. Ik gebruik onder andere de officiële Unity-plugin, om Unity vanuit de terminal te bedienen, en een eigen skill om Blender zonder scherm aan te sturen. Een skill toevoegen is wel een ontwerpkeuze: de Unity-skills voor physics en NavMesh heb ik bewust uitgezet, omdat ze niet passen bij de deterministische simulatie uit het TDD.

Welk model voor welke taak, en zuinig met tokens

Niet elke taak verdient het zwaarste model. Ik kies de aanpak en het model op basis van twee vragen: hoe groot is de taak, en hoe zeker weet ik wat er moet gebeuren?

• Klein en helder: one-shot. Een tekst aanpassen, een knop verplaatsen, een bug met een duidelijke oorzaak. Gewoon vragen en laten uitvoeren, meestal met Sonnet. Voor puur opzoekwerk is Haiku genoeg.
• Middelgroot: eerst plan mode. Een nieuwe puzzel of een nieuw scherm. In plan mode leest Claude eerst de code en schrijft een plan, zonder iets aan te passen. Ik lees het, stuur bij, en pas daarna wordt er gebouwd. Sonnet bouwt, Opus reviewt.
• Groot en onzeker: plan plus ontwerp. Een nieuw systeem of een architectuurkeuze. Dan eerst het ontwerpdocument bijwerken, het werk opknippen in kaarten van hooguit zo'n 400 regels, en verdelen over agents. Hier zet ik Opus in.

Over tokens: een Claude Max-abonnement is ruim, maar met elf agents raakt ook dat op. Wat bij mij het meeste scheelt:

• Overdragen in plaats van hervatten. Elke sessie begint vers vanuit een kort overdrachtsbestand van maximaal 60 regels: wat draait er, wat is af, wat is de volgende stap. Geen lange oude gesprekken die steeds opnieuw worden ingelezen.
• Opschonen bij elke nieuwe taak. Na een afgeronde kaart begint de context schoon.
• Alleen laden wat je gebruikt. Plugins en skills die ik niet gebruik, staan uit. Elke geladen tool kost context, ook als je hem niet aanroept.
• Geen Opus-agent om een bestand te zoeken. Waar een simpele zoekopdracht volstaat, hoort geen dure specialist.
• Tests in batches. Agents draaien Unity niet zelf. De coördinator verzamelt het werk en draait één testbatch voor alles samen.
• Compacte terminal-output. Met de tool RTK wordt de output van commando's ingekort voordat Claude die leest.

Twee AI's: een ontwikkelaar en een illustrator

Claude is sterk in code, plannen en controleren. Voor beelden werk ik met Codex van OpenAI, dat ook afbeeldingen kan genereren. Ze praten niet rechtstreeks met elkaar, maar via een gedeelde wachtrij: een simpele HTML-pagina die lokaal draait op localhost:8765.

Claude schrijft een genummerde opdracht (een brief) in die wachtrij. Een klein script houdt de wachtrij in de gaten en stuurt mij een melding zodra er iets nieuws staat. Codex pakt de brief op, maakt de beelden en zet ze op een reviewpagina, naast elkaar en op ware grootte. Daar kies ik. Mijn keuze gaat terug naar Claude, die het beeld verwerkt en in de game zet.

Voorbeeld: Cobblewatch, van brief tot game

Cobblewatch is een van de vijanden: een wachter van steen met een speer. De eerste versies vond ik te braaf. Dus schreef Claude brief g138 voor Codex, met daarin onder andere:

• Maak R4 op basis van R3, met een duidelijke neus en een grote snor.
• Lever drie opties: R4a, R4b en R4c.
• Formaat 768×1024 met transparante achtergrond.
• Bestemming in de game: het portret van vijand 07.

Codex leverde drie varianten. Op de reviewpagina koos ik R4b, die met de zwarte snor.

Daarna ging het snel. Claude zette het portret in de game en legde dat vast als beslissing D-33.412. Met een tweede brief maakte Codex van R4b een turnaround: hetzelfde personage van voor, opzij en achter. Die turnaround gebruikte Claude als referentie om het 3D-model in Blender bij te werken, met dezelfde neus en snor. De render legt het model naast de tekening van Codex, zodat ik in één oogopslag zie of ze overeenkomen.

Via de Unity CLI wordt het model geïmporteerd, draaien de tests en wordt alles gecommit. En dan staat hij gewoon op het bord, klaar om je te achtervolgen.

Voorbeeld: van feedback op je telefoon naar een nieuwe versie

De mooiste loop is die vanaf mijn telefoon. Ik test de game via TestFlight op mijn iPhone. Zie ik iets wat niet klopt, dan maak ik een screenshot en typ ik er een notitie bij, direct in de app.

Een echt voorbeeld van 30 oktober. Om 12:39 speel ik level 25. De game zegt "This is EMBER! EMBER fights beside you", maar Ember is nergens te zien. Screenshot, notitie: "Ember is not shown on the map, during this text."

Wat er daarna gebeurt, gaat grotendeels vanzelf:

• Een script haalt de feedback op uit App Store Connect en zet hem in een inbox.
• De coördinerende agent leest de notitie en de screenshot, maakt er kaart D-35.166 van en zet een simulatie-engineer erop, in een eigen worktree.
• Die schrijft eerst een test die faalt ("Ember staat in beeld zolang haar uitleg zichtbaar is") en maakt die daarna groen.
• Het werk gaat mee in de volgende testbatch: ruim 7.000 editortests en 2.500 playmode-tests, allemaal groen.
• Er gaat een nieuwe build naar TestFlight. Mijn telefoon werkt de game zelf bij.

Dezelfde middag stond de nieuwe build klaar. Van notitie op de bank tot oplossing op mijn telefoon, zonder dat ik zelf een regel code schreef. Gaat het om een beeld in plaats van code, dan schrijft Claude een brief voor Codex en gaat de asset-loop van hierboven draaien.

Wat kost het?

Minder dan je zou denken:

• Tijd: zo'n één tot twee maanden aan avonden en weekenden.
• Claude Max-abonnement voor Claude Code.
• Codex voor de beelden, via een ChatGPT-abonnement.
• Verder vooral gratis en open source: Blender, Unity Personal, Git en de skills. Alleen de ontwikkelaarsaccounts van Apple en Google kosten nog een klein bedrag per jaar.

Dat zegt meer over de tijd waarin we leven dan over mij. Een paar jaar geleden had je hier een studio voor nodig.

Wat ik ervan leer

• Een plan is het contract. Met een GDD en TDD maakt de AI minder eigen keuzes.
• Kleine stappen, bewezen met een test. 'Het werkt' is geen bewijs. Een test die eerst faalde en nu slaagt, wel.
• Scheid bouwen en controleren. Een agent kan er vol overtuiging naast zitten. Een andere agent die het opnieuw controleert, vangt dat op.
• Kies het model bij de taak. Opus voor oordeel en architectuur, Sonnet voor goed afgebakend bouwwerk, Haiku voor opzoekwerk.
• De mens houdt het oordeel. Wat leuk is, welke versie mooier is en wat binnen scope valt: dat beslis ik. Van een snor tot de moeilijkheid van een eindbaas.

En in mijn werk?

Boombaland is een hobbyproject, maar het levert me iets op wat ik elke dag gebruik: ik leer beter omgaan met AI-tools en begrijp steeds beter welke werkwijzen echt werken. Een goed plan, kleine stappen, tests als bewijs, en bouwen en controleren uit elkaar houden. In deze setup zijn dat Claude en Codex van OpenAI, maar dezelfde technieken worden ook in andere tools opgepakt. Wat je hier leert, neem je dus overal mee naartoe.

Ook in mijn werk met Splunk en Cribl worden AI en vibe coding steeds meer mogelijk. Cribl heeft inmiddels een eigen MCP-server, waarmee een AI-assistent direct met je Cribl-omgeving kan werken. Daarnaast kun je de complete Cribl-interface aanpassen of er eigen features in bouwen. Bij Splunk kun je sinds kort ook de frameworks gebruiken waarmee Splunk zelf werkt, om eigen apps en visualisaties te maken. Met een AI-agent die de juiste context krijgt, is dat ineens geen project van maanden meer, maar van dagen.

Zelf spelen?

Boombaland verschijnt eind november in de App Store en Google Play. Kun je niet wachten? Er loopt een besloten bèta voor iPhone en Android. Stuur me een bericht met "Boombaland bèta" en vermeld of je een iPhone of Android hebt, dan stuur ik je een uitnodiging. Feedback is meer dan welkom, en wie weet zie je jouw notitie terug in de volgende build.

Alles over de game, de helden en de levels vind je op boombaland.com.

Contact

📬 Wil je meespelen in de bèta, sparren over AI-agents, of horen hoe ik dit inzet met Splunk en Cribl? Neem contact op via de opties hieronder, of stuur me een bericht op LinkedIn.