Bir Gizem Oyununda Kayıp Bir Karakterin Yapay Zekâ Asistanı Gerçekte Neler Bilebilir?
Kurgusal bir gizem oyununda yapay zekâ asistanı, yalnızca yazarın kendisine sunduğu hikâye kayıtlarını bilmelidir; üstelik sadece bu kayıtların erişilebilir hâle geldiği hikâye anından itibaren. Her olguya bir kaynak, öğrenildiği bir zaman ve bir erişim kuralı atayın. Bu sayede asistan, gizlice her şeyi bilen bir anlatıcıya dönüşmeden oyuncuların ipuçlarını birleştirmesine yardımcı olabilir.
Hikâyenin kayıtları ile asistanın erişimini birbirinden ayırın
İşe yazara yönelik eksiksiz bir hikâye kaydıyla başlayın: olaylar, karakter ifadeleri, nesneler, mesajlar ve bunların oyuna dâhil olma sırası. Ardından asistan için daha dar kapsamlı bir görünüm tanımlayın. Bir olgu hikâye kılavuzunda yer alabilir ancak henüz asistanın erişimine açık olmayabilir. Bu ayrım, adil bir gizem kurgusunun temelidir: Yazar ne olduğunu bilebilirken, asistan yalnızca kurgusal rolünün görmesine izin verdiği kayıtları kullanabilir.
Twine gibi etkileşimli kurgu araçları hikâyeleri pasajlar hâlinde düzenler ve oyuncunun gördüklerini değiştirmek için değişkenler ile koşullu mantık kullanabilir. Bu, faydalı bir tasarım analojisi sağlar: Yazılan her kaydı bağımsız bir birim olarak ele alın ve bu kayda erişimi ilgili pasaja, olaya veya seçime bağlı hâle getirin. Twine’ın temel kavramları
Örneğin, kurgusal bir karakter olan Mara'nın bir topluluk bahçesi sergisi hazırladığını varsayalım. Asistan; Mara'nın paylaştığı bir planlama notuna, grup panosuna asılan bir programa ve daha sonra boyalı tabelaları içeri taşımakla ilgili gönderdiği bir mesaja erişebilir. Mara'nın sadece bahçecilikten hoşlandığını bildiği için nerede olduğunu tahmin etmemeli ve kendisiyle hiçbir zaman paylaşılmamış özel bir taslağı görmemelidir. Bu sınırlar, gerçek yapay zekâ sistemlerinin nelere erişebileceğine dair bir iddiadan değil, hikâyenin kurgulanmış erişim kurallarından kaynaklanır.
Her olguya bir kaynak ve bir öğrenilme zamanı atayın
Kullanışlı bir olgu kaydı en az dört soruyu yanıtlar: Ne iddia ediliyor, bunu kim veya ne sağladı, asistanın erişimine ne zaman açıldı ve doğrudan mı yoksa çıkarım yoluyla mı elde edildi? W3C kaynak (provenance) modeli, bilginin kökenlerini varlıklar, faaliyetler ve aracılar üzerinden tanımlar; ayrıca kayıtların bir öğenin diğerinden nasıl türetildiğini açıklamasına da olanak tanır. Bir oyun resmi model yerine basit etiketler kullansa bile bu, kurgusal kayıtlar için pratik bir çerçevedir. W3C PROV Model Primer
Kompakt bir kayıt şu şekilde görünebilir:
İddia: Mara bahçe tabelalarını boyamayı planladı; Kaynak: Paylaşılan planlama notu; Asistan tarafından öğrenilme zamanı: Pazartesi, 10:00; Tür: Doğrudan ifade
İddia: Tabelalar içeri taşındı; Kaynak: Grup panosu güncellemesi; Asistan tarafından öğrenilme zamanı: Salı, 16:30; Tür: Doğrudan güncelleme
İddia: Mara, yağmur beklendiği için onları içeri taşımış olabilir; Kaynak: Hava durumu notu ve güncelleme; Asistan tarafından öğrenilme zamanı: Salı, 16:30; Tür: Çıkarım; doğrulanmadı
Örnek zamanlar fikir verme amaçlıdır. Buradaki önemli ayrım, bir olayın ne zaman gerçekleştiği ile asistanın bunu ne zaman öğrendiği arasındadır. Pazartesi günü oluşturulan bir not Salı günü paylaşılırsa, hikâye asistana açıkça daha erken bir erişim sağlamadığı sürece asistanın bilgisi Salı günü başlar. Farklı olduklarında her iki zaman damgasını da saklayın.
Gözlem, bildirim ve çıkarımı birbirinden ayrı tutun
Bir kaynağın varlığı, içeriğini otomatik olarak kesin kılmaz. Bir karakter gördüklerini anlatabilir; bir not eksik olabilir; bir program, fiilen gerçekleşmiş bir eylemden ziyade bir planı kaydediyor olabilir. Kayıt türünü etiketlemek, asistanın yanıtını doğru bir şekilde ifade etmesine yardımcı olur: “Panoda tabelaların taşındığı yazıyor” ifadesi ile “Mara tabelaları taşıdı” ifadesi farklıdır ve her ikisi de “Muhtemelen hava yüzünden onları taşıdı” ifadesinden farklılık gösterir.
Tutarlı bir şekilde sınırlı bir kelime dağarcığı kullanın: doğrudan gözlem, karakter bildirimi, yazar kaydı ve çıkarım. Bir çıkarım, kendisini destekleyen kayıtlara işaret etmeli ve bir çıkarım olarak işaretli kalmalıdır. W3C PROV, aracıların faaliyetlerdeki sorumluluğunu ve bir varlığın diğerinden türetilmesini açıkça modeller; bu ayrımı diyaloglara uygulamak, bir oyunun bir sonucu yeni bir gerçek gibi sunmak yerine nereden kaynaklandığını göstermesine yardımcı olur. W3C PROV-O
Bu aynı zamanda yazım için kullanışlı bir test yaratır: Bir oyuncu, asistanın kendinden emin bir ifadesini erişimine izin verilen bir kayda kadar takip edebilir mi? Edemiyorsa, yanıtı revize edin, eksik yazar kaydını ekleyin veya asistanın yeterli bilgiye sahip olmadığını söylemesini sağlayın.
Erişimi sadece karaktere göre değil, hikâye zamanına göre de tanımlayın
Her kayıt için asistanın erişim kilidini açan olayı belirleyin. Paylaşılan bir mesaj gönderildiği anda erişilebilir olabilir; panoya iğnelenen bir duyuru, asistan panoyu kontrol ettiğinde erişilebilir hâle gelebilir; bir konuşma ise ancak oyuncu bunu sormayı seçtikten sonra kullanılabilir olabilir. Hikâye bu arşivin neler içerdiğini ve ne zaman güncellendiğini belirlemediği sürece “asistan arşivdeki her şeyi bilir” gibi muğlak etiketlere güvenmekten kaçının.
Pratik bir erişim kuralı üç bölümden oluşur: kaydın hedef kitlesi, kullanılabilirlik tetikleyicisi ve varsa gecikme. Örneğin: “Asistan, oyuncu panoyu açtıktan sonra grup panosu gönderilerini okuyabilir; kişisel taslakları okuyamaz.” Dallanan hikâyelerde gecikme önemlidir. Oyuncu panoyu ziyaret etmediyse, o gönderi yazarın dosyalarında başka bir yerde mevcut olsa bile asistan en son gönderiyi görmüş gibi davranmamalıdır.
Twine'da hikâye değişkenleri pasajlar arasında kullanılabilirken, geçici değişkenler Harlowe ve SugarCube'da yalnızca geçerli pasajla sınırlıdır. Bu fark, yazarların bir olgunun tüm hikâye boyunca kalıcı mı olacağına yoksa sadece belirli bir sahneye mi ait olacağına neden bilinçli olarak karar vermesi gerektiğini gösterir. Tam uygulama hikâye formatına bağlıdır; bu nedenle kuralı kod talimatları yerine bir tasarım modeli olarak ele alın. Twine Cookbook: Variables
Belirsizliği oyuncu için faydalı hâle getirin
Bir kayıt eksik, eski veya belirsiz olduğunda, asistanın bu boşluğu somut ifadelerle tanımlamasına izin verin. Pazartesi günkü plana sahip olduğunu ancak daha sonraki bir teyidin bulunmadığını veya bir karakterin tabelaları taşıdığını bildirmesine rağmen panoda herhangi bir güncelleme olmadığını söyleyebilir. Bu, oyuncuya anlamlı bir sonraki adım sağlar: yazılmış başka bir kaynağı kontrol etmek, bir karakter konuşmasını yeniden ziyaret etmek veya ipucunun henüz çözülmediğine karar vermek.
Bu yaklaşım, keyfi bir her şeyi bilme durumuna başvurmadan gizemi destekler. Etkileşimli anlatı üzerine yapılan araştırmalar, oyuncu modellerini keşfetmek için etkileşimli kurgu *Anchorhead*i kullanan bir çalışma da dâhil olmak üzere, sınırlı bilginin oyuncu davranışını nasıl şekillendirebileceğini incelemiştir. Yazılmış bir asistan için tasarım çıkarımı gayet basittir: Oyuncunun ve asistanın öğrendikleri sonraki seçimlerini etkileyebilir, bu nedenle bu bilgi durumlarını açıkça takip edin. Rivera-Villicana ve ark., “Informing a BDI Player Model for an Interactive Narrative”
Asistan diyaloglarını yazmadan önce hızlı bir denetim
Bir yanıt taslağı hazırlamadan önce, sonuç doğuran her iddia için şu noktaları kontrol edin:
İddia yazılmış bir kayıtta mevcut mu, yoksa bir çıkarım olarak mı etiketlenmiş?
Kayıt kaynağını belirtiyor ve bir planı, bildirimi, gözlemi veya sonraki bir onayı birbirinden ayırt ediyor mu?
Asistan hikâye zamanının hangi noktasında buna erişim sağladı?
Asistanın kurgusal rolü bu kaynağa erişime izin veriyor mu?
Kayıt eksik veya çelişkiliyse, diyalog bu belirsizliği koruyor mu?
Bunlardan herhangi birinin yanıtı net değilse, mevcut kayıtla eşleşene kadar asistanın ifadesini daraltın. Ortaya çıkan karakter yine de faydalı olabilir: Gördüklerini özetleyebilir, neyin doğrulanmadığını belirleyebilir ve oyuncuyu yazılmış bir sonraki ipucuna yönlendirebilir. Güvenilirliği, hikâyenin tam kaydı ile fiilen aldığı bilgiler arasındaki görünür sınırdan kaynaklanır.