Protokol dan komunikasi dalam game MUD berbasis teks dengan Telnet

Jika Anda sudah lama bermain game MUD berbasis teks dan menggunakan klien Telnet di perangkat seluler Anda , Anda mungkin pernah mengalami masalah yang sama: semua orang membicarakan sejarah, nostalgia, dan anekdot tentang Telnet… tetapi hampir tidak ada yang menjelaskan secara jelas bagaimana klien dan server sebenarnya berkomunikasi. Artikel ini bertujuan untuk mengisi kekosongan tersebut: untuk membahas protokol, pesan, urutan kontrol, dan cara membuat server MUD Anda sendiri bekerja dengan lancar dengan klien yang sudah ada.

Kita akan membahas secara menyeluruh dan lugas bagaimana protokol MUD berbasis Telnet bekerja , ekstensi apa saja yang digunakan di industri (GMCP, MSSP, kompresi, dll.), bagaimana pesan diformat, apa yang diharapkan oleh klien seluler, dan apa yang perlu Anda kirim dari server Anda untuk memastikan semuanya berjalan lancar tanpa harus membuat protokol dari awal. Semua ini akan dijelaskan dalam bahasa Spanyol standar (dari Spanyol), dengan contoh yang jelas dan tanpa jargon yang tidak perlu.

1. Telnet sebagai basis: apa yang sebenarnya digunakan oleh sebagian besar MUD.

Sebagian besar MUD klasik tidak menciptakan protokol transport baru: mereka mengandalkan Telnet sebagai lapisan komunikasi antara klien dan server . Ini berarti bahwa, pada akhirnya, yang dikirim adalah aliran byte melalui TCP, di mana teks biasa dicampur dengan perintah Telnet khusus yang diawali dengan byte 255 (0xFF).

Dari perspektif jaringan, server MUD berperilaku seperti server Telnet dasar dengan sejumlah ekstensi opsional . Klien (baik seluler, desktop, atau sistem Telnet sederhana) membuat koneksi TCP ke port MUD (seringkali 23, 4000, 5000, dll.), dan dari situ terjadi pertukaran opsi singkat.

Dalam negosiasi awal ini, kedua pihak saling mengirimkan urutan kontrol Telnet dengan tipe "WILL", "WONT", "DO", dan "DONT" untuk mengaktifkan atau menonaktifkan fitur: echo, ukuran jendela, protokol tambahan seperti GMCP, kompresi, dll. Semua ini dikirim bercampur dengan teks permainan, tetapi klien dapat membedakannya karena perintah kontrol ditandai dengan 0xFF yang sudah dikenal.

Aktifkan fitur Wake on LAN dengan Tasker

2. Kerangka protokol Telnet yang digunakan oleh MUD

Dalam Telnet, setiap perintah kontrol dimulai dengan byte IAC (Interpret As Command, nilai 255) . Ini diikuti oleh satu atau lebih byte yang menunjukkan jenis perintah dan, dalam banyak kasus, kode opsi. Pada tingkat protokol MUD standar, Anda terutama akan menemukan:

IAC DO"Saya ingin Anda (klien) mengaktifkan opsi ini."
IAC TIDAK"Saya tidak ingin Anda menggunakan opsi ini."
IAC AKAN: “Saya (server) dapat dan ingin menggunakan opsi ini.”
IAC TIDAK AKAN"Saya tidak akan menggunakan opsi ini."

Opsi-opsi tersebut diidentifikasi dengan sebuah angka; beberapa di antaranya adalah standar Telnet lama, yang lainnya adalah ekstensi yang disepakati dalam komunitas MUD (misalnya, GMCP, MSSP, COMPRESS2 ), yang tidak muncul dalam RFC Telnet klasik, tetapi telah menjadi "standar semu" de facto karena klien utama mendukungnya.

Sebagai MUD, Anda biasanya akan memulai dialog dengan mengirimkan urutan IAC DO/IAC WILL untuk menguji apa yang didukung klien: apakah klien menerima GMCP, apakah klien menginginkan kompresi, apakah klien menawarkan informasi terminal, dll. Klien akan merespons dengan WILL/WONT atau DO/DONT sesuai kebutuhan. Server Anda harus menghormati respons ini dan tidak menggunakan opsi jika klien tidak menerimanya.

3. Pemisahan antara teks game dan kontrol Telnet

Salah satu pertanyaan umum adalah bagaimana membedakan antara teks game biasa dan perintah kontrol . Aturannya sederhana: apa pun yang tidak diawali dengan 0xFF dianggap sebagai teks. Perintah Telnet selalu diawali dengan byte khusus ini, justru untuk menghindari kebingungan.

Contoh konseptual (Anda tidak perlu menyalinnya kata demi kata, ini hanya untuk visualisasi): server dapat mengirimkan baris deskripsi lingkungan diikuti oleh urutan IAC untuk menegosiasikan suatu opsi. Klien membaca byte demi byte: ketika melihat 0xFF, ia memasuki "mode perintah"; selebihnya ia memperlakukannya sebagai teks, menerapkan warna ANSI jika sesuai, dan menampilkannya.

Jika Anda perlu mengirim byte 0xFF sebagai bagian dari teks (cukup jarang, tetapi mungkin), Anda harus "meng-escape" byte tersebut dengan menduplikasinya . Artinya, untuk mengirim literal 0xFF dalam aliran data userland, Anda mengirim dua 0xFF secara berurutan, dan klien akan menginterpretasikannya dengan benar sebagai "satu 0xFF teks, bukan perintah."

4. Format pesan teks: baris, pemisah, dan warna

Sebagian besar konten yang akan dikirimkan MUD Anda terdiri dari pesan teks yang dapat dibaca: deskripsi, dialog, daftar objek, dan perintah . Meskipun ini mungkin tampak sepele, ada baiknya memperhatikan beberapa detail untuk memastikan klien Telnet (terutama di perangkat seluler) menampilkannya dengan benar.

Secara umum, MUD masih menggunakan gaya klasik baris yang diakhiri dengan CRLF (\r\n) . Beberapa klien hanya mendukung LF (\n), tetapi untuk kompatibilitas maksimal, selalu kirimkan carriage return diikuti dengan line feed.

Untuk warna dan format, MUD biasanya menggunakan kode escape ANSI yang tertanam dalam teks. Misalnya, urutan yang dimulai dengan ESC (0x1B) diikuti oleh “[31m” untuk teks merah, “[1m” untuk teks tebal, dan sebagainya. Ini bukan bagian dari protokol Telnet itu sendiri, tetapi dipahami oleh sebagian besar terminal dan klien MUD tingkat lanjut, termasuk banyak klien seluler.

5. Ekstensi MUD melalui Telnet: GMCP, MSSP dan perusahaan

Selain teks biasa, banyak MUD saat ini menggabungkan Telnet dengan protokol tambahan untuk bertukar data terstruktur dengan klien . Hal ini memungkinkan klien seluler untuk menampilkan antarmuka yang lebih kaya daripada sekadar aliran teks sederhana.

Beberapa ekstensi yang paling sering digunakan antara lain:

GMCP (Protokol Komunikasi MUD Generik)Mengirimkan informasi dalam format JSON (meskipun tidak selalu 100% standar) tentang karakter, peta, saluran, dll.
MSSP (Protokol Status Server Lumpur): dirancang untuk menyediakan data server (nama MUD, jumlah pemain, jenis kelamin, dll.) kepada layanan daftar dan klien yang ingin tahu.
KOMPRESI / KOMPRESI2Kompresi data untuk mengurangi bandwidth, sangat dihargai pada koneksi yang lambat.

Ekstensi ini dinegosiasikan seperti opsi Telnet lainnya: server biasanya mengirimkan IAC WILL GMCP atau IAC DO GMCP dan menunggu respons. Setelah disepakati, ekstensi itu sendiri menentukan cara membungkus data (misalnya, GMCP masuk dalam subnegosiasi Telnet: IAC SB <opsi> … IAC SE).

6. Subnegosiasi (SB dan SE): merangkum data khusus

Ketika opsi Telnet memerlukan pengiriman data lebih banyak daripada sekadar ya/tidak, subnegosiasi digunakan . Polanya adalah:

IAC SB IAC SE

Di dalam blok tersebut, Anda dapat mengirimkan string, angka, atau struktur spesifik yang ditentukan oleh ekstensi tersebut . Misalnya, GMCP biasanya mengirimkan sesuatu yang sangat mirip dengan objek JSON, dengan tanda kutip, kurung kurawal, dan nilai.

Ketika klien menerima IAC SB GMCP, ia mengetahui bahwa semua yang sampai dengan IAC SE adalah bagian dari paket GMCP, dan bukan aliran teks game biasa. Hal ini memungkinkan klien untuk memisahkan dengan jelas apa yang masuk ke antarmuka pengguna grafis dari apa yang masuk ke buffer teks klasik.

7. Apa yang dikirim oleh server MUD: alur komunikasi tipikal

Bayangkan urutan kejadian dari saat pemain terhubung dari klien Telnet seluler ke server MUD Anda :

Klien membuka koneksi TCP ke port MUD.
Server akan mengirimkan banner selamat datang (teks) dan mungkin beberapa pesan lainnya. Urutan IAC untuk perdagangan opsi (gema, GMCP, kompresi…).
Pelanggan merespons dengan menerima atau menolak pilihan tersebut dengan WILL/WONT dan DO/DONT.
Dari situ, server mengirimkan layar login (teks) dan memproses perintah yang diketik pemain.

Setiap saat, server harus dapat membaca input klien sebagai campuran teks dan perintah Telnet , sama seperti klien membaca output Anda. Misalnya, ketika pemain mengetik "utara" dan menekan Enter, klien biasanya mengirimkan string tersebut diikuti oleh karakter carriage return dan line feed. Server Anda membaca hingga akhir baris dan menginterpretasikannya sebagai perintah dari pemain.

Jika klien memutuskan untuk memulai opsi apa pun (misalnya, memicu negosiasi ukuran jendela), Anda juga harus siap menerima urutan IAC dari sisi klien dan merespons dengan tepat, bukan hanya sebaliknya.

8. Apa yang dikirimkan oleh klien Telnet (termasuk klien seluler)

Dari sudut pandang server Anda, klien Telnet standar (seluler atau desktop) pada dasarnya akan mengirimkan dua jenis hal kepada Anda: teks pengguna dan perintah Telnet . Teks biasanya berupa ASCII atau UTF-8 tergantung pada klien; sebaiknya diasumsikan setidaknya UTF-8 saat ini.

Perintah Telnet yang Anda terima terutama merupakan respons terhadap permintaan negosiasi Anda . Jika Anda mengirim `IAC DO GMCP`, klien akan merespons dengan `IAC WILL GMCP` jika mendukungnya, atau `IAC WONT GMCP` jika tidak. Klien juga dapat memulai negosiasi sendiri (misalnya, mengenai tipe terminal).

Detail penting untuk kompatibilitas seluler adalah bahwa banyak klien modern menginterpretasikan perintah karakter demi karakter atau baris demi baris, tergantung pada konfigurasinya . Menginterpretasikan baris demi baris lebih umum, jadi susunlah parser input perintah Anda dengan mempertimbangkan baris lengkap yang dipisahkan oleh \r\n, bukan karakter individual.

9. Penggunaan proxy dan masalah jaringan dengan MUD di jaringan terbatas.

Di beberapa lingkungan (misalnya, jaringan perusahaan, kampus, atau operator seluler tertentu), port berkecepatan tinggi yang biasa digunakan oleh MUD mungkin diblokir oleh firewall . Dalam kasus ini, pemain mendapati bahwa mereka tidak dapat terhubung langsung ke port MUD, meskipun Telnet sendiri diizinkan pada port standar.

Solusi klasik melibatkan penggunaan proxy perantara yang mendengarkan pada port yang diizinkan (seperti port Telnet 23 atau port FTP 21) dan meneruskan koneksi ke port sebenarnya dari MUD. Proxy bertindak sebagai jembatan: klien terhubung ke proxy, dan proxy, di balik layar, membuka koneksi ke server game.

Seringkali juga rekan kerja dengan koneksi internet permanen memasang proxy di komputer mereka dan memungkinkan pemain lain mengakses MUD melalui alamat IP mereka . Namun, Anda perlu berhati-hati dengan IP bersama: jika beberapa akun terhubung dari IP yang sama, beberapa MUD mungkin menganggap ini sebagai multiplayer ilegal dan memberikan sanksi. Idealnya, Anda harus memberi tahu administrator game jika Anda berencana untuk berbagi alamat IP Anda secara teratur.

10. Keterbatasan dan risiko penggunaan proksi untuk MUD

Meskipun proxy dapat membantu Anda di jaringan yang sangat tertutup, saat ini proxy anonim publik yang andal tidak banyak tersedia dan beberapa yang tersisa biasanya kelebihan beban, tidak berfungsi, atau diblokir karena alasan keamanan.

Selain itu, jaringan yang memblokir port berkecepatan tinggi mungkin juga memblokir port 8080 , yang sangat umum untuk proxy HTTP. Oleh karena itu, jika seseorang membuat proxy pribadi untuk mengakses MUD, disarankan untuk menempatkannya pada port yang hampir tidak pernah difilter (23, 21, atau port lain yang sangat umum dan diizinkan pada jaringan tersebut).

Gunakan ponsel Anda sebagai server FTP untuk transfer cepat.

11. Contoh interaksi naratif dalam teks MUD

Di luar aspek teknis, MUD berbasis teks mengandalkan deskripsi dan atmosfer yang kaya . Banyak game menyertakan cuplikan teks ikonik, kutipan sastra, atau fragmen yang hampir puitis yang dikirim server secara verbatim ke klien untuk meningkatkan pengalaman bermain pemain.

Sebagai contoh, semacam "litani melawan rasa takut" mungkin muncul di layar ketika karakter menghadapi momen penting. Secara teknis, ini hanyalah rangkaian baris teks dengan jeda yang sesuai dan, jika diinginkan, beberapa warna atau format. Tetapi dalam hal pengalaman pengguna, hal ini memiliki dampak yang signifikan.

Jenis teks ini, meskipun tidak mengubah protokol Telnet, memengaruhi cara Anda menangani spasi baris, penomoran halaman, dan kecepatan penyegaran . Jika Anda menampilkan beberapa paragraf panjang sekaligus, teks tersebut dapat menjadi tidak terbaca di layar kecil (seperti ponsel). Itulah mengapa banyak server menerapkan sistem "penomoran halaman" yang menghentikan sementara output setelah sejumlah baris tertentu dan menunggu pemain menekan tombol untuk melanjutkan.

12. Sumber daya eksternal dan dokumentasi teknis tambahan

Berbeda dengan protokol lain yang sangat terstandarisasi, ekosistem MUD didorong oleh dokumen-dokumen yang tersebar, PDF akademis, dan artikel-artikel lepas yang menjelaskan varian, proposal perluasan, dan studi tentang interaksi di lingkungan MUD.

Tersedia karya-karya di repositori universitas dan perpustakaan digital yang menganalisis arsitektur klien-server MUD, evolusi dari Telnet sederhana ke protokol yang lebih kompleks , dan bahkan masalah pengalaman pengguna pada antarmuka teks. Meskipun banyak dari dokumen-dokumen ini tidak mengajarkan langkah demi langkah cara memformat pesan, dokumen-dokumen tersebut menawarkan konteks yang berguna untuk memahami mengapa protokol tertentu diadopsi dan bagaimana protokol tersebut digabungkan.

Untuk melengkapi implementasi, disarankan juga untuk meninjau dokumentasi klien MUD populer (baik desktop maupun seluler), di mana biasanya mereka merinci ekstensi apa yang mereka dukung (GMCP, MXP, MSDP, dll.), set karakter apa yang mereka tangani, bagaimana mereka menangani warna ANSI, dan batasan apa yang mereka miliki pada layar kecil.

13. Domain dan Nama Host yang Sangat Besar: Kekacauan Infrastruktur yang Terlihat

Jika Anda pernah melihat catatan DNS dari penyedia hosting utama, Anda mungkin pernah melihat daftar nama yang sangat panjang seperti www, mail, ftp, webmail, smtp, pop3, imap, panel, cpanel, admin, dev, test, dan variasi yang tak terhitung jumlahnya . Meskipun mungkin tampak seperti kebisingan, ini sebenarnya mencerminkan bagaimana infrastruktur yang menampung banyak MUD dan layanan terkait diatur.

Di balik satu domain tunggal, terdapat ratusan subdomain: server basis data, mesin pengujian, proxy, penyeimbang beban, layanan statistik, platform email, penyimpanan, VPN … dan seringkali, bahkan port tempat MUD (Multi-User Dungeon) beroperasi. Dalam beberapa kasus, permainan dimainkan pada subdomain yang terpisah; dalam kasus lain, permainan berbagi alamat IP dengan berbagai layanan mulai dari forum hingga wiki dan panel kontrol.

Banyaknya nama domain ini menjadi relevan jika Anda berencana mempublikasikan MUD Anda di server bersama atau menyiapkan proxy khusus untuk pemain: Anda perlu mengoordinasikan dengan cermat subdomain mana yang mengarah ke mesin mana, port mana yang dibuka, dan bagaimana keamanan dikelola agar lalu lintas Telnet tidak mengganggu layanan penting lainnya secara berbahaya.

14. Pertimbangan praktis bagi pelanggan Telnet di perangkat seluler

Memainkan game atau mengembangkan aplikasi dengan klien Telnet di perangkat seluler menambah kerumitan: layar kecil, keyboard sentuh, kemungkinan seringnya pemutusan koneksi jaringan, dan terkadang keterbatasan klien itu sendiri dalam hal dukungan ekstensi.

Saat mendesain server MUD Anda, perhatikan beberapa poin berikut:

Hindari antrean yang terlalu panjang.Gunakan paragraf pendek yang lebih baik agar pengguna tidak perlu menggulir dari sisi ke sisi.
Batasi penggunaan kode ANSI. Dan pastikan mereka tidak merusak tata letak untuk klien yang tidak memahaminya dengan baik.
Tangani penomoran halaman dengan hati-hati. agar pengalaman tersebut tidak menjadi deretan teks yang sulit diikuti.
Terapkan penyambungan ulang lunak.Di perangkat seluler, sinyal mudah hilang dan kemudian terhubung kembali; server Anda harus dapat mentolerir hal ini tanpa mengganggu sesi pemain pada gangguan singkat pertama.

Beberapa aplikasi seluler yang khusus untuk MUD sudah menyertakan dukungan untuk GMCP dan ekstensi lainnya, jadi jika Anda mengimplementasikannya di server, Anda dapat menawarkan informasi terstruktur yang ditampilkan klien sebagai panel, bilah kesehatan, peta cepat , dan alat bantu visual lainnya di atas teks klasik.

15. Buat server MUD Anda sendiri yang kompatibel dengan klien yang sudah ada.

Jika Anda memutuskan untuk membuat server MUD sendiri dari awal, kunci untuk menghindari isolasi adalah dengan menghormati Telnet sebagai lapisan dasar dan menegosiasikan opsi-opsinya dengan benar . Anda tidak perlu menciptakan kembali protokolnya, tetapi cukup ikuti konvensi yang sudah terbukti.

Singkatnya, agar kompatibel dengan sebagian besar klien umum, Anda harus:

Melaksanakan Penguraian perintah Telnet (IAC, DO, DONT, WILL, WONT, SB, SE).
Dukung setidaknya beberapa opsi umum: gema, penekanan gema lokal, GMCP Jika Anda menginginkan data yang lebih kaya, dan mungkin juga kompresi.
Mengirim teks dalam format yang mudah digunakanCRLF, ANSI opsional, tanpa menggunakan baris yang terlalu panjang.
Menerima input dalam mode online dan menangani pemisah baris yang dikirim oleh klien seluler dengan benar.

Dari situ Anda dapat memperluas server Anda dengan protokol tambahan atau bahkan dengan klien Anda sendiri, tetapi memulai dari dasar ini memungkinkan Anda untuk menguji game Anda dengan klien Telnet yang ada dan memanfaatkan seluruh ekosistem yang telah tercipta di sekitar MUD selama bertahun-tahun.