টেলনেট ব্যবহার করে টেক্সট-ভিত্তিক MUD গেমের প্রোটোকল এবং যোগাযোগ

আপনি যদি বেশ কিছুদিন ধরে আপনার মোবাইল ডিভাইসে টেক্সট-ভিত্তিক MUD গেম এবং টেলনেট ক্লায়েন্ট নিয়ে কাজ করে থাকেন , তাহলে সম্ভবত আপনিও একই সমস্যার সম্মুখীন হয়েছেন: সবাই টেলনেটের ইতিহাস, স্মৃতিচারণ এবং নানা গল্প নিয়ে কথা বলে… কিন্তু ক্লায়েন্ট এবং সার্ভার আসলে কীভাবে যোগাযোগ করে, তা প্রায় কেউই পরিষ্কারভাবে ব্যাখ্যা করে না। এই নিবন্ধটির লক্ষ্য হলো সেই শূন্যস্থান পূরণ করা: এর প্রোটোকল, মেসেজ, কন্ট্রোল সিকোয়েন্স এবং কীভাবে আপনার নিজের MUD সার্ভারকে বিদ্যমান ক্লায়েন্টগুলোর সাথে নির্বিঘ্নে কাজ করানো যায়, সে বিষয়ে বিস্তারিত আলোচনা করা।

আমরা একটি সাধারণ টেলনেট-ভিত্তিক MUD প্রোটোকল কীভাবে কাজ করে , ইন্ডাস্ট্রিতে কী কী এক্সটেনশন ব্যবহৃত হয় (যেমন GMCP, MSSP, কম্প্রেশন ইত্যাদি), মেসেজগুলো কীভাবে ফরম্যাট করা হয়, মোবাইল ক্লায়েন্ট কী দেখতে চায় এবং একেবারে গোড়া থেকে কোনো প্রোটোকল তৈরি না করেই সবকিছু যাতে মসৃণভাবে চলে, তা নিশ্চিত করতে আপনার সার্ভার থেকে কী পাঠাতে হবে—এই সবকিছু পুঙ্খানুপুঙ্খ ও সহজবোধ্যভাবে আলোচনা করব। এই সবকিছুই স্পেনের প্রমিত স্প্যানিশ ভাষায়, সুস্পষ্ট উদাহরণসহ এবং কোনো অপ্রয়োজনীয় পরিভাষা ছাড়াই ব্যাখ্যা করা হবে।

১. ভিত্তি হিসেবে টেলনেট: যা বেশিরভাগ MUD আসলে ব্যবহার করে

বেশিরভাগ ক্লাসিক MUD নতুন কোনো ট্রান্সপোর্ট উদ্ভাবন করে না: তারা ক্লায়েন্ট এবং সার্ভারের মধ্যে যোগাযোগের স্তর হিসেবে টেলনেটের উপর নির্ভর করে । এর মানে হলো, শেষ পর্যন্ত যা পাঠানো হয় তা হলো TCP-এর মাধ্যমে বাইট স্ট্রিম, যেখানে সাধারণ টেক্সটের সাথে বাইট ২৫৫ (0xFF) দ্বারা শুরু হওয়া বিশেষ টেলনেট কমান্ড মিশ্রিত থাকে।

নেটওয়ার্কের দৃষ্টিকোণ থেকে, MUD সার্ভারটি বিভিন্ন ঐচ্ছিক এক্সটেনশনসহ একটি সাধারণ টেলনেট সার্ভারের মতো আচরণ করে । ক্লায়েন্ট (সেটি মোবাইল, ডেস্কটপ বা একটি সাধারণ সিস্টেম টেলনেট যাই হোক না কেন) MUD-এর পোর্টে (প্রায়শই ২৩, ৪০০০, ৫০০০, ইত্যাদি) একটি TCP সংযোগ স্থাপন করে এবং সেখান থেকে অপশনগুলোর একটি সংক্ষিপ্ত আদান-প্রদান শুরু হয়।

এই প্রাথমিক আলোচনায়, উভয় পক্ষই বিভিন্ন ফিচার—যেমন ইকো, উইন্ডো সাইজ, GMCP-এর মতো অতিরিক্ত প্রোটোকল, কম্প্রেশন ইত্যাদি—চালু বা বন্ধ করার জন্য একে অপরকে "WILL", "WONT", "DO", এবং "DONT" ধরনের টেলনেট কন্ট্রোল সিকোয়েন্স পাঠায়। এই সবকিছু গেমের টেক্সটের সাথে মিশে যায়, কিন্তু ক্লায়েন্ট তা আলাদা করে চিনতে পারে, কারণ কন্ট্রোল কমান্ডগুলো সুপরিচিত 0xFF দিয়ে চিহ্নিত করা থাকে।

২. MUD-গুলোতে ব্যবহৃত টেলনেট প্রোটোকলের কাঠামো

টেলনেটে, যেকোনো কন্ট্রোল কমান্ড IAC (Interpret As Command, মান 255) বাইট দিয়ে শুরু হয় । এর পরে এক বা একাধিক বাইট থাকে যা কমান্ডের ধরন নির্দেশ করে এবং অনেক ক্ষেত্রে, একটি অপশন কোডও থাকে। স্ট্যান্ডার্ড MUD প্রোটোকল স্তরে, আপনি প্রধানত যা দেখতে পাবেন তা হলো:

• আইএসি ডিওআমি চাই আপনি (ক্লায়েন্ট) এই বিকল্পটি সক্রিয় করুন।
• আইএসি করে নাআমি চাই না তুমি এই বিকল্পটি ব্যবহার করো।
• আইএসি করবে“আমি (সার্ভার) এই বিকল্পটি ব্যবহার করতে পারি এবং করতে চাই।”
• আইএসি করবে নাআমি এই বিকল্পটি ব্যবহার করব না।

বিকল্পগুলো একটি সংখ্যা দ্বারা চিহ্নিত করা হয়; এর মধ্যে কিছু হলো পুরোনো টেলনেট স্ট্যান্ডার্ড, অন্যগুলো হলো MUD কমিউনিটিতে সম্মত হওয়া এক্সটেনশন (যেমন, GMCP, MSSP, COMPRESS2 ), যেগুলো ক্লাসিক টেলনেট RFC-গুলোতে অন্তর্ভুক্ত নয়, কিন্তু মূল ক্লায়েন্টগুলো সমর্থন করার কারণে কার্যত একটি “ছদ্ম-স্ট্যান্ডার্ড”-এ পরিণত হয়েছে।

একটি MUD হিসেবে, আপনি সাধারণত ক্লায়েন্ট কী সমর্থন করে তা পরীক্ষা করার জন্য IAC DO/IAC WILL সিকোয়েন্স পাঠিয়ে আলোচনা শুরু করবেন : যেমন—এটি GMCP গ্রহণ করে কিনা, কম্প্রেশন চায় কিনা, টার্মিনাল তথ্য প্রদান করে কিনা, ইত্যাদি। ক্লায়েন্ট পরিস্থিতি অনুযায়ী WILL/WONT বা DO/DONT দিয়ে সাড়া দেবে। আপনার সার্ভারকে অবশ্যই এই প্রতিক্রিয়াগুলো মেনে চলতে হবে এবং ক্লায়েন্ট কোনো অপশন গ্রহণ না করলে তা ব্যবহার করা যাবে না।

৩. গেমের টেক্সট এবং টেলনেট নিয়ন্ত্রণের মধ্যে পৃথকীকরণ

একটি সাধারণ প্রশ্ন হলো, সাধারণ গেম টেক্সট এবং কন্ট্রোল কমান্ডের মধ্যে কীভাবে পার্থক্য করা যায় । নিয়মটি সহজ: যার আগে 0xFF নেই, তাকেই টেক্সট হিসেবে গণ্য করা হয়। টেলনেট কমান্ডগুলো সবসময় এই বিশেষ বাইট দিয়ে শুরু হয়, ঠিক এই বিভ্রান্তি এড়ানোর জন্যই।

ধারণাগত উদাহরণ (আপনাকে এটি হুবহু কপি করতে হবে না, এটি শুধুমাত্র বিষয়টি বোঝানোর জন্য): সার্ভার একটি অপশন নিয়ে আলোচনার জন্য পরিবেশের বর্ণনার কয়েকটি লাইনের পর একটি IAC সিকোয়েন্স পাঠাতে পারে । ক্লায়েন্ট বাইট বাইট করে পড়ে: যখন এটি 0xFF দেখে, তখন এটি "কমান্ড মোডে" প্রবেশ করে; বাকি সময় এটি এটিকে টেক্সট হিসেবে গণ্য করে, প্রয়োজন অনুযায়ী ANSI কালার প্রয়োগ করে এবং প্রদর্শন করে।

যদি কখনও টেক্সটের অংশ হিসেবে একটি 0xFF বাইট পাঠানোর প্রয়োজন হয় (যা খুবই বিরল, কিন্তু সম্ভব), তবে আপনাকে অবশ্যই এটিকে ডুপ্লিকেট করে "এস্কেপ" করতে হবে । অর্থাৎ, ইউজারল্যান্ড ডেটা স্ট্রিমে একটি আক্ষরিক 0xFF পাঠাতে হলে, আপনাকে পরপর দুটি 0xFF পাঠাতে হবে, এবং ক্লায়েন্ট সেগুলোকে সঠিকভাবে "একটি কমান্ড হিসেবে নয়, বরং টেক্সটের একটি একক 0xFF" হিসেবে ব্যাখ্যা করবে।

৪. টেক্সট মেসেজের ফরম্যাট: লাইন, বিরতি এবং রঙ

আপনার MUD যে কন্টেন্টগুলো পাঠাবে তার বেশিরভাগই পাঠযোগ্য টেক্সট মেসেজ: যেমন বিবরণ, ডায়ালগ, অবজেক্টের তালিকা এবং কমান্ড । যদিও এটি একটি সাধারণ বিষয় মনে হতে পারে, টেলনেট ক্লায়েন্টগুলো (বিশেষ করে মোবাইলে) যাতে এটি সঠিকভাবে প্রদর্শন করে, তা নিশ্চিত করার জন্য কয়েকটি খুঁটিনাটি বিষয়ে মনোযোগ দেওয়া উচিত।

সাধারণত, MUD-গুলো এখনও CRLF (\r\n) দিয়ে লাইন শেষ করার ক্লাসিক শৈলী ব্যবহার করে । কিছু ক্লায়েন্ট শুধুমাত্র LF (\n) সমর্থন করে, কিন্তু সর্বোচ্চ সামঞ্জস্যের জন্য, সর্বদা একটি ক্যারেজ রিটার্নের পরে একটি লাইন ফিড পাঠান।

রঙ এবং ফরম্যাটিংয়ের জন্য, MUD-গুলো সাধারণত টেক্সটের মধ্যে ANSI এস্কেপ কোড ব্যবহার করে । উদাহরণস্বরূপ, ESC (0x1B) দিয়ে শুরু হওয়া সিকোয়েন্সের পরে লাল টেক্সটের জন্য “[31m”, বোল্ডের জন্য “[1m”, ইত্যাদি। এগুলো টেলনেট প্রোটোকলের নিজস্ব অংশ নয়, কিন্তু বেশিরভাগ টার্মিনাল এবং উন্নত MUD ক্লায়েন্ট, যার মধ্যে অনেক মোবাইল ক্লায়েন্টও রয়েছে, এগুলো বুঝতে পারে।

৫. টেলনেটের মাধ্যমে MUD সম্প্রসারণ: GMCP, MSSP এবং অন্যান্য

সাধারণ টেক্সটের পাশাপাশি, বর্তমানে অনেক MUD ক্লায়েন্টদের সাথে কাঠামোগত ডেটা আদান-প্রদানের জন্য টেলনেটের সাথে অতিরিক্ত প্রোটোকল যুক্ত করে । এর ফলে মোবাইল ক্লায়েন্টরা একটি সাধারণ টেক্সট স্ট্রিমের চেয়ে আরও সমৃদ্ধ ইন্টারফেস প্রদর্শন করতে পারে।

সবচেয়ে ঘন ঘন ব্যবহৃত সম্প্রসারণগুলির মধ্যে রয়েছে:

• জিএমসিপি (জেনেরিক মাড কমিউনিকেশন প্রোটোকল)ক্যারেক্টার, ম্যাপ, চ্যানেল ইত্যাদি সম্পর্কে JSON ফরম্যাটে তথ্য পাঠায় (যদিও এটি সবসময় শতভাগ প্রমিত নয়)।
• MSSP (মাড সার্ভার স্ট্যাটাস প্রোটোকল)লিস্টিং পরিষেবা এবং আগ্রহী ক্লায়েন্টদের সার্ভারের ডেটা (MUD-এর নাম, খেলোয়াড়ের সংখ্যা, লিঙ্গ, ইত্যাদি) সরবরাহ করার জন্য ডিজাইন করা হয়েছে।
• কম্প্রেস / কম্প্রেস২ব্যান্ডউইথ কমাতে ডেটা কম্প্রেশন, যা ধীরগতির সংযোগের ক্ষেত্রে অত্যন্ত মূল্যবান।

এই এক্সটেনশনগুলো অন্য যেকোনো টেলনেট অপশনের মতোই আলোচনা সাপেক্ষে নির্ধারিত হয়: সার্ভার সাধারণত IAC WILL GMCP বা IAC DO GMCP পাঠায় এবং উত্তরের জন্য অপেক্ষা করে। একবার সম্মত হয়ে গেলে, এক্সটেনশনটি নিজেই নির্ধারণ করে দেয় যে ডেটা কীভাবে এনক্যাপসুলেট করা হবে (উদাহরণস্বরূপ, GMCP টেলনেট সাব-নেগোসিয়েশনের মধ্যে যায়: IAC SB <option> … IAC SE)।

৬. উপ-আলোচনা (এসবি এবং এসই): বিশেষ তথ্য অন্তর্ভুক্তিকরণ

যখন কোনো টেলনেট অপশনের জন্য সাধারণ হ্যাঁ/না-এর চেয়ে বেশি ডেটা পাঠানোর প্রয়োজন হয়, তখন সাবনেগোসিয়েশন ব্যবহার করা হয় । এর ধরণটি হলো:

• আইএসি এসবি আইএসি এসই

ঐ ব্লকের মধ্যে আপনি স্ট্রিং, সংখ্যা, অথবা এক্সটেনশন দ্বারা সংজ্ঞায়িত নির্দিষ্ট কাঠামো পাঠাতে পারেন । উদাহরণস্বরূপ, GMCP সাধারণত কোটেশন চিহ্ন, দ্বিতীয় বন্ধনী এবং ভ্যালু সহ একটি JSON অবজেক্টের মতোই কিছু পাঠায়।

যখন ক্লায়েন্ট IAC SB GMCP গ্রহণ করে, তখন সে জানে যে IAC SE পর্যন্ত সবকিছুই GMCP প্যাকেজের অংশ, এবং এটি সাধারণ গেম টেক্সট স্ট্রিমের অংশ নয়। এর ফলে, গ্রাফিক্যাল UI-তে কী যাচ্ছে এবং ক্লাসিক টেক্সট বাফারে কী যাচ্ছে, তা স্পষ্টভাবে আলাদা করা যায় ।

৭. MUD সার্ভার যা পাঠায়: সাধারণ যোগাযোগ প্রবাহ

কল্পনা করুন, যখন একজন খেলোয়াড় একটি মোবাইল টেলনেট ক্লায়েন্ট থেকে আপনার MUD সার্ভারে সংযোগ করে, তখন থেকে পরবর্তী ঘটনাপ্রবাহটি কেমন হবে :

1. ক্লায়েন্ট MUD পোর্টে একটি TCP সংযোগ স্থাপন করে।
2. সার্ভার আপনাকে একটি স্বাগত ব্যানার (টেক্সট) এবং সম্ভবত কিছু পাঠায়। ট্রেডিং অপশনের জন্য IAC ক্রম (ইকো, জিএমসিপি, কম্প্রেশন…)।
3. গ্রাহক WILL/WONT এবং DO/DONT ব্যবহার করে সেই বিকল্পগুলো গ্রহণ বা প্রত্যাখ্যান করে প্রতিক্রিয়া জানায়।
4. সেখান থেকে সার্ভার লগইন স্ক্রিন (টেক্সট) পাঠায় এবং প্লেয়ারের টাইপ করা কমান্ডগুলো প্রসেস করে।

সব সময়, সার্ভারকে অবশ্যই ক্লায়েন্টের ইনপুটকে টেক্সট এবং টেলনেট কমান্ডের মিশ্রণ হিসেবে পড়তে সক্ষম হতে হবে , ঠিক যেমন ক্লায়েন্ট আপনার আউটপুটকে পড়ে। উদাহরণস্বরূপ, যখন প্লেয়ার "north" টাইপ করে এন্টার চাপে, তখন ক্লায়েন্ট সাধারণত সেই স্ট্রিংটির পরে একটি ক্যারেজ রিটার্ন এবং একটি লাইন ফিড পাঠায়। আপনার সার্ভার লাইনের শেষ পর্যন্ত পড়ে এবং এটিকে প্লেয়ারের কাছ থেকে আসা একটি কমান্ড হিসেবে ব্যাখ্যা করে।

যদি ক্লায়েন্ট কোনো অপশন শুরু করার সিদ্ধান্ত নেয় (উদাহরণস্বরূপ, উইন্ডো সাইজ নেগোসিয়েশন চালু করা), তবে আপনাকেও ক্লায়েন্ট সাইড থেকে IAC সিকোয়েন্স গ্রহণ করার এবং যথাযথভাবে সাড়া দেওয়ার জন্য প্রস্তুত থাকতে হবে, শুধু উল্টোটা নয়।

৮. টেলনেট ক্লায়েন্ট যা পাঠায় (মোবাইল ক্লায়েন্ট সহ)

আপনার সার্ভারের দৃষ্টিকোণ থেকে, একটি সাধারণ টেলনেট ক্লায়েন্ট (মোবাইল বা ডেস্কটপ) আপনাকে মূলত দুই ধরনের জিনিস পাঠাবে: ব্যবহারকারীর টেক্সট এবং টেলনেট কমান্ড । ক্লায়েন্টের উপর নির্ভর করে টেক্সটটি সাধারণত ASCII বা UTF-8 ফরম্যাটের হয়; আজকাল অন্তত UTF-8 ফরম্যাট ধরে নেওয়াই শ্রেয়।

আপনি যে টেলনেট কমান্ডগুলো পান, সেগুলো মূলত আপনার নেগোসিয়েশন অনুরোধের প্রতিক্রিয়া । আপনি যদি `IAC DO GMCP` পাঠান, তাহলে ক্লায়েন্টটি সমর্থন করলে `IAC WILL GMCP` দিয়ে, আর সমর্থন না করলে `IAC WONT GMCP` দিয়ে প্রতিক্রিয়া জানাবে। এটি নিজেও কিছু নেগোসিয়েশন শুরু করতে পারে (উদাহরণস্বরূপ, টার্মিনালের ধরন সম্পর্কে)।

মোবাইল সামঞ্জস্যের জন্য একটি গুরুত্বপূর্ণ বিষয় হলো, অনেক আধুনিক ক্লায়েন্ট কনফিগারেশনের উপর নির্ভর করে কমান্ডগুলোকে অক্ষর ধরে ধরে অথবা লাইন ধরে ধরে ব্যাখ্যা করে । লাইন ধরে ধরে ব্যাখ্যা করাই বেশি প্রচলিত, তাই আপনার কমান্ড ইনপুট পার্সারের গঠন এমনভাবে করুন যাতে তা স্বতন্ত্র অক্ষরের পরিবর্তে \r\n দ্বারা পৃথক করা সম্পূর্ণ লাইন হিসেবে কাজ করে।

৯. সীমাবদ্ধ নেটওয়ার্কে MUD-এর সাথে প্রক্সির ব্যবহার এবং নেটওয়ার্ক সমস্যা

কিছু পরিবেশে (যেমন, কর্পোরেট নেটওয়ার্ক, ক্যাম্পাস বা নির্দিষ্ট কিছু মোবাইল ক্যারিয়ার), MUD দ্বারা ব্যবহৃত সাধারণ হাই-স্পিড পোর্টগুলো ফায়ারওয়াল দ্বারা ব্লক করা থাকতে পারে । এই ক্ষেত্রে, প্লেয়াররা দেখতে পান যে তারা সরাসরি MUD-এর পোর্টে সংযোগ করতে পারছেন না, যদিও স্ট্যান্ডার্ড পোর্টগুলোতে টেলনেট ব্যবহারের অনুমতি থাকে।

একটি প্রচলিত সমাধানে একটি মধ্যস্থতাকারী প্রক্সি ব্যবহার করা হয় , যা একটি অনুমোদিত পোর্টে (যেমন টেলনেট পোর্ট ২৩ বা এফটিপি পোর্ট ২১) লিসেন করে এবং সংযোগটিকে MUD-এর আসল পোর্টে ফরওয়ার্ড করে দেয়। প্রক্সিটি একটি ব্রিজ হিসেবে কাজ করে: ক্লায়েন্ট প্রক্সির সাথে সংযোগ স্থাপন করে, এবং প্রক্সিটি নেপথ্যে থেকে গেম সার্ভারের সাথে সংযোগটি খুলে দেয়।

স্থায়ী ইন্টারনেট সংযোগ আছে এমন কোনো সহকর্মীর পক্ষে তার মেশিনে একটি প্রক্সি ইনস্টল করে অন্য খেলোয়াড়দেরকে তার আইপি অ্যাড্রেসের মাধ্যমে MUD-এ প্রবেশ করতে দেওয়াটাও বেশ সাধারণ । তবে, শেয়ার করা আইপি নিয়ে আপনাকে সতর্ক থাকতে হবে: যদি একাধিক অ্যাকাউন্ট একই আইপি থেকে সংযোগ করে, তাহলে কিছু MUD এটিকে অবৈধ মাল্টিপ্লেয়ার হিসেবে গণ্য করতে পারে এবং শাস্তিমূলক ব্যবস্থা নিতে পারে। সবচেয়ে ভালো হয়, আপনি যদি নিয়মিত আপনার আইপি অ্যাড্রেস শেয়ার করার পরিকল্পনা করেন, তবে গেম অ্যাডমিনিস্ট্রেটরদেরকে জানিয়ে দেওয়া।

১০. MUD-এর প্রক্সিগুলির সীমাবদ্ধতা এবং ঝুঁকি

যদিও খুব আবদ্ধ নেটওয়ার্কে প্রক্সি আপনাকে বাঁচাতে পারে, আজকাল নির্ভরযোগ্য পাবলিক অ্যানোনিমাস প্রক্সি খুব একটা সহজলভ্য নয় এবং যে কয়েকটি অবশিষ্ট আছে, সেগুলো সাধারণত ওভারলোডেড, ডাউন অথবা নিরাপত্তাজনিত কারণে ব্লক করা থাকে।

এছাড়াও, যে নেটওয়ার্কগুলো উচ্চ পোর্ট ব্লক করে, সেগুলোতে পোর্ট ৮০৮০-ও ব্লক করা থাকতে পারে , যা HTTP প্রক্সির ক্ষেত্রে খুবই সাধারণ। তাই, যদি কেউ কোনো MUD অ্যাক্সেস করার জন্য একটি প্রাইভেট প্রক্সি সেট আপ করে, তবে এটিকে এমন একটি পোর্টে স্থাপন করার পরামর্শ দেওয়া হয় যা প্রায় কখনোই ফিল্টার করা হয় না (যেমন ২৩, ২১, অথবা উক্ত নেটওয়ার্কের অন্য কোনো খুব সাধারণ এবং অনুমোদিত পোর্ট)।

মনে রাখবেন যে এই সেটআপগুলোর নিরাপত্তাগত ঝুঁকি রয়েছে: ট্র্যাফিক একটি মধ্যবর্তী মেশিনের মধ্য দিয়ে যায় এবং সেশন, পাসওয়ার্ড ইত্যাদি লগ করা হতে পারে। MUD সার্ভার ডিজাইনের দৃষ্টিকোণ থেকে, প্রোটোকলের কোনো পরিবর্তন হয় না, কিন্তু আপনাকে ধরে নিতে হবে যে অনেক সংযোগ একটি প্রক্সির মাধ্যমে "মোড়ানো" থাকবে , যার ফলে অতিরিক্ত ল্যাটেন্সি বা ঘন ঘন সংযোগ বিচ্ছিন্ন হওয়ার সম্ভাবনা থাকে।

১১. MUD টেক্সটের মধ্যে বর্ণনামূলক মিথস্ক্রিয়ার উদাহরণ

প্রযুক্তিগত দিকগুলোর বাইরেও, একটি টেক্সট-ভিত্তিক MUD সমৃদ্ধ বর্ণনা এবং আবহের উপর নির্ভর করে । খেলোয়াড়ের নিমগ্নতা বাড়ানোর জন্য অনেক গেমে আইকনিক টেক্সট স্নিপেট, সাহিত্যিক উদ্ধৃতি বা প্রায় কাব্যিক অংশ অন্তর্ভুক্ত থাকে, যা সার্ভার হুবহু ক্লায়েন্টের কাছে পাঠিয়ে দেয়।

উদাহরণস্বরূপ, চরিত্রটি যখন কোনো সংকটপূর্ণ মুহূর্তের মুখোমুখি হয়, তখন পর্দায় এক ধরনের ‘ভয়ের বিরুদ্ধে প্রার্থনা’ ভেসে উঠতে পারে । প্রযুক্তিগতভাবে, এটি যথাযথ বিরতিসহ কয়েকটি পাঠ্য লাইনের একটি ক্রম এবং ইচ্ছা অনুযায়ী কিছু রঙ বা বিন্যাস ছাড়া আর কিছুই নয়। কিন্তু ব্যবহারকারীর অভিজ্ঞতার দিক থেকে এর একটি তাৎপর্যপূর্ণ প্রভাব রয়েছে।

এই ধরনের টেক্সট টেলনেট প্রোটোকল পরিবর্তন না করলেও, এটি লাইন স্পেসিং, পেজিনেশন এবং রিফ্রেশ রেট পরিচালনার পদ্ধতিকে প্রভাবিত করে । যদি আপনি একবারে বেশ কয়েকটি দীর্ঘ অনুচ্ছেদ প্রদর্শন করেন, তবে তা ছোট স্ক্রিনে (যেমন মোবাইল ফোন) অপঠনযোগ্য হয়ে উঠতে পারে। একারণেই অনেক সার্ভার "পেজিনেশন" সিস্টেম প্রয়োগ করে, যা একটি নির্দিষ্ট সংখ্যক লাইনের পর আউটপুট থামিয়ে দেয় এবং প্লেয়ারের কোনো কী চেপে আবার পড়া চালিয়ে যাওয়ার জন্য অপেক্ষা করে।

১২. বাহ্যিক উৎস এবং অতিরিক্ত প্রযুক্তিগত নথিপত্র

অন্যান্য অত্যন্ত মানসম্মত প্রোটোকলের বিপরীতে, MUD ইকোসিস্টেমটি গড়ে উঠেছে বিক্ষিপ্ত নথি, অ্যাকাডেমিক পিডিএফ এবং বিচ্ছিন্ন প্রবন্ধের মাধ্যমে , যেগুলিতে এর বিভিন্ন রূপ, সম্প্রসারণের প্রস্তাবনা এবং MUD পরিবেশে মিথস্ক্রিয়া বিষয়ক গবেষণা বর্ণনা করা হয়েছে।

বিশ্ববিদ্যালয়ের সংগ্রহশালা এবং ডিজিটাল লাইব্রেরিগুলোতে এমন অনেক কাজ পাওয়া যায়, যেগুলো MUD-এর ক্লায়েন্ট-সার্ভার আর্কিটেকচার, সাধারণ টেলনেট থেকে উন্নত প্রোটোকলের বিবর্তন , এমনকি টেক্সট ইন্টারফেসের ব্যবহারকারী-অভিজ্ঞতার সমস্যাগুলো বিশ্লেষণ করে। যদিও এই নথিগুলোর অনেকগুলোই লাইন-বাই-লাইন মেসেজ ফরম্যাট করার পদ্ধতি শেখায় না, তবুও নির্দিষ্ট কিছু প্রোটোকল কেন গ্রহণ করা হয়েছিল এবং কীভাবে সেগুলোকে একত্রিত করা হয়, তা বোঝার জন্য এগুলো প্রয়োজনীয় প্রেক্ষাপট প্রদান করে।

বাস্তবায়নের পরিপূরক হিসেবে, জনপ্রিয় MUD ক্লায়েন্টগুলোর (ডেস্কটপ এবং মোবাইল উভয়ই) ডকুমেন্টেশন পর্যালোচনা করার পরামর্শ দেওয়া হয়, যেখানে সাধারণত বিস্তারিতভাবে উল্লেখ করা থাকে যে তারা কোন কোন এক্সটেনশন সমর্থন করে (GMCP, MXP, MSDP, ইত্যাদি), কোন কোন ক্যারেক্টার সেট পরিচালনা করে, ANSI রঙগুলো কীভাবে ব্যবহার করে এবং ছোট পর্দায় তাদের কী কী সীমাবদ্ধতা রয়েছে।

১৩. বিশাল ডোমেইন ও হোস্টনেম: পরিকাঠামোর দৃশ্যমান বিশৃঙ্খলা

আপনি যদি কখনও প্রধান হোস্টিং প্রোভাইডারদের ডিএনএস রেকর্ড দেখে থাকেন, তাহলে সম্ভবত www, mail, ftp, webmail, smtp, pop3, imap, panel, cpanel, admin, dev, test এবং এর অসংখ্য ভিন্ন রূপের মতো নামের বিশাল তালিকা দেখেছেন । যদিও এটিকে অপ্রয়োজনীয় মনে হতে পারে, এটি আসলে অনেক MUD এবং সম্পর্কিত পরিষেবা হোস্টকারী পরিকাঠামোর গঠনকেই প্রতিফলিত করে।

একটিমাত্র ডোমেইনের আড়ালে শত শত সাবডোমেইন খুঁজে পাওয়া যায়: ডেটাবেস সার্ভার, টেস্টিং মেশিন, প্রক্সি, লোড ব্যালান্সার, পরিসংখ্যান পরিষেবা, ইমেল প্ল্যাটফর্ম, স্টোরেজ, ভিপিএন … এবং প্রায়শই, এমনকি সেই পোর্টটিও যেখানে একটি MUD লিসেন করছে। কিছু ক্ষেত্রে, গেমটি একটি স্বতন্ত্র সাবডোমেইনে খেলা হয়; অন্য ক্ষেত্রে, এটি ফোরাম থেকে শুরু করে উইকি এবং কন্ট্রোল প্যানেল পর্যন্ত বিস্তৃত বিভিন্ন পরিষেবার সাথে একটি আইপি অ্যাড্রেস শেয়ার করে।

নামের এই আধিক্যটি প্রাসঙ্গিক, যদি আপনি আপনার MUD কোনো শেয়ার্ড সার্ভারে প্রকাশ করার কথা ভাবেন অথবা প্লেয়ারদের জন্য নির্দিষ্ট প্রক্সি সেট আপ করেন: আপনাকে সতর্কতার সাথে সমন্বয় করতে হবে কোন সাবডোমেইন কোন মেশিনের দিকে নির্দেশ করবে, কোন পোর্টগুলো খোলা থাকবে এবং নিরাপত্তা কীভাবে পরিচালিত হবে, যাতে টেলনেট ট্র্যাফিক অন্যান্য গুরুত্বপূর্ণ পরিষেবাগুলিতে বিপজ্জনকভাবে হস্তক্ষেপ না করে।

১৪. মোবাইলে টেলনেট গ্রাহকদের জন্য ব্যবহারিক বিবেচ্য বিষয়সমূহ

মোবাইল ডিভাইসে টেলনেট ক্লায়েন্ট ব্যবহার করে গেম খেলা বা ডেভেলপ করার ক্ষেত্রে বেশ কিছু জটিলতা যুক্ত হয়: ছোট স্ক্রিন, টাচ কিবোর্ড, ঘন ঘন নেটওয়ার্ক সংযোগ বিচ্ছিন্ন হওয়ার সম্ভাবনা এবং কখনও কখনও এক্সটেনশন সাপোর্টের ক্ষেত্রে ক্লায়েন্টগুলোর নিজস্ব সীমাবদ্ধতা।

আপনার MUD সার্ভার ডিজাইন করার সময় কয়েকটি বিষয় মনে রাখবেন:

• অতিরিক্ত দীর্ঘ লাইন এড়িয়ে চলুনআরও ভালো ছোট ছোট অনুচ্ছেদ, যাতে ব্যবহারকারীকে এদিক-ওদিক স্ক্রল করতে না হয়।
• ANSI কোডের ব্যবহার সংযত করুন। এবং নিশ্চিত করুন যে, যেসব গ্রাহক এগুলো ভালোভাবে বুঝতে পারেন না, তাদের জন্য যেন লেআউটটি নষ্ট না হয়ে যায়।
• পৃষ্ঠা বিন্যাস সাবধানে করুন। যাতে অভিজ্ঞতাটি অনুসরণ করা অসম্ভব এমন এক বিশাল পাঠ্যস্তম্ভের মতো না হয়।
• সফট রিকানেকশন বাস্তবায়ন করুনমোবাইলে সহজেই সিগন্যাল চলে যায় এবং আবার সংযোগ স্থাপন করতে হয়; আপনার সার্ভারের উচিত এই সামান্য বাধাতেই প্লেয়ারের সেশন নষ্ট না করে বিষয়টি সামলে নেওয়া।

MUD-এর জন্য বিশেষায়িত কিছু মোবাইল ক্লায়েন্টে ইতিমধ্যেই GMCP এবং অন্যান্য এক্সটেনশনের সাপোর্ট অন্তর্ভুক্ত রয়েছে, তাই আপনি যদি সার্ভারে এগুলো প্রয়োগ করেন, তবে আপনি কাঠামোগত তথ্য সরবরাহ করতে পারবেন যা ক্লায়েন্ট প্রচলিত টেক্সটের পরিবর্তে প্যানেল, হেলথ বার, কুইক ম্যাপ এবং অন্যান্য ভিজ্যুয়াল এইড হিসেবে প্রদর্শন করবে।

১৫. বিদ্যমান ক্লায়েন্টদের সাথে সামঞ্জস্যপূর্ণ আপনার নিজস্ব MUD সার্ভার তৈরি করুন।

আপনি যদি একেবারে গোড়া থেকে নিজের MUD সার্ভার তৈরি করার সিদ্ধান্ত নিয়ে থাকেন, তবে বিচ্ছিন্নতা এড়ানোর মূল চাবিকাঠি হলো টেলনেটকে ভিত্তি স্তর হিসেবে সম্মান করা এবং এর অপশনগুলো সঠিকভাবে নেগোশিয়েট করা । আপনার প্রোটোকলটি নতুন করে উদ্ভাবন করার প্রয়োজন নেই, বরং প্রমাণিত প্রচলিত নিয়মগুলো অনুসরণ করলেই চলবে।

সংক্ষেপে, সর্বাধিক প্রচলিত গ্রাহকদের সাথে সামঞ্জস্যপূর্ণ হতে হলে আপনার যা করা উচিত:

• বাস্তবায়ন টেলনেট কমান্ড পার্সিং (IAC, DO, DONT, WILL, WONT, SB, SE).
• অন্তত কিছু সাধারণ বিকল্প সমর্থন করুন: প্রতিধ্বনি, স্থানীয় প্রতিধ্বনি দমন, জিএমসিপি যদি আপনি সমৃদ্ধ ডেটা এবং সম্ভবত কম্প্রেশন চান।
• Enviar ব্যবহারকারী-বান্ধব বিন্যাসে লেখাCRLF, ANSI ঐচ্ছিক, বিশাল লাইনের অতিরিক্ত ব্যবহার ছাড়াই।
• অনলাইন মোডে ইনপুট গ্রহণ করুন এবং মোবাইল ক্লায়েন্ট থেকে পাঠানো লাইন ব্রেক সঠিকভাবে পরিচালনা করুন।

সেখান থেকে আপনি অতিরিক্ত প্রোটোকল বা এমনকি আপনার নিজস্ব ক্লায়েন্ট দিয়ে আপনার সার্ভারকে প্রসারিত করতে পারেন, কিন্তু এই ভিত্তি থেকে শুরু করলে আপনি বিদ্যমান টেলনেট ক্লায়েন্টগুলির সাথে আপনার গেমটি পরীক্ষা করতে পারবেন এবং বছরের পর বছর ধরে MUD-কে ঘিরে গড়ে ওঠা সম্পূর্ণ ইকোসিস্টেমের সুবিধা নিতে পারবেন।

এইসব টেলনেট, এক্সটেনশন, প্রক্সি, হোস্টনেম এবং মোবাইল ক্লায়েন্টের খুঁটিনাটি বিষয়গুলো প্রথমে বিভ্রান্তিকর মনে হতে পারে, কিন্তু যদি আপনি এটিকে ধাপে ধাপে বিশ্লেষণ করেন, তবে দেখবেন যে এর মূল বিষয়টি বেশ সহজ: কয়েকটি সুনির্দিষ্ট নিয়ন্ত্রণ অনুক্রম সহ একটি টেক্সট প্রবাহ। এই বার্তাগুলো কীভাবে গঠিত হয়, অপশনগুলো কীভাবে নির্ধারিত হয় এবং একজন সাধারণ ক্লায়েন্ট কী দেখতে প্রত্যাশা করে, তা বুঝতে পারলে আপনার কাছে একটি শক্তিশালী, সামঞ্জস্যপূর্ণ এবং ব্যবহারকারী-বান্ধব MUD সার্ভার তৈরি করার জন্য প্রয়োজনীয় উপকরণ থাকবে, যা যেকোনো টেলনেট ক্লায়েন্ট থেকে অ্যাক্সেস করা যাবে, তা মোবাইল ডিভাইসেই হোক বা ডেস্কটপ কম্পিউটারে ।