നെറ്റ്‌വർക്ക് ലേറ്റൻസി കോമ്പൻസേഷൻ അൽഗോരിതം ഉപയോഗിച്ച് ഒരു മൊബൈൽ ഷൂട്ടർക്കുള്ള ബാലിസ്റ്റിക് കണക്കുകൂട്ടലുകളുടെ മെക്കാനിക്‌സ് ഞങ്ങൾ എങ്ങനെ മെച്ചപ്പെടുത്തി

ഹായ്, ഞാൻ നികിത ബ്രിഷാക്ക് ആണ്, പിക്സോണിക്സിൽ നിന്നുള്ള ഒരു സെർവർ ഡെവലപ്പർ. മൊബൈൽ മൾട്ടിപ്ലെയറിലെ കാലതാമസത്തിന് നഷ്ടപരിഹാരം നൽകുന്നതിനെക്കുറിച്ച് ഇന്ന് ഞാൻ സംസാരിക്കാൻ ആഗ്രഹിക്കുന്നു.

റഷ്യൻ ഭാഷയിൽ ഉൾപ്പെടെ സെർവർ ലാഗ് നഷ്ടപരിഹാരത്തെക്കുറിച്ച് നിരവധി ലേഖനങ്ങൾ എഴുതിയിട്ടുണ്ട്. 90 കളുടെ അവസാനം മുതൽ മൾട്ടിപ്ലെയർ എഫ്പിഎസ് സൃഷ്ടിക്കുന്നതിൽ ഈ സാങ്കേതികവിദ്യ സജീവമായി ഉപയോഗിക്കുന്നതിനാൽ ഇത് ആശ്ചര്യകരമല്ല. ഉദാഹരണത്തിന്, QuakeWorld മോഡ് നിങ്ങൾക്ക് ഓർമ്മിക്കാം, അത് ആദ്യം ഉപയോഗിച്ച ഒന്നാണ്.

ഞങ്ങളുടെ മൊബൈൽ മൾട്ടിപ്ലെയർ ഷൂട്ടർ ഡിനോ സ്ക്വാഡിലും ഞങ്ങൾ ഇത് ഉപയോഗിക്കുന്നു.

ഈ ലേഖനത്തിൽ, എന്റെ ലക്ഷ്യം ഇതിനകം ആയിരം തവണ എഴുതിയത് ആവർത്തിക്കുകയല്ല, മറിച്ച് ഞങ്ങളുടെ സാങ്കേതികവിദ്യാ സ്റ്റാക്കും പ്രധാന ഗെയിംപ്ലേ സവിശേഷതകളും കണക്കിലെടുത്ത് ഞങ്ങളുടെ ഗെയിമിൽ ലാഗ് നഷ്ടപരിഹാരം ഞങ്ങൾ എങ്ങനെ നടപ്പാക്കി എന്ന് പറയുക എന്നതാണ്.

ഞങ്ങളുടെ കോർട്ടക്സിനെയും സാങ്കേതികവിദ്യയെയും കുറിച്ച് കുറച്ച് വാക്കുകൾ.

ഒരു നെറ്റ്‌വർക്ക് മൊബൈൽ പിവിപി ഷൂട്ടറാണ് ഡിനോ സ്ക്വാഡ്. കളിക്കാർ വിവിധതരം ആയുധങ്ങൾ കൊണ്ട് സജ്ജീകരിച്ചിരിക്കുന്ന ദിനോസറുകളെ നിയന്ത്രിക്കുകയും 6v6 ടീമുകളായി പരസ്പരം പോരാടുകയും ചെയ്യുന്നു.

ക്ലയന്റും സെർവറും യൂണിറ്റി അടിസ്ഥാനമാക്കിയുള്ളതാണ്. ഷൂട്ടർമാർക്ക് ആർക്കിടെക്ചർ തികച്ചും ക്ലാസിക് ആണ്: സെർവർ സ്വേച്ഛാധിപത്യമാണ്, കൂടാതെ ക്ലയന്റ് പ്രവചനം ക്ലയന്റുകളിൽ പ്രവർത്തിക്കുന്നു. ഗെയിം സിമുലേഷൻ ഇൻ-ഹൗസ് ഇസിഎസ് ഉപയോഗിച്ചാണ് എഴുതിയിരിക്കുന്നത്, ഇത് സെർവറിലും ക്ലയന്റിലും ഉപയോഗിക്കുന്നു.

ലാഗ് നഷ്ടപരിഹാരത്തെക്കുറിച്ച് നിങ്ങൾ ആദ്യമായി കേൾക്കുന്നുണ്ടെങ്കിൽ, പ്രശ്നത്തിലേക്കുള്ള ഒരു ഹ്രസ്വ വിനോദയാത്ര ഇതാ.

മൾട്ടിപ്ലെയർ FPS ഗെയിമുകളിൽ, മത്സരം സാധാരണയായി ഒരു റിമോട്ട് സെർവറിൽ അനുകരിക്കപ്പെടുന്നു. കളിക്കാർ അവരുടെ ഇൻപുട്ട് (അമർത്തിയ കീകളെക്കുറിച്ചുള്ള വിവരങ്ങൾ) സെർവറിലേക്ക് അയയ്‌ക്കുന്നു, പ്രതികരണമായി ലഭിച്ച ഡാറ്റ കണക്കിലെടുത്ത് സെർവർ അവർക്ക് ഒരു അപ്‌ഡേറ്റ് ചെയ്‌ത ഗെയിം അവസ്ഥ അയയ്‌ക്കുന്നു. ഈ ഇന്ററാക്ഷൻ സ്കീം ഉപയോഗിച്ച്, ഫോർവേഡ് കീ അമർത്തുന്നതും പ്ലേയർ പ്രതീകം സ്ക്രീനിൽ നീങ്ങുന്ന നിമിഷവും തമ്മിലുള്ള കാലതാമസം എല്ലായ്പ്പോഴും പിങ്ങിനെക്കാൾ വലുതായിരിക്കും.

ലോക്കൽ നെറ്റ്‌വർക്കുകളിൽ ഈ കാലതാമസം (ഇൻപുട്ട് ലാഗ് എന്ന് അറിയപ്പെടുന്നത്) ശ്രദ്ധിക്കപ്പെടാതെ വന്നേക്കാം, ഇന്റർനെറ്റ് വഴി പ്ലേ ചെയ്യുമ്പോൾ അത് ഒരു പ്രതീകം നിയന്ത്രിക്കുമ്പോൾ "ഐസിൽ സ്ലൈഡിംഗ്" എന്ന തോന്നൽ സൃഷ്ടിക്കുന്നു. മൊബൈൽ നെറ്റ്‌വർക്കുകൾക്ക് ഈ പ്രശ്നം ഇരട്ടി പ്രസക്തമാണ്, ഒരു കളിക്കാരന്റെ പിംഗ് 200 എംഎസ് ആയിരിക്കുമ്പോൾ അത് ഇപ്പോഴും മികച്ച കണക്ഷനായി കണക്കാക്കപ്പെടുന്നു. പലപ്പോഴും പിംഗ് 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-ാമത്തെ ടിക്കിൽ, ഈ സാഹചര്യത്തിൽ, ലാഗ് നഷ്ടപരിഹാരം മേലിൽ പ്രയോഗിക്കില്ല

ഞങ്ങളുടെ നടപ്പാക്കലിൽ, ഈ രണ്ട് സമീപനങ്ങളും കോഡിന്റെ രണ്ട് വരികളിൽ വ്യത്യാസപ്പെട്ടിരിക്കുന്നു, അതിനാൽ ഞങ്ങൾ രണ്ടും സൃഷ്ടിച്ചു, വളരെക്കാലം അവ സമാന്തരമായി നിലനിന്നിരുന്നു. ആയുധത്തിന്റെ മെക്കാനിക്സും ബുള്ളറ്റിന്റെ വേഗതയും അനുസരിച്ച്, ഓരോ ദിനോസറിനും ഞങ്ങൾ ഒന്നോ അതിലധികമോ ഓപ്ഷൻ തിരഞ്ഞെടുത്തു. "ഇത്തരമൊരു സമയത്ത് നിങ്ങൾ ശത്രുവിനെ പലതവണ അടിച്ചാൽ, അത്തരമൊരു ബോണസ് നേടുക" എന്നതുപോലുള്ള മെക്കാനിക്സ് ഗെയിമിലെ പ്രത്യക്ഷമായിരുന്നു ഇവിടെ വഴിത്തിരിവ്. കളിക്കാരൻ ശത്രുവിനെ അടിച്ച സമയം ഒരു പ്രധാന പങ്ക് വഹിച്ച ഏതൊരു മെക്കാനിക്കും രണ്ടാമത്തെ സമീപനത്തിൽ പ്രവർത്തിക്കാൻ വിസമ്മതിച്ചു. അതിനാൽ ഞങ്ങൾ ആദ്യ ഓപ്‌ഷനുമായി പോയി, ഇത് ഇപ്പോൾ എല്ലാ ആയുധങ്ങൾക്കും ഗെയിമിലെ എല്ലാ സജീവ കഴിവുകൾക്കും ബാധകമാണ്.

വെവ്വേറെ, പ്രകടനത്തിന്റെ പ്രശ്നം ഉയർത്തുന്നത് മൂല്യവത്താണ്. ഇതെല്ലാം കാര്യങ്ങൾ മന്ദഗതിയിലാക്കുമെന്ന് നിങ്ങൾ കരുതുന്നുണ്ടെങ്കിൽ, ഞാൻ ഉത്തരം നൽകുന്നു: അത്. കൊളൈഡറുകൾ ചലിപ്പിക്കുന്നതിലും അവയെ ഓണാക്കുന്നതിലും ഓഫ് ചെയ്യുന്നതിലും യൂണിറ്റി വളരെ മന്ദഗതിയിലാണ്. ഡിനോ സ്ക്വാഡിൽ, "മോശമായ" സാഹചര്യത്തിൽ, യുദ്ധത്തിൽ ഒരേസമയം നൂറുകണക്കിന് പ്രൊജക്‌ടൈലുകൾ ഉണ്ടാകാം. ഓരോ പ്രൊജക്‌ടൈലിനെയും വ്യക്തിഗതമായി കണക്കാക്കാൻ കൊളൈഡറുകൾ നീക്കുന്നത് താങ്ങാനാവാത്ത ആഡംബരമാണ്. അതിനാൽ, ഭൗതികശാസ്ത്ര "റോൾബാക്കുകളുടെ" എണ്ണം കുറയ്ക്കുന്നതിന് ഞങ്ങൾക്ക് അത് തികച്ചും ആവശ്യമായിരുന്നു. ഇത് ചെയ്യുന്നതിന്, ഞങ്ങൾ ഇസിഎസിൽ ഒരു പ്രത്യേക ഘടകം സൃഷ്ടിച്ചു, അതിൽ ഞങ്ങൾ കളിക്കാരന്റെ സമയം രേഖപ്പെടുത്തുന്നു. ലാഗ് നഷ്ടപരിഹാരം (പ്രൊജക്റ്റൈലുകൾ, കഴിവുകൾ മുതലായവ) ആവശ്യമുള്ള എല്ലാ എന്റിറ്റികളിലേക്കും ഞങ്ങൾ ഇത് ചേർത്തു. ഞങ്ങൾ അത്തരം എന്റിറ്റികൾ പ്രോസസ്സ് ചെയ്യാൻ തുടങ്ങുന്നതിനുമുമ്പ്, ഈ സമയം കൊണ്ട് ഞങ്ങൾ അവയെ ക്ലസ്റ്റർ ചെയ്യുകയും ഒരുമിച്ച് പ്രോസസ്സ് ചെയ്യുകയും ചെയ്യുന്നു, ഓരോ ക്ലസ്റ്ററിനും ഒരിക്കൽ ഭൗതിക ലോകത്തെ തിരികെ കൊണ്ടുവരിക.

ഈ ഘട്ടത്തിൽ ഞങ്ങൾക്ക് പൊതുവായി പ്രവർത്തിക്കുന്ന ഒരു സംവിധാനമുണ്ട്. അതിന്റെ കോഡ് കുറച്ച് ലളിതമായ രൂപത്തിൽ:

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 ഹെർട്‌സിന്റെ ടിക്ക് നിരക്ക്). വളരെ ഉയർന്ന പിംഗിൽ പോലും എതിരാളികളെ അടിക്കാൻ ഇത് കളിക്കാരെ അനുവദിക്കുന്നു.

2. ഏതൊക്കെ വസ്തുക്കളാണ് സമയബന്ധിതമായി നീക്കാൻ കഴിയുക, ഏതെല്ലാം ചെയ്യാൻ കഴിയില്ല എന്ന് നിർണ്ണയിക്കുക.

തീർച്ചയായും ഞങ്ങൾ എതിരാളികളെ ചലിപ്പിക്കുകയാണ്. എന്നാൽ ഇൻസ്റ്റാൾ ചെയ്യാവുന്ന ഊർജ്ജ ഷീൽഡുകൾ, ഉദാഹരണത്തിന്, അല്ല. ഓൺലൈൻ ഷൂട്ടർമാരിൽ പലപ്പോഴും ചെയ്യുന്നത് പോലെ പ്രതിരോധ ശേഷിക്ക് മുൻഗണന നൽകുന്നതാണ് നല്ലതെന്ന് ഞങ്ങൾ തീരുമാനിച്ചു. പ്ലെയർ വർത്തമാനകാലത്ത് ഒരു ഷീൽഡ് സ്ഥാപിച്ചിട്ടുണ്ടെങ്കിൽ, ഭൂതകാലത്തിൽ നിന്നുള്ള ലാഗ് നഷ്ടപരിഹാര ബുള്ളറ്റുകൾ അതിലൂടെ പറക്കാൻ പാടില്ല.

3. ദിനോസറുകളുടെ കഴിവുകൾക്ക് നഷ്ടപരിഹാരം നൽകേണ്ടതുണ്ടോ എന്ന് തീരുമാനിക്കുക: കടി, വാൽ സ്‌ട്രൈക്ക് മുതലായവ. എന്താണ് വേണ്ടതെന്ന് ഞങ്ങൾ തീരുമാനിക്കുകയും ബുള്ളറ്റുകളുടെ അതേ നിയമങ്ങൾക്കനുസൃതമായി അവയെ പ്രോസസ്സ് ചെയ്യുകയും ചെയ്തു.

4. ലാഗ് നഷ്ടപരിഹാരം നടത്തുന്ന കളിക്കാരന്റെ കൊളൈഡറുകൾ എന്തുചെയ്യണമെന്ന് നിർണ്ണയിക്കുക. ഒരു നല്ല രീതിയിൽ, അവരുടെ സ്ഥാനം ഭൂതകാലത്തിലേക്ക് മാറരുത്: കളിക്കാരൻ ഇപ്പോൾ സെർവറിൽ ഉള്ള അതേ സമയം തന്നെ കാണണം. എന്നിരുന്നാലും, ഷൂട്ടിംഗ് പ്ലെയറിന്റെ കൊളൈഡറുകളും ഞങ്ങൾ പിൻവലിക്കുന്നു, ഇതിന് നിരവധി കാരണങ്ങളുണ്ട്.

ആദ്യം, ഇത് ക്ലസ്റ്ററിംഗ് മെച്ചപ്പെടുത്തുന്നു: അടുത്ത പിംഗ് ഉള്ള എല്ലാ കളിക്കാർക്കും ഒരേ ഫിസിക്കൽ സ്റ്റേറ്റ് ഉപയോഗിക്കാം.

രണ്ടാമതായി, എല്ലാ റെയ്‌കാസ്റ്റുകളിലും ഓവർലാപ്പുകളിലും ഞങ്ങൾ എല്ലായ്പ്പോഴും കഴിവുകളോ പ്രൊജക്‌ടൈലുകളോ ഉള്ള കളിക്കാരന്റെ കൊളൈഡറുകളെ ഒഴിവാക്കുന്നു. ഡിനോ സ്ക്വാഡിൽ, കളിക്കാർ ദിനോസറുകളെ നിയന്ത്രിക്കുന്നു, അവയ്ക്ക് ഷൂട്ടർ മാനദണ്ഡങ്ങൾക്കനുസൃതമായി നിലവാരമില്ലാത്ത ജ്യാമിതിയുണ്ട്. കളിക്കാരൻ അസാധാരണമായ ഒരു കോണിൽ വെടിയുതിർത്താലും ബുള്ളറ്റിന്റെ പാത കളിക്കാരന്റെ ദിനോസർ കൂട്ടിയിടിയിലൂടെ കടന്നുപോയാലും, ബുള്ളറ്റ് അത് അവഗണിക്കും.

മൂന്നാമതായി, ലാഗ് നഷ്ടപരിഹാരം ആരംഭിക്കുന്നതിന് മുമ്പുതന്നെ ഇസിഎസിൽ നിന്നുള്ള ഡാറ്റ ഉപയോഗിച്ച് ദിനോസറിന്റെ ആയുധത്തിന്റെ സ്ഥാനങ്ങൾ അല്ലെങ്കിൽ കഴിവിന്റെ പ്രയോഗത്തിന്റെ പോയിന്റ് ഞങ്ങൾ കണക്കാക്കുന്നു.

തൽഫലമായി, ലാഗ്-കമ്പൻസേറ്റഡ് പ്ലെയറിന്റെ കൊളൈഡറുകളുടെ യഥാർത്ഥ സ്ഥാനം ഞങ്ങൾക്ക് അപ്രധാനമാണ്, അതിനാൽ ഞങ്ങൾ കൂടുതൽ ഉൽപ്പാദനക്ഷമവും അതേ സമയം ലളിതവുമായ പാത സ്വീകരിച്ചു.

നെറ്റ്‌വർക്ക് ലേറ്റൻസി നീക്കം ചെയ്യാൻ കഴിയില്ല, അത് മറയ്ക്കാൻ മാത്രമേ കഴിയൂ. മറ്റേതൊരു വേഷംമാറി രീതിയും പോലെ, സെർവർ ലാഗ് നഷ്ടപരിഹാരത്തിന് അതിന്റേതായ ഇടപാടുകളുണ്ട്. വെടിയുതിർത്ത കളിക്കാരന്റെ ചെലവിൽ ഷൂട്ട് ചെയ്യുന്ന കളിക്കാരന്റെ ഗെയിമിംഗ് അനുഭവം ഇത് മെച്ചപ്പെടുത്തുന്നു. എന്നിരുന്നാലും, ഡിനോ സ്ക്വാഡിന്, ഇവിടെ തിരഞ്ഞെടുപ്പ് വ്യക്തമായിരുന്നു.

തീർച്ചയായും, സെർവർ കോഡിന്റെ മൊത്തത്തിലുള്ള സങ്കീർണ്ണത കാരണം ഇതിനെല്ലാം പണം നൽകേണ്ടതുണ്ട് - പ്രോഗ്രാമർമാർക്കും ഗെയിം ഡിസൈനർമാർക്കും. നേരത്തെ സിമുലേഷൻ സിസ്റ്റങ്ങളുടെ ഒരു ലളിതമായ സീക്വൻഷ്യൽ കോളായിരുന്നുവെങ്കിൽ, കാലതാമസത്തോടെ, നെസ്റ്റഡ് ലൂപ്പുകളും ശാഖകളും അതിൽ പ്രത്യക്ഷപ്പെട്ടു. ജോലി ചെയ്യാൻ സൗകര്യമൊരുക്കാൻ ഞങ്ങൾ വളരെയധികം പരിശ്രമിക്കുകയും ചെയ്തു.

2019 പതിപ്പിൽ (അൽപ്പം നേരത്തെയും), യൂണിറ്റി സ്വതന്ത്ര ഫിസിക്കൽ സീനുകൾക്ക് പൂർണ്ണ പിന്തുണ ചേർത്തു. അപ്‌ഡേറ്റ് കഴിഞ്ഞയുടനെ ഞങ്ങൾ അവ സെർവറിൽ നടപ്പിലാക്കി, കാരണം എല്ലാ മുറികൾക്കും പൊതുവായുള്ള ഭൗതിക ലോകത്തെ വേഗത്തിൽ ഒഴിവാക്കാൻ ഞങ്ങൾ ആഗ്രഹിച്ചു.

ഞങ്ങൾ ഓരോ ഗെയിം റൂമിനും അതിന്റേതായ ഫിസിക്കൽ സീൻ നൽകുകയും സിമുലേഷൻ കണക്കാക്കുന്നതിന് മുമ്പ് അയൽ മുറിയിലെ ഡാറ്റയിൽ നിന്ന് സീൻ "ക്ലിയാർ" ചെയ്യേണ്ടതിന്റെ ആവശ്യകത ഇല്ലാതാക്കുകയും ചെയ്തു. ഒന്നാമതായി, ഇത് ഉൽപാദനക്ഷമതയിൽ ഗണ്യമായ വർദ്ധനവ് നൽകി. രണ്ടാമതായി, പുതിയ ഗെയിം ഘടകങ്ങൾ ചേർക്കുമ്പോൾ പ്രോഗ്രാമർ സീൻ ക്ലീനപ്പ് കോഡിൽ ഒരു പിശക് വരുത്തിയാൽ ഉയർന്നുവന്ന മുഴുവൻ ബഗുകളും ഒഴിവാക്കാൻ ഇത് സാധ്യമാക്കി. അത്തരം പിശകുകൾ ഡീബഗ് ചെയ്യാൻ ബുദ്ധിമുട്ടായിരുന്നു, മാത്രമല്ല അവ പലപ്പോഴും ഒരു മുറിയിലെ ദൃശ്യത്തിലെ ഭൗതിക വസ്തുക്കളുടെ അവസ്ഥ മറ്റൊരു മുറിയിലേക്ക് "ഒഴുകുന്ന" അവസ്ഥയിലേക്ക് നയിച്ചു.

കൂടാതെ, ഭൗതിക ലോകത്തിന്റെ ചരിത്രം സൂക്ഷിക്കാൻ ഭൗതിക ദൃശ്യങ്ങൾ ഉപയോഗിക്കാമോ എന്നതിനെക്കുറിച്ച് ഞങ്ങൾ കുറച്ച് ഗവേഷണം നടത്തി. അതായത്, സോപാധികമായി, ഓരോ മുറിയിലും ഒരു സീനല്ല, 30 സീനുകൾ അനുവദിക്കുക, അവയിൽ നിന്ന് ഒരു ചാക്രിക ബഫർ ഉണ്ടാക്കുക, അതിൽ സ്റ്റോറി സൂക്ഷിക്കുക. പൊതുവേ, ഓപ്ഷൻ പ്രവർത്തിക്കുന്നുണ്ടെന്ന് തെളിഞ്ഞു, പക്ഷേ ഞങ്ങൾ അത് നടപ്പിലാക്കിയില്ല: ഇത് ഉൽ‌പാദനക്ഷമതയിൽ ഭ്രാന്തമായ വർദ്ധനവ് കാണിച്ചില്ല, പക്ഷേ അപകടകരമായ മാറ്റങ്ങൾ ആവശ്യമാണ്. ഇത്രയധികം സീനുകൾക്കൊപ്പം ദീർഘനേരം പ്രവർത്തിക്കുമ്പോൾ സെർവർ എങ്ങനെ പ്രവർത്തിക്കുമെന്ന് പ്രവചിക്കാൻ പ്രയാസമായിരുന്നു. അതിനാൽ, ഞങ്ങൾ നിയമം പാലിച്ചു: "അത് തകർന്നിട്ടില്ലെങ്കിൽ, അത് പരിഹരിക്കരുത്".

അവലംബം: www.habr.com