గత రెండు వారాలుగా నేను నా గేమ్ కోసం ఆన్‌లైన్ ఇంజిన్‌పై పని చేస్తున్నాను. దీనికి ముందు, గేమ్‌లలో నెట్వర్కింగ్ గురించి నాకు ఏమీ తెలియదు, కాబట్టి నేను చాలా కథనాలను చదివాను మరియు అన్ని భావనలను అర్థం చేసుకోవడానికి మరియు నా స్వంత నెట్వర్కింగ్ ఇంజిన్‌ను వ్రాయగలిగేలా చాలా ప్రయోగాలు చేసాను.
ఈ గైడ్‌లో, మీ స్వంత గేమ్ ఇంజిన్‌ను వ్రాయడానికి ముందు మీరు నేర్చుకోవలసిన వివిధ కాన్సెప్ట్‌లను, అలాగే వాటిని నేర్చుకోవడానికి ఉత్తమమైన వనరులు మరియు కథనాలను మీతో భాగస్వామ్యం చేయాలనుకుంటున్నాను.
సాధారణంగా, నెట్వర్క్ ఆర్కిటెక్చర్‌లలో రెండు ప్రధాన రకాలు ఉన్నాయి: పీర్-టు-పీర్ మరియు క్లయింట్-సర్వర్. పీర్-టు-పీర్ (p2p) ఆర్కిటెక్చర్‌లో, ఏదైనా జత కనెక్ట్ చేయబడిన ప్లేయర్‌ల మధ్య డేటా బదిలీ చేయబడుతుంది, అయితే క్లయింట్-సర్వర్ ఆర్కిటెక్చర్‌లో, డేటా ప్లేయర్‌లు మరియు సర్వర్ మధ్య మాత్రమే బదిలీ చేయబడుతుంది.
ఇప్పటికీ కొన్ని గేమ్‌లలో పీర్-టు-పీర్ ఆర్కిటెక్చర్ ఉపయోగించబడుతున్నప్పటికీ, క్లయింట్-సర్వర్ ప్రమాణం: దీన్ని అమలు చేయడం సులభం, చిన్న ఛానెల్ వెడల్పు అవసరం మరియు మోసం నుండి రక్షించడాన్ని సులభతరం చేస్తుంది. కాబట్టి, ఈ ట్యుటోరియల్‌లో మేము క్లయింట్-సర్వర్ ఆర్కిటెక్చర్‌పై దృష్టి పెడతాము.
ప్రత్యేకించి, మేము అధికార సర్వర్‌లపై ఎక్కువ ఆసక్తిని కలిగి ఉన్నాము: అటువంటి సిస్టమ్‌లలో, సర్వర్ ఎల్లప్పుడూ సరైనది. ఉదాహరణకు, ఒక ఆటగాడు తాను కోఆర్డినేట్స్ (10, 5) వద్ద ఉన్నాడని భావిస్తే మరియు సర్వర్ అతను (5, 3) వద్ద ఉన్నానని చెబితే, క్లయింట్ తన స్థానాన్ని సర్వర్ నివేదించిన దానితో భర్తీ చేయాలి మరియు వైస్ కాదు. దీనికి విరుద్ధంగా. అధికారిక సర్వర్‌లను ఉపయోగించడం వల్ల మోసగాళ్లను గుర్తించడం సులభం అవుతుంది.
నెట్వర్క్ గేమింగ్ సిస్టమ్‌లు మూడు ప్రధాన భాగాలను కలిగి ఉంటాయి:
- రవాణా ప్రోటోకాల్: క్లయింట్లు మరియు సర్వర్ మధ్య డేటా ఎలా బదిలీ చేయబడుతుంది.
- అప్లికేషన్ ప్రోటోకాల్: క్లయింట్‌ల నుండి సర్వర్‌కు మరియు సర్వర్ నుండి క్లయింట్‌లకు మరియు ఏ ఫార్మాట్‌లో ప్రసారం చేయబడుతుంది.
- అప్లికేషన్ లాజిక్: క్లయింట్లు మరియు సర్వర్ స్థితిని నవీకరించడానికి బదిలీ చేయబడిన డేటా ఎలా ఉపయోగించబడుతుంది.
ప్రతి భాగం యొక్క పాత్రను మరియు వాటికి సంబంధించిన సవాళ్లను అర్థం చేసుకోవడం చాలా ముఖ్యం.
రవాణా ప్రోటోకాల్
సర్వర్ మరియు క్లయింట్‌ల మధ్య డేటాను రవాణా చేయడానికి ప్రోటోకాల్‌ను ఎంచుకోవడం మొదటి దశ. దీని కోసం రెండు ఇంటర్నెట్ ప్రోటోకాల్‌లు ఉన్నాయి: и . కానీ మీరు వాటిలో ఒకదాని ఆధారంగా మీ స్వంత రవాణా ప్రోటోకాల్‌ను సృష్టించవచ్చు లేదా వాటిని ఉపయోగించే లైబ్రరీని ఉపయోగించవచ్చు.
TCP మరియు UDP పోలిక
TCP మరియు UDP రెండూ ఆధారపడి ఉంటాయి . IP ఒక ప్యాకెట్‌ను మూలాధారం నుండి గ్రహీతకు బదిలీ చేయడానికి అనుమతిస్తుంది, కానీ పంపిన ప్యాకెట్ త్వరగా లేదా తరువాత గ్రహీతకు చేరుతుందని, అది కనీసం ఒక్కసారైనా చేరుతుందని మరియు ప్యాకెట్‌ల క్రమం సరిగ్గా వస్తుందని హామీ ఇవ్వదు. ఆర్డర్. అంతేకాకుండా, ఒక ప్యాకెట్ విలువ ద్వారా ఇవ్వబడిన పరిమిత డేటాను మాత్రమే కలిగి ఉంటుంది .
UDP అనేది IP పైన ఉన్న పలుచని పొర. అందువలన, ఇది అదే పరిమితులను కలిగి ఉంది. దీనికి విరుద్ధంగా, TCP అనేక లక్షణాలను కలిగి ఉంది. ఇది ఎర్రర్ చెకింగ్‌తో రెండు నోడ్‌ల మధ్య నమ్మకమైన, క్రమబద్ధమైన కనెక్షన్‌ని అందిస్తుంది. అందువల్ల, TCP చాలా సౌకర్యవంతంగా ఉంటుంది మరియు అనేక ఇతర ప్రోటోకాల్‌లలో ఉపయోగించబడుతుంది, ఉదా. , и . కానీ ఈ లక్షణాలన్నీ ధరతో వస్తాయి: .
ఈ ఫంక్షన్‌లు ఎందుకు జాప్యాన్ని కలిగిస్తాయో అర్థం చేసుకోవడానికి, TCP ఎలా పనిచేస్తుందో మనం అర్థం చేసుకోవాలి. పంపే నోడ్ ఒక ప్యాకెట్‌ను స్వీకరించే నోడ్‌కు ప్రసారం చేసినప్పుడు, అది రసీదు (ACK)ని అందుకోవాలని ఆశిస్తుంది. ఒక నిర్దిష్ట సమయం తర్వాత అది అందుకోకపోతే (ప్యాకెట్ లేదా రసీదు పోయినందున లేదా మరేదైనా కారణం), అప్పుడు అది ప్యాకెట్‌ను మళ్లీ పంపుతుంది. అంతేకాకుండా, TCP ప్యాకెట్లు సరైన క్రమంలో అందుతాయని హామీ ఇస్తుంది, కాబట్టి పోయిన ప్యాకెట్‌ను స్వీకరించే వరకు, అన్ని ఇతర ప్యాకెట్లు ఇప్పటికే స్వీకరించబడిన హోస్ట్ ద్వారా స్వీకరించబడినప్పటికీ వాటిని ప్రాసెస్ చేయడం సాధ్యం కాదు.
కానీ మీరు బహుశా ఊహించినట్లుగా, మల్టీప్లేయర్ గేమ్‌లలో జాప్యం చాలా ముఖ్యమైనది, ముఖ్యంగా FPS వంటి యాక్షన్-ప్యాక్డ్ జానర్‌లలో. అందుకే చాలా గేమ్‌లు తమ సొంత ప్రోటోకాల్‌తో UDPని ఉపయోగిస్తాయి.
వివిధ కారణాల వల్ల TCP కంటే స్థానిక UDP-ఆధారిత ప్రోటోకాల్ మరింత సమర్థవంతంగా ఉంటుంది. ఉదాహరణకు, ఇది కొన్ని ప్యాకెట్లను విశ్వసనీయమైనదిగా మరియు మరికొన్ని అవిశ్వసనీయమైనవిగా గుర్తించగలదు. అందువల్ల, అవిశ్వసనీయ ప్యాకెట్ గ్రహీతకు చేరుతుందా లేదా అనేది పట్టించుకోదు. లేదా ఇది బహుళ డేటా స్ట్రీమ్‌లను ప్రాసెస్ చేయగలదు, తద్వారా ఒక స్ట్రీమ్‌లో పోయిన ప్యాకెట్ మిగిలిన స్ట్రీమ్‌లను నెమ్మదించదు. ఉదాహరణకు, ప్లేయర్ ఇన్‌పుట్ కోసం ఒక థ్రెడ్ మరియు చాట్ సందేశాల కోసం మరొక థ్రెడ్ ఉండవచ్చు. అత్యవసరం కాని చాట్ సందేశం పోయినట్లయితే, అది అత్యవసరమైన ఇన్‌పుట్‌ను నెమ్మదించదు. లేదా యాజమాన్య ప్రోటోకాల్ వీడియో గేమ్ వాతావరణంలో మరింత సమర్థవంతంగా ఉండటానికి TCP కంటే భిన్నంగా విశ్వసనీయతను అమలు చేయవచ్చు.
కాబట్టి, TCP చాలా సక్స్ అయితే, UDP ఆధారంగా మన స్వంత రవాణా ప్రోటోకాల్‌ను సృష్టిస్తామా?
ఇది కొంచెం క్లిష్టంగా ఉంటుంది. గేమింగ్ నెట్వర్క్ సిస్టమ్‌లకు TCP దాదాపు ఉపశీర్షిక అయినప్పటికీ, ఇది మీ నిర్దిష్ట గేమ్‌కు బాగా పని చేస్తుంది మరియు మీ విలువైన సమయాన్ని ఆదా చేస్తుంది. ఉదాహరణకు, టర్న్-బేస్డ్ గేమ్ లేదా LAN నెట్‌వర్క్‌లలో మాత్రమే ఆడగలిగే గేమ్‌కు జాప్యం సమస్య కాకపోవచ్చు, ఇక్కడ జాప్యం మరియు ప్యాకెట్ నష్టం ఇంటర్నెట్‌లో కంటే చాలా తక్కువగా ఉంటుంది.
వరల్డ్ ఆఫ్ వార్‌క్రాఫ్ట్, మిన్‌క్రాఫ్ట్ మరియు టెర్రేరియాతో సహా అనేక విజయవంతమైన గేమ్‌లు TCPని ఉపయోగిస్తాయి. అయినప్పటికీ, చాలా FPSలు వాటి స్వంత UDP-ఆధారిత ప్రోటోకాల్‌లను ఉపయోగిస్తాయి, కాబట్టి మేము వాటి గురించి దిగువన మాట్లాడుతాము.
మీరు TCPని ఉపయోగించాలని నిర్ణయించుకుంటే, అది నిలిపివేయబడిందని నిర్ధారించుకోండి , ఎందుకంటే ఇది పంపే ముందు ప్యాకెట్లను బఫర్ చేస్తుంది, అంటే ఇది జాప్యాన్ని పెంచుతుంది.
మల్టీప్లేయర్ గేమ్‌ల సందర్భంలో UDP మరియు TCP మధ్య తేడాల గురించి మరింత తెలుసుకోవడానికి, మీరు గ్లెన్ ఫిడ్లర్ కథనాన్ని చదవవచ్చు .
సొంత ప్రోటోకాల్
కాబట్టి మీరు మీ స్వంత రవాణా ప్రోటోకాల్‌ను సృష్టించాలనుకుంటున్నారు, కానీ ఎక్కడ ప్రారంభించాలో తెలియదా? గ్లెన్ ఫిడ్లర్ దీని గురించి రెండు అద్భుతమైన కథనాలను వ్రాసినందున మీరు అదృష్టవంతులు. మీరు వారిలో చాలా తెలివైన ఆలోచనలను కనుగొంటారు.
మొదటి వ్యాసం 2008, రెండవదాని కంటే సులభం, 2016. మీరు పాతదానితో ప్రారంభించాలని నేను సిఫార్సు చేస్తున్నాను.
UDP ఆధారంగా కస్టమ్ ప్రోటోకాల్‌ను ఉపయోగించడంలో గ్లెన్ ఫిడ్లర్ పెద్ద ప్రతిపాదకుడు అని గమనించండి. మరియు అతని కథనాలను చదివిన తర్వాత, వీడియో గేమ్‌లలో TCP తీవ్రమైన లోపాలను కలిగి ఉందని మీరు అతని అభిప్రాయాన్ని స్వీకరించవచ్చు మరియు మీరు మీ స్వంత ప్రోటోకాల్‌ను అమలు చేయాలనుకుంటున్నారు.
కానీ మీరు నెట్‌వర్కింగ్‌కు కొత్త అయితే, మీకు మీరే సహాయం చేయండి మరియు TCP లేదా లైబ్రరీని ఉపయోగించండి. మీ స్వంత రవాణా ప్రోటోకాల్‌ను విజయవంతంగా అమలు చేయడానికి, మీరు ముందుగానే చాలా నేర్చుకోవాలి.
నెట్వర్క్ లైబ్రరీలు
మీకు TCP కంటే సమర్థవంతమైనది ఏదైనా అవసరమైతే, కానీ మీ స్వంత ప్రోటోకాల్‌ను అమలు చేయడం మరియు చాలా వివరాలకు వెళ్లడం వంటివి చేయకూడదనుకుంటే, మీరు నెట్వర్కింగ్ లైబ్రరీని ఉపయోగించవచ్చు. వాటిలో చాలా ఉన్నాయి:
- గ్లెన్ ఫీల్డ్
- , ఇది ఇకపై మద్దతు లేదు, కానీ దాని యొక్క ఫోర్క్ ఇది ఇంకా యాక్టివ్‌గా ఉన్నట్లు కనిపిస్తోంది.
- మల్టీప్లేయర్ FPS కోసం సృష్టించబడిన లైబ్రరీ
- వాల్వ్
నేను వాటన్నింటినీ ప్రయత్నించలేదు, కానీ నేను ENetని ఇష్టపడతాను ఎందుకంటే ఇది ఉపయోగించడానికి సులభమైనది మరియు నమ్మదగినది. అదనంగా, ఇది స్పష్టమైన డాక్యుమెంటేషన్ మరియు ప్రారంభకులకు ట్యుటోరియల్‌ని కలిగి ఉంది.
రవాణా ప్రోటోకాల్: ముగింపు
సంగ్రహంగా చెప్పాలంటే: రెండు ప్రధాన రవాణా ప్రోటోకాల్‌లు ఉన్నాయి: TCP మరియు UDP. TCP అనేక ఉపయోగకరమైన లక్షణాలను కలిగి ఉంది: విశ్వసనీయత, ప్యాకెట్ ఆర్డర్ సంరక్షణ, దోష గుర్తింపు. UDPకి ఇవన్నీ లేవు, కానీ TCP దాని స్వభావంతో జాప్యాన్ని పెంచింది, ఇది కొన్ని గేమ్‌లకు ఆమోదయోగ్యం కాదు. అంటే, తక్కువ జాప్యాన్ని నిర్ధారించడానికి, మీరు UDP ఆధారంగా మీ స్వంత ప్రోటోకాల్‌ను సృష్టించవచ్చు లేదా UDPలో రవాణా ప్రోటోకాల్‌ను అమలు చేసే మరియు మల్టీప్లేయర్ వీడియో గేమ్‌లకు అనుగుణంగా ఉండే లైబ్రరీని ఉపయోగించవచ్చు.
TCP, UDP మరియు లైబ్రరీ మధ్య ఎంపిక అనేక అంశాలపై ఆధారపడి ఉంటుంది. మొదట, ఆట యొక్క అవసరాల నుండి: దీనికి తక్కువ జాప్యం అవసరమా? రెండవది, అప్లికేషన్ ప్రోటోకాల్ అవసరాల నుండి: దీనికి నమ్మకమైన ప్రోటోకాల్ అవసరమా? మేము తరువాతి భాగంలో చూస్తాము, అవిశ్వసనీయ ప్రోటోకాల్ చాలా సరిఅయిన అప్లికేషన్ ప్రోటోకాల్‌ను సృష్టించడం సాధ్యమవుతుంది. చివరగా, మీరు నెట్వర్క్ ఇంజిన్ డెవలపర్ యొక్క అనుభవాన్ని కూడా పరిగణనలోకి తీసుకోవాలి.
నాకు రెండు సలహాలు ఉన్నాయి:
- మిగిలిన అప్లికేషన్ నుండి వీలైనంత వరకు రవాణా ప్రోటోకాల్‌ను సంగ్రహించండి, తద్వారా అన్ని కోడ్‌లను తిరిగి వ్రాయకుండా సులభంగా భర్తీ చేయవచ్చు.
- అతిగా ఆప్టిమైజ్ చేయవద్దు. మీరు నెట్వర్కింగ్ నిపుణుడు కాకపోతే మరియు మీకు అనుకూల UDP ఆధారిత రవాణా ప్రోటోకాల్ కావాలా అని ఖచ్చితంగా తెలియకపోతే, మీరు TCP లేదా విశ్వసనీయతను అందించే లైబ్రరీతో ప్రారంభించి, ఆపై పనితీరును పరీక్షించి, కొలవవచ్చు. సమస్యలు తలెత్తితే మరియు రవాణా ప్రోటోకాల్ కారణమని మీకు నమ్మకం ఉంటే, మీ స్వంత రవాణా ప్రోటోకాల్‌ను రూపొందించడానికి ఇది సమయం కావచ్చు.
ఈ భాగం ముగింపులో, మీరు చదవమని నేను సిఫార్సు చేస్తున్నాను బ్రియాన్ హుక్ ద్వారా, ఇది ఇక్కడ చర్చించబడిన అనేక అంశాలను కవర్ చేస్తుంది.
అప్లికేషన్ ప్రోటోకాల్
ఇప్పుడు మేము క్లయింట్లు మరియు సర్వర్‌ల మధ్య డేటాను మార్పిడి చేసుకోవచ్చు, ఏ డేటాను బదిలీ చేయాలో మరియు ఏ ఫార్మాట్‌లో మేము నిర్ణయించుకోవాలి.
క్లయింట్లు సర్వర్‌కు ఇన్‌పుట్ లేదా చర్యలను పంపడం క్లాసిక్ స్కీమ్ మరియు సర్వర్ ప్రస్తుత గేమ్ స్థితిని క్లయింట్‌లకు పంపుతుంది.
సర్వర్ పూర్తి స్థితిని పంపదు, కానీ ప్లేయర్‌కు సమీపంలో ఉన్న ఎంటిటీలతో ఫిల్టర్ చేసిన స్థితిని పంపుతుంది. అతను మూడు కారణాల వల్ల ఇలా చేస్తాడు. మొదటిది, అధిక పౌనఃపున్యం వద్ద ప్రసారం చేయడానికి పూర్తి స్థితి చాలా పెద్దది కావచ్చు. రెండవది, క్లయింట్లు ప్రధానంగా విజువల్ మరియు ఆడియో డేటాపై ఆసక్తి కలిగి ఉంటారు, ఎందుకంటే గేమ్ లాజిక్ చాలా వరకు గేమ్ సర్వర్‌లో అనుకరించబడుతుంది. మూడవదిగా, కొన్ని ఆటలలో ఆటగాడు నిర్దిష్ట డేటాను తెలుసుకోవలసిన అవసరం లేదు, ఉదాహరణకు, మ్యాప్ యొక్క మరొక వైపున శత్రువు యొక్క స్థానం, లేకుంటే అతను ప్యాకెట్లను స్నిఫ్ చేయగలడు మరియు అతనిని చంపడానికి ఎక్కడికి తరలించాలో ఖచ్చితంగా తెలుసుకోగలడు.
సీరియలైజేషన్
మేము పంపాలనుకుంటున్న డేటాను (ఇన్‌పుట్ లేదా గేమ్ స్థితి) ప్రసారానికి అనువైన ఫార్మాట్‌లోకి మార్చడం మొదటి దశ. ఈ ప్రక్రియ అంటారు .
JSON లేదా XML వంటి మానవులు చదవగలిగే ఆకృతిని ఉపయోగించడం అనేది వెంటనే గుర్తుకు వచ్చే ఆలోచన. కానీ ఇది పూర్తిగా అసమర్థంగా ఉంటుంది మరియు చాలా ఛానెల్‌ని వృధా చేస్తుంది.
బదులుగా బైనరీ ఆకృతిని ఉపయోగించమని సిఫార్సు చేయబడింది, ఇది చాలా కాంపాక్ట్. అంటే, ప్యాకెట్లలో కొన్ని బైట్‌లు మాత్రమే ఉంటాయి. ఇక్కడ పరిగణించవలసిన సమస్య ఉంది , ఇది వేర్వేరు కంప్యూటర్లలో తేడా ఉండవచ్చు.
డేటాను క్రమీకరించడానికి మీరు లైబ్రరీని ఉపయోగించవచ్చు, ఉదాహరణకు:
- ఇసుక తుఫాను సంస్థ
- షేన్ గ్రాంట్ మరియు రాండోల్ఫ్ వూర్హీస్
లైబ్రరీ పోర్టబుల్ ఆర్కైవ్‌లను క్రియేట్ చేస్తుందని మరియు ఎండియన్‌నెస్ గురించి శ్రద్ధ వహిస్తుందని నిర్ధారించుకోండి.
ప్రత్యామ్నాయ పరిష్కారం మీరే అమలు చేయడం; ఇది ప్రత్యేకంగా కష్టం కాదు, ప్రత్యేకించి మీరు మీ కోడ్‌కి డేటా-సెంట్రిక్ విధానాన్ని ఉపయోగిస్తే. అదనంగా, లైబ్రరీని ఉపయోగిస్తున్నప్పుడు ఎల్లప్పుడూ సాధ్యం కాని ఆప్టిమైజేషన్‌లను నిర్వహించడానికి ఇది మిమ్మల్ని అనుమతిస్తుంది.
గ్లెన్ ఫీల్డ్ సీరియలైజేషన్ గురించి రెండు వ్యాసాలు రాశాడు: и .
కుదింపు
క్లయింట్లు మరియు సర్వర్ మధ్య బదిలీ చేయబడిన డేటా మొత్తం ఛానెల్ బ్యాండ్‌విడ్త్ ద్వారా పరిమితం చేయబడింది. డేటా కంప్రెషన్ ప్రతి స్నాప్‌షాట్‌లో మరింత డేటాను బదిలీ చేయడానికి, అప్‌డేట్ ఫ్రీక్వెన్సీని పెంచడానికి లేదా ఛానెల్ అవసరాలను తగ్గించడానికి మిమ్మల్ని అనుమతిస్తుంది.
బిట్ ప్యాకేజింగ్
మొదటి టెక్నిక్ బిట్ ప్యాకింగ్. ఇది కావలసిన విలువను వివరించడానికి అవసరమైన బిట్‌ల సంఖ్యను ఖచ్చితంగా ఉపయోగించడాన్ని కలిగి ఉంటుంది. ఉదాహరణకు, మీరు 16 విభిన్న విలువలను కలిగి ఉండే enumని కలిగి ఉంటే, మొత్తం బైట్ (8 బిట్‌లు)కి బదులుగా, మీరు కేవలం 4 బిట్‌లను ఉపయోగించవచ్చు.
వ్యాసం యొక్క రెండవ భాగంలో దీన్ని ఎలా అమలు చేయాలో గ్లెన్ ఫీల్డ్ వివరించాడు .
బిట్ ప్యాకింగ్ ముఖ్యంగా నమూనాతో బాగా పనిచేస్తుంది, ఇది తదుపరి విభాగంలో అంశం అవుతుంది.
నమూనా
విలువను ఎన్‌కోడ్ చేయడానికి సాధ్యమయ్యే విలువల ఉపసమితిని మాత్రమే ఉపయోగించే లాస్సీ కంప్రెషన్ టెక్నిక్. ఫ్లోటింగ్ పాయింట్ సంఖ్యలను చుట్టుముట్టడం ద్వారా విచక్షణను అమలు చేయడానికి సులభమైన మార్గం.
గ్లెన్ ఫీల్డ్ (మళ్ళీ!) తన వ్యాసంలో నమూనాను ఎలా ఆచరణలో పెట్టాలో చూపాడు .
కుదింపు అల్గోరిథంలు
తదుపరి సాంకేతికత లాస్‌లెస్ కంప్రెషన్ అల్గారిథమ్‌లు.
ఇక్కడ, నా అభిప్రాయం ప్రకారం, మీరు తెలుసుకోవలసిన మూడు అత్యంత ఆసక్తికరమైన అల్గోరిథంలు:
- ప్రీ-కంప్యూటెడ్ కోడ్‌తో, ఇది చాలా వేగంగా ఉంటుంది మరియు మంచి ఫలితాలను ఇస్తుంది. ఇది Quake3 నెట్వర్కింగ్ ఇంజిన్‌లో ప్యాకెట్లను కుదించడానికి ఉపయోగించబడింది.
- డేటా మొత్తాన్ని ఎప్పటికీ పెంచని సాధారణ-ప్రయోజన కంప్రెషన్ అల్గోరిథం. మీరు ఎలా చూడగలరు , ఇది వివిధ రకాల అప్లికేషన్లలో ఉపయోగించబడింది. రాష్ట్రాలను నవీకరించడానికి ఇది అనవసరం కావచ్చు. కానీ మీరు సర్వర్ నుండి క్లయింట్‌లకు ఆస్తులు, పొడవైన టెక్స్ట్‌లు లేదా భూభాగాన్ని పంపాల్సిన అవసరం ఉంటే అది ఉపయోగకరంగా ఉంటుంది.
- - ఇది బహుశా సరళమైన కుదింపు అల్గోరిథం, కానీ ఇది నిర్దిష్ట రకాల డేటాకు చాలా ప్రభావవంతంగా ఉంటుంది మరియు zlib కంటే ముందు ప్రాసెసింగ్ దశగా ఉపయోగించవచ్చు. ఇది టైల్స్ లేదా వోక్సెల్స్‌తో కూడిన భూభాగాన్ని కుదించడానికి ప్రత్యేకంగా అనుకూలంగా ఉంటుంది, దీనిలో అనేక ప్రక్కనే ఉన్న అంశాలు పునరావృతమవుతాయి.
డెల్టా కుదింపు
చివరి కంప్రెషన్ టెక్నిక్ డెల్టా కంప్రెషన్. ప్రస్తుత ఆట స్థితి మరియు క్లయింట్ అందుకున్న చివరి స్థితి మధ్య వ్యత్యాసాలు మాత్రమే ప్రసారం చేయబడే వాస్తవాన్ని ఇది కలిగి ఉంటుంది.
ఇది మొదట Quake3 నెట్వర్క్ ఇంజిన్‌లో ఉపయోగించబడింది. దీన్ని ఎలా ఉపయోగించాలో వివరించే రెండు కథనాలు ఇక్కడ ఉన్నాయి:
- బ్రియాన్ హుక్
- ఫాబియన్ సాంగ్లర్స్ [ హబ్రేపై కథనాలు, “నెట్వర్క్ మోడల్” విభాగాన్ని చూడండి]
గ్లెన్ ఫీల్డ్ తన వ్యాసం యొక్క రెండవ భాగంలో కూడా దీనిని ఉపయోగించాడు .
ఎన్క్రిప్షన్
అదనంగా, మీరు క్లయింట్లు మరియు సర్వర్ మధ్య సమాచార బదిలీని ఎన్‌క్రిప్ట్ చేయాల్సి రావచ్చు. దీనికి అనేక కారణాలు ఉన్నాయి:
- గోప్యత/గోప్యత: సందేశాలను గ్రహీత మాత్రమే చదవగలరు మరియు నెట్‌వర్క్‌ను స్నిఫ్ చేసే ఇతర వ్యక్తులు ఎవరూ వాటిని చదవలేరు.
- ప్రమాణీకరణ: ఆటగాడి పాత్రను పోషించాలనుకునే వ్యక్తి తన కీని తప్పనిసరిగా తెలుసుకోవాలి.
- మోసం నివారణ: హానికరమైన ఆటగాళ్లకు వారి స్వంత మోసగాడు ప్యాకేజీలను సృష్టించడం చాలా కష్టంగా ఉంటుంది, వారు ఎన్క్రిప్షన్ స్కీమ్‌ను పునరుత్పత్తి చేయాలి మరియు కీని కనుగొనవలసి ఉంటుంది (ఇది ప్రతి కనెక్షన్‌తో మారుతుంది).
దీని కోసం లైబ్రరీని ఉపయోగించమని నేను గట్టిగా సిఫార్సు చేస్తున్నాను. నేను ఉపయోగించమని సూచిస్తున్నాను , ఎందుకంటే ఇది చాలా సరళమైనది మరియు అద్భుతమైన ట్యుటోరియల్‌లను కలిగి ఉంది. ట్యుటోరియల్ ముఖ్యంగా ఆసక్తికరంగా ఉంటుంది , ఇది ప్రతి కొత్త కనెక్షన్‌తో కొత్త కీలను రూపొందించడానికి మిమ్మల్ని అనుమతిస్తుంది.
అప్లికేషన్ ప్రోటోకాల్: ముగింపు
ఇది మా అప్లికేషన్ ప్రోటోకాల్‌ను ముగించింది. కుదింపు పూర్తిగా ఐచ్ఛికం అని నేను నమ్ముతున్నాను మరియు దానిని ఉపయోగించాలనే నిర్ణయం గేమ్ మరియు అవసరమైన బ్యాండ్‌విడ్త్‌పై మాత్రమే ఆధారపడి ఉంటుంది. ఎన్క్రిప్షన్, నా అభిప్రాయం ప్రకారం, తప్పనిసరి, కానీ మొదటి నమూనాలో మీరు లేకుండా చేయవచ్చు.
అప్లికేషన్ లాజిక్
మేము ఇప్పుడు క్లయింట్‌లో స్థితిని అప్‌డేట్ చేయగలుగుతున్నాము, కానీ జాప్యం సమస్యలు రావచ్చు. ప్లేయర్, ఇన్‌పుట్‌ను పూర్తి చేసిన తర్వాత, గేమ్ స్థితి ప్రపంచంపై ఎలాంటి ప్రభావాన్ని చూపిందో చూడటానికి సర్వర్ నుండి అప్‌డేట్ అయ్యే వరకు వేచి ఉండాలి.
అంతేకాకుండా, రెండు రాష్ట్ర నవీకరణల మధ్య, ప్రపంచం పూర్తిగా స్థిరంగా ఉంటుంది. రాష్ట్ర నవీకరణ రేటు తక్కువగా ఉంటే, కదలికలు చాలా కుదుపుగా ఉంటాయి.
ఈ సమస్య యొక్క ప్రభావాన్ని తగ్గించడానికి అనేక పద్ధతులు ఉన్నాయి మరియు నేను వాటిని తదుపరి విభాగంలో కవర్ చేస్తాను.
లాటెన్సీ స్మూతింగ్ టెక్నిక్స్
ఈ విభాగంలో వివరించిన అన్ని పద్ధతులు సిరీస్‌లో వివరంగా చర్చించబడ్డాయి గాబ్రియేల్ గంబెట్టా. ఈ అద్భుతమైన కథనాల శ్రేణిని చదవమని నేను బాగా సిఫార్సు చేస్తున్నాను. ఇది ఇంటరాక్టివ్ డెమోను కూడా కలిగి ఉంటుంది, ఇది ఆచరణలో ఈ పద్ధతులు ఎలా పని చేస్తాయో చూడటానికి మిమ్మల్ని అనుమతిస్తుంది.
సర్వర్ నుండి ప్రతిస్పందన కోసం వేచి ఉండకుండా నేరుగా ఇన్‌పుట్ ఫలితాన్ని వర్తింపజేయడం మొదటి సాంకేతికత. ఇది అంటారు క్లయింట్ వైపు అంచనా. అయితే, క్లయింట్ సర్వర్ నుండి నవీకరణను స్వీకరించినప్పుడు, దాని అంచనా సరైనదని ధృవీకరించాలి. ఇది అలా కాకపోతే, సర్వర్ నుండి అతను స్వీకరించిన దాని ప్రకారం అతను తన స్థితిని మార్చుకోవాలి, ఎందుకంటే సర్వర్ నిరంకుశమైనది. ఈ సాంకేతికత మొదటిసారిగా క్వేక్‌లో ఉపయోగించబడింది. మీరు వ్యాసంలో దాని గురించి మరింత చదువుకోవచ్చు ఫాబియన్ సాంగ్లర్స్ [ హబ్రేపై].
రెండు స్టేట్ అప్‌డేట్‌ల మధ్య ఇతర ఎంటిటీల కదలికను సులభతరం చేయడానికి రెండవ సెట్ టెక్నిక్‌లు ఉపయోగించబడుతుంది. ఈ సమస్యను పరిష్కరించడానికి రెండు మార్గాలు ఉన్నాయి: ఇంటర్‌పోలేషన్ మరియు ఎక్స్‌ట్రాపోలేషన్. ఇంటర్‌పోలేషన్ విషయంలో, చివరి రెండు రాష్ట్రాలు తీసుకోబడ్డాయి మరియు ఒకదాని నుండి మరొకదానికి పరివర్తన చూపబడుతుంది. దీని ప్రతికూలత ఏమిటంటే, క్లయింట్ ఎల్లప్పుడూ గతంలో ఏమి జరిగిందో చూస్తారు కాబట్టి ఇది చిన్న మొత్తంలో ఆలస్యం అవుతుంది. ఎక్స్‌ట్రాపోలేషన్ అనేది క్లయింట్ అందుకున్న చివరి స్థితి ఆధారంగా ఇప్పుడు ఎంటిటీలు ఎక్కడ ఉండాలో అంచనా వేయడం. దీని ప్రతికూలత ఏమిటంటే, ఎంటిటీ కదలిక దిశను పూర్తిగా మార్చినట్లయితే, అప్పుడు సూచన మరియు వాస్తవ స్థానం మధ్య పెద్ద లోపం ఉంటుంది.
FPSలో మాత్రమే ఉపయోగపడే తాజా, అత్యంత అధునాతన సాంకేతికత లాగ్ పరిహారం. లాగ్ పరిహారాన్ని ఉపయోగిస్తున్నప్పుడు, సర్వర్ లక్ష్యం వద్ద షూట్ చేసినప్పుడు క్లయింట్ యొక్క ఆలస్యాన్ని పరిగణనలోకి తీసుకుంటుంది. ఉదాహరణకు, ఒక ఆటగాడు వారి స్క్రీన్‌పై హెడ్‌షాట్ ప్రదర్శించినట్లయితే, వాస్తవానికి వారి లక్ష్యం ఆలస్యం కారణంగా వేరే ప్రదేశంలో ఉంటే, ఆలస్యం కారణంగా చంపే హక్కును ఆటగాడికి నిరాకరించడం అన్యాయం. అందువల్ల, ప్లేయర్ తన స్క్రీన్‌పై చూసినదాన్ని అనుకరించడానికి మరియు వారి షాట్ మరియు లక్ష్యానికి మధ్య ఢీకొనడాన్ని తనిఖీ చేయడానికి ప్లేయర్ కాల్చిన క్షణం వరకు సర్వర్ రివైండ్ చేస్తుంది.
గ్లెన్ ఫిడ్లర్ (ఎప్పటిలాగే!) 2004లో ఒక కథనాన్ని రాశారు , దీనిలో అతను సర్వర్ మరియు క్లయింట్ మధ్య భౌతిక శాస్త్ర అనుకరణలను సమకాలీకరించడానికి పునాది వేశాడు. 2014లో అతను కొత్త కథనాలను రాశాడు , ఇది భౌతిక శాస్త్ర అనుకరణలను సమకాలీకరించడానికి ఇతర పద్ధతులను వివరించింది.
వాల్వ్ వికీలో రెండు వ్యాసాలు కూడా ఉన్నాయి, и ఇది జాప్యానికి పరిహారంగా పరిగణించబడుతుంది.
మోసాన్ని అరికట్టడం
మోసాన్ని నిరోధించడానికి రెండు ప్రధాన పద్ధతులు ఉన్నాయి.
మొదటిది: మోసగాళ్లు హానికరమైన ప్యాకెట్లను పంపడం మరింత కష్టతరం చేయడం. పైన చెప్పినట్లుగా, దీన్ని అమలు చేయడానికి ఒక మంచి మార్గం ఎన్క్రిప్షన్.
రెండవది: అధికార సర్వర్ ఆదేశాలు/ఇన్‌పుట్/చర్యలను మాత్రమే స్వీకరించాలి. క్లయింట్ ఇన్‌పుట్ పంపడం ద్వారా కాకుండా సర్వర్‌లో స్థితిని మార్చలేరు. ఆపై, సర్వర్ ఇన్‌పుట్‌ను స్వీకరించిన ప్రతిసారీ, దానిని ఉపయోగించే ముందు అది చెల్లుబాటులో ఉందో లేదో తనిఖీ చేయాలి.
అప్లికేషన్ లాజిక్: ముగింపు
మీరు అధిక లేటెన్సీలు మరియు తక్కువ రిఫ్రెష్ రేట్‌లను అనుకరించే మార్గాన్ని అమలు చేయాలని నేను సిఫార్సు చేస్తున్నాను, తద్వారా క్లయింట్ మరియు సర్వర్ ఒకే కంప్యూటర్‌లో రన్ అవుతున్నప్పుడు కూడా పేలవమైన పరిస్థితుల్లో మీ గేమ్ ప్రవర్తనను పరీక్షించవచ్చు. ఇది ఆలస్యం స్మూటింగ్ టెక్నిక్‌ల అమలును చాలా సులభతరం చేస్తుంది.
ఇతర సహాయక వనరులు
మీరు నెట్వర్క్ మోడల్‌లలో ఇతర వనరులను అన్వేషించాలనుకుంటే, మీరు వాటిని ఇక్కడ కనుగొనవచ్చు:
- - అతని బ్లాగ్ మొత్తం చదవదగినది, అక్కడ చాలా గొప్ప కథనాలు ఉన్నాయి. నెట్వర్క్ సాంకేతికతలపై అన్ని కథనాలు సేకరించబడ్డాయి.
- M. ఫాతిహ్ MAR ద్వారా ఆన్‌లైన్ వీడియో గేమ్ ఇంజిన్‌లపై కథనాలు మరియు వీడియోల సమగ్ర జాబితా.
- В చాలా ఉపయోగకరమైన లింక్‌లు కూడా ఉన్నాయి.
మూలం: www.habr.com