Kondisi Kegagalan Game Teks: Cara Membedakan Kemunduran Cerita dari Masalah Input atau Pengiriman
Dalam game teks bergaya obrolan (chat), giliran yang tidak berhasil tidak selalu berarti pemain membuat pilihan yang buruk. Adegan mungkin telah mencapai kemunduran fiksi yang valid, game mungkin tidak mendukung pilihan kata tersebut, karakter mungkin tidak memiliki pengetahuan yang diperlukan untuk bertindak, atau pesan mungkin gagal terkirim. Situasi-situasi ini memerlukan umpan balik yang berbeda dan efek percobaan ulang yang berbeda pula. Klasifikasikan penyebabnya terlebih dahulu, lalu beri tahu pemain apa yang berubah dan apa yang bisa terjadi selanjutnya.
Mulailah dengan menanyakan apa yang gagal
Pertanyaan praktis pertama adalah: apakah game memahami tindakan yang dimaksudkan dan menyelesaikannya di dalam fiksi cerita? Jika ya, hasilnya mungkin berupa sebuah kemunduran cerita (setback). Jika tidak, tentukan apakah masalahnya ada pada input, informasi karakter, atau pengiriman oleh sistem. Pembedaan empat bagian ini merupakan alat bantu desain yang disimpulkan dari cara sistem fiksi interaktif memisahkan penguraian (parsing), aturan dunia, alur cerita, dan perilaku pembatalan (undo); ini bukan standar teknis universal. Dokumentasi Inform, misalnya, menggambarkan parser dan model dunia simulasi sebagai bagian terpisah dari sebuah game, dan parser-nya dapat melaporkan beberapa alasan berbeda mengapa sebuah perintah tidak cocok. (Inform 6 Designer’s Manual: Introduction, Inform 6 Designer’s Manual §33: Helping the parser out of trouble)
Perlakukan pesan sebagai bagian dari kontrak respons game. Pesan tersebut harus menjawab tiga hal: apa yang terjadi, apakah status fiksi berubah, dan apa yang dapat dilakukan pemain sekarang. Kalimat singkat seperti “Perahu kertas terbalik sebelum mencapai tepi seberang. Catatan yang terlipat masih ada di tanganmu. Kamu bisa mencoba saluran yang lebih lebar atau memilih cara lain untuk menyeberang” membuat kemunduran cerita, barang yang tersisa, dan langkah selanjutnya terbaca dengan jelas.
1. Kemunduran fiksi yang valid
Kemunduran cerita tepat digunakan saat game memahami tindakan tersebut, memeriksanya terhadap adegan saat ini, dan secara sengaja menghasilkan konsekuensi di dalam dunia game. Mungkin pemain mencoba membawa terlalu banyak buku perpustakaan sekaligus dan salah satunya meluncur ke kursi terdekat. Mungkin perahu kertas kemasukan air sebelum mencapai sisi lain dari aliran sungai yang dangkal. Hasilnya bisa jadi merepotkan atau mengejutkan tanpa mengubah interaksi tersebut menjadi penghakiman terhadap pemain.
Ciri penentunya adalah perubahan status (state change). Jika adegan menyatakan perahu tenggelam, hasil tersebut harus menjadi kenyataan dalam cerita. Jika pemain dapat mengambilnya kembali, jelaskan caranya; jika perahu itu hilang, jangan menyiratkan bahwa mencoba kembali teks yang sama akan membatalkan kejadian tersebut. Percobaan ulang bisa berarti membuat perahu lain, memilih rute lain, atau melanjutkan dari adegan yang telah berubah. Pilihan pastinya bergantung pada aturan game.
Pesan kemunduran cerita yang berguna menyebutkan tindakan yang dicoba, konsekuensinya, dan kelanjutan yang tersedia. Pesan tersebut tidak boleh menyamarkan tindakan yang didukung sebagai kesalahan input hanya karena hasilnya tidak menguntungkan. Sebaliknya, jangan menyiratkan bahwa suatu konsekuensi telah terjadi jika game sebenarnya tidak mengubah status cerita. Pembedaan ini memungkinkan pemain memahami apakah mereka sedang melanjutkan dari situasi baru atau memperbaiki perintah yang belum diproses.
2. Input yang tidak didukung: game tidak dapat menguraikan susunan kata
Input yang tidak didukung berarti sistem tidak dapat memetakan pesan pemain ke tindakan yang didukungnya. Pemain mungkin mengetik “tanya pembuat roti tentang aprikot” dalam adegan di mana game hanya menerima serangkaian kecil pilihan tombol, atau menggunakan nama yang tidak dikenali oleh parser. Hal ini menunjukkan cakupan antarmuka, bukan kualitas ide pemain.
Parser fiksi interaktif mengilustrasikan mengapa umpan balik yang berguna harus spesifik: Inform mencantumkan kesalahan terpisah untuk kata kerja yang tidak dikenali, referensi yang tidak jelas, input yang terlalu sedikit, dan objek yang tidak dapat dilihat. Panduannya juga menunjukkan bagaimana sebuah game dapat mengganti pesan kesalahan parser generik dengan pesan yang lebih informatif. (Inform 7 §18.35: Printing a parser error) Dalam game obrolan, respons yang ringkas bisa berupa: “Saya tidak dapat menguraikan 'tanya tentang aprikot' di sini. Kamu dapat bertanya tentang pengiriman atau memilih topik dari meja kasir.”
Tawarkan jalur perbaikan. Bergantung pada antarmukanya, itu bisa berarti menampilkan pilihan yang dikenali, mengajukan satu klarifikasi terarah, atau mengajak pemain untuk menyusun ulang kalimatnya. Jangan menceritakan perintah yang tidak didukung sebagai kegagalan fiksi: jika tidak ada tindakan yang dijalankan, nyatakan dengan jelas. Jaga agar adegan sebelumnya tetap utuh, dan jelaskan bahwa mengirimkan input yang telah diperbaiki akan mencoba kembali momen yang sama, bukan memundurkan peristiwa cerita.
3. Pengetahuan karakter tidak tersedia: pertanyaan valid yang belum memiliki jawaban
Terkadang input dapat dipahami, tetapi karakternya tidak tahu cukup banyak untuk bertindak berdasarkan hal tersebut. Seorang pemain mungkin bertanya kepada asisten penjaga toko ke mana sebuah paket dikirimkan, sebelum asisten tersebut melihat tanda terima. Game dapat mengenali pertanyaan tersebut sambil menahan jawaban pasti secara tepat.
Hal ini berbeda dari input yang tidak didukung: topik atau tindakannya valid, dan batasannya terletak pada informasi karakter di dalam fiksi cerita. Tandai batasan itu dengan jelas. Misalnya: “Mina belum melihat slip pengiriman, jadi dia tidak bisa menyebutkan nama jalannya. Label paket masih ada di meja kasir.” Jika pemain dapat memeriksa label, bertanya kepada orang lain, atau kembali lagi nanti, sebutkan opsi tersebut. Jika tidak, sampaikan apa yang sebenarnya diketahui daripada mengarang petunjuk atau memperlakukan pertanyaan tersebut sebagai format yang salah.
Tentukan apakah respons ini memajukan waktu atau mengubah status. Jika mengajukan pertanyaan adalah tindakan normal di dalam dunia game, game dapat merekam percakapan tersebut atau mengubah cara karakter merespons nanti. Jika game bermaksud membuat pertanyaan seputar pengetahuan bebas dari konsekuensi giliran, pertahankan adegan dan biarkan pertanyaan lain menyusul. Pemain tidak perlu menebak-nebak apakah permintaan informasi secara diam-diam telah menghabiskan kesempatan mereka.
4. Kegagalan pengiriman teknis: tindakan mungkin tidak pernah sampai ke cerita
Kegagalan pengiriman terjadi di luar fiksi cerita: respons mengalami waktu habis (time out), muncul dua kali, atau berhenti di tengah kalimat. Game tidak dapat mengklaim dengan pasti bahwa karakter telah bertindak atau cerita telah berjalan kecuali game tahu bahwa tindakan tersebut telah diproses. Ini berbeda dari pesan di dalam dunia game seperti “kurir tidak dapat menemukan alamatnya,” yang merupakan hasil fiksi.
Gunakan susunan kata status yang lugas dan laporkan status yang diketahui. Jika game dapat memverifikasi bahwa giliran belum diproses, katakan demikian dan biarkan pemain mengirimkannya kembali. Jika tidak dapat menentukan apakah giliran telah diproses, hindari mengajak pengulangan buta yang mungkin menjalankan tindakan tersebut dua kali. Jelaskan ketidakpastian tersebut secara singkat dan tawarkan cara untuk memeriksa adegan saat ini atau melanjutkan dari titik terkonfirmasi terakhir. Ini adalah rekomendasi desain yang disimpulkan dari kebutuhan untuk membedakan ketidakcocokan input dari hasil cerita; sistem fiksi yang dikutip tidak menentukan protokol universal untuk kegagalan pengiriman obrolan.
Ketika pengiriman pulih, pulihkan pesan terakhir yang terkonfirmasi atau tunjukkan rekap ringkas dari adegan dan tindakan terbaru yang diketahui telah selesai. Beri label rekap sebagai rekap, bukan sebagai giliran cerita baru. Jika pemain memilih untuk mengirim ulang, jelaskan apakah tindakan itu akan diperlakukan sebagai upaya baru. Sedikit transparansi tersebut mencegah tindakan duplikat disalahartikan sebagai pengulangan yang disengaja.
Bedakan arti coba lagi (retry), batalkan (undo), dan lanjutkan (resume)
Kata-kata ini mendeskripsikan efek status yang berbeda, jadi hindari menggunakannya secara bergantian. Percobaan ulang (retry) mengirimkan tindakan lagi pada status saat ini; tindakan ini tidak boleh secara diam-diam menghapus konsekuensi yang sudah terjadi. Pembatalan (undo) memulihkan status sebelumnya. Pelanjutan (resume) melanjutkan dari status terkonfirmasi terakhir setelah interupsi. Memulai ulang (restart) mengulang cerita dari awal.
Panduan Harlowe Twine mendokumentasikan pembatalan (undo) sebagai tindakan kembali ke bagian (passage) sebelumnya dan melupakan perubahan variabel yang dibuat di bagian saat ini; panduan ini mendeskripsikan memulai ulang (restart) sebagai memuat ulang halaman untuk memulai cerita lagi dari awal. Panduan tersebut juga mencatat bahwa riwayat undo dapat dibatasi. Mekanika tersebut menunjukkan mengapa suatu kontrol harus mengomunikasikan cakupannya alih-alih mengandalkan label “coba lagi” yang samar. (Harlowe 3.3.8 Manual: undo and restart)
Urutan keputusan yang ringkas membantu menjaga antarmuka tetap konsisten:
Apakah game memahami dan menyelesaikan tindakan tersebut? Jika ya, laporkan hasil fiksi dan status yang tersisa.
Apakah sistem gagal memetakan susunan kata ke tindakan yang didukung? Jelaskan apa yang tidak dapat diuraikannya dan tunjukkan jalur perbaikan; pertahankan adegan.
Apakah tindakannya dipahami, tetapi karakternya kekurangan informasi? Jelaskan batasan pengetahuan dan cara apa pun di dalam dunia game untuk mempelajari lebih lanjut.
Apakah pemrosesan atau pengiriman belum pasti? Nyatakan apa yang terkonfirmasi, lalu tawarkan cara yang aman untuk memeriksa atau melanjutkan.
Jika pemain ingin kembali, beri label pada kontrol “Batalkan” (Undo) dan nyatakan momen atau perubahan mana yang dipulihkan. Simpan “Mulai Ulang” (Restart) untuk memulai dari awal.
Pemeriksaan konsistensi singkat untuk setiap pesan kegagalan
Sebelum merilis sebuah respons, periksalah terhadap status cerita. Jika respons tersebut menggambarkan kemunduran cerita, apakah dunia cerita benar-benar berubah? Jika menggambarkan input yang tidak didukung, apakah game menghindari kepura-puraan bahwa tindakan itu telah terjadi? Jika karakter kekurangan pengetahuan, apakah respons tersebut membedakannya dari perintah yang hilang? Jika pengiriman gagal, apakah pemain tahu apakah gilirannya telah diproses? Terakhir, apakah kontrol coba lagi atau lanjutkan melakukan apa yang dijanjikan oleh labelnya?
Game teks terasa adil ketika umpan baliknya membantu pemain membedakan apa yang dialami karakter dari apa yang tidak dapat dilakukan oleh antarmuka. Konsekuensi yang jelas mempertahankan cerita; panduan input yang spesifik memungkinkan upaya lain; batas pengetahuan yang jujur menjaga fiksi tetap koheren; dan jalur pemulihan yang pasti memberi pemain cara yang andal untuk melangkah maju.