Så hindrar du AI-karaktärer från att hitta på ledtrådar i mysterispel

I ett mysterispel samlar spelarna information, drar slutsatser och använder det de lär sig för att söka efter mer information. Därför är förhållandet mellan ledtrådar och spelarens kunskap en del av spelets centrala spelcykel, inte en detalj i dialogens stil. En karaktär som självsäkert nämner ett brev som spelaren inte hittat eller namnger en person som spelaren aldrig har träffat kan råka skapa ett nytt spår. Spelaren har inget tillförlitligt sätt att veta om uppgiften är en avsiktligt utformad ledtråd, en medveten lögn eller utfyllnad som modellen hittat på. Artikeln ”Generative Forensics: Procedural Generation and Information Games” beskriver informationsspel som spel där man samlar kunskap och använder den för att förstå ett mysterium. Med det synsättet kan påståenden som genereras utan att spåras göra den kunskap svårare att reda ut som spelaren förväntas dra slutsatser utifrån.

Lösningen börjar med en tydlig åtskillnad: en ledtråd är ett spelfaktum som spelaren kan agera utifrån; stämningsdialog är uttrycksfull dialog som inte lägger till eller ändrar spelfakta. En karaktär kan låta osäker, undvikande, rolig eller målande, men en replik blir inte ett bevis bara för att den är övertygande formulerad.

Spara en liten, tydlig post för varje ledtråd som spelaren kan agera utifrån. Den kan finnas i en databas, en innehållsfil eller ett berättarverktyg. Det viktiga är att modellen inte hittar på innehållet. Ta med fält som anger vad ledtråden säger, varifrån den kommer, vem som kan känna till den och när den blir tillgänglig.

Fält: clue_id; Vad det registrerar: En stabil identifierare för beviset; Exempel (illustrativt): note_blue_01

Fält: canonical_fact; Vad det registrerar: Faktumet som spelet slår fast; Exempel (illustrativt): ”Anteckningen är signerad med initialen M.”

Fält: source_id; Vad det registrerar: Författat objekt, scen eller replik som stöder uppgiften; Exempel (illustrativt): archive_note_03

Fält: discovery_condition; Vad det registrerar: Speltillstånd som krävs innan uppgiften kan diskuteras; Exempel (illustrativt): found_archive_note_03

Fält: allowed_speakers; Vad det registrerar: Karaktärer som får känna till eller diskutera uppgiften; Exempel (illustrativt): Mara, Ivo

Fält: certainty; Vad det registrerar: Om källan slår fast ett faktum eller antyder en tolkning; Exempel (illustrativt): explicit

Fält: player_facing_label; Vad det registrerar: Hur beviset visas i journalen, om tillämpligt; Exempel (illustrativt): ”Osignerad anteckning”

Namnen och värdena ovan är påhittade exempel som visar ett format, inte uppgifter om något särskilt spel. Lägg märke till att posten skiljer mellan en källas uttryckliga innehåll och en tolkning: en initial som underskrift fastställer inte i sig vem som skrev en anteckning. Den skillnaden gör att dialogsystemet kan låta en karaktär spekulera utan att framställa spekulationen som ny, bekräftad bevisning.

Låt spelet hantera upptäckten som ett eget speltillstånd. Exempelvis blir found_archive_note_03 sant först när spelaren faktiskt hittar anteckningen. När ett samtal börjar skickar du karaktären en lista över de författade fakta som den får diskutera, filtrerade utifrån vad spelaren har upptäckt och vad karaktären känner till. En ledtråd är tillgänglig bara om båda villkoren är uppfyllda: spelaren har nått dess upptäcktsvillkor och talaren har rätt att känna till den.

Det här är en praktisk tillämpning av retrieval-augmented generation: hämta relevanta poster, lägg dem i modellens kontext och generera utifrån dem. Microsofts översikt över RAG beskriver flödet hämta–utöka–generera och varnar för att dålig eller ofullständig hämtning fortfarande kan leda till felaktiga svar. I ett spel bör hämtningen ta hänsyn till upptäcktsvillkoren innan informationen når modellen. Att säga till modellen ”avslöja inget” är mindre tillförlitligt än att helt undanhålla oupptäckta bevis.

Gör behörighetskontrollen utanför modellen när det går. Det är spelet, inte en genererad replik, som ska avgöra om ett bevis förs in i journalen, löser ett pussel eller låser upp en interaktion. Modellen kan formulera ett godkänt faktum; speltillståndet ska avgöra om faktumet över huvud taget är godkänt.

En användbar prompt bör ange karaktärens röst, den aktuella scenen, vilka ledtrådsposter som får användas och skillnaden mellan bevis och stämningsdialog. Ange vad modellen ska göra när en fråga går utanför den tillhandahållna bevisningen: avstå från att bekräfta uppgiften, säga att karaktären inte vet eller ge ett svar som passar karaktären men inte går att agera utifrån. Ta också med instruktioner för motstridiga eller tvetydiga poster. Microsofts vägledning om promptdesign för RAG rekommenderar tydliga gränser för förankring, reservbeteende, källidentifierare och instruktioner för konflikter. Det är användbara designprinciper för kontrollerad karaktärsdialog såväl som för informationsassistenter.

Om spelaren till exempel frågar om initialen M bevisar att Mara skrev anteckningen kan ett tillåtet svar vara: ”M:et står där, men det säger inte i sig vem som skrev under.” Systemet kan tillåta den formuleringen eftersom den bevarar skillnaden mellan källfaktumet och en slutsats. Modellen bör inte hitta på ett vittne, en matchning av handstilen eller ett andra dokument för att göra svaret mer tillfredsställande.

Låt modellen returnera strukturerade fält som spoken_text, claim_type och source_ids. För ett svar som innehåller en ledtråd ska du kräva minst en giltig källidentifierare och kontrollera den mot posterna som skickades med i den omgången. För stämningsdialog ska svaret märkas som icke-bevis och får inte ändra ledtrådsflaggor. Strukturerad utdata bevisar inte att texten är sann; den ger spelet något att kontrollera innan det visas eller ändrar speltillståndet.

Stämningsdialog kan handla om en karaktärs sinnesstämning, ett oskyldigt skämt eller en ospecifik reaktion på rummet. Den bör inte obemärkt introducera ett datum, en plats, ett föremål, ett namngivet vittne, ett motiv eller någon annan detalj som spelarna rimligen kan uppfatta som ett spår. Om du vill tillåta spekulationer ska osäkerheten framgå tydligt av formuleringen, och uppgifterna ska hållas borta från objektiva system som bevislistan, uppdragsstatus och ledtrådsstyrda interaktioner.

Skillnaden kan återspeglas både i data och presentation. Märk upp repliker internt som bevis, tolkning eller stämningsdialog. I gränssnittet bör du reservera bevisformatering och journalanteckningar för spelförfattade ledtrådar. En karaktär kan säga: ”Kanske lämnades anteckningen i all hast”, men om spelet inte har författat den möjligheten som en tillåten tolkning ska den inte visas som en bekräftad ledtråd eller utlösa en ny förgrening. Denna indelning i tre kategorier är en designrekommendation som följer av behovet att bevara skillnaden mellan vad källan säger, vad någon drar för slutsats och vad som bara är uttrycksfull dialog.

Du behöver ingen särskild spelmotor för att använda det här arbetssättet. Interaktiva berättarverktyg har ofta stöd för avsnitt, variabler och villkorat innehåll. Den officiella dokumentationen för Ink beskriver variabler och villkorslogik för att styra berättelseinnehåll. Twine Cookbooks guide till passager förklarar att passager är innehållsavsnitt som också kan innehålla kod som påverkar hur text visas eller reagerar. De här funktionerna kan representera upptäcktsläge, talarens kunskap och villkorad dialog, oavsett om dialogen genereras eller skrivs i förväg.

Håll ledtråds-ID:n och tillståndsnamn enhetliga i berättelseposterna och spellogiken. En variabel som found_archive_note_03 är lättare att granska än en vag flagga som clue2, särskilt när olika scener läser eller ändrar den. Lägg till en spårbar länk från varje genererad replik som går att agera på till dess tillåtna källpost. Om en replik saknar en giltig källa kan spelet avvisa den eller begära ett säkert standardsvar i stället för att behandla den som bevis.

Testa samtal vid gränserna för när något upptäcks, där tillståndsreglerna har störst risk att fallera. Starta ett nytt samtal innan ledtråden har hittats, direkt efter att den har hittats och efter att en karaktär med annan kunskap har sagt något. Ställ direkta frågor om oupptäckta bevis, fråga om något som källan bara delvis besvarar och spela om scenen om spelet stöder det. Jämför den visade repliken, dess returnerade käll-ID:n och eventuella ändringar i journalen eller berättelsens tillstånd.

En kort testlista gör kontrollerna konkreta:

Varje påstående som går att agera på kan kopplas till en författad ledtråd eller en uttryckligen tillåten tolkning.

Ledtrådens upptäcktsvillkor är uppfyllt innan den blir tillgänglig kunskap.

Talaren får känna till informationen i den scenen.

Frågor som saknar stöd får det valda standardsvaret i stället för ett nytt, specifikt faktum.

Stämningsdialog kan inte lägga till journalanteckningar, uppfylla ledtrådsvillkor eller ändra bevisstatus.

Tvetydiga eller motstridiga poster leder till osäkerhet eller ett standardsvar som går att granska, inte till en tyst ny lösning.

Förankring minskar utrymmet för påhittade spår, men garanterar inte att genererad text alltid följer de angivna fakta. Hämtningen kan missa en relevant post, och modellen kan fortfarande producera felaktig text trots förankring, vilket Microsoft påpekar i sin vägledning om RAG:s begränsningar. Låt de författade posterna och spellogiken ha sista ordet om ledtrådar. Använd generering för att ge replikerna personlighet inom de gränserna.

Den praktiska regeln är enkel: låt modellen välja orden, medan det författade mysteriet och det aktuella speltillståndet avgör vad orden får slå fast. När varje ledtråd som går att agera på har en källa, ett upptäcktsvillkor och en tydlig status kan karaktärerna låta mer naturliga utan att ge spelarna bevis som spelet aldrig har placerat ut.