અમે નેટવર્ક લેટન્સી વળતર અલ્ગોરિધમ સાથે મોબાઇલ શૂટર માટે બેલિસ્ટિક ગણતરીઓના મિકેનિક્સને કેવી રીતે વિસ્તૃત કર્યું

હાય, હું નિકિતા બ્રિઝાક છું, Pixonic ના સર્વર ડેવલપર. આજે હું મોબાઇલ મલ્ટિપ્લેયરમાં લેગ માટે વળતર વિશે વાત કરવા માંગુ છું.

રશિયન સહિત સર્વર લેગ વળતર વિશે ઘણા લેખો લખવામાં આવ્યા છે. આ આશ્ચર્યજનક નથી, કારણ કે 90 ના દાયકાના અંતથી મલ્ટિપ્લેયર એફપીએસની રચનામાં આ તકનીકનો સક્રિયપણે ઉપયોગ કરવામાં આવ્યો છે. ઉદાહરણ તરીકે, તમે QuakeWorld મોડને યાદ કરી શકો છો, જે તેનો ઉપયોગ કરનાર સૌપ્રથમ એક હતો.

અમે તેનો ઉપયોગ અમારા મોબાઇલ મલ્ટિપ્લેયર શૂટર ડિનો સ્ક્વોડમાં પણ કરીએ છીએ.

આ લેખમાં, મારો ધ્યેય એક હજાર વખત પહેલાથી જ લખાયેલું છે તેનું પુનરાવર્તન કરવાનો નથી, પરંતુ અમારી ટેક્નોલોજી સ્ટેક અને મુખ્ય ગેમપ્લે સુવિધાઓને ધ્યાનમાં લઈને અમે અમારી રમતમાં લેગ કમ્પેન્સેશન કેવી રીતે લાગુ કર્યું તે જણાવવાનું છે.

અમારા કોર્ટેક્સ અને ટેકનોલોજી વિશે થોડાક શબ્દો.

ડીનો સ્ક્વોડ એ નેટવર્ક મોબાઇલ PvP શૂટર છે. ખેલાડીઓ વિવિધ પ્રકારના શસ્ત્રોથી સજ્જ ડાયનાસોરને નિયંત્રિત કરે છે અને 6v6 ટીમોમાં એકબીજા સાથે લડે છે.

ક્લાયંટ અને સર્વર બંને યુનિટી પર આધારિત છે. શૂટર્સ માટે આર્કિટેક્ચર એકદમ ક્લાસિક છે: સર્વર સરમુખત્યારશાહી છે, અને ક્લાયંટની આગાહી ક્લાયંટ પર કામ કરે છે. ગેમ સિમ્યુલેશન ઇન-હાઉસ ECS નો ઉપયોગ કરીને લખવામાં આવે છે અને તેનો સર્વર અને ક્લાયંટ બંને પર ઉપયોગ થાય છે.

જો તમે લેગ કમ્પેન્સેશન વિશે પહેલીવાર સાંભળ્યું હોય, તો અહીં આ મુદ્દામાં સંક્ષિપ્ત પ્રવાસ છે.

મલ્ટિપ્લેયર FPS રમતોમાં, મેચ સામાન્ય રીતે રિમોટ સર્વર પર સિમ્યુલેટ કરવામાં આવે છે. ખેલાડીઓ સર્વર પર તેમનું ઇનપુટ (દબાવેલી કી વિશેની માહિતી) મોકલે છે અને તેના જવાબમાં સર્વર તેમને પ્રાપ્ત ડેટાને ધ્યાનમાં લઈને અપડેટેડ ગેમ સ્ટેટ મોકલે છે. આ ક્રિયાપ્રતિક્રિયા યોજના સાથે, ફોરવર્ડ કી દબાવવામાં અને પ્લેયરનું પાત્ર સ્ક્રીન પર ફરે તે ક્ષણ વચ્ચેનો વિલંબ હંમેશા પિંગ કરતા વધારે હશે.

જ્યારે સ્થાનિક નેટવર્ક્સ પર આ વિલંબ (લોકપ્રિય રીતે ઇનપુટ લેગ કહેવાય છે) ધ્યાનપાત્ર ન હોઈ શકે, જ્યારે ઈન્ટરનેટ દ્વારા રમવામાં આવે ત્યારે તે પાત્રને નિયંત્રિત કરતી વખતે "બરફ પર સરકતા" ની લાગણી પેદા કરે છે. આ સમસ્યા મોબાઇલ નેટવર્ક્સ માટે બમણી રીતે સંબંધિત છે, જ્યાં પ્લેયરનું પિંગ 200 ms હોય તે કેસ હજુ પણ ઉત્તમ કનેક્શન માનવામાં આવે છે. ઘણીવાર પિંગ 350, 500 અથવા 1000 ms હોઈ શકે છે. પછી ઇનપુટ લેગ સાથે ઝડપી શૂટર રમવું લગભગ અશક્ય બની જાય છે.

આ સમસ્યાનો ઉકેલ ક્લાયંટ-સાઇડ સિમ્યુલેશન અનુમાન છે. અહીં ક્લાયંટ સર્વર તરફથી પ્રતિસાદની રાહ જોયા વિના, પ્લેયર કેરેક્ટર પર ઇનપુટ લાગુ કરે છે. અને જ્યારે જવાબ પ્રાપ્ત થાય છે, ત્યારે તે ફક્ત પરિણામોની તુલના કરે છે અને વિરોધીઓની સ્થિતિને અપડેટ કરે છે. આ કિસ્સામાં કી દબાવવા અને સ્ક્રીન પર પરિણામ પ્રદર્શિત કરવા વચ્ચેનો વિલંબ ન્યૂનતમ છે.

અહીં સૂક્ષ્મતા સમજવી મહત્વપૂર્ણ છે: ક્લાયંટ હંમેશા તેના છેલ્લા ઇનપુટ અનુસાર પોતાને દોરે છે, અને દુશ્મનો - નેટવર્ક વિલંબ સાથે, સર્વરમાંથી ડેટામાંથી અગાઉની સ્થિતિ અનુસાર. એટલે કે, જ્યારે કોઈ દુશ્મન પર ગોળીબાર કરે છે, ત્યારે ખેલાડી તેને પોતાના સંબંધમાં ભૂતકાળમાં જુએ છે. ક્લાયંટની આગાહી વિશે વધુ અમે અગાઉ લખ્યું હતું.

આમ, ક્લાયંટની આગાહી એક સમસ્યાનું નિરાકરણ લાવે છે, પરંતુ બીજી બનાવે છે: જો કોઈ ખેલાડી એ જ બિંદુએ શૂટ કરે છે જ્યાં દુશ્મન ભૂતકાળમાં હતો, તે જ બિંદુએ શૂટિંગ કરતી વખતે સર્વર પર, દુશ્મન હવે તે જગ્યાએ ન હોઈ શકે. સર્વર લેગ વળતર આ સમસ્યાને હલ કરવાનો પ્રયાસ કરે છે. જ્યારે કોઈ શસ્ત્ર ફાયર કરવામાં આવે છે, ત્યારે સર્વર રમતની સ્થિતિને પુનઃસ્થાપિત કરે છે જે ખેલાડીએ શોટ સમયે સ્થાનિક રીતે જોયું હતું, અને તે ખરેખર દુશ્મનને ફટકારી શક્યો હોત કે કેમ તે તપાસે છે. જો જવાબ "હા" હોય, તો હિટ ગણવામાં આવે છે, પછી ભલે તે સમયે દુશ્મન સર્વર પર ન હોય.

આ જ્ઞાનથી સજ્જ, અમે ડીનો સ્ક્વોડમાં સર્વર લેગ વળતરનો અમલ કરવાનું શરૂ કર્યું. સૌ પ્રથમ, અમારે સમજવું પડ્યું કે ક્લાયંટે જે જોયું તે સર્વર પર કેવી રીતે પુનઃસ્થાપિત કરવું? અને બરાબર શું પુનઃસ્થાપિત કરવાની જરૂર છે? અમારી રમતમાં, શસ્ત્રો અને ક્ષમતાઓમાંથી હિટની ગણતરી રેકાસ્ટ અને ઓવરલે દ્વારા કરવામાં આવે છે - એટલે કે, દુશ્મનના ભૌતિક અથડામણો સાથેની ક્રિયાપ્રતિક્રિયાઓ દ્વારા. તદનુસાર, અમારે આ અથડામણની સ્થિતિને પુનઃઉત્પાદિત કરવાની જરૂર હતી, જે ખેલાડીએ સર્વર પર સ્થાનિક રીતે "જોયું" હતું. તે સમયે અમે યુનિટી વર્ઝન 2018.x નો ઉપયોગ કરતા હતા. ત્યાં ભૌતિકશાસ્ત્ર API સ્થિર છે, ભૌતિક વિશ્વ એક નકલમાં અસ્તિત્વમાં છે. તેના રાજ્યને બચાવવા અને પછી તેને બૉક્સમાંથી પુનઃસ્થાપિત કરવાનો કોઈ રસ્તો નથી. તો શું કરવું?

ઉકેલ સપાટી પર હતો; તેના તમામ ઘટકોનો ઉપયોગ અન્ય સમસ્યાઓ ઉકેલવા માટે અમારા દ્વારા પહેલેથી જ કરવામાં આવ્યો હતો:

1. દરેક ક્લાયંટ માટે, આપણે તે જાણવાની જરૂર છે કે જ્યારે તેણે કી દબાવી ત્યારે તેણે કયા સમયે વિરોધીઓને જોયા. અમે આ માહિતી પહેલાથી જ ઇનપુટ પેકેજમાં લખી છે અને ક્લાયંટની આગાહીને સમાયોજિત કરવા માટે તેનો ઉપયોગ કર્યો છે.
2. આપણે રમતના રાજ્યોના ઇતિહાસને સંગ્રહિત કરવામાં સક્ષમ બનવાની જરૂર છે. તે તેમાં છે કે અમે અમારા વિરોધીઓ (અને તેથી તેમના ટક્કરવાળા) ની સ્થિતિને પકડી રાખીશું. અમારી પાસે સર્વર પર પહેલાથી જ રાજ્યનો ઇતિહાસ હતો, અમે તેનો ઉપયોગ બિલ્ડ કરવા માટે કર્યો હતો ડેલ્ટા. યોગ્ય સમય જાણવાથી, આપણે ઇતિહાસમાં યોગ્ય રાજ્ય સરળતાથી શોધી શકીએ છીએ.
3. હવે જ્યારે આપણી પાસે ઇતિહાસમાંથી રમતની સ્થિતિ હાથમાં છે, ત્યારે આપણે ભૌતિક વિશ્વની સ્થિતિ સાથે પ્લેયર ડેટાને સિંક્રનાઇઝ કરવામાં સક્ષમ બનવાની જરૂર છે. હાલના કોલાઈડર્સ - ખસેડો, ગુમ થયેલ - બનાવો, બિનજરૂરી - નાશ કરો. આ તર્ક પણ પહેલેથી જ લખવામાં આવ્યો હતો અને તેમાં અનેક ECS સિસ્ટમનો સમાવેશ થતો હતો. અમે તેનો ઉપયોગ એક યુનિટી પ્રક્રિયામાં ઘણા ગેમ રૂમ રાખવા માટે કર્યો. અને કારણ કે ભૌતિક વિશ્વ પ્રક્રિયા દીઠ એક છે, તેનો રૂમ વચ્ચે ફરીથી ઉપયોગ કરવો પડ્યો. સિમ્યુલેશનની દરેક ટિક પહેલાં, અમે ભૌતિક વિશ્વની સ્થિતિને "રીસેટ" કરીએ છીએ અને તેને વર્તમાન રૂમ માટેના ડેટા સાથે ફરીથી પ્રારંભ કરીએ છીએ, એક ચતુર પુલિંગ સિસ્ટમ દ્વારા યુનિટી ગેમ ઑબ્જેક્ટ્સનો શક્ય તેટલો ફરીથી ઉપયોગ કરવાનો પ્રયાસ કરીએ છીએ. જે બાકી હતું તે ભૂતકાળથી રમતની સ્થિતિ માટે સમાન તર્કનો ઉપયોગ કરવાનું હતું.

આ બધા તત્વોને એકસાથે મૂકીને, અમને એક "ટાઈમ મશીન" મળ્યું જે ભૌતિક વિશ્વની સ્થિતિને યોગ્ય સમયે પાછું ફેરવી શકે. કોડ સરળ હોવાનું બહાર આવ્યું:

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 હર્ટ્ઝના ટિક રેટ સાથે). આનાથી ખેલાડીઓ ખૂબ ઊંચા પિંગ્સ પર પણ વિરોધીઓને ફટકારી શકે છે.

2. નક્કી કરો કે કઈ વસ્તુઓ સમયસર ખસેડી શકાય છે અને કઈ નહીં.

અમે, અલબત્ત, અમારા વિરોધીઓને ખસેડી રહ્યા છીએ. પરંતુ ઇન્સ્ટોલ કરી શકાય તેવી ઉર્જા શિલ્ડ, ઉદાહરણ તરીકે, નથી. અમે નક્કી કર્યું કે રક્ષણાત્મક ક્ષમતાને પ્રાધાન્ય આપવું વધુ સારું છે, જેમ કે ઘણીવાર ઑનલાઇન શૂટર્સમાં કરવામાં આવે છે. જો ખેલાડીએ પહેલાથી જ વર્તમાનમાં ઢાલ લગાવી દીધી હોય, તો ભૂતકાળની લેગ-કમ્પેન્સેટેડ ગોળીઓ તેમાંથી ઉડી ન જોઈએ.

3. ડાયનાસોરની ક્ષમતાઓ માટે વળતર આપવું જરૂરી છે કે કેમ તે નક્કી કરો: ડંખ, પૂંછડીની હડતાલ, વગેરે. અમે નક્કી કર્યું કે શું જરૂરી હતું અને ગોળીઓ જેવા જ નિયમો અનુસાર તેની પ્રક્રિયા કરીએ છીએ.

4. જે ખેલાડી માટે લેગ કમ્પેન્સેશન કરવામાં આવી રહ્યું છે તેના કોલાઈડર સાથે શું કરવું તે નક્કી કરો. સારી રીતે, તેમની સ્થિતિ ભૂતકાળમાં ન બદલવી જોઈએ: ખેલાડીએ પોતાને તે જ સમયે જોવું જોઈએ જેમાં તે હવે સર્વર પર છે. જો કે, અમે શૂટિંગ પ્લેયરના કોલાઈડરને પણ રોલ બેક કરીએ છીએ અને આના ઘણા કારણો છે.

પ્રથમ, તે ક્લસ્ટરિંગને સુધારે છે: અમે નજીકના પિંગ્સવાળા તમામ ખેલાડીઓ માટે સમાન ભૌતિક સ્થિતિનો ઉપયોગ કરી શકીએ છીએ.

બીજું, તમામ રેકાસ્ટ અને ઓવરલેપમાં અમે હંમેશા ક્ષમતાઓ અથવા અસ્ત્રોની માલિકી ધરાવતા ખેલાડીના કોલાઈડરને બાકાત રાખીએ છીએ. ડીનો સ્ક્વોડમાં, ખેલાડીઓ ડાયનાસોરને નિયંત્રિત કરે છે, જે શૂટરના ધોરણો દ્વારા બિન-માનક ભૂમિતિ ધરાવે છે. જો ખેલાડી અસામાન્ય ખૂણા પર ગોળીબાર કરે અને બુલેટનો માર્ગ ખેલાડીના ડાયનાસોર અથડામણમાંથી પસાર થાય તો પણ બુલેટ તેની અવગણના કરશે.

ત્રીજે સ્થાને, અમે લેગ વળતરની શરૂઆત પહેલાં જ ડાયનાસોરના શસ્ત્રની સ્થિતિ અથવા ECS માંથી ડેટાનો ઉપયોગ કરવાની ક્ષમતાના એપ્લિકેશનના બિંદુની ગણતરી કરીએ છીએ.

પરિણામે, લેગ-કમ્પેન્સેટેડ પ્લેયરના અથડામણની વાસ્તવિક સ્થિતિ અમારા માટે બિનમહત્વપૂર્ણ છે, તેથી અમે વધુ ઉત્પાદક અને તે જ સમયે સરળ માર્ગ અપનાવ્યો.

નેટવર્ક લેટન્સી ખાલી દૂર કરી શકાતી નથી, તે માત્ર માસ્ક કરી શકાય છે. વેશપલટોની અન્ય કોઈપણ પદ્ધતિની જેમ, સર્વર લેગ વળતરમાં પણ તેના ટ્રેડઓફ્સ છે. તે જે ખેલાડીને ગોળી મારવામાં આવી છે તેના ખર્ચે શૂટિંગ કરી રહેલા ખેલાડીના ગેમિંગ અનુભવને સુધારે છે. ડીનો સ્ક્વોડ માટે, જોકે, અહીં પસંદગી સ્પષ્ટ હતી.

અલબત્ત, આ બધા માટે સર્વર કોડની વધેલી જટિલતા દ્વારા ચૂકવણી કરવી પડી હતી - પ્રોગ્રામરો અને ગેમ ડિઝાઇનર્સ બંને માટે. જો અગાઉ સિમ્યુલેશન એ સિસ્ટમનો એક સરળ ક્રમિક કૉલ હતો, તો પછી લેગ વળતર સાથે, નેસ્ટેડ લૂપ્સ અને શાખાઓ તેમાં દેખાયા હતા. અમે તેની સાથે કામ કરવા માટે અનુકૂળ બનાવવા માટે ઘણા પ્રયત્નો પણ કર્યા.

2019ના સંસ્કરણમાં (અને કદાચ થોડા સમય પહેલા), યુનિટીએ સ્વતંત્ર ભૌતિક દ્રશ્યો માટે સંપૂર્ણ સમર્થન ઉમેર્યું. અમે અપડેટ પછી લગભગ તરત જ સર્વર પર તેનો અમલ કર્યો, કારણ કે અમે તમામ રૂમમાં સામાન્ય ભૌતિક વિશ્વમાંથી ઝડપથી છુટકારો મેળવવા માગીએ છીએ.

અમે દરેક ગેમ રૂમને તેનું પોતાનું ભૌતિક દ્રશ્ય આપ્યું અને આમ સિમ્યુલેશનની ગણતરી કરતા પહેલા પડોશી રૂમના ડેટામાંથી દ્રશ્ય "સાફ" કરવાની જરૂરિયાતને દૂર કરી. પ્રથમ, તેણે ઉત્પાદકતામાં નોંધપાત્ર વધારો કર્યો. બીજું, જો પ્રોગ્રામરે નવા રમત તત્વો ઉમેરતી વખતે સીન ક્લીનઅપ કોડમાં ભૂલ કરી હોય તો ઉદ્ભવતા બગ્સના સંપૂર્ણ વર્ગથી છુટકારો મેળવવાનું શક્ય બન્યું. આવી ભૂલોને ડીબગ કરવી મુશ્કેલ હતી, અને તે ઘણીવાર એક રૂમના દ્રશ્યમાં ભૌતિક વસ્તુઓની સ્થિતિ અન્ય રૂમમાં "વહેતી" માં પરિણમી હતી.

વધુમાં, અમે ભૌતિક વિશ્વના ઇતિહાસને સંગ્રહિત કરવા માટે ભૌતિક દ્રશ્યોનો ઉપયોગ કરી શકાય છે કે કેમ તે અંગે કેટલાક સંશોધન કર્યા. એટલે કે, શરતી રીતે, દરેક રૂમમાં એક દ્રશ્ય નહીં, પરંતુ 30 દ્રશ્યો ફાળવો, અને તેમાંથી એક ચક્રીય બફર બનાવો, જેમાં વાર્તા સંગ્રહિત કરી શકાય. સામાન્ય રીતે, વિકલ્પ કામ કરતો હોવાનું બહાર આવ્યું છે, પરંતુ અમે તેનો અમલ કર્યો નથી: તે ઉત્પાદકતામાં કોઈ ઉન્મત્ત વધારો દર્શાવતો નથી, પરંતુ તેના બદલે જોખમી ફેરફારો જરૂરી છે. આટલા બધા દ્રશ્યો સાથે લાંબા સમય સુધી કામ કરતી વખતે સર્વર કેવું વર્તન કરશે તેની આગાહી કરવી મુશ્કેલ હતું. તેથી, અમે નિયમનું પાલન કર્યું: "જો તે તૂટેલું નથી, તો તેને ઠીક કરશો નહીં».

સોર્સ: www.habr.com