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

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

সবাইকে হ্যালো, আমি দিমিত্রি ইভাশচেঙ্কো, MY.GAMES-এর একজন লিড সফটওয়্যার ইঞ্জিনিয়ার৷ "2023 সালে ইউনিটি নেটওয়ার্কিং ল্যান্ডস্কেপ"-এ এই সিরিজের নিবন্ধগুলি নেটওয়ার্ক পরিবেশের জটিল দিক এবং সীমাবদ্ধতাগুলিকে কভার করবে, বিভিন্ন প্রোটোকল (TCP, UDP, এবং WebSocket সহ) অনুসন্ধান করবে এবং নির্ভরযোগ্য UDP প্রোটোকলের তাৎপর্য তুলে ধরবে৷ আমরা রিয়েল-টাইম মাল্টিপ্লেয়ার গেমগুলিতে NAT-এর প্রভাব অন্বেষণ করব এবং নেটওয়ার্ক ট্রান্সমিশনের জন্য গেম ডেটা প্রস্তুত করার বিষয়ে আপনাকে গাইড করব।

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

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

অবকাঠামো বোঝা

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

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

অতিরিক্তভাবে, ডেটা সেন্টারে শক্তিশালী সার্ভার রয়েছে যেখানে ওয়েবসাইট, অ্যাপ্লিকেশন এবং অনলাইন পরিষেবাগুলি থাকে। আপনি যখন একটি ওয়েবসাইট বা অনলাইন পরিষেবায় অ্যাক্সেসের অনুরোধ করেন, তখন আপনার অনুরোধটি এই বিস্তৃত নেটওয়ার্কের মাধ্যমে প্রাসঙ্গিক সার্ভারে যায় এবং পরবর্তীকালে, ডেটা একই পথ ধরে ফেরত পাঠানো হয়।

নেটওয়ার্ক সীমাবদ্ধতা

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

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

এই মৌলিক নীতিগুলি এবং সীমাবদ্ধতাগুলি বোঝা আপনাকে আপনার গেমগুলির সফল নেটওয়ার্ক একীকরণের জন্য প্রয়োজনীয় সম্ভাব্য সমাধান এবং কৌশলগুলিকে আরও ভালভাবে মূল্যায়ন করতে সহায়তা করবে৷

ব্যান্ডউইথ

ব্যান্ডউইথ হল সর্বাধিক পরিমাণ ডেটা যা একটি নির্দিষ্ট সময়ের মধ্যে একটি নেটওয়ার্কের মাধ্যমে প্রেরণ করা যায়। ডেটা ট্রান্সমিশন গতি সরাসরি উপলব্ধ ব্যান্ডউইথের উপর নির্ভর করে: যত বেশি ব্যান্ডউইথ, তত বেশি ডেটা একই সাথে আপলোড করা যায়।

ব্যান্ডউইথ প্রতি সেকেন্ডে বিটগুলিতে পরিমাপ করা হয় এবং এটি দুই ধরনের হতে পারে: প্রতিসম (সমান আপলোড এবং ডাউনলোড গতি সহ) এবং অসমমিত (বিভিন্ন আপলোড এবং ডাউনলোড গতি সহ)।

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

ব্যান্ডউইথ সাধারণত বিট পার সেকেন্ডে (বিপিএস) বা মাল্টিপে পরিমাপ করা হয়, যেমন প্রতি সেকেন্ডে মেগাবিট (এমবিপিএস)। একটি উচ্চ ব্যান্ডউইথ মানে কম সময়ে আরও ডেটা প্রেরণ করা যেতে পারে, যা রিয়েল-টাইম মাল্টিপ্লেয়ার গেমগুলির জন্য একেবারে অপরিহার্য।

রাউন্ড-ট্রিপ সময়

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

RTT বেশি হলে, খেলোয়াড়দের বিলম্ব হতে পারে যা গেমপ্লেকে নেতিবাচকভাবে প্রভাবিত করতে পারে। তাই, গেম ডেভেলপারদের একটি মসৃণ এবং আরও প্রতিক্রিয়াশীল গেমপ্লে অভিজ্ঞতা প্রদানের জন্য RTT কমানোর চেষ্টা করা উচিত।

নেটওয়ার্ক বিলম্ব

একটি নেটওয়ার্ক বিলম্ব (প্রায়ই "ল্যাগ" হিসাবে উল্লেখ করা হয়) প্রেরক থেকে প্রাপকের কাছে একটি ডেটা প্যাকেট প্রেরণের জন্য প্রয়োজনীয় সময়। এমনকি ছোট নেটওয়ার্ক বিলম্বগুলি উচ্চ প্রতিক্রিয়াশীলতার প্রয়োজনীয়তা যেমন প্রথম-ব্যক্তি শ্যুটারগুলির মতো গেমগুলিতে গেমপ্লেকে উল্লেখযোগ্যভাবে প্রভাবিত করতে পারে।

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

আলোর গতি এবং নেটওয়ার্ক লেটেন্সি

ডেটা ট্রান্সমিশনের উপায়গুলি কীভাবে নেটওয়ার্ক লেটেন্সিকে প্রভাবিত করে সে সম্পর্কে কথা বলা যাক। অপটিক্যাল ফাইবারের মাধ্যমে আলোর সাথে প্রেরিত ডেটা ঠিক আলোর গতিতে স্থানান্তরিত হয় না। বাস্তবে, অপটিক্যাল ফাইবারের আলো ভ্যাকুয়ামের চেয়ে ধীর গতিতে প্রেরণ করে, যেহেতু ফাইবারের উপাদান গতির উপর প্রভাব ফেলে।

(আলোর সর্বোচ্চ গতি প্রতি সেকেন্ডে প্রায় 299 মিলিয়ন মিটার বা প্রতি ঘন্টায় 186 হাজার মাইল, কিন্তু আবার, এটি শুধুমাত্র আদর্শ ভ্যাকুয়াম শর্ত।)

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

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

যদিও লোকেরা মিলিসেকেন্ড বিলম্বের জন্য বিশেষভাবে সংবেদনশীল নয়, গবেষণায় দেখা গেছে যে যখন আমরা 100-200 ms পৌঁছাই, বিলম্বটি ইতিমধ্যেই মানুষের মস্তিষ্কে লক্ষণীয়। যদি এটি 300 ms অতিক্রম করে, মানব মস্তিষ্ক এটি একটি ধীর প্রতিক্রিয়া হিসাবে উপলব্ধি করে।

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

জিটার

জিটার হল নেটওয়ার্ক বিলম্বের একটি ভিন্নতা বা "অস্থিরতা"; এটি ধারাবাহিক ডেটা প্যাকেটের মধ্যে বিলম্বের সময়ের পরিবর্তন বর্ণনা করে। যখন ডেটা প্যাকেটগুলি অনিয়মিত বিরতিতে আসে, এটি নেটওয়ার্ক ট্রান্সমিশন অস্থিরতা নির্দেশ করে। এটি নেটওয়ার্কের ভিড়, ট্রাফিকের পরিবর্তন এবং সরঞ্জামের ঘাটতি সহ বিভিন্ন কারণের কারণে হতে পারে।

এমনকি যদি একটি গড় বিলম্ব গ্রহণযোগ্য বলে বিবেচিত হয়, উচ্চ ঝাঁকুনি সমস্যা সৃষ্টি করতে পারে, বিশেষ করে রিয়েল-টাইম অ্যাপ্লিকেশন যেমন অনলাইন গেমিং বা ইন্টারনেট টেলিফোনি যেখানে বিলম্বের ধারাবাহিকতা অপরিহার্য।

যদি জিটারের পরিমাণ খুব বেশি হয়, তাহলে গেমের অক্ষর বা বস্তু নড়াচড়া করার সময় খেলোয়াড়রা ল্যাগ বা "তোতলা" অনুভব করতে পারে। এটি প্যাকেটের ক্ষতির কারণ হতে পারে, যেখানে ডেটা প্যাকেটগুলি তাদের গন্তব্যে পৌঁছায় না বা দরকারী হতে খুব দেরি করে।

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

প্যাকেটের ক্ষয়ক্ষতি

প্যাকেট লস এমন একটি পরিস্থিতি যখন ডেটার এক বা একাধিক প্যাকেট তাদের গন্তব্যে পৌঁছাতে ব্যর্থ হয়। এটি বিভিন্ন কারণে ঘটতে পারে, যেমন নেটওয়ার্ক সমস্যা, ট্রাফিক ওভারলোড বা সরঞ্জামের সমস্যা।

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

প্যাকেট হারানোর ফলে গেমপ্লে সম্পূর্ণভাবে বাধাগ্রস্ত হতে পারে, কারণ ট্রান্সমিশনের সময় প্রয়োজনীয় তথ্য হারিয়ে যেতে পারে।

অতএব, প্যাকেটের ক্ষতি মোকাবেলা করার জন্য বা গেমপ্লেতে এর প্রভাব কমানোর জন্য প্রক্রিয়া তৈরি করা গুরুত্বপূর্ণ।

টিক রেট

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

60Hz-এর টিক রেট 30Hz-এর চেয়ে বেশি কার্যকর কারণ এটি সিমুলেশন ধাপের মধ্যে সময় কমিয়ে দেয়, যার ফলে কম বিলম্ব হয়। উপরন্তু, এই হার সার্ভারকে প্রতি সেকেন্ডে 60টি আপডেট প্রেরণ করতে দেয়, যা ক্লায়েন্ট এবং সার্ভারের মধ্যে রাউন্ড ট্রিপ বিলম্বকে প্রায় 33ms (ক্লায়েন্ট থেকে সার্ভারে -16ms এবং সার্ভার থেকে ক্লায়েন্টে অন্য -16ms) কমিয়ে দেয়।

যাইহোক, গেমপ্লে সমস্যা যেমন রাবার ব্যান্ডিং, টেলিপোর্টিং প্লেয়ার, প্রত্যাখ্যাত হিট, এবং পদার্থবিজ্ঞানের ব্যর্থতা দেখা দিতে পারে যখন সার্ভার প্রতিটি টিক রেটের জন্য বরাদ্দ ব্যবধানের মধ্যে টিকগুলি প্রক্রিয়া করতে সংগ্রাম করে। উদাহরণস্বরূপ, যদি একটি সার্ভার একটি 60Hz টিক রেট সেট করা থাকে কিন্তু প্রতিটি টিক জন্য উপলব্ধ আনুমানিক 16.67 মিলিসেকেন্ড (1 সেকেন্ড / 60) মধ্যে প্রয়োজনীয় সিমুলেশন এবং ডেটা ট্রান্সমিশন সম্পূর্ণ করতে না পারে, এই সমস্যাগুলি ঘটতে পারে।

সীমাবদ্ধতা মোকাবেলা

যেমনটি আমরা বিলম্ব এবং প্যাকেট ক্ষয় সংক্রান্ত বিভাগগুলিতে আলোচনা করেছি, বিলম্ব একটি সমস্যা যা আমাদের সমাধান করতে হবে এবং জিটার একটি নিরবচ্ছিন্ন গেমিং অভিজ্ঞতা তৈরি করা আরও চ্যালেঞ্জিং করে তোলে।

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

এই পদ্ধতিটি সঠিকতাকে অগ্রাধিকার দেয়, নিশ্চিত করে যে সঠিক ব্যবহারকারীর অবস্থা সর্বদা প্রদর্শিত হয়। যাইহোক, এর বেশ কয়েকটি ত্রুটি রয়েছে:

1. সার্ভারের আপডেট ফ্রিকোয়েন্সি পর্যাপ্ত না হলে এটি বিলম্ব এবং একটি অস্থির গেমিং অভিজ্ঞতার কারণ হতে পারে। ক্লায়েন্টের সম্ভাব্য ফ্রেম রেট নির্বিশেষে গেমটি সার্ভারের গতিতে চলবে। এটি একটি লক্ষণীয় ইনপুট বিলম্বের সাথে একটি উচ্চ-ফ্রিকোয়েন্সি গেমকে নিম্ন-মানের অভিজ্ঞতায় অবনমিত করতে পারে।
2. প্রতিক্রিয়াশীলতায় বিলম্ব কিছু গেম জেনারে গ্রহণযোগ্য হতে পারে, তবে সব নয়। খেলার জগতের একটি পুরানো ভিজ্যুয়ালাইজেশন অন্য খেলোয়াড়দের সঠিকভাবে লক্ষ্য করা কঠিন করে তুলতে পারে। বিলম্বের জন্য ক্ষতিপূরণের আগে লক্ষ্য রেখে খেলোয়াড়দের তাদের কর্মের পূর্বাভাস দিতে হবে।
3. সবচেয়ে খারাপ পরিস্থিতিতে, খেলোয়াড়রা তাদের লক্ষ্য পুরোপুরি মিস করতে পারে। শত্রুরা এলোমেলোভাবে নড়াচড়া না করলেও ডিসপ্লের তুলনায় 100-150 ms এগিয়ে বলে মনে হতে পারে। এই অসঙ্গতির কারণে খেলোয়াড়রা মিস করতে পারে এমনকি যদি তাদের লক্ষ্য তাদের স্ক্রীন অনুযায়ী স্পট-অন হয়।

অতএব, যদিও "বোবা টার্মিনাল" পদ্ধতিটি সঠিক রাষ্ট্রীয় প্রতিনিধিত্ব নিশ্চিত করে, এটি তার অন্তর্নিহিত সীমাবদ্ধতার কারণে গেমিং অভিজ্ঞতার গুণমানকে সম্ভাব্যভাবে কমিয়ে দিতে পারে।

ক্লায়েন্ট-সাইড ইন্টারপোলেশন

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

ক্লায়েন্ট-সাইড ইন্টারপোলেশনের সাথে, ক্লায়েন্ট সার্ভার থেকে পাঠানো তাদের অবস্থানের উপর নির্ভর না করে সময়ের সাথে সাথে বস্তুর অবস্থাকে মসৃণভাবে ইন্টারপোলেট করে। এই পদ্ধতিটি সতর্ক, কারণ এটি শুধুমাত্র সার্ভার থেকে পাঠানো প্রকৃত অবস্থার মধ্যে স্থানান্তরকে মসৃণ করে।

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

মৃত হিসাব

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

এই ক্ষেত্রে, এটা মনে রাখা গুরুত্বপূর্ণ যে আমরা এখনও একই অনুমান পদ্ধতি ব্যবহার করতে পারি যদি একটি নতুন প্যাকেট পূর্বাভাস অনুযায়ী না আসে। কিন্তু আমরা যত বেশি সময় ধরে ভবিষ্যৎ অনুমান করব, তত বেশি ভুল হওয়ার সম্ভাবনা থাকবে; এটি মোকাবেলা করার জন্য, DR অ্যালগরিদম প্রকৃত তথ্য প্রাপ্ত হওয়ার পরে সংশোধন করতে "প্রকল্পিত বেগ মিশ্রন" ব্যবহার করে।

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

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

ক্লায়েন্ট-সাইড পূর্বাভাস

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

ক্লায়েন্ট-সাইড পূর্বাভাস সার্ভার এবং ক্লায়েন্ট যা দেখে তার মধ্যে পার্থক্য সৃষ্টি করে। এটি "অপ্রত্যাশিত" চাক্ষুষ প্রভাবের দিকে নিয়ে যেতে পারে। অপ্রসেসড প্লেয়ার অ্যাকশনগুলি বিবেচনায় নেওয়া এবং প্রতিটি সার্ভার আপডেটের পরে সেগুলি পুনরায় প্রয়োগ করা গুরুত্বপূর্ণ৷

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

ল্যাগ ক্ষতিপূরণ

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

ল্যাগ ক্ষতিপূরণ নীতি হল যে সার্ভার যে কোনো সময় বিশ্ব রাষ্ট্র পুনরায় তৈরি করতে পারে. সার্ভার যখন শট সম্পর্কে তথ্য সহ আপনার ডেটা প্যাকেট গ্রহণ করে, তখন এটি শটের মুহুর্তে বিশ্বকে পুনরায় তৈরি করে এবং সিদ্ধান্ত নেয় এটি আঘাত বা মিস হয়েছে কিনা।

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

এই কারণে, ল্যাগ ক্ষতিপূরণ এড়ানো উচিত। ক্লায়েন্ট-সাইডে উপরে বর্ণিত তিনটি কৌশল সার্ভার থেকে ক্লায়েন্টের প্রতি আস্থা বোঝায় না এবং এই ধরনের অপব্যবহারের জন্য সংবেদনশীল নয়।

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

শেষ পর্ব ১

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

পরবর্তী বিভাগে, আমরা TCP, UDP, এবং WebSockets এর মত প্রধান ডেটা ট্রান্সমিশন প্রোটোকল নিয়ে আলোচনা করব।