Oyunlar Serbest Metin Girişlerindeki Gizli Bilgileri Nasıl Ele Almalıdır?
Bir oyuncu oyuna sıradan kişisel bir detay yazdığında en güvenli tasarım; yalnızca özelliğin ihtiyaç duyduğu veriyi toplamak, ham metni kurgusal dünyanın ve paylaşılan karakter bağlamının dışında tutmak ve oyuncuya kaydedilen materyali kaldırması için görünür bir yol sunmaktır. Bir oyun ekibi için pratik görev, serbest metinli tek bir mesajı girişten depolamaya, işlemeye ve silmeye kadar izlemek ve her adımda oyunun bu metne gerçekten ihtiyacı olup olmadığına karar vermektir.
Öncelikle özelliğin neye ihtiyacı olduğuna karar vererek başlayın
Serbest metin kutusu, bir oyunun ihtiyaç duyduğundan daha fazla bilgiyi davet edebilir. Bir oyuncu, pasta seçimiyle ilgili bir sahne talep ederken "Genelde eve otobüsle giderim ve fırına uğrarım" yazabilir. Sahnenin pasta seçimine veya mekana ihtiyacı olabilir; oyuncunun her zamanki güzergahını saklamasına gerek yoktur. Mesajın tamamına faydalı oyun verisi muamelesi yapmak, kişisel ayrıntıların özelliğin gerektirdiğinden daha uzağa gitmesini kolaylaştırır.
Giriş akışını oluşturmadan önce, amacını sade bir dille yazın: örneğin, "bu sahneyi kişiselleştirmek için oyuncunun seçtiği mekanı kullanın". Ardından bu amaca hizmet edebilecek en küçük bilgi parçasını belirleyin. Bu, veri minimizasyonunun bir ürün tasarımı uygulamasıdır: Birleşik Krallık Bilgi Komisyonerliği Ofisi (ICO), varsayılan veri kullanımını her bir özel amaç için gerekli olanla sınırlı olarak tanımlar ve tasarımdan ürün yaşam döngüsü boyunca gizliliğin göz önünde bulundurulmasını önerir (ICO: Tasarım yoluyla ve varsayılan olarak veri koruma).
Faydalı bir tasarım sorusu şudur: Ham mesaj mevcut yanıttan sonra yok olsaydı oyun ne kaybederdi? Cevap "hiçbir şey" ise, bunu kaydedilmiş bir tercihe dönüştürmeyin. Daha sonra bir şeye ihtiyaç duyulursa, oyunun fazladan ayrıntılar içerebilecek bir cümleyi saklaması yerine, oyuncunun "fırın mekanlarını dahil et" gibi kısa ve açık bir tercih seçip seçemeyeceğini değerlendirin. Bu tercih, belirli bir oyun özelliğine yönelik bir iddia değil, önerilen bir tasarım kalıbıdır.
Oyuncu metnini kurgusal belleğin dışında tutun
Bir oyuncunun girdiği metni, kurgusal dünyayı tanımlayan gerçeklerden ayırın. Bir oyunun "karakter fırını ziyaret etti" veya "bir sonraki sahne pazarda geçiyor" gibi kalıcı hikaye durumlarına ihtiyacı olabilir. Bu gerçekler hikayeye aittir. Oyuncunun gerçek rutini hakkındaki bir cümle, sırf bir komut isteminde (prompt) yer aldı diye kurgusal bir karakter anısına dönüşmez.
Pratik yaklaşımlardan biri, her bilgi türüne ayrı bir hedef belirlemektir: mevcut üretim için geçici girdi, kurgusal olaylar için açık hikaye durumu ve yeniden kullanılabilir seçimler için oyuncu kontrollü isteğe bağlı bir tercih. Ham mesajı otomatik olarak bir karakter profiline, özete, uzun vadeli belleğe, analiz etkinliğine veya paylaşılan bağlama kopyalamayın. Oyunun daha sonraki bir sahneye önceki bağlamı aktarması gerekiyorsa, yalnızca özelliğin gerektirdiği seçilmiş hikaye gerçeklerini veya tercihleri aktarın.
Bu ayrım, belirli bir platformun açıklaması değil, tasarımdan gelen gizlilik (privacy-by-design) ilkelerinden türetilen mimari bir öneridir. NIST Gizlilik Çerçevesi, kuruluşların kendi veri işleme bağlamlarına göre uyarlayabilecekleri gönüllü bir araçtır; sunduğu rehberlik, veri işleme ekosistemine ve insanların gizlilik ihtiyaçlarına dayalı olarak ilgili çıktıların seçilmesini vurgular (NIST: Gizlilik Çerçevesine Başlarken). Bir oyun ekibi için yararlı adım, metnin nereye aktığını haritalamak ve her bir hedefe net bir amaç vermektir.
Paylaşımı ayrı ve görünür bir seçenek haline getirin
Kişisel bir oyun etkileşimi için girilen serbest metin, sessizce paylaşılan bir karakter detayına dönüşmemelidir. Bir oyuncu bir karakter kartı, hikaye alıntısı veya topluluk gönderisi yayınlamak isterse, tam olarak neyin paylaşılacağını gösterin ve göndermeden önce düzenlemesine izin verin. Özel bir sahneyi şekillendirmek için yazılan bir cümle, varsayılan olarak bir profilde, liderlik tablosunda veya herkese açık yayında görünmemelidir.
Bu önemlidir çünkü oyun metinleri olağan ürün operasyonlarında sınırları aşabilir. Örneğin Ubisoft'un gizlilik bildirimi, sohbet kayıtlarının ve kullanıcı tarafından oluşturulan içeriğin sosyal özelliklerle bağlantılı olarak işlenmesini açıklar ve bazı kullanıcı adlarının ve metinlerin liderlik tablolarında veya yayın bağlamlarında görünür olabileceğini belirtir (Ubisoft: Gizlilik Politikası). Bu politika Ubisoft'un hizmetlerine dair bir kanıttır, oyunların evrensel bir tanımı değildir. Tasarımcıların hangi özelliğin metni aldığını neden tanımlaması gerektiğini ve kitle değişikliklerini neden açık hale getirmesi gerektiğini gösterir.
Her paylaşım yolu için kitleyi o anda gösterin: bu sahneye özel, seçilen arkadaşlara görünür veya herkese açık. Kontrolü, görünürlüğü değiştiren eylemin yakınında tutun. Tek seferlik bir yayınlama seçimini açıklamak için genel bir ayarlar sayfasına güvenmekten kaçının.
Girdiye ne olduğunu açıklayın
Net bir arayüz, oyunculara bir mesajın yalnızca mevcut yanıtı üretmek için mi kullanıldığını, sonraki sahneler için mi saklandığını yoksa harici bir servise mi gönderildiğini söylemelidir. Açıklamayı kısa tutun ve metin kutusuna yakın bir yere koyun. Farklı özellikler farklı davranıyorsa, tek bir kuralın her girdiyi kapsadığını ima etmek yerine bunu her özelliğin yanında belirtin.
Bunun nedeni pratiktir: Bir oyunun kendi depolama alanı, işleme yolundaki olası adımlardan yalnızca biridir. Örneğin OpenAI'ın API belgeleri, kötüye kullanım izleme günlüklerini uygulama durumundan ayırır ve uç noktaya ve özelliğe göre saklama farklılıklarını açıklar. Belirtilen kontroller ve sınırlar o API için geçerlidir; her sağlayıcı veya oyun için geçerli değildir (OpenAI: OpenAI platformundaki veri kontrolleri). Bir oyun ekibi, kullandığı sağlayıcının gerçek ayarlarını ve koşullarını kontrol etmeli, ardından ortaya çıkan davranışı doğru bir şekilde açıklamalıdır.
Sırf oyun mesajı bir oyuncu profiline kaydetmiyor diye bir özelliği "geçici" olarak etiketlemeyin. Metnin istek günlüklerinde, hata ayıklama çıktılarında, kilitlenme raporlarında, analizlerde, denetim araçlarında veya kaydedilmiş konuşma bağlamında kalıp kalamayacağını izleyin. Bir hedefin tanımlanmış operasyonel bir nedenle metne ihtiyacı varsa, bu akışı ve saklama süresini dahili olarak belgeleyin ve ham metni buna ihtiyacı olmayan sistemlere yerleştirmekten kaçının.
Oyunculara kaydedilen kopyalara ulaşan bir kaldırma kontrolü verin
Oyun yeniden kullanılabilir bir tercihi veya konuşma bağlamını kaydediyorsa, oyuncuya bunu incelemesi ve kaldırması için görünür bir denetim sunun. Bu denetimi, oyuncuların ilgili özelliği yönettiği yere koyun; örneğin, kaydedilen her öğenin yanında bir kaldırma eylemi bulunan "Kaydedilen hikaye tercihleri" ekranı. Eylemi açık bir dille onaylayın ve kaldırma işleminin ne zaman tamamlandığını gösterin.
Bir kaldırma eylemi, yalnızca arayüzden bir satırı gizlemekle kalmamalı, oyunun kontrol ettiği kopyaları da kapsamalıdır. Bir tasarım kontrol listesi olarak, kaydedilen öğeyi profil deposu, hikaye özeti, arama dizini veya erişim deposu ve onu geri yükleyebilecek tüm önbellekler boyunca izleyin. Yedeklemelerin ve operasyonel kayıtların sürelerinin nasıl dolduğunu tanımlayın ve bazı kayıtlar ayrı bir saklama planına tabi ise bunu oyunculara bildirin. NIST'in gizlilik çerçevesi çekirdeği; inceleme, değiştirme ve silme erişimini veri yönetimi çıktıları arasında tanımlar ve teknik önlemlerin test edilmesini bir faaliyet olarak içerir (NIST Gizlilik Çerçevesi Çekirdeği).
Kaldırma akışını basit bir kurgusal örnekle test edin: fırın mekanları için bir tercih kaydedin, bunun sonraki bir sahneyi etkileyebileceğini doğrulayın, tercihi kaldırın, ardından kaydedilen tercihler görünümünde veya sonraki bir sahne için sağlanan bağlamda artık görünmediğini doğrulayın. Bu, önerilen bir ürün testidir; bildirilmiş bir sonuç değildir. Silme işlemi asenkron ise durumunu gösterin ve tamamlanmamış bir talebi bitmiş gibi sunmaktan kaçının.
Bir metin özelliğini yayınlamadan önce kısa bir inceleme yapın
Bir ekip, her serbest metin özelliği için dört soruyu gözden geçirebilir: İhtiyaç duyulan en küçük girdi nedir; ham metni hangi sistemler alıyor; varsa hangi kısımlar kalıcı oyun durumu haline geliyor; ve oyuncu bu kayıtlı durumu nerede inceleyebilir veya kaldırabilir? Harici servisler de dahil olmak üzere gerçek ürün yolu boyunca örnek bir mesajı takip edin ve oyuncuya yönelik açıklamanın bununla eşleştiğini kontrol edin.
Hedeflenen deneyim oldukça basittir: Bir oyuncu, oyun tüm bir cümleyi sessizce kalıcı bir karakter anısına dönüştürmeden, bir sahneyi şekillendirmek için sıradan kişisel seçimlerini kullanabilir. Ham girdiyi dar tutmak, hikaye gerçeklerini oyuncu ayrıntılarından ayırmak, paylaşımı açık hale getirmek ve erişilebilir bir kaldırma kontrolü sağlamak; bu hedefi bir tasarım ve mühendislik ekibinin uygulayabileceği ve doğrulayabileceği kararlara dönüştürür.