Metin Tabanlı Oyun Hata Durumları: Bir Engeli Girdi veya İletim Sorunundan Ayırt Etme Yöntemleri
Sohbet tarzı bir metin oyununda, başarısız bir hamle oyuncunun her zaman kötü bir seçim yaptığı anlamına gelmez. Sahne geçerli bir kurgusal engelle karşılaşmış olabilir, oyun kullanılan ifadeyi desteklemiyor olabilir, karakter harekete geçmek için gereken bilgiden yoksun olabilir veya mesaj yerine ulaşmamış olabilir. Bu durumlar farklı geri bildirimler ve farklı yeniden deneme etkileri gerektirir. Öncelikle nedeni sınıflandırın, ardından oyuncuya neyin değiştiğini ve bundan sonra ne olabileceğini bildirin.
Neyin başarısız olduğunu sorarak başlayın
Pratik bir ilk soru şudur: Oyun hedeflenen eylemi anladı mı ve bunu kurgu içinde çözüme kavuşturdu mu? Yanıt evet ise, sonuç bir engel olabilir. Değilse, sorunun girdiden mi, karakterin bilgisinden mi yoksa sistemin iletiminden mi kaynaklandığını belirleyin. Bu dört parçalı ayrım, etkileşimli kurgu sistemlerinin ayrıştırma (parsing), dünya kuralları, hikaye akışı ve geri alma (undo) davranışlarını birbirinden nasıl ayırdığından çıkarılmış bir tasarım desteğidir; evrensel bir teknik standart değildir. Örneğin Inform'un belgeleri, ayrıştırıcıyı ve simüle edilmiş dünya modelini bir oyunun ayrı parçaları olarak tanımlar ve ayrıştırıcısı bir komutun neden eşleşmediğine dair birkaç farklı neden bildirebilir. (Inform 6 Designer’s Manual: Introduction, Inform 6 Designer’s Manual §33: Helping the parser out of trouble)
Mesajı, oyunun yanıt sözleşmesinin bir parçası olarak değerlendirin. Üç soruyu yanıtlamalıdır: Ne oldu, kurgusal durum değişti mi ve oyuncu şimdi ne yapabilir? “Kağıt tekne karşı kıyıya ulaşamadan alabora oluyor. Katlanmış not hala elinizde. Daha geniş bir kanalı deneyebilir veya karşıya geçmek için başka bir yol seçebilirsiniz” gibi kısa bir ifade; engeli, elde tutulan eşyayı ve sonraki adımı anlaşılır kılar.
1. Geçerli bir kurgusal engel
Oyun eylemi anladığında, mevcut sahneye göre kontrol ettiğinde ve kasıtlı olarak dünya içinde bir sonuç ürettiğinde bir engel uygundur. Belki oyuncu aynı anda çok fazla kütüphane kitabı taşımaya çalışır ve biri yakındaki bir sandalyeye kayar. Belki de bir kağıt tekne, sığ bir derenin diğer tarafına ulaşmadan önce su alır. Karşılıklı etkileşimi oyuncuya yönelik bir yargılamaya dönüştürmeden, sonuç can sıkıcı veya şaşırtıcı olabilir.
Belirleyici özellik durum değişikliğidir. Sahne teknenin battığını söylüyorsa, bu sonuç hikayede gerçek olmalıdır. Oyuncu onu kurtarabiliyorsa, nasıl olduğunu açıklayın; tekne yok olduysa, aynı metni tekrar denemenin bu olayı geri alacağını ima etmeyin. Yeniden deneme; başka bir tekne yapmak, başka bir rota seçmek veya değişen sahneden devam etmek anlamına gelebilir. Kesin seçenek oyunun kurallarına bağlıdır.
Kullanışlı bir engel mesajı; denenmiş eylemi, sonucu ve mevcut devam yolunu belirtir. Sırf sonuç olumsuz oldu diye desteklenen bir eylemi girdi hatası gibi sunmamalıdır. Tersine, oyun hikaye durumunu gerçekten değiştirmediyse bir sonucun gerçekleştiğini ima etmeyin. Bu ayrım, oyuncunun yeni bir durumdan mı devam ettiğini yoksa işlenmemiş bir komutu mu düzelttiğini anlamasını sağlar.
2. Desteklenmeyen girdi: Oyun ifadeyi çözemedi
Desteklenmeyen girdi, sistemin oyuncunun mesajını desteklediği bir eylemle eşleştiremediği anlamına gelir. Oyuncu, oyunun yalnızca küçük bir düğme seçimi kümesini kabul ettiği bir sahnede “fırıncıya kayısıları sor” yazabilir veya ayrıştırıcının tanımadığı bir isim kullanabilir. Bu, arayüzün kapsamı hakkında bir şeyler söyler, oyuncunun fikrinin niteliği hakkında değil.
Etkileşimli kurgu ayrıştırıcıları, faydalı geri bildirimlerin neden spesifik olması gerektiğini gösterir: Inform; tanınmayan bir fiil, belirsiz bir referans, çok az girdi ve görülemeyen bir nesne için ayrı hatalar listeler. Kılavuzu ayrıca bir oyunun genel bir ayrıştırıcı hatasını nasıl daha bilgilendirici bir mesajla değiştirebileceğini de gösterir. (Inform 7 §18.35: Printing a parser error) Bir sohbet oyununda kısa ve öz bir yanıt şöyle olabilir: “Burada 'kayısıları sor' ifadesini çözümleyemiyorum. Teslimat hakkında soru sorabilir veya tezgahtan bir konu seçebilirsiniz.”
Bir onarım yolu sunun. Arayüze bağlı olarak bu; tanınan seçenekleri göstermek, odaklanmış tek bir açıklama istemek veya oyuncuyu cümleyi yeniden ifade etmeye davet etmek anlamına gelebilir. Desteklenmeyen bir komutu kurgusal bir başarısızlık olarak anlatmayın: Hiçbir eylem çalışmadıysa, bunu açıkça belirtin. Önceki sahneyi olduğu gibi koruyun ve düzeltilmiş bir girdi göndermenin bir hikaye olayını geri sarmak yerine aynı anı yeniden deneyeceğini netleştirin.
3. Ulaşılamayan karakter bilgisi: Henüz yanıtı olmayan geçerli bir soru
Bazen girdi anlaşılırdır, ancak karakter bu doğrultuda hareket etmek için yeterli bilgiye sahip değildir. Bir oyuncu, dükkan sahibinin asistanına, asistan henüz makbuzu görmeden bir paketin nereye teslim edildiğini sorabilir. Oyun, kesin bir yanıtı haklı olarak saklı tutarken soruyu tanıyabilir.
Bu durum desteklenmeyen girdiden farklıdır: Konu veya eylem geçerlidir ve sınırlama kurgu içinde karakterin bilgisine aittir. Bu sınırı açıkça belirtin. Örneğin: “Mina teslimat fişini görmedi, bu yüzden sokak adını söyleyemiyor. Paket etiketi hala tezgahta.” Oyuncu etiketi inceleyebiliyor, başkasına sorabiliyor veya daha sonra geri dönebiliyorsa, bu yolu belirtin. Değilse, bir ipucu uydurmak veya soruyu hatalı biçimlendirilmiş olarak değerlendirmek yerine gerçekte neyin bilindiğini söyleyin.
Bu yanıtın zamanı ilerletip ilerletmediğine veya durumu değiştirip değiştirmediğine karar verin. Soruyu sormak dünya içinde normal bir eylemse, oyun bu konuşmayı kaydedebilir veya bir karakterin daha sonra nasıl yanıt vereceğini değiştirebilir. Oyun bilgi sorularının bir bedeli olmamasını amaçlıyorsa, sahneyi koruyun ve başka bir sorunun gelmesine izin verin. Oyuncu, bir bilgi talebinin sessizce bir fırsatı harcayıp harcamadığını tahmin etmek zorunda kalmamalıdır.
4. Teknik iletim hatası: Eylem hikayeye hiç ulaşmamış olabilir
Bir iletim hatası kurgunun dışında gerçekleşir: Bir yanıt zaman aşımına uğrar, iki kez görünür veya bir cümlenin ortasında durur. Oyun, eylemin işlendiğini bilmediği sürece karakterin harekete geçtiğini veya hikayenin ilerlediğini güvenle iddia edemez. Bu, kurgusal bir sonuç olan “kurye adresi bulamadı” gibi dünya içi bir mesajdan farklıdır.
Sade bir durum dili kullanın ve bilinen durumu bildirin. Oyun hamlenin işlenmediğini doğrulayabiliyorsa, bunu belirtin ve oyuncunun tekrar göndermesine izin verin. Hamlenin işlenip işlenmediğini belirleyemiyorsa, eylemi iki kez gerçekleştirebilecek körü körüne bir tekrara davet etmekten kaçının. Belirsizliği kısaca açıklayın ve mevcut sahneyi kontrol etme veya son onaylanan noktadan devam etme yolu sunun. Bunlar, başarısız bir girdi eşleşmesini bir hikaye sonucundan ayırt etme ihtiyacından çıkarılan tasarım önerileridir; atıfta bulunulan kurgu sistemleri sohbet iletim hataları için evrensel bir protokol tanımlamaz.
İletim düzeldiğinde, son onaylanan mesajı geri yükleyin veya sahnenin ve tamamlandığı bilinen en son eylemin kısa bir özetini gösterin. Bir özeti yeni bir hikaye hamlesi olarak değil, özet olarak etiketleyin. Oyuncu yeniden göndermeyi seçerse, bunun yeni bir deneme olarak kabul edilip edilmeyeceğini netleştirin. Bu ufak şeffaflık, yinelenen bir eylemin kasıtlı bir tekrarla karıştırılmasını önler.
Yeniden dene (retry), geri al (undo) ve sürdür (resume) kavramlarını farklı anlamlara getirin
Bu kelimeler farklı durum etkilerini tanımlar, bu nedenle bunları birbirinin yerine kullanmaktan kaçının. Yeniden dene (retry), mevcut durumda bir eylemi tekrar gönderir; gerçekleşmiş bir sonucu sessizce silmemelidir. Geri al (undo), daha önceki bir durumu geri yükler. Sürdür (resume), kesintiden sonra son onaylanan durumdan devam eder. Yeniden başlat (restart), hikayeye baştan başlar.
Twine’ın Harlowe kılavuzu, geri almayı (undo) önceki bölüme dönmek ve geçerli bölümde yapılan değişken değişikliklerini unutmak olarak belgeler; yeniden başlatmayı (restart) ise hikayeye yeniden başlamak için sayfayı yeniden yüklemek olarak tanımlar. Ayrıca geri alma geçmişinin sınırlı olabileceğini belirtir. Bu mekanikler, bir denetimin belirsiz bir “tekrar dene” etiketine güvenmek yerine kapsamını neden iletmesi gerektiğini gösterir. (Harlowe 3.3.8 Manual: undo and restart)
Kompakt bir karar sırası arayüzün tutarlı kalmasına yardımcı olur:
Oyun eylemi anladı ve çözüme kavuşturdu mu? Evet ise, kurgusal sonucu ve kalan durumu bildirin.
Sistem ifadeyi desteklenen bir eylemle eşleştiremedi mi? Neyi çözümleyemediğini açıklayın ve bir onarım yolu gösterin; sahneyi koruyun.
Eylem anlaşıldı ancak karakter bilgiden yoksun mu? Bilgi sınırını ve daha fazlasını öğrenmenin dünya içi herhangi bir yolunu açıklayın.
İşleme veya iletim belirsiz mi? Nelerin onaylandığını belirtin, ardından kontrol etmek veya devam etmek için güvenli bir yol sunun.
Oyuncu geri gitmek istiyorsa, denetimi “Geri Al” (Undo) olarak etiketleyin ve hangi anı veya değişiklikleri geri yüklediğini belirtin. “Yeniden Başlat”ı (Restart) baştan başlamaya ayırın.
Her hata mesajı için kısa bir tutarlılık kontrolü
Bir yanıtı yayınlamadan önce hikaye durumuna göre kontrol edin. Bir engeli açıklıyorsa, dünya gerçekten değişti mi? Desteklenmeyen bir girdiyi açıklıyorsa, oyun eylemin gerçekleştiğini iddia etmekten kaçındı mı? Karakter bilgiden yoksunsa, yanıt bunu eksik bir komuttan ayırt ediyor mu? İletim başarısız olduysa, oyuncu hamlenin işlenip işlenmediğini biliyor mu? Son olarak, yeniden dene veya sürdür denetimi etiketinin vaat ettiği şeyi yapıyor mu?
Metin tabanlı bir oyun, sunduğu geri bildirimler oyuncunun karakterin yaşadığı deneyimi arayüzün yapamadığı şeylerden ayırt etmesine yardımcı olduğunda adil hissettirir. Net sonuçlar hikayeyi korur; spesifik girdi yönlendirmesi başka bir denemeyi mümkün kılar; dürüst bilgi sınırları kurguyu tutarlı tutar; ve tanımlanmış bir kurtarma yolu oyuncuya güvenilir bir ilerleme yöntemi sunar.