Protokol dan komunikasi dalam permainan MUD berasaskan teks dengan Telnet

Jika anda telah lama bermain-main dengan permainan MUD berasaskan teks dan klien Telnet pada peranti mudah alih anda , anda mungkin pernah menghadapi masalah yang sama: semua orang bercakap tentang sejarah, nostalgia dan anekdot Telnet… tetapi hampir tiada siapa yang menjelaskan dengan jelas bagaimana klien dan pelayan sebenarnya berkomunikasi. Artikel ini bertujuan untuk mengisi jurang tersebut: untuk mendalami protokol, mesej, jujukan kawalan dan cara menjadikan pelayan MUD anda sendiri berfungsi dengan lancar dengan klien sedia ada.

Kita akan melihat secara menyeluruh dan terus terang cara protokol MUD berasaskan Telnet yang biasa berfungsi , sambungan yang digunakan dalam industri (GMCP, MSSP, pemampatan, dll.), cara mesej diformatkan, apa yang diharapkan oleh klien mudah alih dan apa yang perlu anda hantar dari pelayan anda untuk memastikan semuanya berjalan lancar tanpa perlu membuat protokol dari awal. Semua ini akan dijelaskan dalam bahasa Sepanyol standard (dari Sepanyol), dengan contoh yang jelas dan tanpa jargon yang tidak perlu.

1. Telnet sebagai asas: apa yang sebenarnya digunakan oleh kebanyakan MUD

Kebanyakan MUD klasik tidak mencipta pengangkutan baharu: ia bergantung pada Telnet sebagai lapisan komunikasi antara klien dan pelayan . Ini bermakna, pada penghujung hari, apa yang dihantar ialah strim bait melalui TCP, di mana teks biasa dicampur dengan arahan Telnet khas yang didahului oleh bait 255 (0xFF).

Pelayan MUD bertindak, dari perspektif rangkaian, seperti pelayan Telnet asas dengan pelbagai sambungan pilihan . Klien (sama ada mudah alih, desktop atau sistem Telnet mudah) mewujudkan sambungan TCP ke port MUD (selalunya 23, 4000, 5000, dll.), dan dari situ pertukaran pilihan ringkas bermula.

Dalam rundingan awal ini, kedua-dua pihak saling menghantar jujukan kawalan Telnet jenis "WILL", "WONT", "DO", dan "DONT" untuk mengaktifkan atau menyahaktifkan ciri-ciri: gema, saiz tetingkap, protokol tambahan seperti GMCP, pemampatan, dll. Semua ini bercampur dengan teks permainan, tetapi klien boleh membezakannya kerana arahan kawalan ditanda dengan 0xFF yang terkenal.

2. Rangka protokol Telnet yang digunakan oleh MUD

Dalam Telnet, sebarang arahan kawalan bermula dengan bait IAC (Interpret As Command, nilai 255) . Ini diikuti oleh satu atau lebih bait yang menunjukkan jenis arahan dan, dalam banyak kes, kod pilihan. Pada peringkat protokol MUD standard, anda akan menemui terutamanya:

• IAC DO"Saya mahu anda (pelanggan) mengaktifkan pilihan ini."
• IAC JANGAN"Saya tak nak awak guna pilihan ni."
• IAC WILL: “Saya (pelayan) boleh dan mahu menggunakan pilihan ini.”
• IAC WON"Saya tidak akan menggunakan pilihan ini."

Pilihan-pilihan tersebut dikenal pasti melalui suatu nombor; sesetengahnya adalah piawaian Telnet lama, yang lain adalah sambungan yang dipersetujui dalam komuniti MUD (contohnya, GMCP, MSSP, COMPRESS2 ), yang tidak muncul dalam RFC Telnet klasik, tetapi telah menjadi "pseudo-piawai" de facto kerana klien utama menyokongnya.

Sebagai MUD, anda biasanya akan memulakan dialog dengan menghantar jujukan IAC DO/IAC WILL untuk menguji apa yang disokong oleh klien: sama ada ia menerima GMCP, sama ada ia mahukan pemampatan, sama ada ia menawarkan maklumat terminal, dsb. Klien akan bertindak balas dengan WILL/WONT atau DO/DONT yang sesuai. Pelayan anda mesti menghormati respons ini dan tidak menggunakan pilihan jika klien tidak menerimanya.

3. Pemisahan antara teks permainan dan kawalan Telnet

Satu soalan biasa ialah bagaimana untuk membezakan antara teks permainan biasa dan arahan kawalan . Peraturannya mudah: apa-apa sahaja yang tidak didahului oleh 0xFF dianggap sebagai teks. Arahan Telnet sentiasa bermula dengan bait khas ini, tepat untuk mengelakkan kekeliruan.

Contoh konseptual (anda tidak perlu menyalinnya secara verbatim, ia hanya untuk visualisasi): pelayan boleh menghantar baris penerangan persekitaran diikuti dengan urutan IAC untuk merundingkan pilihan. Klien membaca bait demi bait: apabila ia melihat 0xFF, ia memasuki "mod arahan"; selebihnya ia melayannya sebagai teks, menggunakan warna ANSI jika sesuai dan memaparkannya.

Jika anda perlu menghantar bait 0xFF sebagai sebahagian daripada teks (agak jarang berlaku, tetapi mungkin), anda mesti "mengecualikannya" dengan menduplikasinya . Iaitu, untuk menghantar 0xFF literal dalam strim data userland, anda menghantar dua 0xFF berturut-turut dan klien mentafsirkannya dengan betul sebagai "satu 0xFF teks, bukan arahan".

4. Format mesej teks: baris, jeda dan warna

Kebanyakan kandungan yang akan dihantar oleh MUD anda terdiri daripada mesej teks yang boleh dibaca: penerangan, dialog, senarai objek dan arahan . Walaupun ini mungkin kelihatan remeh, adalah wajar untuk memberi perhatian kepada beberapa butiran bagi memastikan klien Telnet (terutamanya pada mudah alih) memaparkannya dengan betul.

Secara amnya, MUD masih menggunakan gaya klasik baris yang ditamatkan dengan CRLF (\r\n) . Sesetengah klien hanya menyokong LF (\n), tetapi untuk keserasian maksimum, sentiasa hantar carriage return diikuti dengan suapan baris.

Untuk warna dan pemformatan, MUD biasanya menggunakan kod escape ANSI yang terbenam dalam teks. Contohnya, urutan yang bermula dengan ESC (0x1B) diikuti dengan “[31m” untuk teks merah, “[1m” untuk huruf tebal, dsb. Ini bukan sebahagian daripada protokol Telnet itu sendiri, tetapi difahami oleh kebanyakan terminal dan klien MUD lanjutan, termasuk banyak klien mudah alih.

5. Sambungan MUD melalui Telnet: GMCP, MSSP dan syarikat

Selain teks biasa, banyak MUD hari ini menggabungkan Telnet dengan protokol tambahan untuk bertukar data berstruktur dengan klien . Ini membolehkan klien mudah alih memaparkan antara muka yang lebih kaya daripada strim teks mudah.

Antara pelanjutan yang paling kerap ialah:

• GMCP (Protokol Komunikasi MUD Generik): menghantar maklumat dalam format JSON (walaupun tidak selalunya 100% standard) tentang aksara, peta, saluran, dsb.
• MSSP (Protokol Status Pelayan Lumpur): direka untuk menyediakan data pelayan (nama MUD, bilangan pemain, jantina, dll.) kepada perkhidmatan penyenaraian dan pelanggan yang ingin tahu.
• MAMPAT / MAMPAT2Pemampatan data untuk mengurangkan lebar jalur, sangat dihargai dalam sambungan perlahan.

Sambungan ini dirundingkan sama seperti pilihan Telnet yang lain: pelayan biasanya menghantar IAC WILL GMCP atau IAC DO GMCP dan menunggu respons. Setelah dipersetujui, sambungan itu sendiri menentukan cara untuk merangkum data (contohnya, GMCP berada dalam subrundingan Telnet: IAC SB <option> … IAC SE).

6. Subrundingan (SB dan SE): merangkum data khas

Apabila pilihan Telnet memerlukan penghantaran lebih banyak data daripada ya/tidak yang mudah, subrundingan digunakan . Coraknya ialah:

• IAC SB IAC SE

Dalam blok itu, anda boleh menghantar rentetan, nombor atau struktur tertentu yang ditakrifkan oleh sambungan tersebut . Contohnya, GMCP biasanya menghantar sesuatu yang sangat serupa dengan objek JSON, dengan petikan, pendakap kerinting dan nilai.

Apabila klien menerima IAC SB GMCP, ia tahu bahawa semua yang berkaitan dengan IAC SE adalah sebahagian daripada pakej GMCP, dan bukan strim teks permainan biasa. Ini membolehkannya memisahkan dengan jelas apa yang masuk ke UI grafik daripada apa yang masuk ke penimbal teks klasik.

7. Apa yang dihantar oleh pelayan MUD: aliran komunikasi biasa

Bayangkan urutan dari masa pemain menyambung dari klien Telnet mudah alih ke pelayan MUD anda :

1. Klien membuka sambungan TCP ke port MUD.
2. Pelayan menghantar sepanduk alu-aluan (teks) dan mungkin beberapa Urutan IAC untuk pilihan perdagangan (gema, GMCP, pemampatan…).
3. Pelanggan bertindak balas dengan menerima atau menolak pilihan tersebut dengan AKAN/AKAN dan LAKUKAN/TIDAK.
4. Dari sana, pelayan menghantar skrin log masuk (teks) dan memproses arahan yang ditaip oleh pemain.

Pada setiap masa, pelayan mesti dapat membaca input klien sebagai campuran teks dan arahan Telnet , sama seperti yang dilakukan oleh klien dengan output anda. Apabila pemain menaip, contohnya, "north" dan menekan Enter, klien biasanya menghantar rentetan tersebut diikuti dengan carriage return dan suapan baris. Pelayan anda membaca hingga akhir baris dan mentafsirkannya sebagai arahan daripada pemain.

Jika klien memutuskan untuk memulakan sebarang pilihan (contohnya, mencetuskan rundingan saiz tetingkap), anda juga mesti bersedia untuk menerima jujukan IAC daripada pihak klien dan bertindak balas dengan sewajarnya, bukan sebaliknya sahaja.

8. Apa yang dihantar oleh klien Telnet (termasuk klien mudah alih)

Dari perspektif pelayan anda, klien Telnet standard (mudah alih atau desktop) pada asasnya akan menghantar dua jenis perkara kepada anda: teks pengguna dan arahan Telnet . Teks tersebut biasanya ASCII atau UTF-8 bergantung pada klien; adalah lebih baik untuk menganggap sekurang-kurangnya UTF-8 pada masa kini.

Arahan Telnet yang anda terima terutamanya merupakan respons kepada permintaan rundingan anda . Jika anda menghantar `IAC DO GMCP`, klien akan membalas dengan `IAC WILL GMCP` jika ia menyokongnya, atau `IAC WONT GMCP` jika tidak. Ia juga boleh memulakan beberapa rundingan itu sendiri (contohnya, mengenai jenis terminal).

Satu butiran penting untuk keserasian mudah alih ialah ramai klien moden mentafsir arahan aksara demi aksara atau baris demi baris, bergantung pada konfigurasi . Baris demi baris adalah lebih biasa, jadi strukturkan pemikiran penghurai input arahan anda dari segi baris lengkap yang dipisahkan oleh \r\n, bukan aksara individu.

9. Penggunaan proksi dan masalah rangkaian dengan MUD dalam rangkaian terhad

Dalam sesetengah persekitaran (cth., rangkaian korporat, kampus atau pembawa mudah alih tertentu), port tinggi biasa yang digunakan oleh MUD mungkin disekat oleh tembok api . Dalam kes ini, pemain mendapati mereka tidak boleh bersambung terus ke port MUD, walaupun Telnet itu sendiri dibenarkan pada port standard.

Penyelesaian klasik melibatkan penggunaan proksi perantara yang mendengar pada port yang dibenarkan (seperti port Telnet 23 atau port FTP 21) dan meneruskan sambungan ke port sebenar MUD. Proksi bertindak sebagai jambatan: klien bersambung ke proksi, dan proksi, di sebalik tabir, membuka sambungan ke pelayan permainan.

Adalah juga perkara biasa bagi rakan sekerja yang mempunyai sambungan internet tetap untuk memasang proksi pada mesin mereka dan membenarkan pemain lain mengakses MUD melalui alamat IP mereka . Walau bagaimanapun, anda perlu berhati-hati dengan IP yang dikongsi: jika berbilang akaun bersambung dari IP yang sama, sesetengah MUD mungkin mentafsirkannya sebagai berbilang pemain yang menyalahi undang-undang dan mengeluarkan penalti. Sebaik-baiknya, anda harus memaklumkan pentadbir permainan jika anda merancang untuk berkongsi alamat IP anda secara berkala.

10. Had dan risiko proksi untuk MUD

Walaupun proksi boleh menyelamatkan anda dalam rangkaian yang sangat tertutup, pada masa kini proksi awam tanpa nama yang boleh dipercayai tidak banyak dan beberapa yang tinggal biasanya terlebih beban, tergendala atau disekat atas sebab keselamatan.

Tambahan pula, rangkaian yang sama yang menyekat port tinggi juga mungkin mempunyai port 8080 yang disekat , yang sangat biasa berlaku untuk proksi HTTP. Oleh itu, jika seseorang menyediakan proksi peribadi untuk mengakses MUD, adalah dinasihatkan untuk meletakkannya pada port yang hampir tidak pernah ditapis (23, 21 atau port lain yang sangat biasa dan dibenarkan pada rangkaian yang dimaksudkan).

Jangan lupa bahawa persediaan ini mempunyai implikasi keselamatan: trafik melalui mesin perantara, dan sesi, kata laluan, dsb., boleh direkodkan. Dari perspektif reka bentuk pelayan MUD, protokol tidak berubah, tetapi anda perlu menganggap bahawa banyak sambungan akan "dibungkus" melalui proksi , yang berpotensi mengakibatkan latensi tambahan atau pemutusan sambungan yang lebih kerap.

11. Contoh interaksi naratif dalam teks MUD

Di luar aspek teknikal, MUD berasaskan teks bergantung pada penerangan dan suasana yang kaya . Banyak permainan termasuk petikan teks ikonik, petikan sastera atau serpihan yang hampir puitis yang dihantar oleh pelayan secara verbatim kepada klien untuk meningkatkan rendaman pemain.

Contohnya, sejenis "litani menentang ketakutan" mungkin muncul di skrin apabila watak menghadapi saat genting. Secara teknikalnya, ini tidak lebih daripada urutan baris teks dengan jeda yang sesuai dan, jika dikehendaki, sedikit warna atau format. Tetapi dari segi pengalaman pengguna, ia mempunyai impak yang ketara.

Teks jenis ini, walaupun tidak mengubah protokol Telnet, mempengaruhi cara anda mengendalikan jarak baris, penomboran halaman dan kadar penyegaran . Jika anda memaparkan beberapa perenggan panjang dalam satu letusan, ia boleh menjadi tidak boleh dibaca pada skrin kecil (seperti telefon bimbit). Itulah sebabnya banyak pelayan melaksanakan sistem "penomboran halaman" yang menjeda output selepas beberapa baris tertentu dan menunggu pemain menekan kekunci untuk meneruskan.

12. Sumber luaran dan dokumentasi teknikal tambahan

Tidak seperti protokol lain yang sangat piawai, ekosistem MUD telah didorong oleh dokumen yang berselerak, PDF akademik dan artikel longgar yang menerangkan varian, cadangan peluasan dan kajian tentang interaksi dalam persekitaran MUD.

Terdapat karya yang tersedia di repositori universiti dan perpustakaan digital yang menganalisis seni bina klien-pelayan MUD, evolusi daripada Telnet kosong kepada protokol kaya , malah isu pengalaman pengguna dalam antara muka teks. Walaupun kebanyakan dokumen ini tidak mengajar baris demi baris cara memformat mesej, ia menawarkan konteks yang berguna untuk memahami mengapa protokol tertentu diguna pakai dan bagaimana ia digabungkan.

Untuk melengkapi pelaksanaan, adalah dinasihatkan untuk menyemak dokumentasi klien MUD yang popular (desktop dan mudah alih), yang biasanya memperincikan sambungan yang disokong (GMCP, MXP, MSDP, dll.), set aksara yang dikendalikan, cara ia mengendalikan warna ANSI dan batasan yang ada pada skrin kecil.

13. Domain dan Nama Hos Besar-besaran: Kekacauan Infrastruktur yang Kelihatan

Jika anda pernah melihat rekod DNS penyedia hosting utama, anda mungkin pernah melihat senarai nama yang besar seperti www, mail, ftp, webmail, smtp, pop3, imap, panel, cpanel, admin, dev, test dan pelbagai variasi . Walaupun ia mungkin kelihatan seperti hingar-bingar, ini sebenarnya mencerminkan bagaimana infrastruktur yang menganjurkan banyak MUD dan perkhidmatan berkaitan disusun.

Di sebalik satu domain, beratus-ratus subdomain boleh ditemui: pelayan pangkalan data, mesin ujian, proksi, pengimbang beban, perkhidmatan statistik, platform e-mel, storan, VPN ... dan selalunya, malah port tempat MUD mendengar. Dalam beberapa kes, permainan dimainkan pada subdomain yang tidak disentuh; dalam kes lain, ia berkongsi alamat IP dengan pelbagai perkhidmatan daripada forum hingga wiki dan panel kawalan.

Percambahan nama ini relevan jika anda bercadang untuk menerbitkan MUD anda pada pelayan kongsi atau menyediakan proksi khusus untuk pemain: anda perlu menyelaraskan subdomain yang menunjukkan mesin, port yang dibuka dan cara keselamatan diuruskan dengan teliti supaya trafik Telnet tidak mengganggu perkhidmatan kritikal yang lain secara berbahaya.

14. Pertimbangan praktikal untuk pelanggan Telnet di telefon bimbit

Bermain permainan atau membangunkan perisian dengan klien Telnet pada peranti mudah alih menambahkan lapisan komplikasi: skrin kecil, papan kekunci sentuh, kemungkinan pemutusan rangkaian yang kerap dan kadangkala batasan klien itu sendiri dari segi sokongan sambungan.

Semasa mereka bentuk pelayan MUD anda, ingat beberapa perkara:

• Elakkan beratur terlalu panjang: perenggan pendek yang lebih baik supaya pengguna tidak perlu menatal dari sisi ke sisi.
• Sederhanakan penggunaan kod ANSI Dan pastikan mereka tidak merosakkan susun atur untuk pelanggan yang tidak mentafsirkannya dengan baik.
• Kendalikan penomboran halaman dengan berhati-hati. supaya pengalaman itu bukanlah dinding teks yang mustahil untuk diikuti.
• Laksanakan penyambungan semula secara lembutPada mudah alih, isyarat mudah terputus dan menyambung semula; pelayan anda sepatutnya bertolak ansur dengan perkara ini tanpa memutuskan sesi pemain pada gangguan ringkas pertama.

Sesetengah klien mudah alih yang pakar dalam MUD sudah menggabungkan sokongan untuk GMCP dan sambungan lain, jadi jika anda melaksanakannya pada pelayan, anda boleh menawarkan maklumat berstruktur yang dipaparkan oleh klien sebagai panel, bar kesihatan, peta pantas dan alat bantuan visual lain di atas teks klasik.

15. Cipta pelayan MUD anda sendiri yang serasi dengan klien sedia ada

Jika anda telah memutuskan untuk menulis pelayan MUD anda sendiri dari awal, kunci untuk mengelakkan pengasingan adalah dengan menghormati Telnet sebagai lapisan asas dan merundingkan pilihannya dengan betul . Anda tidak perlu mencipta semula protokol, tetapi sebaliknya ikuti konvensyen yang telah terbukti.

Pendek kata, untuk serasi dengan pelanggan yang paling biasa, anda harus:

• Melaksanakan Penghuraian arahan Telnet (IAC, LAKUKAN, JANGAN, AKAN, AKAN, SB, SE).
• Sokong sekurang-kurangnya beberapa pilihan biasa: gema, penindasan gema tempatan, GMCP Jika anda mahukan data yang diperkaya, dan mungkin pemampatan.
• Hantar teks dalam format mesra penggunaCRLF, ANSI pilihan, tanpa menggunakan garisan besar secara berlebihan.
• Terima input dalam mod dalam talian dan kendalikan pemisah baris yang dihantar oleh klien mudah alih dengan betul.

Dari situ anda boleh melanjutkan pelayan anda dengan protokol tambahan atau bahkan dengan klien anda sendiri, tetapi bermula dari pangkalan ini membolehkan anda menguji permainan anda dengan klien Telnet sedia ada dan memanfaatkan keseluruhan ekosistem yang telah dicipta di sekitar MUD selama ini.

Semua kebiasaan Telnet, sambungan, proksi, nama hos dan klien mudah alih ini mungkin kelihatan mengelirukan pada mulanya, tetapi jika anda menguraikannya langkah demi langkah, anda akan melihat bahawa terasnya agak mudah: aliran teks dengan beberapa jujukan kawalan yang jelas. Dengan memahami bagaimana mesej ini dibentuk, bagaimana pilihan dirundingkan dan apa yang diharapkan oleh klien biasa, anda akan mempunyai alatan yang anda perlukan untuk membina pelayan MUD yang mantap, serasi dan mesra pengguna yang boleh diakses daripada mana-mana klien Telnet, sama ada pada peranti mudah alih atau komputer desktop.