কিভাবে আমরা একটি নেটওয়ার্ক বিলম্ব ক্ষতিপূরণ অ্যালগরিদম সহ একটি মোবাইল শ্যুটারের জন্য ব্যালিস্টিক গণনার মেকানিক্স তৈরি করেছি

হাই, আমি Nikita Brizhak, Pixonic-এর একজন সার্ভার ডেভেলপার। আজ আমি মোবাইল মাল্টিপ্লেয়ারে ল্যাগের জন্য ক্ষতিপূরণ সম্পর্কে কথা বলতে চাই।

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

আমরা আমাদের মোবাইল মাল্টিপ্লেয়ার শ্যুটার ডিনো স্কোয়াডেও এটি ব্যবহার করি।

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

আমাদের কর্টেক্স এবং প্রযুক্তি সম্পর্কে কয়েকটি শব্দ।

ডিনো স্কোয়াড একটি নেটওয়ার্ক মোবাইল পিভিপি শ্যুটার। খেলোয়াড়রা বিভিন্ন অস্ত্রে সজ্জিত ডাইনোসর নিয়ন্ত্রণ করে এবং 6v6 দলে একে অপরের সাথে লড়াই করে।

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

যদি এই প্রথমবার আপনি ল্যাগ ক্ষতিপূরণ সম্পর্কে শুনে থাকেন তবে এখানে এই সমস্যাটির একটি সংক্ষিপ্ত ভ্রমণ।

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

স্থানীয় নেটওয়ার্কগুলিতে এই বিলম্ব (জনপ্রিয়ভাবে ইনপুট ল্যাগ বলা হয়) অলক্ষিত হতে পারে, ইন্টারনেটের মাধ্যমে খেলার সময় এটি একটি চরিত্র নিয়ন্ত্রণ করার সময় "বরফের উপর স্লাইডিং" এর অনুভূতি তৈরি করে। এই সমস্যাটি মোবাইল নেটওয়ার্কগুলির জন্য দ্বিগুণভাবে প্রাসঙ্গিক, যেখানে প্লেয়ারের পিং 200 ms হলে সেটি একটি চমৎকার সংযোগ হিসেবে বিবেচিত হয়। প্রায়শই পিং 350, 500, বা 1000 ms হতে পারে। তারপর ইনপুট ল্যাগ সহ একটি দ্রুত শ্যুটার খেলা প্রায় অসম্ভব হয়ে পড়ে।

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

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

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

এই জ্ঞানের সাথে সজ্জিত, আমরা ডিনো স্কোয়াডে সার্ভার ল্যাগ ক্ষতিপূরণ বাস্তবায়ন শুরু করেছি। প্রথমত, আমাদের বুঝতে হবে কীভাবে সার্ভারে ক্লায়েন্ট কী দেখল তা পুনরুদ্ধার করবেন? এবং ঠিক কি পুনরুদ্ধার করা প্রয়োজন? আমাদের গেমে, অস্ত্র এবং ক্ষমতা থেকে হিটগুলি রেকাস্ট এবং ওভারলেগুলির মাধ্যমে গণনা করা হয় - অর্থাৎ শত্রুর শারীরিক সংঘর্ষের সাথে মিথস্ক্রিয়ার মাধ্যমে। তদনুসারে, আমাদের এই সংঘর্ষের অবস্থান পুনরুত্পাদন করতে হবে, যা প্লেয়ার স্থানীয়ভাবে সার্ভারে "দেখেছিল"। সেই সময় আমরা ইউনিটি সংস্করণ 2018.x ব্যবহার করছিলাম। সেখানে পদার্থবিজ্ঞান API স্থির, ভৌত জগত একটি একক অনুলিপিতে বিদ্যমান। এর রাষ্ট্র সংরক্ষণ এবং তারপর বাক্স থেকে এটি পুনরুদ্ধার করার কোন উপায় নেই। তো এখন কি করা?

সমাধানটি পৃষ্ঠে ছিল; এর সমস্ত উপাদান ইতিমধ্যে অন্যান্য সমস্যা সমাধানের জন্য আমাদের দ্বারা ব্যবহার করা হয়েছে:

1. প্রতিটি ক্লায়েন্টের জন্য, আমাদের জানতে হবে যে তিনি কী টিপলে তিনি কোন সময়ে বিরোধীদের দেখেছিলেন। আমরা ইতিমধ্যে ইনপুট প্যাকেজে এই তথ্যটি লিখেছি এবং ক্লায়েন্টের পূর্বাভাস সামঞ্জস্য করতে এটি ব্যবহার করেছি।
2. আমাদের গেম স্টেটের ইতিহাস সংরক্ষণ করতে সক্ষম হওয়া দরকার। এটিতে আমরা আমাদের প্রতিপক্ষের অবস্থান ধরে রাখব (এবং তাই তাদের সংঘর্ষকারী)। আমাদের ইতিমধ্যে সার্ভারে একটি রাষ্ট্রীয় ইতিহাস ছিল, আমরা এটি তৈরি করতে ব্যবহার করেছি ডেল্টাস. সঠিক সময় জানা থাকলে আমরা সহজেই ইতিহাসে সঠিক রাষ্ট্র খুঁজে পেতাম।
3. এখন যেহেতু আমাদের হাতে ইতিহাস থেকে গেমের অবস্থা রয়েছে, তাই আমাদের প্লেয়ার ডেটাকে শারীরিক বিশ্বের অবস্থার সাথে সিঙ্ক্রোনাইজ করতে সক্ষম হতে হবে। বিদ্যমান সংঘর্ষ - সরান, অনুপস্থিতগুলি - তৈরি করুন, অপ্রয়োজনীয়গুলি - ধ্বংস করুন। এই যুক্তিটি ইতিমধ্যেই লিখিত এবং বেশ কয়েকটি ইসিএস সিস্টেম নিয়ে গঠিত। আমরা এক ইউনিটি প্রক্রিয়ায় বেশ কয়েকটি গেম রুম রাখার জন্য এটি ব্যবহার করেছি। এবং যেহেতু ভৌত জগৎ প্রক্রিয়া প্রতি এক, তাই এটি কক্ষগুলির মধ্যে পুনরায় ব্যবহার করতে হয়েছিল। সিমুলেশনের প্রতিটি টিক দেওয়ার আগে, আমরা ভৌত জগতের অবস্থা "রিসেট" করি এবং এটিকে বর্তমান রুমের ডেটা দিয়ে পুনরায় চালু করি, একটি চতুর পুলিং সিস্টেমের মাধ্যমে যতটা সম্ভব ইউনিটি গেম অবজেক্টগুলি পুনরায় ব্যবহার করার চেষ্টা করি। যা বাকি ছিল তা হল অতীত থেকে গেম স্টেটের জন্য একই যুক্তিকে আহ্বান করা।

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

public class TimeMachine : ITimeMachine
{
     //История игровых состояний
     private readonly IGameStateHistory _history;

     //Текущее игровое состояние на сервере
     private readonly ExecutableSystem[] _systems;

     //Набор систем, расставляющих коллайдеры в физическом мире 
     //по данным из игрового состояния
     private readonly GameState _presentState;

     public TimeMachine(IGameStateHistory history, GameState presentState, ExecutableSystem[] timeInitSystems)
     {
         _history = history; 
         _presentState = presentState;
         _systems = timeInitSystems;  
     }

     public GameState TravelToTime(int tick)
     {
         var pastState = tick == _presentState.Time ? _presentState : _history.Get(tick);
         foreach (var system in _systems)
         {
             system.Execute(pastState);
         }
         return pastState;
     }
}

শট এবং ক্ষমতার জন্য সহজেই ক্ষতিপূরণ দেওয়ার জন্য এই মেশিনটি কীভাবে ব্যবহার করা যায় তা নির্ধারণ করা বাকি ছিল।

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

কিন্তু ডিনো স্কোয়াডে এমন মেকানিক্স খুব কমই আছে! গেমের বেশিরভাগ অস্ত্রই প্রজেক্টাইল তৈরি করে - দীর্ঘস্থায়ী বুলেট যা বেশ কয়েকটি সিমুলেশন টিকগুলির জন্য উড়ে যায় (কিছু ক্ষেত্রে, কয়েক ডজন টিক্স)। তাদের সাথে কি করা উচিত, তারা কোন সময় উড়তে হবে?

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

আমাদের কাছে এই বিকল্পটি ছিল না: প্রজেক্টাইল-ভিত্তিক অস্ত্রগুলি গেম ডিজাইনের একটি মূল বৈশিষ্ট্য ছিল। তাই আমরা কিছু সঙ্গে আসা ছিল. কিছু বুদ্ধিমত্তার পরে, আমরা দুটি বিকল্প প্রণয়ন করেছি যা কাজ বলে মনে হয়েছিল:

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

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

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

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

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

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

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

এই পর্যায়ে আমরা একটি সাধারণ কাজ সিস্টেম আছে. এর কোড কিছুটা সরলীকৃত আকারে:

public sealed class LagCompensationSystemGroup : ExecutableSystem
{
     //Машина времени
     private readonly ITimeMachine _timeMachine;

     //Набор систем лагкомпенсации
     private readonly LagCompensationSystem[] _systems;
     
     //Наша реализация кластеризатора
     private readonly TimeTravelMap _travelMap = new TimeTravelMap();

    public LagCompensationSystemGroup(ITimeMachine timeMachine, 
        LagCompensationSystem[] lagCompensationSystems)
     {
         _timeMachine = timeMachine;
         _systems = lagCompensationSystems;
     }

     public override void Execute(GameState gs)
     {
         //На вход кластеризатор принимает текущее игровое состояние,
         //а на выход выдает набор «корзин». В каждой корзине лежат энтити,
         //которым для лагкомпенсации нужно одно и то же время из истории.
         var buckets = _travelMap.RefillBuckets(gs);

         for (int bucketIndex = 0; bucketIndex < buckets.Count; bucketIndex++)
         {
             ProcessBucket(gs, buckets[bucketIndex]);
         }

         //В конце лагкомпенсации мы восстанавливаем физический мир 
         //в исходное состояние
         _timeMachine.TravelToTime(gs.Time);
     }

     private void ProcessBucket(GameState presentState, TimeTravelMap.Bucket bucket)
     {
         //Откатываем время один раз для каждой корзины
         var pastState = _timeMachine.TravelToTime(bucket.Time);

         foreach (var system in _systems)
         {
               system.PastState = pastState;
               system.PresentState = presentState;

               foreach (var entity in bucket)
               {
                   system.Execute(entity);
               }
          }
     }
}

যা অবশিষ্ট ছিল তা ছিল বিশদ কনফিগার করা:

1. সময়ের মধ্যে চলাচলের সর্বোচ্চ দূরত্ব কতটা সীমাবদ্ধ করতে হবে তা বুঝুন।

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

2. কোন বস্তু সময়মতো সরানো যাবে এবং কোনটি যাবে না তা নির্ধারণ করুন।

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

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

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

প্রথমত, এটি ক্লাস্টারিং উন্নত করে: আমরা ঘনিষ্ঠ পিং সহ সমস্ত খেলোয়াড়ের জন্য একই শারীরিক অবস্থা ব্যবহার করতে পারি।

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

তৃতীয়ত, আমরা ল্যাগ ক্ষতিপূরণ শুরুর আগেও ইসিএস থেকে ডেটা ব্যবহার করে ডাইনোসরের অস্ত্রের অবস্থান বা ক্ষমতা প্রয়োগের পয়েন্ট গণনা করি।

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

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

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

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

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

উপরন্তু, আমরা কিছু গবেষণা করেছি যে শারীরিক দৃশ্যগুলিকে ভৌত জগতের ইতিহাস সংরক্ষণ করতে ব্যবহার করা যেতে পারে কিনা। অর্থাৎ, শর্তসাপেক্ষে, প্রতিটি ঘরে একটি দৃশ্য নয়, তবে 30টি দৃশ্য বরাদ্দ করুন এবং সেগুলির মধ্যে একটি চক্রীয় বাফার তৈরি করুন, যাতে গল্পটি সংরক্ষণ করা যায়। সাধারণভাবে, বিকল্পটি কাজ করছে বলে প্রমাণিত হয়েছে, কিন্তু আমরা এটি বাস্তবায়ন করিনি: এটি উত্পাদনশীলতায় কোনও উন্মত্ত বৃদ্ধি দেখায়নি, বরং ঝুঁকিপূর্ণ পরিবর্তনগুলি প্রয়োজন। এত দৃশ্য নিয়ে দীর্ঘ সময় ধরে কাজ করার সময় সার্ভার কীভাবে আচরণ করবে তা অনুমান করা কঠিন ছিল। অতএব, আমরা নিয়ম অনুসরণ করেছি: "যদি এটি না ভেঙে যায় তবে এটি ঠিক করবেন না».

উত্স: www.habr.com