Bagaimana Game Seharusnya Menangani Detail Pribadi dalam Input Teks Bebas
Ketika seorang pemain mengetikkan detail pribadi biasa ke dalam game, desain yang paling aman adalah hanya mengumpulkan apa yang dibutuhkan oleh fitur tersebut, menjauhkan teks mentah dari dunia fiksi dan konteks karakter bersama, serta memberi pemain cara yang terlihat untuk menghapus materi yang tersimpan. Bagi tim pengembang game, tugas praktisnya adalah melacak satu pesan teks bebas mulai dari input hingga penyimpanan, pemrosesan, dan penghapusan—serta memutuskan di setiap langkah apakah game benar-benar membutuhkan teks tersebut.
Mulailah dengan menentukan apa yang dibutuhkan fitur
Kotak teks bebas dapat memancing informasi lebih banyak daripada yang dibutuhkan game. Seorang pemain mungkin mengetik, “Saya biasanya naik bus pulang dan mampir ke toko roti,” saat meminta adegan tentang memilih kue. Adegan tersebut mungkin hanya membutuhkan pilihan kue atau latarnya; tidak perlu menyimpan rute pulang yang biasa dilalui pemain. Memperlakukan seluruh pesan sebagai data game yang berguna mempermudah detail pribadi tersebar lebih jauh dari yang dibutuhkan fitur tersebut.
Sebelum membangun alur input, tuliskan tujuannya dalam bahasa yang lugas: misalnya, “gunakan latar yang dipilih pemain untuk mempersonalisasi adegan ini.” Kemudian tentukan potongan informasi terkecil yang dapat memenuhi tujuan tersebut. Ini adalah penerapan desain produk dari minimalisasi data (data minimisation): Information Commissioner’s Office Inggris mendeskripsikan penggunaan data bawaan (default) terbatas pada apa yang diperlukan untuk setiap tujuan tertentu, dan merekomendasikan untuk mempertimbangkan privasi sejak tahap desain di seluruh siklus hidup produk (ICO: Data protection by design and by default).
Pertanyaan desain yang berguna adalah: jika pesan mentah tersebut lenyap setelah respons saat ini diberikan, apa kerugian bagi game? Jika jawabannya “tidak ada,” jangan jadikan itu preferensi yang tersimpan. Jika ada sesuatu yang dibutuhkan nanti, pertimbangkan apakah pemain dapat memilih preferensi singkat dan eksplisit—seperti “sertakan latar toko roti”—daripada membiarkan game menyimpan kalimat utuh yang mungkin berisi detail tambahan. Preferensi tersebut adalah pola desain yang diusulkan, bukan klaim tentang fitur game tertentu mana pun.
Jauhkan teks pemain dari memori fiksi
Pisahkan teks yang dimasukkan pemain dari fakta-fakta yang mendefinisikan dunia fiksi. Game mungkin memerlukan status cerita yang persisten seperti “karakter mengunjungi toko roti” atau “adegan berikutnya berada di pasar.” Fakta-fakta tersebut adalah bagian dari cerita. Kalimat tentang rutinitas nyata pemain tidak serta-merta menjadi memori karakter fiksi hanya karena muncul dalam sebuah prompt.
Salah satu pendekatan praktis adalah memberikan destinasi yang berbeda untuk setiap jenis informasi: input sementara untuk pembuatan saat ini, status cerita eksplisit untuk peristiwa fiksi, dan preferensi opsional yang dikontrol pemain untuk pilihan yang dapat digunakan kembali. Jangan menyalin pesan mentah secara otomatis ke profil karakter, ringkasan, memori jangka panjang, event analitik, atau konteks bersama. Jika game perlu meneruskan konteks sebelumnya ke adegan berikutnya, teruskan hanya fakta cerita atau preferensi terpilih yang memang dibutuhkan fitur tersebut.
Pemisahan ini merupakan rekomendasi arsitektural yang diturunkan dari prinsip privasi berdasarkan desain (privacy-by-design), bukan deskripsi dari platform tertentu. NIST Privacy Framework adalah alat bantu sukarela yang dapat disesuaikan oleh organisasi dengan konteks pemrosesan mereka; panduannya menekankan pemilihan hasil yang relevan berdasarkan ekosistem pemrosesan data dan kebutuhan privasi individu (NIST: Getting Started with the Privacy Framework). Bagi tim game, langkah yang bermanfaat adalah memetakan ke mana teks mengalir dan memberikan tujuan yang jelas untuk setiap destinasi.
Jadikan berbagi sebagai pilihan terpisah yang terlihat jelas
Teks bebas yang dimasukkan untuk interaksi game pribadi tidak boleh diam-diam berubah menjadi detail karakter yang dibagikan. Jika pemain ingin memublikasikan kartu karakter, kutipan cerita, atau kiriman komunitas, tunjukkan secara tepat apa yang akan dibagikan dan izinkan pemain mengeditnya sebelum dipublikasikan. Kalimat yang diketik untuk membentuk adegan pribadi tidak boleh muncul di profil, papan peringkat (leaderboard), atau siaran publik secara default.
Hal ini penting karena teks game dapat melintasi batasan dalam operasional produk biasa. Pemberitahuan privasi Ubisoft, misalnya, mendeskripsikan pemrosesan rekaman obrolan dan konten buatan pengguna sehubungan dengan fitur sosial, serta menyatakan bahwa beberapa nama pengguna dan teks mungkin dapat dilihat di papan peringkat atau konteks streaming (Ubisoft: Privacy Policy). Kebijakan tersebut adalah bukti mengenai layanan Ubisoft, bukan deskripsi universal untuk semua game. Ini mengilustrasikan mengapa desainer harus mengidentifikasi fitur mana yang menerima teks dan membuat perubahan audiens apa pun terlihat eksplisit.
Untuk setiap jalur pembagian, tunjukkan audiensnya saat itu juga: privat untuk adegan ini, terlihat oleh teman terpilih, atau publik. Letakkan kontrol di dekat tindakan yang mengubah visibilitas. Hindari bergantung pada halaman pengaturan yang luas untuk menjelaskan pilihan publikasi yang bersifat situasional.
Jelaskan apa yang terjadi pada input
Antarmuka yang jelas harus memberi tahu pemain apakah suatu pesan hanya digunakan untuk menghasilkan respons saat ini, disimpan untuk adegan mendatang, atau dikirim ke layanan eksternal. Buat penjelasannya singkat dan dekat dengan kotak teks. Jika fitur yang berbeda memiliki perilaku yang berbeda, sampaikan demikian pada masing-masing fitur alih-alih menyiratkan bahwa satu aturan berlaku untuk setiap input.
Alasannya bersifat praktis: penyimpanan milik game itu sendiri hanyalah salah satu langkah yang mungkin ada dalam jalur pemrosesan. Misalnya, dokumentasi API OpenAI membedakan log pemantauan penyalahgunaan dari status aplikasi dan mendeskripsikan perbedaan retensi berdasarkan endpoint dan fitur. Kontrol dan batasan yang dinyatakannya berlaku untuk API tersebut, bukan untuk setiap penyedia atau game (OpenAI: Data controls in the OpenAI platform). Tim game harus memeriksa pengaturan dan ketentuan aktual dari penyedia mana pun yang digunakannya, lalu menjelaskan perilaku yang dihasilkan secara akurat.
Jangan melabeli suatu fitur sebagai “sementara” hanya karena game tidak menyimpan pesan tersebut di profil pemain. Lacak apakah teks dapat tertinggal di log permintaan, keluaran debugging, laporan crash, analitik, alat moderasi, atau konteks percakapan yang disimpan. Jika suatu destinasi membutuhkan teks untuk alasan operasional yang jelas, dokumentasikan alur tersebut beserta masa retensinya secara internal, dan hindari menempatkan teks mentah di sistem yang tidak membutuhkannya.
Beri pemain kontrol penghapusan yang menjangkau salinan tersimpan
Jika game menyimpan preferensi yang dapat digunakan kembali atau konteks percakapan, beri pemain kontrol yang terlihat untuk memeriksa dan menghapusnya. Tempatkan kontrol tersebut di tempat pemain mengelola fitur terkait—misalnya, layar “Preferensi cerita tersimpan” dengan tindakan hapus di samping setiap item yang disimpan. Konfirmasikan tindakan tersebut dengan bahasa yang jelas dan tunjukkan saat penghapusan selesai.
Tindakan penghapusan harus mencakup salinan yang dikontrol oleh game, bukan sekadar menyembunyikan satu baris dari antarmuka. Sebagai daftar periksa desain, lacak item yang disimpan melalui penyimpanan profil, ringkasan cerita, indeks pencarian atau penyimpanan pengambilan (retrieval store), dan cache apa pun yang dapat memulihkannya. Tentukan bagaimana cadangan (backup) dan catatan operasional kedaluwarsa, dan beri tahu pemain jika beberapa catatan mengikuti jadwal retensi terpisah. Kerangka kerja inti privasi NIST mengidentifikasi akses untuk peninjauan, pengubahan, dan penghapusan di antara hasil manajemen data, dan mencakup pengujian langkah-langkah teknis sebagai suatu aktivitas (NIST Privacy Framework Core).
Uji alur penghapusan dengan contoh fiksi sederhana: simpan preferensi untuk latar toko roti, pastikan preferensi tersebut dapat memengaruhi adegan berikutnya, hapus preferensi tersebut, lalu pastikan bahwa ia tidak lagi muncul di tampilan preferensi tersimpan atau konteks yang disediakan untuk adegan berikutnya. Ini adalah usulan pengujian produk, bukan hasil yang dilaporkan. Jika penghapusan bersifat asinkron, tunjukkan statusnya dan hindari menampilkan permintaan yang belum selesai seolah-olah sudah tuntas.
Gunakan tinjauan singkat sebelum merilis fitur teks
Untuk setiap fitur teks bebas, tim dapat memeriksa empat pertanyaan: apa input terkecil yang dibutuhkan; sistem mana yang menerima teks mentah; bagian mana, jika ada, yang menjadi status game yang persisten; dan di mana pemain dapat meninjau atau menghapus status tersimpan tersebut? Telusuri satu sampel pesan melalui jalur produk yang sebenarnya, termasuk layanan eksternal, dan pastikan penjelasan yang ditampilkan kepada pemain sesuai dengan alur tersebut.
Pengalaman targetnya sederhana: pemain dapat menggunakan pilihan pribadi biasa untuk membentuk adegan tanpa membuat game secara diam-diam mengubah seluruh kalimat menjadi memori karakter yang permanen. Menjaga input mentah tetap terbatas, memisahkan fakta cerita dari detail pribadi pemain, membuat pembagian transparan, dan menyediakan kontrol penghapusan yang mudah dijangkau akan mengubah tujuan tersebut menjadi keputusan yang dapat diimplementasikan dan diverifikasi oleh tim desain dan rekayasa (engineering).
