Å lage et spill med et team av KI-agenter

Jeg lager et spill på si. Et roguelite-strategispill, siden du spør. Mer om selve spillet når det er klart.

Dette innlegget handler om hvordan det blir til. Jeg gjør det ikke alene, og jeg gjør det ikke med et studio heller. Teamet mitt er en liten gruppe KI-agenter, der hver har ansvar for én del av jobben. Jeg er kreativ leder. De gjør mye av resten.

Det er delvis et eksperiment, delvis en designprosess, og så langt fungerer det bedre enn jeg trodde. Her er oppsettet.

Møt teamet

En agent er en KI-assistent med én bestemt jobb, egne instruksjoner og tilgang til bare de delene av prosjektet den trenger. Når områdene holdes adskilt, kan flere av dem jobbe samtidig uten å gå i beina på hverandre.

En hovedagent koordinerer, og sju spesialister tar resten. Merket på hvert kort viser hvilken Claude-modell agenten bruker, og hvor mye den tenker. De som tenker tyngst, får den store modellen.

• Isabel

  Kreativ leder

  Jeg bestemmer hva spillet skal være. Jeg godkjenner planer og regler før noe bygges, spiller hver milepæl og har siste ord om hvordan ting føles.

  Menneske, siste ord
• Forvalteren

  Hovedagent

  Agenten jeg snakker direkte med. Den gjør forespørslene mine om til planer, deler ut oppgaver til spesialistene, sørger for at arbeidet henger sammen, og spør meg når noe må avgjøres.

  Opus, høy innsats
• Regelsmeden

  Spilldesigner

  Skriver reglene for hver del av spillet, også de rare unntakene, så alle bygger ut fra samme beskrivelse.

  Opus, høy innsats
• Mekanikeren

  Gameplay-utvikler

  Skriver koden som driver reglene bak kulissene, sammen med automatiske tester som sjekker at den virker.

  Opus, høy innsats
• Scenearbeideren

  Godot-utvikler

  Bygger det spillerne ser og tar på: skjermer, menyer, kontroller og animasjon.

  Opus, middels innsats
• Kortsmeden

  Innholdsforfatter

  Lager spillets innhold som datafiler, som sjekkes for feil automatisk.

  Sonnet, middels innsats
• Krønikeskriveren

  Lorevokter

  Tar vare på historien, navnene og tonen i verdenen, og holder teksten i tråd med hva ting faktisk gjør.

  Sonnet, høy innsats
• Regnemesteren

  Balanseanalytiker

  Kjører tusenvis av simulerte spill for å finne det som er urettferdig eller for tregt, og melder hva som bør justeres.

  Sonnet, middels innsats
• Vokteren

  QA-kontrollør

  Går gjennom hvert arbeid før det godtas, og sjekker at hver milepæl når målene sine.

  Opus, høy innsats

Ja, de har navn. Navnene gjorde rollene lettere å huske, og mye morsommere å jobbe med.

Fra idé til spillbar versjon

Hver ny funksjon går gjennom de samme stegene. Det er en designprosess, bare med et veldig raskt team.

1. Jeg setter målet. Jeg beskriver hva vi lager og hvordan vi vet at det er ferdig. Målet handler alltid om hvordan det spilles, ikke hvordan det ser ut: dette skal være gøy med enkle firkanter i stedet for grafikk.
2. Forvalteren planlegger. Den deler arbeidet opp i oppgaver og fordeler dem. Jeg går gjennom planen og justerer før noe bygges.
3. Reglene skrives. Regelsmeden skriver ned nøyaktig hvordan funksjonen virker, også de sjeldne tilfellene. Jeg godkjenner reglene.
4. Bygging i parallell. Mekanikeren skriver koden og testene, mens Kortsmeden og Krønikeskriveren lager innholdet og teksten.
5. Det kommer på skjermen. Scenearbeideren bygger grensesnittet, med støtte for både mus og kontroller.
6. Testing. Regnemesteren simulerer tusen spill for å sjekke balanse og tempo, og Vokteren sjekker arbeidet mot det opprinnelige målet.
7. Automatiske sjekker. Hver endring sendes inn som en pull request. Testene kjører automatisk, og ingenting blir en del av spillet før alle går gjennom.
8. Jeg spiller. Er det ikke gøy ennå, går notatene tilbake til Regelsmeden, og vi tar en runde til. Grafikken kommer til slutt, når den enkle versjonen spiller godt.

Det første og det siste steget er mine med vilje. Agentene er raske, men å bestemme hva «bra» betyr, og å merke når noe føles feil, er fortsatt en menneskejobb. Det er også den beste delen.

Felles hukommelse

KI-agenter husker ikke tidligere samtaler. Hver økt starter på null. Alt viktig må derfor skrives ned, og prosjektets filer blir teamets hukommelse. Hver agent leser det den trenger når den starter, og oppdaterer det før den stopper.

• Husregler. Den første filen hver agent leser: hvordan prosjektet er organisert, hvordan arbeid overleveres, hva som krever min godkjenning, og hvordan endringer lagres.
• Designdokumentet. Hele designet av spillet. Agentene kan oppdatere det, og hver endring logges med hva som ble endret, hvorfor og av hvem.
• Statustavla. Hva som er ferdig, hva som pågår og hva som kommer, oppdatert på slutten av hver økt.
• Overleveringer. Stopper en agent midt i en oppgave, legger den igjen et notat: hva som er gjort, hva som gjenstår, og åpne spørsmål. Den neste tar over derfra.
• Spesifikasjoner. De detaljerte reglene for hver del av spillet, godkjent av meg før noe kode skrives.
• Beslutningslogg. Korte notater om viktige valg og hvorfor vi tok dem, så vi slipper å diskutere dem to ganger.
• Lore. Spillet henter teksten sin rett fra disse filene, så det spillerne ser, alltid stemmer med kilden.

Morsomt nok er dette det samme jeg maser om i menneskelige team. Skriv ned beslutninger. Legg igjen et overleveringsnotat. Ha én sannhetskilde. Agenter kommer bare ikke unna det.

Rekkverk

Når flere agenter jobber samtidig, holder noen få regler prosjektet på beina.

I tillegg havner hver endring i spilldesignet i en endringslogg: hva som ble endret, hvorfor og hvilken agent som gjorde det. Når noe går i stykker, ser jeg nøyaktig hvordan vi havnet der.

Veikartet

Det første målet er lite, men komplett: en kort versjon av spillet med en hel runde fra start til slutt. Det er delt i seks milepæler, og hver må nå målet sitt før neste begynner.

1. 1Milepæl 1Grunnmur
2. 2Milepæl 2Kjernekamper
3. 3Milepæl 3Kartet
4. 4Milepæl 4Hel runde
5. 5Milepæl 5Variasjon
6. Milepæl 6Stil

Vi er i starten, med grunnmuren på plass: prosjektet, motoren og testene er satt opp, og det første innholdet er allerede lagt til av en agent. Hver milepæl har et mål skrevet som en følelse, ikke en funksjonsliste. Den siste er ikke ferdig før spillere utenfra vil spille igjen.

Nye versjoner

Det samme systemet som kjører testene, pakker også spillet, så det finnes en fersk versjon å prøve etter hver godkjente endring.

• Hver endring: Windows- og Linux-versjoner, laget automatisk så jeg og agentene kan teste.
• Senere: private spilltester med en liten gruppe testere.
• Til slutt: bredere testing på Steam, så lansering. Støtte for Steam Deck er planlagt fra starten.

Det jeg har lagt merke til så langt

Dette oppsettet ligner mye på å lede et designteam. Tydelige roller. Et felles mål. Nedskrevne beslutninger. Små steg du kan teste. Og noen som holder visjonen og sier «ikke ennå» når det ikke er gøy.

Forskjellen er tempoet. Ideer blir til noe spillbart mye raskere, så jeg bruker mer tid på det jeg bryr meg mest om: å bestemme hvordan spillet skal føles, og å spille det til det gjør det.

Mer når det er klart.