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

এই নির্দেশিকাটিতে, আমি আপনার সাথে আপনার নিজের গেম ইঞ্জিন লেখার আগে যে বিভিন্ন ধারণাগুলি শিখতে হবে, সেইসাথে সেগুলি শেখার জন্য সেরা সংস্থান এবং নিবন্ধগুলি শেয়ার করতে চাই৷

সাধারণভাবে, দুটি প্রধান ধরণের নেটওয়ার্ক আর্কিটেকচার রয়েছে: পিয়ার-টু-পিয়ার এবং ক্লায়েন্ট-সার্ভার। একটি পিয়ার-টু-পিয়ার (p2p) আর্কিটেকচারে, যেকোনো জোড়া সংযুক্ত প্লেয়ারের মধ্যে ডেটা স্থানান্তর করা হয়, যখন একটি ক্লায়েন্ট-সার্ভার আর্কিটেকচারে, ডেটা শুধুমাত্র প্লেয়ার এবং সার্ভারের মধ্যে স্থানান্তরিত হয়।

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

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

গেমিং নেটওয়ার্ক সিস্টেমে তিনটি প্রধান উপাদান রয়েছে:

• ট্রান্সপোর্ট প্রোটোকল: ক্লায়েন্ট এবং সার্ভারের মধ্যে কীভাবে ডেটা স্থানান্তর করা হয়।
• অ্যাপ্লিকেশন প্রোটোকল: ক্লায়েন্ট থেকে সার্ভারে এবং সার্ভার থেকে ক্লায়েন্টে কী প্রেরণ করা হয় এবং কোন বিন্যাসে।
• অ্যাপ্লিকেশন লজিক: কিভাবে প্রেরিত ডেটা ক্লায়েন্ট এবং সার্ভারের অবস্থা আপডেট করতে ব্যবহার করা হয়।

প্রতিটি অংশের ভূমিকা এবং তাদের সাথে যুক্ত অসুবিধাগুলি বোঝা খুব গুরুত্বপূর্ণ।

পরিবহন প্রোটোকল

প্রথম ধাপ হল সার্ভার এবং ক্লায়েন্টদের মধ্যে ডেটা পরিবহনের জন্য একটি প্রোটোকল বেছে নেওয়া। এর জন্য দুটি ইন্টারনেট প্রোটোকল রয়েছে: বিভিন্ন TCP и এর ফলে UDP. কিন্তু আপনি তাদের একটির উপর ভিত্তি করে আপনার নিজস্ব পরিবহন প্রোটোকল তৈরি করতে পারেন বা সেগুলি ব্যবহার করে এমন একটি লাইব্রেরি ব্যবহার করতে পারেন।

TCP এবং UDP এর তুলনা

TCP এবং UDP উভয়ের উপর ভিত্তি করে IP. আইপি একটি প্যাকেটকে উত্স থেকে একটি রিসিভারে প্রেরণ করার অনুমতি দেয়, তবে এটি গ্যারান্টি দেয় না যে প্রেরিত প্যাকেটটি শীঘ্র বা পরে রিসিভারের কাছে পৌঁছাবে, এটি অন্তত একবার এটি পাবে এবং প্যাকেটের ক্রমটি আসবে। সঠিক আদেশ। অধিকন্তু, একটি প্যাকেটে মান দ্বারা প্রদত্ত শুধুমাত্র একটি সীমিত ডেটা আকার থাকতে পারে MTU.

UDP হল IP এর উপরে একটি পাতলা স্তর। অতএব, এর একই সীমাবদ্ধতা রয়েছে। বিপরীতে, TCP এর অনেক বৈশিষ্ট্য রয়েছে। এটি ত্রুটি পরীক্ষা সহ দুটি নোডের মধ্যে একটি নির্ভরযোগ্য আদেশযুক্ত সংযোগ প্রদান করে। অতএব, টিসিপি খুব সুবিধাজনক এবং অন্যান্য অনেক প্রোটোকলের মধ্যে ব্যবহার করা হয়, উদাহরণস্বরূপ, ইন HTTP- র, FTP- র и SMTP এর. কিন্তু এই সমস্ত বৈশিষ্ট্য একটি মূল্যে আসে: বিলম্ব.

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

কিন্তু আপনি সম্ভবত বুঝতে পেরেছেন, মাল্টিপ্লেয়ার গেমগুলিতে লেটেন্সি খুবই গুরুত্বপূর্ণ, বিশেষ করে FPS এর মতো সক্রিয় জেনারে। এজন্য অনেক গেমই নিজস্ব প্রোটোকলের সাথে UDP ব্যবহার করে।

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

তাহলে, যদি TCP চুষে যায়, তাহলে আমরা UDP-এর উপর ভিত্তি করে আমাদের নিজস্ব পরিবহন প্রোটোকল তৈরি করতে যাচ্ছি?

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

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

আপনি যদি TCP ব্যবহার করতে চান তাহলে নিশ্চিত করুন যে এটি অক্ষম আছে নাগলের অ্যালগরিদম, কারণ এটি পাঠানোর আগে প্যাকেটগুলিকে বাফার করে, যার মানে এটি বিলম্ব বাড়ায়।

মাল্টিপ্লেয়ার গেমের প্রসঙ্গে ইউডিপি এবং টিসিপির মধ্যে পার্থক্য সম্পর্কে আরও জানতে, গ্লেন ফিডলারের নিবন্ধটি দেখুন UDP বনাম টিসিপি.

মালিকানা প্রোটোকল

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

প্রথম নিবন্ধ গেম প্রোগ্রামারদের জন্য নেটওয়ার্কিং 2008, দ্বিতীয় তুলনায় সহজ একটি গেম নেটওয়ার্ক প্রোটোকল তৈরি করা 2016। আমি আপনাকে পুরোনো দিয়ে শুরু করার পরামর্শ দিচ্ছি।

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

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

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

আপনার যদি TCP-এর চেয়ে আরও দক্ষ কিছুর প্রয়োজন হয়, কিন্তু আপনার নিজের প্রোটোকল প্রয়োগ করতে এবং অনেক বিশদে যেতে বিরক্ত করতে চান না, আপনি নেট লাইব্রেরি ব্যবহার করতে পারেন। তাদের অনেক আছে:

• yojimbo গ্লেন ফিডলার
• রাকনেট, যা আর সমর্থিত নয়, কিন্তু এর কাঁটা স্লাইকনেট সক্রিয় বলে মনে হচ্ছে।
• ENET মাল্টিপ্লেয়ার FPS-এর জন্য তৈরি একটি লাইব্রেরি ঘনক্ষেত্র
• গেম নেটওয়ার্কিং সকেট ভালভ দ্বারা

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

পরিবহন প্রোটোকল উপসংহার

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

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

আমার দুটি টিপস আছে:

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

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

অ্যাপ্লিকেশন প্রোটোকল

এখন যেহেতু আমরা ক্লায়েন্ট এবং সার্ভারের মধ্যে ডেটা বিনিময় করতে পারি, আমাদের সিদ্ধান্ত নিতে হবে কোন ডেটা স্থানান্তর করতে হবে এবং কোন বিন্যাসে।

ক্লাসিক স্কিম হল যে ক্লায়েন্টরা সার্ভারে ইনপুট বা অ্যাকশন পাঠায় এবং সার্ভার ক্লায়েন্টদের কাছে বর্তমান গেমের অবস্থা পাঠায়।

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

সিরিয়ালাইজেশন

প্রথম ধাপ হল আমরা যে ডেটা পাঠাতে চাই তা (ইনপুট বা গেম স্টেট) ট্রান্সমিশনের জন্য উপযুক্ত ফর্ম্যাটে রূপান্তর করা। এই প্রক্রিয়া বলা হয় ক্রমিককরণ.

JSON বা XML এর মতো একটি মানব-পাঠযোগ্য বিন্যাস ব্যবহার করার জন্য অবিলম্বে ধারণাটি মাথায় আসে। কিন্তু এটি সম্পূর্ণরূপে অকার্যকর হবে এবং চ্যানেলের বেশিরভাগ অংশ গ্রহণ করবে না।

পরিবর্তে, এটি বাইনারি বিন্যাস ব্যবহার করার সুপারিশ করা হয়, যা অনেক বেশি কম্প্যাক্ট। অর্থাৎ, প্যাকেটগুলিতে শুধুমাত্র কয়েকটি বাইট থাকবে। এখানে আমাদের অবশ্যই সমস্যাটি বিবেচনা করতে হবে বাইট অর্ডার, যা বিভিন্ন কম্পিউটারে ভিন্ন হতে পারে।

ডেটা সিরিয়ালাইজ করতে, আপনি একটি লাইব্রেরি ব্যবহার করতে পারেন, উদাহরণস্বরূপ:

• ফ্ল্যাটবাফারস গুগল
• ক্যাপন প্রোটো বালির ঝড়
• খাদ্যশস্য শেন গ্রান্ট এবং র্যান্ডলফ ভুরিস

শুধু নিশ্চিত করুন যে লাইব্রেরি পোর্টেবল আর্কাইভ তৈরি করে এবং শেষের যত্ন নেয়।

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

গ্লেন ফিডলার সিরিয়ালাইজেশনের উপর দুটি নিবন্ধ লিখেছেন: প্যাকেট পড়া এবং লেখা и সিরিয়ালাইজেশন কৌশল.

সংকোচন

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

বিট প্যাকিং

প্রথম কৌশলটি বিট প্যাকিং। এটি পছন্দসই মান বর্ণনা করার জন্য প্রয়োজনীয় বিটগুলির সঠিক সংখ্যা ব্যবহার করে। উদাহরণস্বরূপ, যদি আপনার একটি এনাম থাকে যার 16 টি ভিন্ন মান থাকতে পারে, তাহলে পুরো বাইট (8 বিট) এর পরিবর্তে আপনি মাত্র 4 বিট ব্যবহার করতে পারেন।

গ্লেন ফিডলার প্রবন্ধের দ্বিতীয় অংশে কীভাবে এটি বাস্তবায়ন করবেন তা ব্যাখ্যা করেছেন। প্যাকেট পড়া এবং লেখা.

বিট প্যাকিং বিচক্ষণতার সাথে বিশেষভাবে ভাল কাজ করে, যা পরবর্তী বিভাগের বিষয় হবে।

নমুনা

নমুনা একটি ক্ষতিকর কম্প্রেশন কৌশল যা একটি মান এনকোড করতে সম্ভাব্য মানের একটি উপসেট ব্যবহার করে। বিচক্ষণতা বাস্তবায়নের সবচেয়ে সহজ উপায় হল ফ্লোটিং-পয়েন্ট সংখ্যাকে রাউন্ডিং করা।

গ্লেন ফিডলার (আবার!) তার নিবন্ধে অনুশীলনে কীভাবে বিচক্ষণতা প্রয়োগ করতে হয় তা দেখান স্ন্যাপশট কম্প্রেশন.

কম্প্রেশন অ্যালগরিদম

পরবর্তী কৌশলটি হবে ক্ষতিহীন কম্প্রেশন অ্যালগরিদম।

এখানে, আমার মতে, তিনটি সবচেয়ে আকর্ষণীয় অ্যালগরিদম যা আপনার জানা দরকার:

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

ডেল্টা কম্প্রেশন

চূড়ান্ত কম্প্রেশন কৌশল হল ডেল্টা কম্প্রেশন। এটি সত্য যে বর্তমান গেমের অবস্থা এবং ক্লায়েন্ট দ্বারা প্রাপ্ত শেষ অবস্থার মধ্যে শুধুমাত্র পার্থক্যগুলি প্রেরণ করা হয়।

এটি প্রথম Quake3 নেটওয়ার্ক ইঞ্জিনে ব্যবহার করা হয়েছিল। এটি কীভাবে ব্যবহার করবেন তা ব্যাখ্যা করে এখানে দুটি নিবন্ধ রয়েছে:

• Quake3 নেটওয়ার্কিং মডেল ব্রায়ান হুক
• কোয়েক 3 সোর্স কোড রিভিউ: নেটওয়ার্ক মডেল ফ্যাবিয়ান স্যাংলারস [অনুবাদ হাবরে নিবন্ধ, বিভাগ "নেটওয়ার্ক মডেল" দেখুন]

গ্লেন ফিডলার তার প্রবন্ধের দ্বিতীয় অংশেও এটি ব্যবহার করেছেন। স্ন্যাপশট কম্প্রেশন.

এনক্রিপশন

এছাড়াও, আপনাকে ক্লায়েন্ট এবং সার্ভারের মধ্যে তথ্যের সংক্রমণ এনক্রিপ্ট করতে হতে পারে। এর বেশ কয়েকটি কারণ রয়েছে:

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

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

অ্যাপ্লিকেশন প্রোটোকল: উপসংহার

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

অ্যাপ্লিকেশন লজিক

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

তদুপরি, দুটি রাষ্ট্রীয় আপডেটের মধ্যে, বিশ্ব সম্পূর্ণরূপে স্থির। যদি রাষ্ট্রীয় আপডেটের হার কম হয়, তাহলে আন্দোলন খুব ঝাঁকুনি হবে।

এই সমস্যার প্রভাব কমানোর জন্য বেশ কয়েকটি কৌশল রয়েছে এবং আমি পরবর্তী বিভাগে সেগুলি নিয়ে আলোচনা করব।

বিলম্ব মসৃণ কৌশল

এই বিভাগে বর্ণিত সমস্ত কৌশল সিরিজে বিস্তারিতভাবে আলোচনা করা হয়েছে। দ্রুত গতির মাল্টিপ্লেয়ার গ্যাব্রিয়েল গাম্বেটা। আমি অত্যন্ত নিবন্ধের এই চমৎকার সিরিজ পড়ার সুপারিশ. এই কৌশলগুলি অনুশীলনে কীভাবে কাজ করে তা দেখতে এটি একটি ইন্টারেক্টিভ ডেমোও অন্তর্ভুক্ত করে।

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

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

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

গ্লেন ফিডলার (সর্বদা হিসাবে!) 2004 সালে একটি নিবন্ধ লিখেছিলেন নেটওয়ার্ক পদার্থবিদ্যা (2004), যেখানে তিনি সার্ভার এবং ক্লায়েন্টের মধ্যে পদার্থবিজ্ঞানের সিমুলেশনের সিঙ্ক্রোনাইজেশনের ভিত্তি স্থাপন করেছিলেন। 2014 সালে তিনি নিবন্ধগুলির একটি নতুন সিরিজ লিখেছেন নেটওয়ার্কিং পদার্থবিদ্যা, যেখানে তিনি পদার্থবিজ্ঞানের সিমুলেশন সিঙ্ক্রোনাইজ করার জন্য অন্যান্য কৌশল বর্ণনা করেছেন।

ভালভের উইকিতেও দুটি নিবন্ধ রয়েছে, সোর্স মাল্টিপ্লেয়ার নেটওয়ার্কিং и ক্লায়েন্ট/সার্ভার ইন-গেম প্রোটোকল ডিজাইন এবং অপ্টিমাইজেশানে লেটেন্সি ক্ষতিপূরণের পদ্ধতি বিলম্বের ক্ষতিপূরণ নিয়ে কাজ করা।

প্রতারণা প্রতিরোধ

দুটি প্রধান প্রতারণা প্রতিরোধ কৌশল আছে.

প্রথমত, প্রতারকদের জন্য দূষিত প্যাকেট পাঠানো কঠিন করে তোলে। উপরে উল্লিখিত হিসাবে, এটি বাস্তবায়ন করার একটি ভাল উপায় হল এনক্রিপশন।

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

আবেদনের যুক্তি: উপসংহার

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

অন্যান্য সহায়ক সম্পদ

আপনি যদি অন্যান্য নেটওয়ার্ক মডেল সংস্থানগুলি অন্বেষণ করতে চান তবে আপনি সেগুলি এখানে খুঁজে পেতে পারেন:

• গ্লেন ফিডলারের ব্লগ — এটা তার সম্পূর্ণ ব্লগ পড়ার মূল্য, এটা অনেক চমৎকার নিবন্ধ আছে. এটা হল নেটওয়ার্ক প্রযুক্তির সব নিবন্ধ সংগ্রহ করা হয়.
• দুর্দান্ত গেম নেটওয়ার্কিং M. Fatih MAR দ্বারা ভিডিও গেম নেটওয়ার্কিং ইঞ্জিনগুলিতে নিবন্ধ এবং ভিডিওগুলির একটি বিস্তৃত তালিকা৷
• В উইকি subreddit r/gamedev এছাড়াও অনেক দরকারী লিঙ্ক আছে.

উত্স: www.habr.com