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

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

સામાન્ય રીતે, નેટવર્ક આર્કિટેક્ચરના બે મુખ્ય પ્રકારો છે: પીઅર-ટુ-પીઅર અને ક્લાયંટ-સર્વર. પીઅર-ટુ-પીઅર (p2p) આર્કિટેક્ચરમાં, કનેક્ટેડ પ્લેયર્સની કોઈપણ જોડી વચ્ચે ડેટા ટ્રાન્સફર થાય છે, જ્યારે ક્લાયંટ-સર્વર આર્કિટેક્ચરમાં, ડેટા ફક્ત પ્લેયર્સ અને સર્વર વચ્ચે ટ્રાન્સફર થાય છે.

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

ખાસ કરીને, અમે સરમુખત્યારશાહી સર્વર્સમાં સૌથી વધુ રસ ધરાવીએ છીએ: આવી સિસ્ટમોમાં, સર્વર હંમેશા યોગ્ય હોય છે. ઉદાહરણ તરીકે, જો ખેલાડી વિચારે છે કે તે (10, 5) પર છે અને સર્વર તેને કહે છે કે તે (5, 3) પર છે, તો ક્લાયન્ટે તેની સ્થિતિને સર્વર જે રિપોર્ટ કરી રહ્યું છે તેની સાથે બદલવી જોઈએ, બીજી રીતે નહીં. અધિકૃત સર્વરનો ઉપયોગ ચીટર્સને ઓળખવાનું સરળ બનાવે છે.

ગેમિંગ નેટવર્ક સિસ્ટમ્સમાં ત્રણ મુખ્ય ઘટકો છે:

• ટ્રાન્સપોર્ટ પ્રોટોકોલ: ક્લાયંટ અને સર્વર વચ્ચે ડેટા કેવી રીતે ટ્રાન્સફર થાય છે.
• એપ્લિકેશન પ્રોટોકોલ: ક્લાયંટથી સર્વર પર અને સર્વરથી ક્લાયંટમાં શું પ્રસારિત થાય છે અને કયા ફોર્મેટમાં થાય છે.
• એપ્લિકેશન લોજિક: ક્લાયંટ અને સર્વરની સ્થિતિને અપડેટ કરવા માટે ટ્રાન્સમિટેડ ડેટાનો ઉપયોગ કેવી રીતે થાય છે.

દરેક ભાગની ભૂમિકા અને તેમની સાથે સંકળાયેલી મુશ્કેલીઓને સમજવી ખૂબ જ મહત્વપૂર્ણ છે.

પરિવહન પ્રોટોકોલ

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

TCP અને UDP ની સરખામણી

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

UDP એ IP ની ટોચ પર માત્ર એક પાતળું પડ છે. તેથી, તેની સમાન મર્યાદાઓ છે. તેનાથી વિપરીત, TCP ઘણી સુવિધાઓ ધરાવે છે. તે ભૂલ ચકાસણી સાથે બે ગાંઠો વચ્ચે વિશ્વસનીય આદેશિત જોડાણ પ્રદાન કરે છે. તેથી, TCP ખૂબ અનુકૂળ છે અને તેનો ઉપયોગ અન્ય ઘણા પ્રોટોકોલમાં થાય છે, ઉદાહરણ તરીકે, માં HTTP, FTP и SMTP. પરંતુ આ તમામ સુવિધાઓ કિંમત પર આવે છે: વિલંબ.

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

પરંતુ જેમ તમે કદાચ સમજો છો, મલ્ટિપ્લેયર રમતોમાં લેટન્સી ખૂબ જ મહત્વપૂર્ણ છે, ખાસ કરીને FPS જેવી સક્રિય શૈલીઓમાં. તેથી જ ઘણી રમતો તેના પોતાના પ્રોટોકોલ સાથે UDP નો ઉપયોગ કરે છે.

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

તો, જો TCP નીરસ છે, તો અમે UDP પર આધારિત અમારો પોતાનો ટ્રાન્સપોર્ટ પ્રોટોકોલ બનાવીશું?

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

વર્લ્ડ ઑફ વૉરક્રાફ્ટ, માઇનક્રાફ્ટ અને ટેરેરિયા સહિતની ઘણી સફળ રમતો TCPનો ઉપયોગ કરે છે. જો કે, મોટાભાગના FPSs તેમના પોતાના UDP-આધારિત પ્રોટોકોલનો ઉપયોગ કરે છે, તેથી અમે નીચે તેમના વિશે વધુ વાત કરીશું.

જો તમે TCP નો ઉપયોગ કરવાનું પસંદ કરો તો ખાતરી કરો કે તે અક્ષમ છે નાગલેનું અલ્ગોરિધમ, કારણ કે તે મોકલતા પહેલા પેકેટોને બફર કરે છે, જેનો અર્થ છે કે તે વિલંબને વધારે છે.

મલ્ટિપ્લેયર રમતોના સંદર્ભમાં યુડીપી અને ટીસીપી વચ્ચેના તફાવતો વિશે વધુ જાણવા માટે, ગ્લેન ફિડલરનો લેખ જુઓ UDP વિ. TCP.

માલિકીનો પ્રોટોકોલ

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

પ્રથમ લેખ ગેમ પ્રોગ્રામર્સ માટે નેટવર્કિંગ 2008, બીજા કરતા સરળ એક ગેમ નેટવર્ક પ્રોટોકોલ બનાવવું 2016. હું ભલામણ કરું છું કે તમે જૂની સાથે પ્રારંભ કરો.

ધ્યાન રાખો કે Glenn Fiedler UDP પર આધારિત તમારા પોતાના પ્રોટોકોલનો ઉપયોગ કરવાનો મોટો સમર્થક છે. અને તેના લેખો વાંચ્યા પછી, તમે કદાચ તેનો અભિપ્રાય અપનાવશો કે TCPમાં વિડિયો ગેમ્સમાં ગંભીર ખામીઓ છે, અને તમે તમારા પોતાના પ્રોટોકોલને અમલમાં મૂકવા માંગો છો.

પરંતુ જો તમે નેટવર્કિંગ માટે નવા છો, તો તમારી તરફેણ કરો અને TCP અથવા લાઇબ્રેરીનો ઉપયોગ કરો. તમારા પોતાના ટ્રાન્સપોર્ટ પ્રોટોકોલનો સફળતાપૂર્વક અમલ કરવા માટે, તમારે પહેલાથી ઘણું શીખવાની જરૂર છે.

નેટવર્ક લાઇબ્રેરીઓ

જો તમને TCP કરતાં વધુ કાર્યક્ષમ વસ્તુની જરૂર હોય, પરંતુ તમે તમારા પોતાના પ્રોટોકોલને અમલમાં મૂકવા અને ઘણી બધી વિગતોમાં જવાની તસ્દી લેવા માંગતા નથી, તો તમે નેટ લાઇબ્રેરીનો ઉપયોગ કરી શકો છો. તેમાંના ઘણા બધા છે:

• યોજિમ્બો ગ્લેન ફિડલર
• રાકનેટ, જે હવે સમર્થિત નથી, પરંતુ તેનો કાંટો SLikeNet સક્રિય જણાય છે.
• ENet મલ્ટિપ્લેયર FPS માટે બનાવેલ લાઇબ્રેરી છે ક્યુબ
• ગેમનેટવર્કિંગ સોકેટ્સ વાલ્વ દ્વારા

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

ટ્રાન્સપોર્ટ પ્રોટોકોલ નિષ્કર્ષ

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

TCP, UDP અને લાઇબ્રેરી વચ્ચેની પસંદગી ઘણા પરિબળો પર આધારિત છે. પ્રથમ, રમતની જરૂરિયાતોમાંથી: શું તેને ઓછી વિલંબની જરૂર છે? બીજું, એપ્લિકેશન પ્રોટોકોલની આવશ્યકતાઓમાંથી: શું તેને વિશ્વસનીય પ્રોટોકોલની જરૂર છે? જેમ આપણે આગળના ભાગમાં જોઈશું, એપ્લિકેશન પ્રોટોકોલ બનાવવાનું શક્ય છે જેના માટે અવિશ્વસનીય પ્રોટોકોલ એકદમ યોગ્ય છે. છેલ્લે, તમારે નેટવર્ક એન્જિન ડેવલપરના અનુભવને પણ ધ્યાનમાં લેવાની જરૂર છે.

મારી પાસે બે ટીપ્સ છે:

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

આ ભાગના અંતે, હું ભલામણ કરું છું કે તમે વાંચો મલ્ટિપ્લેયર ગેમ પ્રોગ્રામિંગનો પરિચય બ્રાયન હૂક, જે અહીં ચર્ચા કરાયેલા ઘણા વિષયોને આવરી લે છે.

એપ્લિકેશન પ્રોટોકોલ

હવે જ્યારે આપણે ક્લાયન્ટ અને સર્વર વચ્ચે ડેટાની આપ-લે કરી શકીએ છીએ, ત્યારે આપણે નક્કી કરવાની જરૂર છે કે કયો ડેટા ટ્રાન્સફર કરવો અને કયા ફોર્મેટમાં.

ક્લાસિક સ્કીમ એ છે કે ક્લાયંટ સર્વરને ઇનપુટ અથવા ક્રિયાઓ મોકલે છે, અને સર્વર ક્લાયંટને વર્તમાન રમતની સ્થિતિ મોકલે છે.

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

સીરીયલાઇઝેશન

પ્રથમ પગલું એ છે કે અમે જે ડેટા (ઇનપુટ અથવા ગેમ સ્ટેટ) મોકલવા માગીએ છીએ તેને ટ્રાન્સમિશન માટે યોગ્ય ફોર્મેટમાં કન્વર્ટ કરવું. આ પ્રક્રિયા કહેવામાં આવે છે ક્રમાંકન.

માનવ વાંચી શકાય તેવા ફોર્મેટનો ઉપયોગ કરવાનો વિચાર તરત જ મનમાં આવે છે, જેમ કે JSON અથવા XML. પરંતુ આ સંપૂર્ણપણે બિનકાર્યક્ષમ હશે અને મોટાભાગની ચેનલને કંટાળી જશે.

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

ડેટાને સીરીયલાઇઝ કરવા માટે, તમે લાઇબ્રેરીનો ઉપયોગ કરી શકો છો, ઉદાહરણ તરીકે:

• ફ્લેટબફર્સ Google
• ક'પન પ્રોટો રેતીનું તોફાન
• અનાજ શેન ગ્રાન્ટ અને રેન્ડોલ્ફ વૂરહીસ

ફક્ત ખાતરી કરો કે લાઇબ્રેરી પોર્ટેબલ આર્કાઇવ્સ બનાવે છે અને એન્ડિયનનેસની કાળજી લે છે.

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

ગ્લેન ફિડલરે શ્રેણીબદ્ધતા પર બે લેખો લખ્યા છે: વાંચન અને લેખન પેકેટો и સીરીયલાઇઝેશન વ્યૂહરચનાઓ.

કમ્પ્રેશન

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

બીટ પેકિંગ

પ્રથમ તકનીક બીટ પેકિંગ છે. તે ઇચ્છિત મૂલ્યનું વર્ણન કરવા માટે જરૂરી બિટ્સની બરાબર સંખ્યાનો ઉપયોગ કરે છે. ઉદાહરણ તરીકે, જો તમારી પાસે 16 અલગ-અલગ મૂલ્યો હોઈ શકે તેવા enum હોય, તો પછી સંપૂર્ણ બાઈટ (8 બિટ્સ) ને બદલે, તમે માત્ર 4 બિટ્સનો ઉપયોગ કરી શકો છો.

ગ્લેન ફિડલર લેખના બીજા ભાગમાં આને કેવી રીતે અમલમાં મૂકવું તે સમજાવે છે. વાંચન અને લેખન પેકેટો.

બીટ પેકિંગ ખાસ કરીને વિવેકીકરણ સાથે સારી રીતે કામ કરે છે, જે આગામી વિભાગનો વિષય હશે.

સેમ્પલિંગ

સેમ્પલિંગ એક નુકસાનકારક કમ્પ્રેશન તકનીક છે જે મૂલ્યને એન્કોડ કરવા માટે માત્ર સંભવિત મૂલ્યોના સબસેટનો ઉપયોગ કરે છે. વિવેકીકરણનો અમલ કરવાનો સૌથી સહેલો રસ્તો એ છે કે ફ્લોટિંગ-પોઇન્ટ નંબરોને રાઉન્ડિંગ કરીને.

ગ્લેન ફિડલર (ફરીથી!) તેમના લેખમાં વ્યવહારમાં સમજદારી કેવી રીતે લાગુ કરવી તે બતાવે છે સ્નેપશોટ કમ્પ્રેશન.

કમ્પ્રેશન એલ્ગોરિધમ્સ

આગળની તકનીક લોસલેસ કમ્પ્રેશન અલ્ગોરિધમ્સ હશે.

અહીં, મારા મતે, ત્રણ સૌથી રસપ્રદ અલ્ગોરિધમ્સ છે જે તમારે જાણવાની જરૂર છે:

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

ડેલ્ટા કમ્પ્રેશન

અંતિમ સંકોચન તકનીક ડેલ્ટા કમ્પ્રેશન છે. તે હકીકતમાં રહેલું છે કે વર્તમાન રમત સ્થિતિ અને ક્લાયંટ દ્વારા પ્રાપ્ત થયેલ છેલ્લી સ્થિતિ વચ્ચેના તફાવતો જ પ્રસારિત થાય છે.

તેનો સૌપ્રથમ ઉપયોગ Quake3 નેટવર્ક એન્જિનમાં થયો હતો. તેનો ઉપયોગ કેવી રીતે કરવો તે સમજાવતા અહીં બે લેખો છે:

• Quake3 નેટવર્કિંગ મોડલ બ્રાયન હૂક
• ક્વેક 3 સોર્સ કોડ રિવ્યુ: નેટવર્ક મોડલ ફેબિયન સાંગલાર્સ [સ્થાનાંતરણ હેબ્રે પરના લેખો, "નેટવર્ક મોડેલ" વિભાગ જુઓ]

ગ્લેન ફિડલરે તેના લેખના બીજા ભાગમાં પણ તેનો ઉપયોગ કર્યો હતો. સ્નેપશોટ કમ્પ્રેશન.

એન્ક્રિપ્શન

વધુમાં, તમારે ક્લાયંટ અને સર્વર વચ્ચેની માહિતીના પ્રસારણને એન્ક્રિપ્ટ કરવાની જરૂર પડી શકે છે. આના માટે ઘણા કારણો છે:

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

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

એપ્લિકેશન પ્રોટોકોલ: નિષ્કર્ષ

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

એપ્લિકેશન લોજિક

અમે હવે ક્લાયંટમાં સ્થિતિને અપડેટ કરવામાં સક્ષમ છીએ, પરંતુ અમને લેટન્સી સમસ્યાઓનો સામનો કરવો પડી શકે છે. ખેલાડી, ઇનપુટ કર્યા પછી, વિશ્વ પર તેની શું અસર થઈ છે તે જોવા માટે સર્વર તરફથી રમત સ્ટેટ અપડેટની રાહ જોવી પડશે.

તદુપરાંત, બે રાજ્ય અપડેટ્સ વચ્ચે, વિશ્વ સંપૂર્ણપણે સ્થિર છે. જો રાજ્ય અપડેટ રેટ ઓછો હોય, તો હલનચલન ખૂબ જ આંચકાજનક હશે.

આ સમસ્યાની અસરને ઘટાડવા માટે ઘણી તકનીકો છે, અને હું આગામી વિભાગમાં તેમની ચર્ચા કરીશ.

વિલંબ સ્મૂથિંગ તકનીકો

આ વિભાગમાં વર્ણવેલ તમામ તકનીકોની શ્રેણીમાં વિગતવાર ચર્ચા કરવામાં આવી છે. ફાસ્ટ પેસ્ડ મલ્ટિપ્લેયર ગેબ્રિયલ ગેમ્બેટા. હું લેખોની આ ઉત્તમ શ્રેણી વાંચવાની ખૂબ ભલામણ કરું છું. આ તકનીકો વ્યવહારમાં કેવી રીતે કાર્ય કરે છે તે જોવા માટે તેમાં એક ઇન્ટરેક્ટિવ ડેમો પણ શામેલ છે.

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

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

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

ગ્લેન ફિડલરે (હંમેશની જેમ!) 2004માં એક લેખ લખ્યો હતો નેટવર્ક ભૌતિકશાસ્ત્ર (2004), જેમાં તેણે સર્વર અને ક્લાયંટ વચ્ચે ભૌતિકશાસ્ત્રના સિમ્યુલેશનના સુમેળ માટે પાયો નાખ્યો. 2014 માં તેણે લેખોની નવી શ્રેણી લખી નેટવર્કિંગ ભૌતિકશાસ્ત્ર, જેમાં તેણે ભૌતિકશાસ્ત્રના સિમ્યુલેશનને સુમેળ કરવા માટેની અન્ય તકનીકોનું વર્ણન કર્યું.

વાલ્વના વિકિ પર પણ બે લેખો છે, સોર્સ મલ્ટિપ્લેયર નેટવર્કિંગ и ક્લાયંટ/સર્વર ઇન-ગેમ પ્રોટોકોલ ડિઝાઇન અને ઑપ્ટિમાઇઝેશનમાં લેટન્સી વળતરની પદ્ધતિઓ વિલંબ વળતર સાથે વ્યવહાર.

ઠગ નિવારણ

છેતરપિંડી અટકાવવાની બે મુખ્ય પદ્ધતિઓ છે.

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

બીજું, અધિકૃત સર્વરને ફક્ત આદેશો/ઈનપુટ/ક્રિયાઓ પ્રાપ્ત થવી જોઈએ. ક્લાયન્ટ ઇનપુટ મોકલવા સિવાય સર્વર પરની સ્થિતિ બદલવા માટે સક્ષમ ન હોવો જોઈએ. પછી સર્વર, જ્યારે પણ તે ઇનપુટ મેળવે છે, ત્યારે તેને લાગુ કરતાં પહેલાં તેની માન્યતા તપાસવી આવશ્યક છે.

એપ્લિકેશન તર્ક: નિષ્કર્ષ

હું ભલામણ કરું છું કે તમે ઉચ્ચ લેટન્સી અને નીચા રિફ્રેશ રેટનું અનુકરણ કરવાની રીતનો અમલ કરો જેથી કરીને તમે ક્લાયંટ અને સર્વર એક જ મશીન પર ચાલી રહ્યા હોય ત્યારે પણ ખરાબ સ્થિતિમાં તમારી રમતના વર્તનનું પરીક્ષણ કરી શકો. આ વિલંબને સરળ બનાવવાની તકનીકોના અમલીકરણને મોટા પ્રમાણમાં સરળ બનાવે છે.

અન્ય મદદરૂપ સંસાધનો

જો તમે અન્ય નેટવર્ક મોડલ સંસાધનોનું અન્વેષણ કરવા માંગતા હો, તો તમે તેમને અહીં શોધી શકો છો:

• ગ્લેન ફિડલરનો બ્લોગ — તેનો આખો બ્લોગ વાંચવા યોગ્ય છે, તેમાં ઘણા ઉત્તમ લેખો છે. તે નેટવર્ક ટેકનોલોજી પરના તમામ લેખો એકત્રિત કરવામાં આવ્યા છે.
• અદ્ભુત ગેમ નેટવર્કિંગ M. Fatih MAR દ્વારા વિડીયો ગેમ નેટવર્કીંગ એન્જીન પર લેખો અને વિડીયોની વ્યાપક યાદી છે.
• В wiki subreddit r/gamedev ઘણી ઉપયોગી લિંક્સ પણ છે.

સોર્સ: www.habr.com