Blog Metlivi

Apa yang Sebenarnya Dapat Diketahui oleh Asisten AI Karakter yang Hilang dalam Game Misteri?

Untuk game misteri fiksi, asisten AI seharusnya hanya mengetahui catatan cerita yang telah disediakan penulis untuknya—dan hanya dari titik cerita saat catatan tersebut mulai dapat diakses. Berikan setiap fakta sumber, waktu fakta tersebut diketahui, dan aturan akses. Hal ini memungkinkan asisten membantu pemain menghubungkan petunjuk tanpa secara diam-diam menjadi narator yang serba tahu.

30 September 20266 menit membacaMembaca, seni, dan budayaOleh Metlivi Editorial Team
Bagian 1

Pisahkan catatan cerita dari akses asisten

Mulailah dengan catatan cerita lengkap yang ditujukan untuk penulis: peristiwa, pernyataan karakter, objek, pesan, dan urutan kemunculannya dalam permainan. Kemudian tentukan pandangan yang lebih terbatas untuk asisten. Suatu fakta dapat ada di dalam bible cerita tanpa harus langsung dapat diakses oleh sang asisten. Perbedaan itulah yang menjadi fondasi misteri yang adil: penulis boleh mengetahui apa yang terjadi, sementara asisten hanya dapat menggunakan catatan yang diizinkan untuk dilihat oleh peran fiksinya.

Alat fiksi interaktif seperti Twine menyusun cerita ke dalam bagian-bagian (passages) dan dapat menggunakan variabel serta logika kondisional untuk mengubah apa yang dilihat pemain. Hal ini memberikan analogi desain yang berguna: perlakukan setiap catatan yang ditulis sebagai unit diskret, dan buat akses ke catatan tersebut bergantung pada bagian, peristiwa, atau pilihan yang relevan. Twine’s basic concepts

Sebagai contoh, bayangkan seorang karakter fiksi bernama Mara sedang mempersiapkan pajangan kebun komunitas. Asisten mungkin memiliki akses ke catatan perencanaan yang ia bagikan, jadwal yang ditempel di papan grup, dan pesan berikutnya yang ia kirim tentang pemindahan papan tanda lukis ke dalam ruangan. Asisten tidak boleh menyimpulkan keberadaan Mara hanya dari fakta bahwa ia suka berkebun, dan asisten tidak boleh melihat draf pribadi yang tidak pernah dibagikan kepadanya. Batasan-batasan tersebut berasal dari aturan akses cerita yang dibuat oleh penulis, bukan dari klaim tentang apa yang dapat diakses oleh sistem AI di dunia nyata.

Bagian 2

Berikan setiap fakta sumber dan waktu diketahuinya

Catatan fakta yang berguna setidaknya menjawab empat pertanyaan: apa yang diklaim, siapa atau apa yang menyediakannya, kapan fakta tersebut dapat diakses oleh asisten, dan apakah itu bersifat langsung atau berupa inferensi. Model asal-usul (provenance) W3C mendeskripsikan asal-usul informasi dalam bentuk entitas, aktivitas, dan agen; model ini juga memungkinkan catatan mendeskripsikan bagaimana suatu item diturunkan dari item lainnya. Itu adalah kerangka kerja yang praktis untuk catatan fiksi, bahkan jika game hanya menggunakan label sederhana alih-alih model formal. W3C PROV Model Primer

Catatan yang ringkas mungkin terlihat seperti ini:

Klaim: Mara berencana mengecat papan tanda kebun; Sumber: Catatan perencanaan bersama; Diketahui asisten sejak: Senin, 10:00; Jenis: Pernyataan langsung

Klaim: Papan tanda dipindahkan ke dalam ruangan; Sumber: Pembaruan papan grup; Diketahui asisten sejak: Selasa, 16:30; Jenis: Pembaruan langsung

Klaim: Mara mungkin memindahkannya karena prakiraan hujan; Sumber: Catatan cuaca ditambah pembaruan; Diketahui asisten sejak: Selasa, 16:30; Jenis: Inferensi; belum terkonfirmasi

Waktu dalam contoh ini bersifat ilustratif. Perbedaan yang penting adalah antara kapan suatu peristiwa terjadi dan kapan asisten mengetahuinya. Jika sebuah catatan yang dibuat pada hari Senin dibagikan pada hari Selasa, pengetahuan asisten dimulai pada hari Selasa kecuali jika cerita secara eksplisit memberinya akses lebih awal. Pertahankan kedua stempel waktu tersebut jika keduanya berbeda.

Bagian 3

Bedakan antara observasi, laporan, dan inferensi

Sebuah sumber tidak otomatis membuat isinya menjadi pasti. Seorang karakter mungkin mendeskripsikan apa yang mereka lihat; sebuah catatan mungkin tidak lengkap; sebuah jadwal mungkin mencatat rencana dan bukan tindakan yang benar-benar terjadi. Melabeli jenis catatan membantu asisten menyusun responsnya secara akurat: "Papan informasi menyatakan papan tanda telah dipindahkan" berbeda dengan "Mara memindahkan papan tanda," dan keduanya berbeda dengan "Dia mungkin memindahkannya karena faktor cuaca."

Gunakan kosakata terbatas secara konsisten: observasi langsung, laporan karakter, catatan penulis, dan inferensi. Sebuah inferensi harus mengarah kembali ke catatan pendukungnya dan tetap ditandai sebagai inferensi. W3C PROV secara eksplisit memodelkan tanggung jawab agen atas aktivitas dan penurunan satu entitas dari entitas lainnya; menerapkan pembedaan tersebut pada dialog membantu game menunjukkan dari mana suatu kesimpulan berasal, alih-alih menyajikannya sebagai fakta baru. W3C PROV-O

Hal ini juga menciptakan uji kepenulisan yang bermanfaat: dapatkah pemain melacak pernyataan asisten yang meyakinkan kembali ke catatan yang memang diizinkan untuk diaksesnya? Jika tidak, revisi jawabannya, tambahkan catatan penulis yang hilang, atau buat asisten menyatakan bahwa ia tidak memiliki cukup informasi.

Bagian 4

Tentukan akses dalam lini masa cerita, bukan hanya berdasarkan karakter

Untuk setiap catatan, tentukan peristiwa yang membuka akses asisten. Pesan bersama mungkin tersedia segera setelah dikirim; pemberitahuan yang dipasang di papan informasi mungkin tersedia saat asisten memeriksa papan tersebut; sebuah percakapan mungkin baru tersedia setelah pemain memilih untuk menanyakannya. Hindari mengandalkan label yang samar seperti "asisten mengetahui segalanya di dalam arsip" kecuali jika cerita menetapkan apa isi arsip tersebut dan kapan arsip itu diperbarui.

Aturan akses yang praktis memiliki tiga bagian: audiens catatan, pemicu ketersediaannya, dan keterlambatan (delay) apa pun. Misalnya: "Asisten dapat membaca postingan papan grup setelah pemain membuka papan tersebut; ia tidak dapat membaca draf pribadi." Keterlambatan menjadi penting dalam cerita yang bercabang. Jika pemain belum mengunjungi papan tersebut, asisten tidak boleh bertindak seolah-olah ia telah melihat postingan terbaru hanya karena postingan itu ada di tempat lain dalam berkas penulis.

Di Twine, variabel cerita dapat tersedia di seluruh bagian (passages), sedangkan variabel sementara terbatas pada bagian saat ini di Harlowe dan SugarCube. Perbedaan tersebut mengilustrasikan mengapa penulis harus memutuskan secara sengaja apakah suatu fakta bertahan di sepanjang cerita atau hanya milik adegan tertentu. Penerapan persisnya tergantung pada format cerita, jadi perlakukan aturan ini sebagai model desain alih-alih instruksi kode. Twine Cookbook: Variables

Bagian 5

Buat ketidakpastian berguna bagi pemain

Ketika sebuah catatan hilang, usang, atau ambigu, biarkan asisten mendeskripsikan kesenjangan tersebut dalam istilah yang konkret. Asisten dapat mengatakan bahwa ia memiliki rencana hari Senin tetapi tidak ada konfirmasi setelahnya, atau bahwa seorang karakter melaporkan telah memindahkan papan tanda sementara papan informasi tidak memuat pembaruan apa pun. Hal ini memberi pemain langkah selanjutnya yang bermakna: memeriksa sumber lain yang dibuat penulis, meninjau kembali percakapan karakter, atau memutuskan bahwa petunjuk tersebut belum terpecahkan.

Pendekatan tersebut mendukung misteri tanpa kemahatahuan yang sewenang-wenang. Penelitian tentang narasi interaktif telah meneliti bagaimana pengetahuan yang terbatas dapat membentuk perilaku pemain, termasuk studi yang menggunakan fiksi interaktif *Anchorhead* untuk mengeksplorasi model pemain. Bagi asisten yang dirancang penulis, implikasi desainnya cukup sederhana: apa yang telah dipelajari pemain dan asisten dapat memengaruhi pilihan mereka selanjutnya, jadi pantau kondisi pengetahuan tersebut secara eksplisit. Rivera-Villicana et al., “Informing a BDI Player Model for an Interactive Narrative”

Bagian 6

Audit singkat sebelum menulis dialog asisten

Sebelum menyusun draf respons, periksa poin-poin berikut untuk setiap klaim yang berdampak penting:

Apakah klaim tersebut ada dalam catatan penulis, atau dilabeli sebagai inferensi?

Apakah catatan tersebut menyebutkan sumbernya dan membedakan antara rencana, laporan, observasi, atau konfirmasi di kemudian hari?

Pada waktu cerita kapan asisten mendapatkan akses ke catatan tersebut?

Apakah peran fiksi asisten mengizinkan akses ke sumber tersebut?

Jika catatan tersebut tidak lengkap atau saling bertentangan, apakah dialog mempertahankan ketidakpastian tersebut?

Jika jawaban untuk salah satu dari pertanyaan ini tidak jelas, persempit pernyataan asisten hingga sesuai dengan catatan yang tersedia. Karakter yang dihasilkan tetap dapat membantu: ia dapat merangkum apa yang telah dilihatnya, mengidentifikasi apa yang masih belum terkonfirmasi, dan mengarahkan pemain ke petunjuk berikutnya yang telah disiapkan penulis. Keandalannya berasal dari batas yang jelas antara catatan lengkap cerita dan informasi yang benar-benar telah diterimanya.

Bacaan terkait

Lanjutkan topik ini