Jacquard och typade världar för AI-byggda spel

AI-byggda spel ser enkla ut i en demo. Det svåra är typade begränsningar, editorstöd, fysik, NPC-beteende, repriser och säker generering som en mänsklig...

Jacquard och typade världar för AI-byggda spel

Demon är den lätta delen

Den första Jacquard-demon är medvetet förförisk. En agent öppnar en webbläsarnativ motor, anropar ett typat verktyg, skapar en scen, formar terräng, placerar objekt, kopplar beteenden, sparar bunten och lämnar över världen till en människa som kan trycka på play. Ingen flera gigabyte stor editor. Ingen skrivbordsmotorsceremoni. Ingen ritual med att installera en nativ verktygskedja innan den första idén kan röra sig.

Om det vore hela historien skulle Jacquard vara lätt att förklara: snabbare prototyper, billigare träningssimuleringar och små interaktiva världar skapade från naturligt språk. Källmaterialet stöder delvis den bilden: Jacquard är ett Dweve-forskningsprojekt, skrivet i strikt TypeScript och utformat för att köras i en webbläsarflik. Ruttmetadata beskriver en webbnativ spelmotor där AI-agenter bygger kompletta spel genom ett typat API, med visuell editor, fysik och NPC-beteenden inkluderade.

Men en bra demo kan dölja det verkliga problemet. Att få en agent att producera en trovärdig spelscen är inte längre den svåra delen. Det svåra är att göra den genererade världen tillräckligt begränsad för att inspekteras, tillräckligt redigerbar för en designer, tillräckligt fysisk för att spelas, tillräckligt beteendemässig för att vara meningsfull och tillräckligt säker för att generering inte ska bli ett nytt sätt att skapa tillstånd som inte kan granskas.

Det är den intressanta frågan: kan en spelmotor exponera varje meningsfull operation som en typad yta som delas av agenter och människor, samtidigt som den bevarar repris, författarskap, säkerhet och designens textur?

Varför frågan fortfarande är öppen

Ett vanligt paketerat verktyg försöker frysa sitt löfte. Så här fungerar det. Så här ser supportmodellen ut. Så här går gränsen. Så här ser feltillståndet ut. Jacquard är mer intressant innan de meningarna blir för släta, eftersom de svåra frågorna fortfarande hänger samman.

Den nuvarande källkoden beskriver en agent-först-motor, en MCP-yta, deterministisk repris, Rapier3D i WASM, WebGPU med WebGL2 som reserv, glTF 2.0-tillgångar och en webbläsarbaserad väg. Det är konkreta tekniska val. De är också bara början på det sociala kontraktet kring AI-skapade spel.

Spel är inte dokument med kollisionsboxar. En spelvärld är en levande uppsättning av geometri, tajming, fysik, indata, tillståndsövergångar, spelarförväntningar och författad överraskning. Om ett AI-system genererar en rapport kan en läsare markera ett stycke som fel. Om ett AI-system genererar en spelvärld kan felet visa sig som en dörr som inte går att nå, en icke-spelbar karaktär som ljuger om uppdragsstatus, en fysikimpuls som bryter reprisen eller en editoroperation som agenten utförde men som designern inte kan förstå i efterhand.

De obekväma frågorna är poängen. Vad ska en agent få mutera direkt? Vilka editorfunktioner måste vara förstklassiga typade operationer? Vilka genererade tillgångar är säkra att paketera? Vilka beteenden måste kunna inspekteras innan de körs? Vilket världstillstånd hör hemma i en händelselogg snarare än i en dold motorheap? Det här är inte kosmetiska backlogposter. Det är motorn.

Motorn är ett argument om räckvidd

De flesta spelmotorer är utmärkta verktyg för människor vid ett skrivbord. Det gör dem inte till bra underlag för agenter. Deras kraft ligger ofta bakom menyer, paneler, motorspecifika skriptspråk, proprietära tillgångspipelines och UI-flöden som förutsätter att en person visuellt kan söka efter nästa kontroll. En agent kan lära sig att klicka, men att klicka genom en editor är inte samma sak som att ha ett programmatiskt kontrakt.

Jacquard blir svårt just för att räckvidden är problemet: varje genererad världsåtgärd behöver en typad väg.

Jacquard intar den motsatta positionen. Om editorn kan göra det, ska ett verktygsanrop kunna göra det. En funktion som en agent inte kan nå via kod existerar egentligen inte för den här forskningsfrågan. Den regeln låter hård tills du ser en agent försöka bygga en värld i en motor som bara har ett grafiskt gränssnitt. Agenten tvingas till approximationer: gissa menyn, hoppas att den valda panelen är aktiv, skrapa en felsträng och fortsätta med ett tillstånd den inte kan bevisa.

Källan namnger friktionen rakt på sak: funktioner som bara finns i grafiska gränssnitt, tunga installationer, motorns egna DSL:er, stängda pipelines. Jacquard svarar med en webbläsarflik, öppna format, glTF-tillgångar, serialiserbara världar, schema-validerade parametrar, typade fel och en enda typad yta som delas av den visuella editorn och agenten. Det är därför motorn inte bara är en motor. Den är ett experiment i räckvidd.

Räckvidd är inte bekvämlighet. Det är säkerhet. När varje operation är ett anrop kan varje operation namnges, begränsas, loggas, avvisas, spelas upp och förklaras. När kapacitet är gömd bakom en meny måste agenten smuggla in avsikter genom en yta som aldrig designats för det. Skillnaden är skillnaden mellan en ingenjör som läser en API-spårning och en människa som försöker minnas vilken panel som var öppen när scenen ändrades.

En värld är inte en bild

AI-bildgenerering har tränat människor att acceptera en märklig byteshandel: be om en bild, få en bild, förlåt strukturen om ytan ser rätt ut. Spel kan inte överleva den byteshandeln. En spelbana bedöms inte bara utifrån vad den liknar från en kamera vinkel. Den bedöms utifrån om en spelare kan röra sig genom den, om fysiken förblir stabil, om mål löser sig, om NPC-beteende respekterar världen och om tillståndet kan spelas upp när något går fel.

En värld är inte en bild. Den är tillstånd, regler, tid och uppspelbara konsekvenser.

Det är här som typade begränsningar blir centrala. Ett terrängverktyg kan inte bara måla kullar. Det måste veta var gångbara ytor finns, hur sluttningar samverkar med karaktärskontroller, hur vegetation och belysning påverkar sikt, och hur fröbaserad generering senare ska återskapa samma resultat. Ett scenverktyg kan inte bara placera saker. Det måste skapa adresserbara entiteter, koppla komponenter, versionshantera grafen och göra resultatet tillräckligt diffbart för granskning.

Jacquards verktygspalett gör detta synligt. Sidan namnger femton kategorier: scen, entitet, komponent, asset, material, fysik, terräng, belysning, ljud, UI, quest, NPC, build, debug och playtest. Den namnger också skrivskyddade resurser som projektmetadata, scenograf, assetkatalog, prestandamått och fellogg. Det är ingen godtycklig meny. Det är en taxonomi över vad en spelvärld måste exponera innan en agent kan vara mer än en smart makroinspelare.

Forskningsproblemet är inte huruvida alla femton kategorier kan existera. De existerar redan som ett källpåstående. Problemet är hur uttrycksfulla, säkra och komponerbara var och en måste vara innan genererade världar slutar vara sköra artefakter och börjar bete sig som författade system. Svaret kommer inte att hittas genom att prompta hårdare. Det kommer att hittas genom att göra representationen svårare att ljuga för.

Editorn är ingen dekoration

En svag läsning av agentförst verktyg behandlar editorn som en visare. Agenten skapar saker; människan tittar på. Det är fel modell för Jacquard. Källtexten är noggrann: den visuella editorn använder samma API som agenter. Den är en icke-privilegierad klient till samma yta. Det enda faktumet förhindrar att en djup klyfta bildas inom projektet.

Om agenten har en privat väg in i världen och editorn en annan, förlorar människan till slut. Det genererade tillståndet blir tekniskt giltigt men praktiskt taget oredigerbart. Designern kan se slottet, men kan inte upptäcka varför questflaggan är kopplad till just den entiteten, varför terrängen har en osynlig blockerare, eller varför NPC-schemat ändras efter andra natten. Resultatet ser ut som produktivitet och beter sig som skuld.

Delat API innebär att editorn måste ha stöd för samma koncept som agenten manipulerar. Den måste visa scenograf, komponenter, beteenden, resurser, fel och prestanda på sätt som en människa kan resonera kring. Den måste låta designern korrigera världen utan att kliva utanför det kontrakt som uppspelning är beroende av. Editorn är därför en del av forskningsinstrumentet.

Detta är ett obekvämt krav eftersom det saktar ner fantasin. Det är lättare att låta agenten generera dold koppling och sedan hoppas att demon fortsätter fungera. Jacquard kräver att den dolda kopplingen blir tillräckligt synlig för att en designer ska kunna ta ägarskap. AI-byggda spel blir bara seriösa när människan kan ärva dem utan rättsmedicinsk arkeologi.

Fysik är där charm blir ansvarsskyldighet

Fysik har ett brutalt sätt att förvandla vag generering till synligt misslyckande. En berättelse kan tåla lite narrativt handviftande. En 3D-värld med kroppar, kollisioner, terräng och spelarinmatning kan inte. Om steget ändras med bildhastigheten, driver uppspelningen. Om karaktärskontroll beror på en ologgad impuls, blir en buggrapport ett rykte. Om samma frö producerar olika kroppspositioner på en annan maskin, är världen inte reproducerbara bevis.

Fysik är det första stället där genererad charm måste svara mot ett mekaniskt system.

Jacquard förankrar detta med Rapier3D i WASM och ett fast tidsteg på 60 Hz. Källmaterialet beskriver deterministisk fysik, seedad slump, inspelad input och mekanisk repris från en typad händelselogg. Samma seed, samma logg, samma bildrutor. En buggrapport är den bifogade loggen; spela upp den och se vad spelaren såg. Det är ett starkare påstående än en skärminspelning, eftersom det bevarar de interaktiva orsakerna, inte bara pixlarna.

Forskningsfrågan är vad som händer när generering går in i den loopen. En agent kan skapa en bro, men bron måste följa begränsningar för massa, kollision, nåbarhet och playtest. Den kan skapa en NPC, men NPC:n måste navigera i en värld vars geometri kan ändras. Den kan justera terräng, men de resulterande lutningarna måste förbli spelbara. Den kan lägga till en scriptad händelse, men den händelsen måste loggas på ett sätt som reprisen kan vika in.

Fysik är därför inte ett delsystem längst ner i stacken. Det är en av domarna över generering. En genererad spelvärld är inte bra för att den ser trovärdig ut. Den är bra när spelaren kan vistas i den, när reglerna håller och när en senare granskare kan spela upp samma misslyckande i stället för att fråga modellen vad den menade.

NPC-beteende är lagret där språket tar slut

Icke-spelbara karaktärer gör Jacquard svårare än en leveleditor. Ett statiskt rum kan inspekteras som geometri. En NPC är tillstånd över tid: schema, mål, perception, dialog, social graf, questrelation, pathfinding, minne och misslyckande. Källmaterialet namnger beteendeträd, scheman, mål, narrativ som data, konditionsgrafer och förgrenad progression. De orden är där AI-byggda spel slutar vara en leksak.

Språk är användbart för avsikt. Det är en dålig slutlig representation för beteende. En prompt kan säga att en vakt ska vara misstänksam på natten, hjälpsam mot bybor, fientlig mot tjuvar och förlåtande efter att spelaren slutfört en uppgift. Motorn behöver något skarpare: vilken sensor läser fara, vilket villkor ändrar attityd, vilken questflagga åsidosätter misstänksamhet, vilket schema flyttar vakten och vilken dialograd är tillåten efter tillståndsövergången.

Den skärpan är varför typade NPC-verktyg spelar roll. Utan dem producerar agenten vibbar. Med dem måste den skriva beteende i inspekterbara strukturer. Designern kan då fråga om vakten är orättvis, om questen kan hamna i dödläge, om den sociala grafen skapar omöjliga förpliktelser eller om en genererad instruktion skulle få varje NPC att konvergera mot samma tråkiga rutin.

NPC-beteende gör också säkerhet praktiskt. Osäker generering är inte bara stötande text eller förbjudet innehåll. Det kan vara en beteendeloop som fångar spelaren, ett uppdrag som inte kan lösas, en genererad social graf som kodar en fientlig stereotyp, eller ett schema som skapar prestandakollaps. Säkerhet kring generering måste verka på nivån av spelsystem, inte bara på ordnivå.

Säkerhet är ett formproblem

Den enklaste säkerhetsberättelsen säger att agenten kanske genererar ett innehåll, kanske inte. Jacquard behöver en mer strukturell berättelse. Frågan är inte bara om en genererad tillgång är tillåten. Det är om den genererade förändringen passar världskontraktet. Muteras bara den omfattning som gavs? Exponeras det som ändrades? Kan redigeraren inspektera det? Kan repris återskapa det? Kan bygg- och playtestverktygen avvisa det innan en människa misstar nyhet för färdigställande?

Säkerhet är inte en varningsetikett. Det är en form som påtvingas av budgetar, typer, repris och gränser.

Källan pekar mot detta genom typade anrop, schemavalidering, skrivskyddade resurser, debug, playtest, portabla paket och öppna filer. Det är inte glamorösa säkerhetsfunktioner, men de betyder mer än ett dramatiskt avvisningsmeddelande. Ett begränsat anrop kan nekas. Ett typat fel kan repareras. En skrivskyddad resurs kan låta en agent inspektera utan att mutera. Ett byggsteg kan paketera bara det som är serialiserbart. En deterministisk playtest kan avslöja att den genererade dörren aldrig öppnas.

Säker generering innebär också att motstå frestelsen att dölja osäkerhet. Om agenten inte kan veta om ett pussel är lösbart, bör systemet inte paketera det som löst. Om ett NPC-beteende beror på ett tvetydigt tillstånd, bör redigeraren göra den tvetydigheten synlig. Om fysikrepris divergerar, bör påståendet misslyckas. Misslyckandets vokabulär byggs fortfarande.

Jacquard bör göra osäkerhet synlig istället för att polera den till ett falskt löfte. När genererat innehåll inte är tillräckligt begränsat bör redigeraren, loggen, reprisvägen och de typade felen exponera gapet medan det fortfarande är litet nog att fixa. Det är inte grovhet för sin egen skull. Det är så genererade världar undviker att bli innehållsskuld.

Webbläsaren ändrar iterationsekonomins villkor

Jacquard som körs i en webbläsarflik kan låta som en distributionsfunktion, och det är det. Nollinstallation sänker kostnaden för att prova en värld. WebGPU och WebGL2 ger motorn en praktisk renderingsväg. Ett klassrum, en forskningspartner eller en designsession behöver inte börja med en tung nativ installation. Men webbläsaren spelar roll av en djupare anledning.

Den gör iterationsloopen kortare. En agent kan bygga, redigeraren kan inspektera, spelaren kan testa och loggen kan spelas upp utan att flytta världen genom en kedja av proprietära verktyg. Samma miljö kan exponera en scenegraf, köra fysik, spela ljud, inspektera prestanda och paketera ett portabelt paket. Det löser inte speldesign, men det tar bort mycket onödig ceremoni från att studera den.

Webbläsaren gör också gränserna tydligare. Om världen öppnas som en webbsida kan gränsen för vad som kördes, vad som laddades, vilket tillstånd som ändrades och vad som exporterades göras explicit. Om motorn är strikt TypeScript riktat mot ES2022, med öppna glTF-tillgångar och serialiserbara världar, kan artefakten läsas av fler människor än den lilla prästerskapet kring en enda skrivbordsmotor.

Den öppenheten är en praktisk fördel. Fler ögon kan granska representationen. Fler agenter kan kopplas in via MCP. Fler misslyckanden kan återskapas som loggar i stället för att berättas som anekdoter. Webbläsaren gör inte problemet enkelt. Den gör problemet observerbart.

Prototypens tryck skulle krossa det

Det finns en välbekant mjukvarureflex: när något demonstrerar väl, polera det tills det går att paketera. Jacquard är exakt den typen av system som straffar den reflexen. Polerar man för tidigt måste teamet låtsas att författarkontraktet är fastställt innan de svåra frågorna är lösta. Vad är det stabila författarkontraktet? Vilka genererade beteenden går att stödja? Vilka fysikanspråk håller över webbläsare? Vilka editorbegrepp är nu permanenta? Vilka säkerhetskontroller är obligatoriska?

Ett för tidigt paket skulle behöva låtsas att svaren redan är fastställda. Det skulle begränsa forskningen till det som är lättast att paketera. Resultatet skulle bli en rolig leksak med en polerad framsida och en skör baksida. Jacquards intressanta löfte är större: en spelmotor där AI-agenter och mänskliga designers delar samma typade operativa yta, där världstillståndet är inspekterbart, där repris är mekanisk och där generering begränsas av system snarare än vibbar.

Det löftet förtjänar tålamod eftersom det rör flera svåra fält samtidigt. Programspråksdesign syns i verktygsschemana. Människa-datorinteraktion syns i editorn. Simulering syns i fysiken. Spel-AI syns i NPC-beteende. Säkerhet syns i gränserna kring generering. Infrastruktur syns i paketering, webbläsarkörning och öppna format. En snäv implementering skulle välja ett och kalla de andra för randfall. Jacquard håller dem sammankopplade.

Poängen är att hålla anspråket precist. Jacquard är forskning om agentstyrd, webbläsarnativ spelutveckling. Det kan vara användbart för experiment och partnersamarbete utan att låtsas att varje författarkontrakt är slutgiltigt. Den ärligheten är en del av ingenjörskonsten.

Vad som gör forskningen trovärdig

Tecknen är inte marknadsföringstecken. De är tekniska och erfarenhetsmässiga tecken. En genererad värld ska kunna inspekteras genom editorn utan hemligt tillstånd. Verktygsanrop ska misslyckas med användbara typade fel. Repris ska återskapa meningsfulla misslyckanden. NPC-beteenden ska vara läsbara som data och felsökningsbara som system. Speltest ska fånga uppenbara omöjligheter innan de blir mänsklig besvikelse.

Motorn ska också bevara författarskap. AI-byggda spel behöver fortfarande mänsklig smak. Agenten kan utkasta en värld, men designern måste kunna forma den utan att tappa spåret av hur den skapades. Om människan måste börja om för att återfå kontrollen var agenten ingen samarbetspartner. Den var en snabb källa till teknisk skuld.

Säkerhet borde bli mindre teatralisk och mer mekanisk. En genererad ändring ska bära omfattning, ursprung och granskningsstatus. Skrivskyddad inspektion ska vara åtskild från mutation. Bygget ska vägra det som inte kan paketeras rent. Felsökning ska visa var ett beteende kom ifrån. Speltest ska vara tillräckligt skriptbart för att göra anspråk upprepningsbara. Det är tråkiga ord, vilket är varför de betyder något.

När dessa egenskaper är vardagliga kan Jacquard stödja starkare löften. Tills dess är forskning den ärliga etiketten. Den säger till teamet och läsaren att målet inte bara är att få AI att producera spel, utan att göra AI-producerade spelvärldar läsbara nog att äga.

Det användbara anspråket

Jacquard och typade världar för AI-byggda spel, för det handlar egentligen inte om spel som dyker upp ur prompts. Det handlar om maskineriet som krävs innan promptade spel blir seriösa artefakter: typade begränsningar, delade editorfunktioner, deterministisk fysik, inspekterbart NPC-beteende, öppna tillgångar, portabla paket och säkerhet kring generering.

Den användbara bilden är inte en magisk motor. Det är en verkstad där agenten och designern rör vid samma verktyg. Agenten får ingen hemlig dörr. Editorn får ingen svagare karta. Fysiksystemet blir inte valfritt bara för att scenen ser snygg ut. Händelseloggen försvinner inte efter demon. Den genererade världen förblir en värld som någon kan inspektera, spela om, ändra och försvara.

Det är ett långt ingenjörsprogram, inte en slogan. Om det lyckas blir ytorna mot användaren tydligare eftersom de svåra frågorna inte forcerades. Om det misslyckas lär misslyckandet ändå något om villkoren under vilka AI säkert kan skapa interaktiva system. Båda utfallen är användbara.

Just nu är det mest precisa man kan säga detta: Jacquard är en öppen forskningsmotor för AI-byggda spelvärldar. Den får vara spännande. Den måste också vara exakt. Framtiden för AI-författade spel vinns inte av den vackraste första scenen. Den vinns av den värld som fortfarande är begriplig när spelaren, designern, agenten och reprisloggen alla återvänder till den.