Vad kan en försvunnen karaktärs AI-assistent egentligen veta i ett mysterium?
I ett fiktivt mysterium bör en AI-assistent bara känna till de berättelseuppgifter som författaren har gjort tillgängliga för den – och bara från den tidpunkt i berättelsen då uppgifterna blir åtkomliga. Ange en källa, när den blev känd och en åtkomstregel för varje faktum. Då kan assistenten hjälpa spelarna att knyta ihop ledtrådar utan att i smyg bli en allvetande berättare.
Skilj berättelsens uppgifter från assistentens åtkomst
Börja med en fullständig berättelsedokumentation avsedd för författaren: händelser, karaktärers uttalanden, föremål, meddelanden och i vilken ordning de introduceras i spelet. Definiera sedan en mer begränsad vy för assistenten. Ett faktum kan finnas i berättelsebibeln utan att ännu vara tillgängligt för assistenten. Den skillnaden är grunden för ett rättvist mysterium: författaren kan veta vad som hände, medan assistenten bara kan använda uppgifter som dess fiktiva roll ger den rätt att se.
Verktyg för interaktiv fiktion, som Twine, organiserar berättelser i passager och kan använda variabler och villkorslogik för att förändra vad spelaren ser. Det ger en användbar designanalogi: behandla varje författad uppgift som en separat enhet och gör åtkomsten villkorad av den relevanta passagen, händelsen eller det val som görs. Twines grundläggande begrepp
Anta till exempel att en fiktiv karaktär vid namn Mara förbereder en utställning för en gemensam trädgård. Assistenten kan ha tillgång till en planeringsanteckning som hon delade, ett schema som publicerats på gruppens anslagstavla och ett senare meddelande där hon skriver att hon flyttar in målade skyltar. Den bör inte dra slutsatser om var Mara befinner sig bara för att den vet att hon tycker om trädgårdsarbete, och den bör inte se ett privat utkast som aldrig delades med den. De gränserna följer av berättelsens författade åtkomstregler, inte av några påståenden om vad verkliga AI-system kan komma åt.
Ange en källa och tidpunkt då varje faktum blev känt
En användbar faktauppgift besvarar minst fyra frågor: vad som påstås, vem eller vad som står för uppgiften, när den blev tillgänglig för assistenten och om den är direkt eller härledd. W3C:s proveniensmodell beskriver informations ursprung i termer av entiteter, aktiviteter och agenter. Den låter också uppgifter beskriva hur en post härletts från en annan. Det är ett praktiskt ramverk för fiktiv dokumentation, även om ett spel använder enkla etiketter i stället för den formella modellen. Introduktion till W3C PROV-modellen
En kompakt uppgift kan se ut så här:
Påstående: Mara planerade att måla trädgårdsskyltarna; Källa: Delad planeringsanteckning; Känt för assistenten från: måndag kl. 10.00; Typ: Direkt uttalande
Påstående: Skyltarna flyttades inomhus; Källa: Uppdatering på gruppens anslagstavla; Känt för assistenten från: tisdag kl. 16.30; Typ: Direkt uppdatering
Påstående: Mara kan ha flyttat in skyltarna eftersom regn hade förutspåtts; Källa: Vädernotering plus uppdatering; Känt för assistenten från: tisdag kl. 16.30; Typ: Slutsats; obekräftad
Exempeltiderna är illustrativa. Det viktiga är skillnaden mellan när en händelse inträffade och när assistenten fick kännedom om den. Om en anteckning som skapats på måndagen delas på tisdagen börjar assistentens kännedom på tisdagen, såvida berättelsen inte uttryckligen ger den tillgång tidigare. Spara båda tidsstämplarna när de skiljer sig åt.
Håll isär observation, rapport och slutsats
En källa gör inte automatiskt innehållet säkert. En karaktär kan beskriva vad den såg, en anteckning kan vara ofullständig och ett schema kan dokumentera en plan snarare än något som faktiskt har hänt. Om uppgiftstypen märks ut kan assistenten formulera sig korrekt: ”Det står på anslagstavlan att skyltarna flyttades” är något annat än ”Mara flyttade skyltarna”, och båda skiljer sig från ”Hon flyttade dem förmodligen på grund av vädret.”
Använd en liten uppsättning begrepp konsekvent: direkt observation, karaktärsrapport, författad uppgift och slutsats. En slutsats bör hänvisa tillbaka till de uppgifter som stöder den och fortfarande vara märkt som en slutsats. W3C PROV modellerar uttryckligen agenters ansvar för aktiviteter och hur en entitet härleds från en annan. Genom att tillämpa den skillnaden på dialog kan spelet visa var en slutsats kommer ifrån i stället för att presentera den som ett nytt faktum. W3C PROV-O
Det här ger också ett användbart test för författaren: kan spelaren spåra ett självsäkert påstående från assistenten till en uppgift som den hade rätt att komma åt? Om inte, revidera svaret, lägg till den saknade författade uppgiften eller låt assistenten säga att den inte har tillräckligt med information.
Definiera åtkomst utifrån berättelsens tid, inte bara karaktären
Ange för varje uppgift vilken händelse som ger assistenten åtkomst. Ett delat meddelande kan bli tillgängligt så snart det skickas, ett anslag på en tavla när assistenten tittar på tavlan och ett samtal kanske först efter att spelaren väljer att fråga om det. Undvik vaga etiketter som ”assistenten känner till allt i arkivet” om inte berättelsen fastställer vad arkivet innehåller och när det uppdateras.
En praktisk åtkomstregel har tre delar: uppgiftens målgrupp, vad som gör den tillgänglig och eventuell fördröjning. Till exempel: ”Assistenten kan läsa inlägg på gruppens anslagstavla när spelaren öppnar den; den kan inte läsa privata utkast.” Fördröjningen spelar roll i berättelser med förgreningar. Om spelaren inte har besökt tavlan bör assistenten inte agera som om den har sett det senaste inlägget bara för att inlägget finns någon annanstans i författarens filer.
I Twine kan berättelsevariabler användas i flera passager, medan tillfälliga variabler i Harlowe och SugarCube begränsas till den aktuella passagen. Den skillnaden visar varför författare medvetet bör avgöra om ett faktum består genom hela berättelsen eller bara hör till en viss scen. Den exakta implementeringen beror på berättelseformatet, så se regeln som en designmodell snarare än kodinstruktioner. Twine Cookbook: Variabler
Gör osäkerhet användbar för spelaren
När en uppgift saknas, är gammal eller tvetydig kan assistenten beskriva luckan konkret. Den kan säga att den har måndagens plan men ingen senare bekräftelse, eller att en karaktär har uppgett att skyltarna flyttades medan tavlan saknar en uppdatering. Det ger spelaren ett meningsfullt nästa steg: kontrollera en annan författad källa, återuppta ett samtal med en karaktär eller bestämma att ledtråden förblir olöst.
Det här tillvägagångssättet möjliggör mysterier utan godtycklig allvetenhet. Forskning om interaktivt berättande har undersökt hur begränsad kunskap kan påverka spelares beteende, bland annat i en studie som använde den interaktiva fiktionen Anchorhead för att utforska spelarmodeller. För en författad assistent är designslutsatsen enkel: vad spelaren och assistenten har fått veta kan påverka deras nästa val, så håll reda på deras kunskapslägen uttryckligen. Rivera-Villicana et al., ”Informing a BDI Player Model for an Interactive Narrative”
En snabb granskning innan du skriver assistentens dialog
Kontrollera följande punkter för varje betydelsefullt påstående innan du skriver ett svar:
Finns påståendet i en författad uppgift, eller är det märkt som en slutsats?
Anger uppgiften sin källa och skiljer mellan en plan, rapport, observation eller senare bekräftelse?
När i berättelsen fick assistenten åtkomst till uppgiften?
Ger assistentens fiktiva roll den rätt att komma åt källan?
Om uppgiften är ofullständig eller motstridig, bevarar dialogen den osäkerheten?
Om svaret på någon av frågorna är oklart, begränsa assistentens påstående tills det stämmer med den tillgängliga uppgiften. Karaktären kan fortfarande vara hjälpsam: den kan sammanfatta vad den har sett, peka ut vad som ännu inte har bekräftats och vägleda spelaren till nästa författade ledtråd. Dess tillförlitlighet bygger på en tydlig gräns mellan berättelsens fullständiga dokumentation och den information den faktiskt har fått.