കഴിഞ്ഞ രണ്ടാഴ്ചയായി ഞാൻ എന്റെ ഗെയിമിനായി ഓൺലൈൻ എഞ്ചിനിൽ പ്രവർത്തിക്കുകയാണ്. ഇതിന് മുമ്പ്, ഗെയിമുകളിലെ നെറ്റ്‌വർക്കിംഗിനെക്കുറിച്ച് എനിക്ക് ഒന്നും അറിയില്ലായിരുന്നു, അതിനാൽ ഞാൻ ധാരാളം ലേഖനങ്ങൾ വായിക്കുകയും എല്ലാ ആശയങ്ങളും മനസിലാക്കാനും എന്റെ സ്വന്തം നെറ്റ്വർക്കിംഗ് എഞ്ചിൻ എഴുതാനും ധാരാളം പരീക്ഷണങ്ങൾ നടത്തുകയും ചെയ്തു.
ഈ ഗൈഡിൽ, നിങ്ങളുടെ സ്വന്തം ഗെയിം എഞ്ചിൻ എഴുതുന്നതിന് മുമ്പ് നിങ്ങൾ പഠിക്കേണ്ട വിവിധ ആശയങ്ങളും അവ പഠിക്കാനുള്ള മികച്ച ഉറവിടങ്ങളും ലേഖനങ്ങളും നിങ്ങളുമായി പങ്കിടാൻ ഞാൻ ആഗ്രഹിക്കുന്നു.
പൊതുവേ, രണ്ട് പ്രധാന തരം നെറ്റ്വർക്ക് ആർക്കിടെക്ചറുകൾ ഉണ്ട്: പിയർ-ടു-പിയർ, ക്ലയന്റ്-സെർവർ. ഒരു പിയർ-ടു-പിയർ (p2p) ആർക്കിടെക്ചറിൽ, കണക്റ്റുചെയ്‌തിരിക്കുന്ന ഏതെങ്കിലും ജോഡി കളിക്കാർക്കിടയിൽ ഡാറ്റ കൈമാറ്റം ചെയ്യപ്പെടുന്നു, അതേസമയം ഒരു ക്ലയന്റ്-സെർവർ ആർക്കിടെക്ചറിൽ, കളിക്കാരും സെർവറും തമ്മിൽ മാത്രമേ ഡാറ്റ കൈമാറൂ.
ചില ഗെയിമുകളിൽ പിയർ-ടു-പിയർ ആർക്കിടെക്ചർ ഇപ്പോഴും ഉപയോഗിക്കുന്നുണ്ടെങ്കിലും, ക്ലയന്റ്-സെർവറാണ് സ്റ്റാൻഡേർഡ്: ഇത് നടപ്പിലാക്കാൻ എളുപ്പമാണ്, ഒരു ചെറിയ ചാനൽ വീതി ആവശ്യമാണ്, കൂടാതെ തട്ടിപ്പിൽ നിന്ന് പരിരക്ഷിക്കുന്നത് എളുപ്പമാക്കുന്നു. അതിനാൽ, ഈ ട്യൂട്ടോറിയലിൽ ഞങ്ങൾ ക്ലയന്റ്-സെർവർ ആർക്കിടെക്ചറിൽ ശ്രദ്ധ കേന്ദ്രീകരിക്കും.
പ്രത്യേകിച്ചും, സ്വേച്ഛാധിപത്യ സെർവറുകളിൽ ഞങ്ങൾക്ക് ഏറ്റവും താൽപ്പര്യമുണ്ട്: അത്തരം സിസ്റ്റങ്ങളിൽ, സെർവർ എല്ലായ്പ്പോഴും ശരിയാണ്. ഉദാഹരണത്തിന്, ഒരു കളിക്കാരൻ താൻ കോർഡിനേറ്റുകളിലാണെന്ന് കരുതുന്നുണ്ടെങ്കിൽ (10, 5), സെർവർ അവനോട് (5, 3) ആണെന്ന് പറയുകയാണെങ്കിൽ, ക്ലയന്റ് അതിന്റെ സ്ഥാനം സെർവർ റിപ്പോർട്ട് ചെയ്ത സ്ഥാനം ഉപയോഗിച്ച് മാറ്റിസ്ഥാപിക്കണം, വൈസ് അല്ല തിരിച്ചും. ആധികാരിക സെർവറുകൾ ഉപയോഗിക്കുന്നത് തട്ടിപ്പുകാരെ തിരിച്ചറിയുന്നത് എളുപ്പമാക്കുന്നു.
നെറ്റ്വർക്ക് ഗെയിമിംഗ് സിസ്റ്റങ്ങൾക്ക് മൂന്ന് പ്രധാന ഘടകങ്ങളുണ്ട്:
- ട്രാൻസ്പോർട്ട് പ്രോട്ടോക്കോൾ: ക്ലയന്റിനും സെർവറിനും ഇടയിൽ ഡാറ്റ എങ്ങനെയാണ് കൈമാറുന്നത്.
- ആപ്ലിക്കേഷൻ പ്രോട്ടോക്കോൾ: ക്ലയന്റുകളിൽ നിന്ന് സെർവറിലേക്കും സെർവറിൽ നിന്ന് ക്ലയന്റുകളിലേക്കും ഏത് ഫോർമാറ്റിലാണ് കൈമാറുന്നത്.
- ആപ്ലിക്കേഷൻ ലോജിക്: ക്ലയന്റുകളുടെയും സെർവറിന്റെയും അവസ്ഥ അപ്ഡേറ്റ് ചെയ്യുന്നതിന് കൈമാറിയ ഡാറ്റ എങ്ങനെ ഉപയോഗിക്കുന്നു.
ഓരോ ഭാഗത്തിന്റെയും പങ്കും അവയുമായി ബന്ധപ്പെട്ട വെല്ലുവിളികളും മനസ്സിലാക്കേണ്ടത് വളരെ പ്രധാനമാണ്.
ഗതാഗത പ്രോട്ടോക്കോൾ
സെർവറിനും ക്ലയന്റിനുമിടയിൽ ഡാറ്റ ട്രാൻസ്പോർട്ട് ചെയ്യുന്നതിനുള്ള ഒരു പ്രോട്ടോക്കോൾ തിരഞ്ഞെടുക്കുക എന്നതാണ് ആദ്യപടി. ഇതിനായി രണ്ട് ഇന്റർനെറ്റ് പ്രോട്ടോക്കോളുകൾ ഉണ്ട്: и . എന്നാൽ അവയിലൊന്നിനെ അടിസ്ഥാനമാക്കി നിങ്ങൾക്ക് സ്വന്തമായി ട്രാൻസ്പോർട്ട് പ്രോട്ടോക്കോൾ സൃഷ്ടിക്കാം അല്ലെങ്കിൽ അവ ഉപയോഗിക്കുന്ന ഒരു ലൈബ്രറി ഉപയോഗിക്കാം.
TCP, UDP എന്നിവയുടെ താരതമ്യം
ടിസിപിയും യുഡിപിയും അടിസ്ഥാനമാക്കിയുള്ളതാണ് . ഒരു സ്രോതസ്സിൽ നിന്ന് ഒരു സ്വീകർത്താവിലേക്ക് ഒരു പാക്കറ്റ് കൈമാറാൻ IP അനുവദിക്കുന്നു, എന്നാൽ അയച്ച പാക്കറ്റ് എത്രയും വേഗം സ്വീകർത്താവിൽ എത്തുമെന്നും അത് ഒരിക്കലെങ്കിലും എത്തുമെന്നും പാക്കറ്റുകളുടെ ക്രമം കൃത്യമായി എത്തുമെന്നും ഉറപ്പുനൽകുന്നില്ല. ഓർഡർ. മാത്രമല്ല, ഒരു പാക്കറ്റിന് മൂല്യം നൽകുന്ന പരിമിതമായ ഡാറ്റ മാത്രമേ ഉൾക്കൊള്ളാൻ കഴിയൂ .
UDP എന്നത് IP-യുടെ മുകളിലുള്ള ഒരു നേർത്ത പാളി മാത്രമാണ്. അതുകൊണ്ട് തന്നെ അതിന് പരിമിതികളുണ്ട്. വിപരീതമായി, ടിസിപിക്ക് നിരവധി സവിശേഷതകൾ ഉണ്ട്. പിശക് പരിശോധിക്കുന്ന രണ്ട് നോഡുകൾക്കിടയിൽ ഇത് വിശ്വസനീയവും ക്രമാനുഗതവുമായ കണക്ഷൻ നൽകുന്നു. അതിനാൽ, ടിസിപി വളരെ സൗകര്യപ്രദവും മറ്റ് പല പ്രോട്ടോക്കോളുകളിലും ഉപയോഗിക്കുന്നു, ഉദാ. , и . എന്നാൽ ഈ സവിശേഷതകളെല്ലാം ഒരു വിലയിൽ വരുന്നു: .
എന്തുകൊണ്ടാണ് ഈ ഫംഗ്‌ഷനുകൾ ലേറ്റൻസിക്ക് കാരണമാകുന്നത് എന്ന് മനസിലാക്കാൻ, TCP എങ്ങനെയാണ് പ്രവർത്തിക്കുന്നത് എന്ന് നമ്മൾ മനസ്സിലാക്കേണ്ടതുണ്ട്. ഒരു അയക്കുന്ന നോഡ് സ്വീകരിക്കുന്ന നോഡിലേക്ക് ഒരു പാക്കറ്റ് കൈമാറുമ്പോൾ, അത് ഒരു അംഗീകാരം (ACK) ലഭിക്കുമെന്ന് പ്രതീക്ഷിക്കുന്നു. ഒരു നിശ്ചിത സമയത്തിന് ശേഷം അത് ലഭിച്ചില്ലെങ്കിൽ (പാക്കറ്റ് അല്ലെങ്കിൽ അംഗീകാരം നഷ്ടപ്പെട്ടതിനാൽ, അല്ലെങ്കിൽ മറ്റേതെങ്കിലും കാരണത്താൽ), അത് പാക്കറ്റ് വീണ്ടും അയയ്ക്കുന്നു. കൂടാതെ, പാക്കറ്റുകൾ ശരിയായ ക്രമത്തിലാണ് ലഭിക്കുന്നതെന്ന് ടിസിപി ഉറപ്പ് നൽകുന്നു, അതിനാൽ നഷ്ടപ്പെട്ട പാക്കറ്റ് ലഭിക്കുന്നതുവരെ, മറ്റ് എല്ലാ പാക്കറ്റുകളും സ്വീകരിക്കുന്ന ഹോസ്റ്റിന് ഇതിനകം ലഭിച്ചിട്ടുണ്ടെങ്കിലും അവ പ്രോസസ്സ് ചെയ്യാൻ കഴിയില്ല.
എന്നാൽ നിങ്ങൾക്ക് ഊഹിക്കാൻ കഴിയുന്നത് പോലെ, മൾട്ടിപ്ലെയർ ഗെയിമുകളിലെ ലേറ്റൻസി വളരെ പ്രധാനമാണ്, പ്രത്യേകിച്ച് FPS പോലുള്ള ആക്ഷൻ-പാക്ക് വിഭാഗങ്ങളിൽ. അതുകൊണ്ടാണ് പല ഗെയിമുകളും അവരുടെ സ്വന്തം പ്രോട്ടോക്കോൾ ഉപയോഗിച്ച് UDP ഉപയോഗിക്കുന്നത്.
വിവിധ കാരണങ്ങളാൽ ഒരു നേറ്റീവ് യുഡിപി അടിസ്ഥാനമാക്കിയുള്ള പ്രോട്ടോക്കോൾ ടിസിപിയേക്കാൾ കാര്യക്ഷമമായിരിക്കും. ഉദാഹരണത്തിന്, ഇതിന് ചില പാക്കറ്റുകൾ വിശ്വസനീയവും മറ്റുള്ളവ വിശ്വസനീയമല്ലാത്തതുമായി അടയാളപ്പെടുത്താൻ കഴിയും. അതിനാൽ, അവിശ്വസനീയമായ പാക്കറ്റ് സ്വീകർത്താവിലേക്ക് എത്തുന്നുണ്ടോ എന്നത് പ്രശ്നമല്ല. അല്ലെങ്കിൽ ഇതിന് ഒന്നിലധികം ഡാറ്റ സ്ട്രീമുകൾ പ്രോസസ്സ് ചെയ്യാൻ കഴിയും, അങ്ങനെ ഒരു സ്ട്രീമിലെ നഷ്ടപ്പെട്ട പാക്കറ്റ് ശേഷിക്കുന്ന സ്ട്രീമുകളുടെ വേഗത കുറയ്ക്കില്ല. ഉദാഹരണത്തിന്, പ്ലെയർ ഇൻപുട്ടിനായി ഒരു ത്രെഡും ചാറ്റ് സന്ദേശങ്ങൾക്കായി മറ്റൊരു ത്രെഡും ഉണ്ടായിരിക്കാം. അടിയന്തിരമല്ലാത്ത ഒരു ചാറ്റ് സന്ദേശം നഷ്ടപ്പെട്ടാൽ, അത് അടിയന്തിരമായ ഇൻപുട്ടിനെ മന്ദഗതിയിലാക്കില്ല. അല്ലെങ്കിൽ ഒരു വീഡിയോ ഗെയിം പരിതസ്ഥിതിയിൽ കൂടുതൽ കാര്യക്ഷമമായി പ്രവർത്തിക്കുന്നതിന് ടിസിപിയിൽ നിന്ന് വ്യത്യസ്തമായി ഒരു പ്രൊപ്രൈറ്ററി പ്രോട്ടോക്കോൾ വിശ്വാസ്യത നടപ്പിലാക്കിയേക്കാം.
അതിനാൽ, TCP ഇത്രയധികം ചൂഷണം ചെയ്യുകയാണെങ്കിൽ, UDP അടിസ്ഥാനമാക്കി ഞങ്ങൾ ഞങ്ങളുടെ സ്വന്തം ഗതാഗത പ്രോട്ടോക്കോൾ സൃഷ്ടിക്കുമോ?
ഇത് കുറച്ചുകൂടി സങ്കീർണ്ണമാണ്. ഗെയിമിംഗ് നെറ്റ്വർക്ക് സിസ്റ്റങ്ങൾക്ക് ടിസിപി ഏറെക്കുറെ ഉപയുക്തമാണെങ്കിലും, നിങ്ങളുടെ നിർദ്ദിഷ്ട ഗെയിമിന് ഇത് നന്നായി പ്രവർത്തിക്കാനും നിങ്ങളുടെ വിലയേറിയ സമയം ലാഭിക്കാനും കഴിയും. ഉദാഹരണത്തിന്, ഒരു ടേൺ അധിഷ്‌ഠിത ഗെയിമിനോ അല്ലെങ്കിൽ ലാൻ നെറ്റ്‌വർക്കുകളിൽ മാത്രം കളിക്കാനാകുന്ന ഗെയിമിനോ ലേറ്റൻസി ഒരു പ്രശ്‌നമായിരിക്കില്ല, അവിടെ ലേറ്റൻസിയും പാക്കറ്റ് നഷ്‌ടവും ഇൻറർനെറ്റിനേക്കാൾ വളരെ കുറവാണ്.
World of Warcraft, Minecraft, Terraria എന്നിവയുൾപ്പെടെ നിരവധി വിജയകരമായ ഗെയിമുകൾ TCP ഉപയോഗിക്കുന്നു. എന്നിരുന്നാലും, മിക്ക FPS-കളും അവരുടേതായ UDP-അധിഷ്‌ഠിത പ്രോട്ടോക്കോളുകൾ ഉപയോഗിക്കുന്നു, അതിനാൽ ഞങ്ങൾ അവയെക്കുറിച്ച് കൂടുതൽ സംസാരിക്കും.
നിങ്ങൾ TCP ഉപയോഗിക്കാൻ തീരുമാനിക്കുകയാണെങ്കിൽ, അത് പ്രവർത്തനരഹിതമാണെന്ന് ഉറപ്പാക്കുക , കാരണം ഇത് അയയ്‌ക്കുന്നതിന് മുമ്പ് പാക്കറ്റുകളെ ബഫർ ചെയ്യുന്നു, അതിനർത്ഥം ഇത് ലേറ്റൻസി വർദ്ധിപ്പിക്കുന്നു എന്നാണ്.
മൾട്ടിപ്ലെയർ ഗെയിമുകളുടെ പശ്ചാത്തലത്തിൽ യുഡിപിയും ടിസിപിയും തമ്മിലുള്ള വ്യത്യാസങ്ങളെക്കുറിച്ച് കൂടുതലറിയാൻ, നിങ്ങൾക്ക് ഗ്ലെൻ ഫീഡ്‌ലറുടെ ലേഖനം വായിക്കാം .
സ്വന്തം പ്രോട്ടോക്കോൾ
അതിനാൽ നിങ്ങളുടെ സ്വന്തം ട്രാൻസ്പോർട്ട് പ്രോട്ടോക്കോൾ സൃഷ്ടിക്കാൻ നിങ്ങൾ ആഗ്രഹിക്കുന്നു, എന്നാൽ എവിടെ തുടങ്ങണമെന്ന് അറിയില്ലേ? ഗ്ലെൻ ഫീഡ്‌ലർ ഇതിനെക്കുറിച്ച് രണ്ട് അതിശയകരമായ ലേഖനങ്ങൾ എഴുതിയതിനാൽ നിങ്ങൾ ഭാഗ്യവാനാണ്. അവയിൽ ധാരാളം ബുദ്ധിപരമായ ചിന്തകൾ നിങ്ങൾ കണ്ടെത്തും.
ആദ്യ ലേഖനം 2008, രണ്ടാമത്തേതിനേക്കാൾ എളുപ്പമാണ്, 2016. നിങ്ങൾ പഴയതിൽ നിന്ന് ആരംഭിക്കാൻ ഞാൻ ശുപാർശ ചെയ്യുന്നു.
UDP അടിസ്ഥാനമാക്കിയുള്ള ഒരു ഇഷ്‌ടാനുസൃത പ്രോട്ടോക്കോൾ ഉപയോഗിക്കുന്നതിന്റെ ഒരു വലിയ വക്താവാണ് ഗ്ലെൻ ഫീഡ്‌ലർ എന്നത് ശ്രദ്ധിക്കുക. അദ്ദേഹത്തിന്റെ ലേഖനങ്ങൾ വായിച്ചതിനുശേഷം, വീഡിയോ ഗെയിമുകളിൽ ടിസിപിക്ക് ഗുരുതരമായ പോരായ്മകളുണ്ടെന്ന അദ്ദേഹത്തിന്റെ അഭിപ്രായം നിങ്ങൾ സ്വീകരിക്കും, നിങ്ങളുടെ സ്വന്തം പ്രോട്ടോക്കോൾ നടപ്പിലാക്കാൻ നിങ്ങൾ ആഗ്രഹിക്കും.
എന്നാൽ നിങ്ങൾ നെറ്റ്‌വർക്കിംഗിൽ പുതിയ ആളാണെങ്കിൽ, സ്വയം ഒരു ഉപകാരം ചെയ്ത് TCP അല്ലെങ്കിൽ ലൈബ്രറി ഉപയോഗിക്കുക. നിങ്ങളുടെ സ്വന്തം ട്രാൻസ്പോർട്ട് പ്രോട്ടോക്കോൾ വിജയകരമായി നടപ്പിലാക്കാൻ, നിങ്ങൾ മുമ്പ് ഒരുപാട് പഠിക്കേണ്ടതുണ്ട്.
നെറ്റ്വർക്ക് ലൈബ്രറികൾ
നിങ്ങൾക്ക് ടിസിപിയേക്കാൾ കൂടുതൽ കാര്യക്ഷമമായ എന്തെങ്കിലും ആവശ്യമുണ്ടെങ്കിൽ, എന്നാൽ നിങ്ങളുടെ സ്വന്തം പ്രോട്ടോക്കോൾ നടപ്പിലാക്കുന്നതിലും കൂടുതൽ വിശദാംശങ്ങളിലേക്ക് കടക്കേണ്ട ആവശ്യമില്ലെങ്കിൽ, നിങ്ങൾക്ക് ഒരു നെറ്റ്വർക്കിംഗ് ലൈബ്രറി ഉപയോഗിക്കാം. അവയിൽ ധാരാളം ഉണ്ട്:
- ഗ്ലെൻ ഫീൽഡർ
- , ഇനി പിന്തുണയ്ക്കില്ല, പക്ഷേ അതിന്റെ ഒരു നാൽക്കവല അത് ഇപ്പോഴും സജീവമാണെന്ന് തോന്നുന്നു.
- മൾട്ടിപ്ലെയർ FPS-നായി സൃഷ്ടിച്ച ഒരു ലൈബ്രറിയാണ്
- വാൽവ്
ഞാൻ അവയെല്ലാം പരീക്ഷിച്ചിട്ടില്ല, പക്ഷേ ഉപയോഗിക്കാൻ എളുപ്പവും വിശ്വസനീയവുമായതിനാൽ ഞാൻ ENet തിരഞ്ഞെടുക്കുന്നു. കൂടാതെ, ഇതിന് വ്യക്തമായ ഡോക്യുമെന്റേഷനും തുടക്കക്കാർക്കുള്ള ട്യൂട്ടോറിയലും ഉണ്ട്.
ഗതാഗത പ്രോട്ടോക്കോൾ: ഉപസംഹാരം
ചുരുക്കത്തിൽ: രണ്ട് പ്രധാന ഗതാഗത പ്രോട്ടോക്കോളുകൾ ഉണ്ട്: TCP, UDP. ടിസിപിക്ക് ധാരാളം ഉപയോഗപ്രദമായ സവിശേഷതകൾ ഉണ്ട്: വിശ്വാസ്യത, പാക്കറ്റ് ഓർഡർ സംരക്ഷണം, പിശക് കണ്ടെത്തൽ. യു‌ഡി‌പിക്ക് ഇതെല്ലാം ഇല്ല, പക്ഷേ ടിസിപി അതിന്റെ സ്വഭാവമനുസരിച്ച് ലേറ്റൻസി വർദ്ധിപ്പിച്ചു, ഇത് ചില ഗെയിമുകൾക്ക് അസ്വീകാര്യമാണ്. അതായത്, കുറഞ്ഞ ലേറ്റൻസി ഉറപ്പാക്കാൻ, നിങ്ങൾക്ക് UDP അടിസ്ഥാനമാക്കി നിങ്ങളുടെ സ്വന്തം പ്രോട്ടോക്കോൾ സൃഷ്ടിക്കാം അല്ലെങ്കിൽ UDP-യിൽ ഒരു ട്രാൻസ്പോർട്ട് പ്രോട്ടോക്കോൾ നടപ്പിലാക്കുകയും മൾട്ടിപ്ലെയർ വീഡിയോ ഗെയിമുകൾക്ക് അനുയോജ്യമായ ഒരു ലൈബ്രറി ഉപയോഗിക്കുകയും ചെയ്യാം.
TCP, UDP, ലൈബ്രറി എന്നിവയ്ക്കിടയിലുള്ള തിരഞ്ഞെടുപ്പ് പല ഘടകങ്ങളെ ആശ്രയിച്ചിരിക്കുന്നു. ആദ്യം, ഗെയിമിന്റെ ആവശ്യങ്ങളിൽ നിന്ന്: ഇതിന് കുറഞ്ഞ ലേറ്റൻസി ആവശ്യമുണ്ടോ? രണ്ടാമതായി, ആപ്ലിക്കേഷൻ പ്രോട്ടോക്കോൾ ആവശ്യകതകളിൽ നിന്ന്: ഇതിന് വിശ്വസനീയമായ ഒരു പ്രോട്ടോക്കോൾ ആവശ്യമുണ്ടോ? അടുത്ത ഭാഗത്ത് നമ്മൾ കാണുന്നത് പോലെ, വിശ്വസനീയമല്ലാത്ത ഒരു പ്രോട്ടോക്കോൾ തികച്ചും അനുയോജ്യമായ ഒരു ആപ്ലിക്കേഷൻ പ്രോട്ടോക്കോൾ സൃഷ്ടിക്കാൻ സാധിക്കും. അവസാനമായി, നെറ്റ്വർക്ക് എഞ്ചിൻ ഡെവലപ്പറുടെ അനുഭവവും നിങ്ങൾ കണക്കിലെടുക്കേണ്ടതുണ്ട്.
എനിക്ക് രണ്ട് ഉപദേശങ്ങളുണ്ട്:
- ട്രാൻസ്പോർട്ട് പ്രോട്ടോക്കോൾ ആപ്ലിക്കേഷന്റെ ബാക്കി ഭാഗങ്ങളിൽ നിന്ന് പരമാവധി സംഗ്രഹിക്കുക, അതുവഴി എല്ലാ കോഡുകളും മാറ്റിയെഴുതാതെ എളുപ്പത്തിൽ മാറ്റിസ്ഥാപിക്കാനാകും.
- അമിതമായി ഒപ്റ്റിമൈസ് ചെയ്യരുത്. നിങ്ങൾ ഒരു നെറ്റ്വർക്കിംഗ് വിദഗ്‌ദ്ധനല്ലെങ്കിൽ നിങ്ങൾക്ക് ഒരു ഇഷ്‌ടാനുസൃത UDP-അധിഷ്‌ഠിത ട്രാൻസ്പോർട്ട് പ്രോട്ടോക്കോൾ ആവശ്യമുണ്ടോ എന്ന് ഉറപ്പില്ലെങ്കിൽ, നിങ്ങൾക്ക് TCP അല്ലെങ്കിൽ വിശ്വാസ്യത നൽകുന്ന ഒരു ലൈബ്രറി ഉപയോഗിച്ച് ആരംഭിക്കാം, തുടർന്ന് പ്രകടനം പരിശോധിച്ച് അളക്കുക. പ്രശ്നങ്ങൾ ഉണ്ടാകുകയും കാരണം ഗതാഗത പ്രോട്ടോക്കോൾ ആണെന്ന് നിങ്ങൾക്ക് ഉറപ്പുണ്ടെങ്കിൽ, നിങ്ങളുടെ സ്വന്തം ട്രാൻസ്പോർട്ട് പ്രോട്ടോക്കോൾ സൃഷ്ടിക്കാനുള്ള സമയമായിരിക്കാം.
ഈ ഭാഗത്തിന്റെ അവസാനം, നിങ്ങൾ വായിക്കാൻ ഞാൻ ശുപാർശ ചെയ്യുന്നു ബ്രയാൻ ഹുക്ക് എഴുതിയത്, ഇവിടെ ചർച്ച ചെയ്ത പല വിഷയങ്ങളും ഉൾക്കൊള്ളുന്നു.
ആപ്ലിക്കേഷൻ പ്രോട്ടോക്കോൾ
ഇപ്പോൾ നമുക്ക് ക്ലയന്റുകളും സെർവറും തമ്മിൽ ഡാറ്റ കൈമാറാൻ കഴിയും, ഏത് ഡാറ്റയാണ് കൈമാറേണ്ടതെന്നും ഏത് ഫോർമാറ്റിലാണെന്നും ഞങ്ങൾ തീരുമാനിക്കേണ്ടതുണ്ട്.
ക്ലയന്റുകൾ സെർവറിലേക്ക് ഇൻപുട്ടോ പ്രവർത്തനങ്ങളോ അയയ്ക്കുന്നു എന്നതാണ് ക്ലാസിക് സ്കീം, സെർവർ നിലവിലെ ഗെയിം അവസ്ഥ ക്ലയന്റുകൾക്ക് അയയ്ക്കുന്നു.
സെർവർ അയയ്‌ക്കുന്നത് പൂർണ്ണമായ അവസ്ഥയല്ല, പ്ലെയറിന് സമീപം സ്ഥിതിചെയ്യുന്ന എന്റിറ്റികളുള്ള ഒരു ഫിൽട്ടർ ചെയ്ത അവസ്ഥയാണ്. മൂന്ന് കാരണങ്ങളാൽ അവൻ ഇത് ചെയ്യുന്നു. ഒന്നാമതായി, പൂർണ്ണമായ അവസ്ഥ ഉയർന്ന ആവൃത്തിയിൽ സംപ്രേഷണം ചെയ്യാൻ കഴിയാത്തത്ര വലുതായിരിക്കാം. രണ്ടാമതായി, ക്ലയന്റുകൾക്ക് പ്രധാനമായും വിഷ്വൽ, ഓഡിയോ ഡാറ്റയിൽ താൽപ്പര്യമുണ്ട്, കാരണം ഗെയിം ലോജിക്കിന്റെ ഭൂരിഭാഗവും ഗെയിം സെർവറിൽ അനുകരിക്കപ്പെടുന്നു. മൂന്നാമതായി, ചില ഗെയിമുകളിൽ കളിക്കാരന് ചില ഡാറ്റ അറിയേണ്ടതില്ല, ഉദാഹരണത്തിന്, മാപ്പിന്റെ മറുവശത്തുള്ള ശത്രുവിന്റെ സ്ഥാനം, അല്ലാത്തപക്ഷം അയാൾക്ക് പാക്കറ്റുകൾ മണക്കാനും അവനെ കൊല്ലാൻ എവിടേക്ക് നീങ്ങണമെന്ന് കൃത്യമായി അറിയാനും കഴിയും.
സീരിയലൈസേഷൻ
നമ്മൾ അയയ്‌ക്കാൻ ആഗ്രഹിക്കുന്ന ഡാറ്റ (ഇൻപുട്ട് അല്ലെങ്കിൽ ഗെയിം സ്റ്റേറ്റ്) പ്രക്ഷേപണത്തിന് അനുയോജ്യമായ ഫോർമാറ്റിലേക്ക് പരിവർത്തനം ചെയ്യുക എന്നതാണ് ആദ്യപടി. ഈ പ്രക്രിയയെ വിളിക്കുന്നു .
JSON അല്ലെങ്കിൽ XML പോലുള്ള മനുഷ്യർക്ക് വായിക്കാൻ കഴിയുന്ന ഒരു ഫോർമാറ്റ് ഉപയോഗിക്കുക എന്നതാണ് ഉടനടി മനസ്സിൽ വരുന്ന ചിന്ത. എന്നാൽ ഇത് പൂർണ്ണമായും ഫലപ്രദമല്ലാത്തതും ചാനലിന്റെ ഭൂരിഭാഗവും പാഴാക്കുകയും ചെയ്യും.
പകരം ബൈനറി ഫോർമാറ്റ് ഉപയോഗിക്കാൻ ശുപാർശ ചെയ്യുന്നു, അത് കൂടുതൽ ഒതുക്കമുള്ളതാണ്. അതായത്, പാക്കറ്റുകളിൽ കുറച്ച് ബൈറ്റുകൾ മാത്രമേ അടങ്ങിയിട്ടുള്ളൂ. ഇവിടെ പരിഗണിക്കേണ്ട ഒരു പ്രശ്നമുണ്ട് , വ്യത്യസ്ത കമ്പ്യൂട്ടറുകളിൽ ഇത് വ്യത്യാസപ്പെട്ടിരിക്കാം.
ഡാറ്റ സീരിയലൈസ് ചെയ്യുന്നതിന്, നിങ്ങൾക്ക് ഒരു ലൈബ്രറി ഉപയോഗിക്കാം, ഉദാഹരണത്തിന്:
- ഗൂഗിൾ
- സാൻഡ്സ്റ്റോം കമ്പനി
- ഷെയ്ൻ ഗ്രാന്റും റാൻഡോൾഫ് വൂർഹീസും
ലൈബ്രറി പോർട്ടബിൾ ആർക്കൈവുകൾ സൃഷ്‌ടിക്കുന്നുവെന്നും അന്തസ്സിനെക്കുറിച്ച് ശ്രദ്ധിക്കുന്നുണ്ടെന്നും ഉറപ്പാക്കുക.
ഒരു ബദൽ പരിഹാരം അത് സ്വയം നടപ്പിലാക്കുക എന്നതാണ്; ഇത് പ്രത്യേകിച്ച് ബുദ്ധിമുട്ടുള്ള കാര്യമല്ല, പ്രത്യേകിച്ചും നിങ്ങളുടെ കോഡിന് ഒരു ഡാറ്റാ കേന്ദ്രീകൃത സമീപനം ഉപയോഗിക്കുകയാണെങ്കിൽ. കൂടാതെ, ലൈബ്രറി ഉപയോഗിക്കുമ്പോൾ എല്ലായ്പ്പോഴും സാധ്യമല്ലാത്ത ഒപ്റ്റിമൈസേഷനുകൾ നടത്താൻ ഇത് നിങ്ങളെ അനുവദിക്കും.
സീരിയലൈസേഷനെ കുറിച്ച് ഗ്ലെൻ ഫീഡ്‌ലർ രണ്ട് ലേഖനങ്ങൾ എഴുതി: и .
കംപ്രഷൻ
ക്ലയന്റുകൾക്കും സെർവറിനുമിടയിൽ കൈമാറ്റം ചെയ്യപ്പെടുന്ന ഡാറ്റയുടെ അളവ് ചാനലിന്റെ ബാൻഡ്‌വിഡ്ത്ത് പരിമിതപ്പെടുത്തിയിരിക്കുന്നു. ഓരോ സ്നാപ്പ്ഷോട്ടിലും കൂടുതൽ ഡാറ്റ കൈമാറാനോ അപ്ഡേറ്റ് ആവൃത്തി കൂട്ടാനോ ചാനൽ ആവശ്യകതകൾ കുറയ്ക്കാനോ ഡാറ്റ കംപ്രഷൻ നിങ്ങളെ അനുവദിക്കും.
ബിറ്റ് പാക്കേജിംഗ്
ആദ്യത്തെ സാങ്കേതികത ബിറ്റ് പാക്കിംഗ് ആണ്. ആവശ്യമുള്ള മൂല്യം വിവരിക്കുന്നതിന് ആവശ്യമായ ബിറ്റുകളുടെ എണ്ണം കൃത്യമായി ഉപയോഗിക്കുന്നത് ഇതിൽ അടങ്ങിയിരിക്കുന്നു. ഉദാഹരണത്തിന്, നിങ്ങൾക്ക് 16 വ്യത്യസ്ത മൂല്യങ്ങളുള്ള ഒരു enum ഉണ്ടെങ്കിൽ, ഒരു മുഴുവൻ ബൈറ്റ് (8 ബിറ്റുകൾ) എന്നതിനുപകരം, നിങ്ങൾക്ക് വെറും 4 ബിറ്റുകൾ ഉപയോഗിക്കാം.
ലേഖനത്തിന്റെ രണ്ടാം ഭാഗത്തിൽ ഇത് എങ്ങനെ നടപ്പിലാക്കാമെന്ന് ഗ്ലെൻ ഫീൽഡർ വിശദീകരിക്കുന്നു .
സാമ്പിളിനൊപ്പം ബിറ്റ് പാക്കിംഗ് നന്നായി പ്രവർത്തിക്കുന്നു, അത് അടുത്ത വിഭാഗത്തിന്റെ വിഷയമായിരിക്കും.
സാമ്പിളിംഗ്
ഒരു മൂല്യം എൻകോഡ് ചെയ്യുന്നതിന് സാധ്യമായ മൂല്യങ്ങളുടെ ഒരു ഉപവിഭാഗം മാത്രം ഉപയോഗിക്കുന്ന ഒരു നഷ്ടമായ കംപ്രഷൻ സാങ്കേതികതയാണ്. ഫ്ലോട്ടിംഗ് പോയിന്റ് നമ്പറുകൾ റൗണ്ട് ചെയ്യുക എന്നതാണ് ഡിസ്ക്രിറ്റൈസേഷൻ നടപ്പിലാക്കുന്നതിനുള്ള ഏറ്റവും എളുപ്പ മാർഗം.
ഗ്ലെൻ ഫീഡ്‌ലർ (വീണ്ടും!) തന്റെ ലേഖനത്തിൽ സാമ്പിൾ എങ്ങനെ പ്രായോഗികമാക്കാമെന്ന് കാണിക്കുന്നു .
കംപ്രഷൻ അൽഗോരിതങ്ങൾ
അടുത്ത സാങ്കേതികത നഷ്ടരഹിതമായ കംപ്രഷൻ അൽഗോരിതങ്ങളായിരിക്കും.
എന്റെ അഭിപ്രായത്തിൽ, നിങ്ങൾ അറിഞ്ഞിരിക്കേണ്ട ഏറ്റവും രസകരമായ മൂന്ന് അൽഗോരിതങ്ങൾ ഇതാ:
- പ്രീ-കമ്പ്യൂട്ടഡ് കോഡ് ഉപയോഗിച്ച്, അത് വളരെ വേഗമേറിയതും നല്ല ഫലങ്ങൾ ഉണ്ടാക്കാൻ കഴിയുന്നതുമാണ്. Quake3 നെറ്റ്വർക്കിംഗ് എഞ്ചിനിലെ പാക്കറ്റുകൾ കംപ്രസ്സുചെയ്യാൻ ഇത് ഉപയോഗിച്ചു.
- ഡാറ്റയുടെ അളവ് ഒരിക്കലും വർദ്ധിപ്പിക്കാത്ത ഒരു പൊതു-ഉദ്ദേശ്യ കംപ്രഷൻ അൽഗോരിതം ആണ്. നിങ്ങൾക്ക് എങ്ങനെ കാണാൻ കഴിയും , ഇത് വിവിധ ആപ്ലിക്കേഷനുകളിൽ ഉപയോഗിച്ചിട്ടുണ്ട്. സംസ്ഥാനങ്ങൾ അപ്ഡേറ്റ് ചെയ്യുന്നതിന് ഇത് അനാവശ്യമായേക്കാം. എന്നാൽ സെർവറിൽ നിന്ന് ക്ലയന്റുകൾക്ക് അസറ്റുകൾ, ദൈർഘ്യമേറിയ ടെക്‌സ്‌റ്റുകൾ അല്ലെങ്കിൽ ഭൂപ്രദേശം എന്നിവ അയയ്‌ക്കണമെങ്കിൽ അത് ഉപയോഗപ്രദമാകും.
- - ഇത് ഒരുപക്ഷേ ഏറ്റവും ലളിതമായ കംപ്രഷൻ അൽഗോരിതം ആണ്, എന്നാൽ ചില തരം ഡാറ്റകൾക്ക് ഇത് വളരെ ഫലപ്രദമാണ്, കൂടാതെ zlib-ന് മുമ്പുള്ള ഒരു പ്രീ-പ്രോസസ്സിംഗ് ഘട്ടമായി ഇത് ഉപയോഗിക്കാം. ടൈലുകളോ വോക്സലുകളോ അടങ്ങിയ ഭൂപ്രദേശം കംപ്രസ്സുചെയ്യുന്നതിന് ഇത് പ്രത്യേകിച്ചും അനുയോജ്യമാണ്, അതിൽ നിരവധി അടുത്തുള്ള ഘടകങ്ങൾ ആവർത്തിക്കുന്നു.
ഡെൽറ്റ കംപ്രഷൻ
അവസാനത്തെ കംപ്രഷൻ ടെക്നിക് ഡെൽറ്റ കംപ്രഷൻ ആണ്. നിലവിലെ ഗെയിം നിലയും ക്ലയന്റ് സ്വീകരിച്ച അവസാന അവസ്ഥയും തമ്മിലുള്ള വ്യത്യാസങ്ങൾ മാത്രമേ കൈമാറ്റം ചെയ്യപ്പെടുന്നുള്ളൂ എന്ന വസ്തുത ഇതിൽ അടങ്ങിയിരിക്കുന്നു.
Quake3 നെറ്റ്വർക്ക് എഞ്ചിനിലാണ് ഇത് ആദ്യമായി ഉപയോഗിച്ചത്. ഇത് എങ്ങനെ ഉപയോഗിക്കണമെന്ന് വിശദീകരിക്കുന്ന രണ്ട് ലേഖനങ്ങൾ ഇതാ:
- ബ്രയാൻ ഹുക്ക്
- ഫാബിൻ സാംഗ്ലാർസ് [ ഹബ്രെയിലെ ലേഖനങ്ങൾ, "നെറ്റ്വർക്ക് മോഡൽ" എന്ന വിഭാഗം കാണുക]
ഗ്ലെൻ ഫീഡ്‌ലറും തന്റെ ലേഖനത്തിന്റെ രണ്ടാം ഭാഗത്തിൽ ഇത് ഉപയോഗിച്ചു .
എൻക്രിപ്ഷൻ
കൂടാതെ, ക്ലയന്റിനും സെർവറിനും ഇടയിലുള്ള വിവരങ്ങളുടെ കൈമാറ്റം നിങ്ങൾ എൻക്രിപ്റ്റ് ചെയ്യേണ്ടതായി വന്നേക്കാം. ഇതിന് നിരവധി കാരണങ്ങളുണ്ട്:
- സ്വകാര്യത/രഹസ്യത: സന്ദേശങ്ങൾ സ്വീകർത്താവിന് മാത്രമേ വായിക്കാൻ കഴിയൂ, കൂടാതെ നെറ്റ്വർക്ക് മണക്കുന്ന മറ്റൊരു വ്യക്തിക്കും അവ വായിക്കാൻ കഴിയില്ല.
- പ്രാമാണീകരണം: ഒരു കളിക്കാരന്റെ വേഷം ചെയ്യാൻ ആഗ്രഹിക്കുന്ന ഒരു വ്യക്തി അവന്റെ താക്കോൽ അറിഞ്ഞിരിക്കണം.
- വഞ്ചന തടയൽ: ക്ഷുദ്ര കളിക്കാർക്ക് അവരുടെ സ്വന്തം ചീറ്റ് പാക്കേജുകൾ സൃഷ്ടിക്കുന്നത് കൂടുതൽ ബുദ്ധിമുട്ടായിരിക്കും, അവർ എൻക്രിപ്ഷൻ സ്കീം പുനർനിർമ്മിക്കുകയും കീ കണ്ടെത്തുകയും വേണം (ഓരോ കണക്ഷനിലും ഇത് മാറുന്നു).
ഇതിനായി ഒരു ലൈബ്രറി ഉപയോഗിക്കാൻ ഞാൻ ശക്തമായി ശുപാർശ ചെയ്യുന്നു. ഉപയോഗിക്കാൻ ഞാൻ നിർദ്ദേശിക്കുന്നു , കാരണം ഇത് പ്രത്യേകിച്ച് ലളിതവും മികച്ച ട്യൂട്ടോറിയലുകളുമുണ്ട്. ട്യൂട്ടോറിയൽ പ്രത്യേകിച്ചും രസകരമാണ് , ഓരോ പുതിയ കണക്ഷനും പുതിയ കീകൾ സൃഷ്ടിക്കാൻ നിങ്ങളെ അനുവദിക്കുന്നു.
ആപ്ലിക്കേഷൻ പ്രോട്ടോക്കോൾ: ഉപസംഹാരം
ഇത് ഞങ്ങളുടെ ആപ്ലിക്കേഷൻ പ്രോട്ടോക്കോൾ അവസാനിപ്പിക്കുന്നു. കംപ്രഷൻ പൂർണ്ണമായും ഓപ്‌ഷണൽ ആണെന്നും അത് ഉപയോഗിക്കാനുള്ള തീരുമാനം ഗെയിമിനെയും ആവശ്യമായ ബാൻഡ്‌വിഡ്‌ത്തും മാത്രം ആശ്രയിച്ചിരിക്കുന്നുവെന്നും ഞാൻ വിശ്വസിക്കുന്നു. എൻക്രിപ്ഷൻ, എന്റെ അഭിപ്രായത്തിൽ, നിർബന്ധമാണ്, എന്നാൽ ആദ്യ പ്രോട്ടോടൈപ്പിൽ നിങ്ങൾക്ക് ഇത് കൂടാതെ ചെയ്യാൻ കഴിയും.
ആപ്ലിക്കേഷൻ ലോജിക്
ഞങ്ങൾക്ക് ഇപ്പോൾ ക്ലയന്റിലുള്ള അവസ്ഥ അപ്ഡേറ്റ് ചെയ്യാൻ കഴിയും, പക്ഷേ ലേറ്റൻസി പ്രശ്നങ്ങൾ ഉണ്ടായേക്കാം. പ്ലെയർ, ഇൻപുട്ട് പൂർത്തിയാക്കിയ ശേഷം, ഗെയിമിന്റെ അവസ്ഥ ലോകത്തിൽ എന്ത് സ്വാധീനം ചെലുത്തിയെന്ന് കാണാൻ സെർവറിൽ നിന്ന് അപ്ഡേറ്റ് ചെയ്യുന്നതിനായി കാത്തിരിക്കേണ്ടതുണ്ട്.
മാത്രമല്ല, രണ്ട് സംസ്ഥാന അപ്‌ഡേറ്റുകൾക്കിടയിൽ, ലോകം പൂർണ്ണമായും നിശ്ചലമാണ്. സംസ്ഥാന അപ്ഡേറ്റ് നിരക്ക് കുറവാണെങ്കിൽ, ചലനങ്ങൾ വളരെ അസ്വസ്ഥമായിരിക്കും.
ഈ പ്രശ്നത്തിന്റെ ആഘാതം കുറയ്ക്കുന്നതിന് നിരവധി ടെക്നിക്കുകൾ ഉണ്ട്, അടുത്ത വിഭാഗത്തിൽ ഞാൻ അവ കവർ ചെയ്യും.
ലേറ്റൻസി സ്മൂത്തിംഗ് ടെക്നിക്കുകൾ
ഈ വിഭാഗത്തിൽ വിവരിച്ചിരിക്കുന്ന എല്ലാ സാങ്കേതികതകളും പരമ്പരയിൽ വിശദമായി ചർച്ചചെയ്യുന്നു ഗബ്രിയേൽ ഗാംബെറ്റ. ഈ മികച്ച ലേഖന പരമ്പര വായിക്കാൻ ഞാൻ വളരെ ശുപാർശ ചെയ്യുന്നു. ഈ സാങ്കേതിക വിദ്യകൾ പ്രായോഗികമായി എങ്ങനെ പ്രവർത്തിക്കുന്നുവെന്ന് കാണാൻ നിങ്ങളെ അനുവദിക്കുന്ന ഒരു സംവേദനാത്മക ഡെമോയും ഇതിൽ ഉൾപ്പെടുന്നു.
സെർവറിൽ നിന്നുള്ള പ്രതികരണത്തിനായി കാത്തിരിക്കാതെ ഇൻപുട്ട് ഫലം നേരിട്ട് പ്രയോഗിക്കുക എന്നതാണ് ആദ്യത്തെ സാങ്കേതികത. ഇത് വിളിക്കപ്പെടുന്നത് ക്ലയന്റ് സൈഡ് പ്രവചനം. എന്നിരുന്നാലും, ക്ലയന്റിന് സെർവറിൽ നിന്ന് ഒരു അപ്ഡേറ്റ് ലഭിക്കുമ്പോൾ, അതിന്റെ പ്രവചനം ശരിയാണോ എന്ന് അത് പരിശോധിക്കേണ്ടതാണ്. ഇത് അങ്ങനെയല്ലെങ്കിൽ, സെർവറിൽ നിന്ന് ലഭിച്ചതനുസരിച്ച് അയാൾ തന്റെ അവസ്ഥ മാറ്റേണ്ടതുണ്ട്, കാരണം സെർവർ സ്വേച്ഛാധിപതിയാണ്. ഭൂകമ്പത്തിലാണ് ഈ വിദ്യ ആദ്യമായി ഉപയോഗിച്ചത്. ലേഖനത്തിൽ നിങ്ങൾക്ക് ഇതിനെക്കുറിച്ച് കൂടുതൽ വായിക്കാം ഫാബിൻ സാംഗ്ലാർസ് [ ഹബ്രെയിൽ].
രണ്ട് സ്റ്റേറ്റ് അപ്‌ഡേറ്റുകൾക്കിടയിൽ മറ്റ് എന്റിറ്റികളുടെ ചലനം സുഗമമാക്കുന്നതിന് രണ്ടാമത്തെ സെറ്റ് ടെക്നിക്കുകൾ ഉപയോഗിക്കുന്നു. ഈ പ്രശ്നം പരിഹരിക്കാൻ രണ്ട് വഴികളുണ്ട്: ഇന്റർപോളേഷൻ, എക്സ്ട്രാപോളേഷൻ. ഇന്റർപോളേഷന്റെ കാര്യത്തിൽ, അവസാനത്തെ രണ്ട് അവസ്ഥകൾ എടുത്ത് ഒന്നിൽ നിന്ന് മറ്റൊന്നിലേക്കുള്ള മാറ്റം കാണിക്കുന്നു. മുൻകാലങ്ങളിൽ എന്താണ് സംഭവിച്ചതെന്ന് ക്ലയന്റ് എപ്പോഴും കാണുന്നതിനാൽ ഇത് ഒരു ചെറിയ കാലതാമസത്തിന് കാരണമാകുന്നു എന്നതാണ് ഇതിന്റെ പോരായ്മ. എക്സ്ട്രാപോളേഷൻ എന്നത് ക്ലയന്റിന് ലഭിച്ച അവസാന അവസ്ഥയെ അടിസ്ഥാനമാക്കി എന്റിറ്റികൾ എവിടെയായിരിക്കണമെന്ന് പ്രവചിക്കുന്നതാണ്. എന്റിറ്റി ചലനത്തിന്റെ ദിശ പൂർണ്ണമായും മാറ്റുകയാണെങ്കിൽ, പ്രവചനത്തിനും യഥാർത്ഥ സ്ഥാനത്തിനും ഇടയിൽ ഒരു വലിയ പിശക് ഉണ്ടാകും എന്നതാണ് ഇതിന്റെ പോരായ്മ.
FPS-ൽ മാത്രം ഉപയോഗപ്രദമായ ഏറ്റവും പുതിയ, ഏറ്റവും നൂതനമായ സാങ്കേതികതയാണ് കാലതാമസം നഷ്ടപരിഹാരം. ലാഗ് നഷ്ടപരിഹാരം ഉപയോഗിക്കുമ്പോൾ, സെർവർ ടാർഗെറ്റിൽ ഷൂട്ട് ചെയ്യുമ്പോൾ ക്ലയന്റിന്റെ കാലതാമസം കണക്കിലെടുക്കുന്നു. ഉദാഹരണത്തിന്, ഒരു കളിക്കാരൻ അവരുടെ സ്‌ക്രീനിൽ ഒരു ഹെഡ്‌ഷോട്ട് നടത്തിയിരുന്നുവെങ്കിലും യഥാർത്ഥത്തിൽ അവരുടെ ലക്ഷ്യം കാലതാമസം കാരണം മറ്റൊരു സ്ഥലത്തായിരുന്നുവെങ്കിൽ, കാലതാമസം കാരണം കളിക്കാരന് കൊല്ലാനുള്ള അവകാശം നിഷേധിക്കുന്നത് അന്യായമായിരിക്കും. അതിനാൽ, കളിക്കാരൻ അവരുടെ സ്‌ക്രീനിൽ കണ്ടത് അനുകരിക്കാനും അവരുടെ ഷോട്ടും ലക്ഷ്യവും തമ്മിലുള്ള കൂട്ടിയിടി പരിശോധിക്കാനും പ്ലെയർ വെടിയുതിർത്ത നിമിഷത്തിലേക്ക് സെർവർ സമയം തിരികെ നൽകുന്നു.
ഗ്ലെൻ ഫീഡ്‌ലർ (എപ്പോഴും പോലെ!) 2004-ൽ ഒരു ലേഖനം എഴുതി , അതിൽ അദ്ദേഹം സെർവറും ക്ലയന്റും തമ്മിലുള്ള ഫിസിക്സ് സിമുലേഷനുകൾ സമന്വയിപ്പിക്കുന്നതിനുള്ള അടിത്തറയിട്ടു. 2014 ൽ അദ്ദേഹം ഒരു പുതിയ ലേഖന പരമ്പര എഴുതി , ഇത് ഫിസിക്സ് സിമുലേഷനുകൾ സമന്വയിപ്പിക്കുന്നതിനുള്ള മറ്റ് സാങ്കേതികതകളെ വിവരിച്ചു.
വാൽവ് വിക്കിയിലും രണ്ട് ലേഖനങ്ങളുണ്ട്, и കാലതാമസത്തിനുള്ള നഷ്ടപരിഹാരം പരിഗണിക്കുന്നു.
വഞ്ചന തടയുന്നു
തട്ടിപ്പ് തടയുന്നതിന് രണ്ട് പ്രധാന സാങ്കേതിക വിദ്യകളുണ്ട്.
ആദ്യം: വഞ്ചകർക്ക് ക്ഷുദ്രകരമായ പാക്കറ്റുകൾ അയക്കുന്നത് കൂടുതൽ ബുദ്ധിമുട്ടാക്കുന്നു. മുകളിൽ സൂചിപ്പിച്ചതുപോലെ, ഇത് നടപ്പിലാക്കുന്നതിനുള്ള ഒരു നല്ല മാർഗ്ഗം എൻക്രിപ്ഷൻ ആണ്.
രണ്ടാമത്: ഒരു സ്വേച്ഛാധിപത്യ സെർവറിന് കമാൻഡുകൾ/ഇൻപുട്ട്/പ്രവർത്തനങ്ങൾ മാത്രമേ ലഭിക്കൂ. ഇൻപുട്ട് അയയ്‌ക്കാതെ സെർവറിലെ അവസ്ഥ മാറ്റാൻ ക്ലയന്റിന് കഴിയില്ല. തുടർന്ന്, ഓരോ തവണയും സെർവറിന് ഇൻപുട്ട് ലഭിക്കുമ്പോൾ, അത് ഉപയോഗിക്കുന്നതിന് മുമ്പ് അത് സാധുതയുള്ളതാണോ എന്ന് പരിശോധിക്കണം.
പ്രയോഗത്തിന്റെ യുക്തി: നിഗമനം
ക്ലയന്റും സെർവറും ഒരേ കമ്പ്യൂട്ടറിൽ പ്രവർത്തിക്കുമ്പോൾ പോലും മോശം സാഹചര്യങ്ങളിൽ നിങ്ങളുടെ ഗെയിമിന്റെ സ്വഭാവം പരിശോധിക്കാൻ കഴിയുന്ന തരത്തിൽ ഉയർന്ന ലേറ്റൻസികളും കുറഞ്ഞ പുതുക്കൽ നിരക്കുകളും അനുകരിക്കുന്നതിനുള്ള ഒരു മാർഗം നടപ്പിലാക്കാൻ ഞാൻ ശുപാർശ ചെയ്യുന്നു. ഇത് കാലതാമസം സുഗമമാക്കൽ സാങ്കേതിക വിദ്യകൾ നടപ്പിലാക്കുന്നത് വളരെ ലളിതമാക്കും.
മറ്റ് സഹായകരമായ ഉറവിടങ്ങൾ
നെറ്റ്വർക്ക് മോഡലുകളിൽ മറ്റ് ഉറവിടങ്ങൾ പര്യവേക്ഷണം ചെയ്യാൻ നിങ്ങൾ ആഗ്രഹിക്കുന്നുവെങ്കിൽ, നിങ്ങൾക്ക് അവ ഇവിടെ കണ്ടെത്താനാകും:
- - അദ്ദേഹത്തിന്റെ മുഴുവൻ ബ്ലോഗും വായിക്കേണ്ടതാണ്, അവിടെ ധാരാളം മികച്ച ലേഖനങ്ങളുണ്ട്. നെറ്റ്വർക്ക് സാങ്കേതികവിദ്യകളെക്കുറിച്ചുള്ള എല്ലാ ലേഖനങ്ങളും ശേഖരിക്കുന്നു.
- M. Fatih MAR എന്നത് ഓൺലൈൻ വീഡിയോ ഗെയിം എഞ്ചിനുകളിലെ ലേഖനങ്ങളുടെയും വീഡിയോകളുടെയും ഒരു സമഗ്രമായ പട്ടികയാണ്.
- В ധാരാളം ഉപയോഗപ്രദമായ ലിങ്കുകളും ഉണ്ട്.
അവലംബം: www.habr.com