Τις τελευταίες δύο εβδομάδες εργάζομαι στη μηχανή δικτύωσης για το παιχνίδι μου. Πριν από αυτό, δεν ήξερα τίποτα για τη δικτύωση σε παιχνίδια, οπότε διάβασα πολλά άρθρα και έκανα πολλά πειράματα για να κατανοήσω όλες τις έννοιες και να μπορέσω να γράψω τη δική μου μηχανή δικτύωσης.

Σε αυτόν τον οδηγό, θα ήθελα να μοιραστώ μαζί σας τις διάφορες έννοιες που πρέπει να μάθετε πριν γράψετε τη δική σας μηχανή παιχνιδιών, καθώς και τους καλύτερους πόρους και άρθρα για την εκμάθησή τους.

Γενικά, υπάρχουν δύο κύριοι τύποι αρχιτεκτονικών δικτύων: peer-to-peer και client-server. Σε μια αρχιτεκτονική peer-to-peer (p2p), τα δεδομένα μεταφέρονται μεταξύ οποιουδήποτε ζεύγους συνδεδεμένων παικτών, ενώ σε μια αρχιτεκτονική πελάτη-διακομιστή, τα δεδομένα μεταφέρονται μόνο μεταξύ των παικτών και του διακομιστή.

Αν και η αρχιτεκτονική peer-to-peer εξακολουθεί να χρησιμοποιείται σε ορισμένα παιχνίδια, η αρχιτεκτονική πελάτη-διακομιστή είναι το πρότυπο: είναι ευκολότερη στην εφαρμογή της, απαιτεί μικρότερο πλάτος καναλιού και διευκολύνει την προστασία από την εξαπάτηση. Επομένως, σε αυτόν τον οδηγό, θα επικεντρωθούμε στην αρχιτεκτονική πελάτη-διακομιστή.

Συγκεκριμένα, μας ενδιαφέρουν περισσότερο οι αυταρχικοί διακομιστές: σε τέτοια συστήματα, ο διακομιστής έχει πάντα δίκιο. Για παράδειγμα, εάν ο παίκτης πιστεύει ότι βρίσκεται στο (10, 5) και ο διακομιστής του λέει ότι βρίσκεται στο (5, 3), τότε ο πελάτης θα πρέπει να αντικαταστήσει τη θέση του με αυτή που αναφέρει ο διακομιστής και όχι το αντίστροφο. Η χρήση έγκυρων διακομιστών διευκολύνει την αναγνώριση των απατεώνων.

Υπάρχουν τρία κύρια στοιχεία στα συστήματα δικτύων παιχνιδιών:

• Πρωτόκολλο μεταφοράς: πώς μεταφέρονται τα δεδομένα μεταξύ των πελατών και του διακομιστή.
• Πρωτόκολλο εφαρμογής: τι μεταδίδεται από τους πελάτες στον διακομιστή και από τον διακομιστή στους πελάτες και σε ποια μορφή.
• Λογική εφαρμογής: πώς χρησιμοποιούνται τα μεταδιδόμενα δεδομένα για την ενημέρωση της κατάστασης των πελατών και του διακομιστή.

Είναι πολύ σημαντικό να κατανοήσουμε τον ρόλο του κάθε μέρους και τις δυσκολίες που συνδέονται με αυτό.

Πρωτόκολλο μεταφοράς

Το πρώτο βήμα είναι να επιλέξετε ένα πρωτόκολλο για τη μεταφορά δεδομένων μεταξύ του διακομιστή και των πελατών. Υπάρχουν δύο πρωτόκολλα Διαδικτύου για αυτό: TCP и UDP. Αλλά μπορείτε να δημιουργήσετε το δικό σας πρωτόκολλο μεταφοράς με βάση ένα από αυτά ή να χρησιμοποιήσετε μια βιβλιοθήκη που τα χρησιμοποιεί.

Σύγκριση TCP και UDP

Τόσο το TCP όσο και το UDP βασίζονται σε IP. Η IP επιτρέπει τη μετάδοση ενός πακέτου από μια πηγή σε έναν δέκτη, αλλά δεν εγγυάται ότι το αποσταλμένο πακέτο θα φτάσει στον παραλήπτη αργά ή γρήγορα, ότι θα φτάσει σε αυτό τουλάχιστον μία φορά και ότι η ακολουθία των πακέτων θα φτάσει στο τη σωστή σειρά. Επιπλέον, ένα πακέτο μπορεί να περιέχει μόνο ένα περιορισμένο μέγεθος δεδομένων, που δίνεται από την τιμή MTU.

Το UDP είναι απλώς ένα λεπτό στρώμα πάνω από το IP. Ως εκ τούτου, έχει τους ίδιους περιορισμούς. Αντίθετα, το TCP έχει πολλά χαρακτηριστικά. Παρέχει μια αξιόπιστη, διατεταγμένη σύνδεση μεταξύ δύο κόμβων με έλεγχο σφαλμάτων. Επομένως, το TCP είναι πολύ βολικό και χρησιμοποιείται σε πολλά άλλα πρωτόκολλα, για παράδειγμα, στο HTTP, fTP и SMTP. Αλλά όλα αυτά τα χαρακτηριστικά έχουν μια τιμή: καθυστέρηση.

Για να κατανοήσουμε γιατί αυτές οι συναρτήσεις μπορούν να προκαλέσουν καθυστέρηση, πρέπει να κατανοήσουμε πώς λειτουργεί το TCP. Όταν ο κεντρικός υπολογιστής αποστολής μεταδίδει ένα πακέτο στον λαμβάνοντα κεντρικό υπολογιστή, αναμένει να λάβει μια επιβεβαίωση (ACK). Εάν μετά από κάποιο χρονικό διάστημα δεν το λάβει (επειδή χάθηκε το πακέτο ή η επιβεβαίωση ή για κάποιο άλλο λόγο), τότε στέλνει ξανά το πακέτο. Επιπλέον, το TCP εγγυάται ότι τα πακέτα λαμβάνονται με τη σωστή σειρά, επομένως μέχρι να ληφθεί ένα χαμένο πακέτο, όλα τα άλλα πακέτα δεν μπορούν να υποβληθούν σε επεξεργασία, ακόμα κι αν έχουν ήδη ληφθεί από τον κόμβο λήψης.

Όμως, όπως μάλλον καταλαβαίνετε, η καθυστέρηση στα παιχνίδια για πολλούς παίκτες είναι πολύ σημαντική, ειδικά σε ενεργά είδη όπως το FPS. Αυτός είναι ο λόγος που πολλά παιχνίδια χρησιμοποιούν το UDP με το δικό του πρωτόκολλο.

Ένα εγγενές πρωτόκολλο που βασίζεται σε UDP μπορεί να είναι πιο αποτελεσματικό από το TCP για διάφορους λόγους. Για παράδειγμα, μπορεί να επισημάνει ορισμένα πακέτα ως αξιόπιστα και άλλα ως μη αξιόπιστα. Επομένως, δεν τον ενδιαφέρει αν το αναξιόπιστο πακέτο έχει φτάσει στον παραλήπτη. Ή μπορεί να επεξεργαστεί πολλαπλές ροές δεδομένων, έτσι ώστε ένα πακέτο που χάνεται σε μια ροή να μην επιβραδύνει άλλες ροές. Για παράδειγμα, μπορεί να υπάρχει ένα νήμα για την εισαγωγή του προγράμματος αναπαραγωγής και ένα άλλο νήμα για τα μηνύματα συνομιλίας. Εάν χαθεί ένα μήνυμα συνομιλίας που δεν είναι επείγοντα δεδομένα, τότε δεν θα επιβραδύνει την εισαγωγή που είναι επείγουσα. Ή ένα ιδιόκτητο πρωτόκολλο μπορεί να εφαρμόσει την αξιοπιστία διαφορετικά από το TCP για να είναι πιο αποτελεσματικό σε περιβάλλον βιντεοπαιχνιδιών.

Έτσι, εάν το TCP είναι χάλια, τότε θα δημιουργήσουμε το δικό μας πρωτόκολλο μεταφοράς με βάση το UDP;

Όλα είναι λίγο πιο περίπλοκα. Παρόλο που το TCP είναι σχεδόν μη βέλτιστο για συστήματα δικτύων παιχνιδιών, μπορεί να λειτουργήσει αρκετά καλά για το συγκεκριμένο παιχνίδι σας και να σας εξοικονομήσει πολύτιμο χρόνο. Για παράδειγμα, η καθυστέρηση μπορεί να μην αποτελεί πρόβλημα για ένα παιχνίδι turn-based ή ένα παιχνίδι που μπορεί να παιχτεί μόνο σε δίκτυα LAN, όπου η καθυστέρηση και η απώλεια πακέτων είναι πολύ μικρότερες από ό,τι στο Διαδίκτυο.

Πολλά επιτυχημένα παιχνίδια, συμπεριλαμβανομένων των World of Warcraft, Minecraft και Terraria, χρησιμοποιούν το TCP. Ωστόσο, τα περισσότερα FPS χρησιμοποιούν τα δικά τους πρωτόκολλα που βασίζονται στο UDP, οπότε θα μιλήσουμε για αυτά με περισσότερες λεπτομέρειες παρακάτω.

Εάν επιλέξετε να χρησιμοποιήσετε το TCP, βεβαιωθείτε ότι είναι απενεργοποιημένο Ο αλγόριθμος του Nagle, επειδή αποθηκεύει πακέτα πριν από την αποστολή, πράγμα που σημαίνει ότι αυξάνει την καθυστέρηση.

Για να μάθετε περισσότερα σχετικά με τις διαφορές μεταξύ UDP και TCP στο πλαίσιο των παιχνιδιών για πολλούς παίκτες, ανατρέξτε στο άρθρο του Glenn Fiedler UDP vs. TCP.

Ιδιόκτητο Πρωτόκολλο

Θέλετε λοιπόν να δημιουργήσετε το δικό σας πρωτόκολλο μεταφοράς αλλά δεν ξέρετε από πού να ξεκινήσετε; Είσαι τυχερός, γιατί ο Glenn Fiedler έγραψε δύο καταπληκτικά άρθρα γι' αυτό. Θα βρείτε πολλές έξυπνες ιδέες σε αυτά.

Πρώτο άρθρο Δικτύωση για προγραμματιστές παιχνιδιών 2008, πιο εύκολο από το δεύτερο Δημιουργία Πρωτοκόλλου Δικτύου Παιχνιδιού 2016. Σας συνιστώ να ξεκινήσετε με το παλαιότερο.

Να γνωρίζετε ότι ο Glenn Fiedler είναι μεγάλος υπέρμαχος της χρήσης του δικού σας πρωτοκόλλου που βασίζεται στο UDP. Και αφού διαβάσετε τα άρθρα του, μάλλον θα υιοθετήσετε την άποψή του ότι το TCP έχει σοβαρά μειονεκτήματα στα βιντεοπαιχνίδια και θα θέλετε να εφαρμόσετε το δικό σας πρωτόκολλο.

Αλλά αν είστε νέος στη δικτύωση, κάντε τη χάρη στον εαυτό σας και χρησιμοποιήστε το TCP ή μια βιβλιοθήκη. Για να εφαρμόσετε με επιτυχία το δικό σας πρωτόκολλο μεταφοράς, πρέπει να μάθετε πολλά εκ των προτέρων.

Βιβλιοθήκες Δικτύων

Εάν χρειάζεστε κάτι πιο αποτελεσματικό από το TCP, αλλά δεν θέλετε να κάνετε τον κόπο να εφαρμόσετε το δικό σας πρωτόκολλο και να υπεισέλθετε σε πολλές λεπτομέρειες, μπορείτε να χρησιμοποιήσετε τη βιβλιοθήκη δικτύου. Υπάρχουν πολλά από αυτά:

• γιοτζίμπο Γκλεν Φίντλερ
• RakNet, το οποίο δεν υποστηρίζεται πλέον, αλλά το πιρούνι του SLikeNet φαίνεται να είναι ενεργή.
• ENet είναι μια βιβλιοθήκη που δημιουργήθηκε για FPS για πολλούς παίκτες Κύβος
• GameNetworkingSockets από τη Valve

Δεν τα έχω δοκιμάσει όλα, αλλά προτιμώ το ENet γιατί είναι εύχρηστο και αξιόπιστο. Επιπλέον, έχει σαφή τεκμηρίωση και ένα σεμινάριο για αρχάριους.

Συμπέρασμα Πρωτοκόλλου Μεταφορών

Συνοψίζοντας, υπάρχουν δύο κύρια πρωτόκολλα μεταφοράς: TCP και UDP. Το TCP έχει πολλά χρήσιμα χαρακτηριστικά: αξιοπιστία, διατήρηση της παραγγελίας πακέτων, ανίχνευση σφαλμάτων. Το UDP δεν τα έχει όλα αυτά, αλλά το TCP, από τη φύση του, έχει υψηλή καθυστέρηση που είναι απαράδεκτη για ορισμένα παιχνίδια. Δηλαδή, για να εξασφαλίσετε χαμηλό λανθάνοντα χρόνο, μπορείτε να δημιουργήσετε το δικό σας πρωτόκολλο με βάση το UDP ή να χρησιμοποιήσετε μια βιβλιοθήκη που υλοποιεί το πρωτόκολλο μεταφοράς στο UDP και είναι προσαρμοσμένη για βιντεοπαιχνίδια για πολλούς παίκτες.

Η επιλογή μεταξύ TCP, UDP και βιβλιοθήκης εξαρτάται από πολλούς παράγοντες. Πρώτον, από τις ανάγκες του παιχνιδιού: χρειάζεται χαμηλή καθυστέρηση; Δεύτερον, από τις απαιτήσεις του πρωτοκόλλου εφαρμογής: χρειάζεται αξιόπιστο πρωτόκολλο; Όπως θα δούμε στο επόμενο μέρος, είναι δυνατό να δημιουργηθεί ένα πρωτόκολλο εφαρμογής για το οποίο ένα αναξιόπιστο πρωτόκολλο είναι αρκετά κατάλληλο. Τέλος, πρέπει επίσης να λάβετε υπόψη την εμπειρία του προγραμματιστή της μηχανής δικτύου.

Έχω δύο συμβουλές:

• Αφαιρέστε το πρωτόκολλο μεταφοράς όσο το δυνατόν περισσότερο από την υπόλοιπη εφαρμογή, ώστε να μπορεί να αντικατασταθεί εύκολα χωρίς να ξαναγράψετε όλο τον κώδικα.
• Μην βελτιστοποιείτε υπερβολικά. Εάν δεν είστε ειδικός στο δίκτυο και δεν είστε σίγουροι αν χρειάζεστε το δικό σας πρωτόκολλο μεταφοράς που βασίζεται σε UDP, μπορείτε να ξεκινήσετε με το TCP ή μια βιβλιοθήκη που παρέχει αξιοπιστία και στη συνέχεια να δοκιμάσετε και να μετρήσετε την απόδοση. Εάν αντιμετωπίζετε προβλήματα και είστε σίγουροι ότι πρόκειται για πρωτόκολλο μεταφοράς, τότε ίσως είναι καιρός να δημιουργήσετε το δικό σας πρωτόκολλο μεταφοράς.

Στο τέλος αυτού του μέρους, σας συνιστώ να διαβάσετε Εισαγωγή στον προγραμματισμό παιχνιδιών για πολλούς παίκτες Brian Hook, το οποίο καλύπτει πολλά από τα θέματα που συζητούνται εδώ.

Πρωτόκολλο εφαρμογής

Τώρα που μπορούμε να ανταλλάξουμε δεδομένα μεταξύ των πελατών και του διακομιστή, πρέπει να αποφασίσουμε ποια δεδομένα θα μεταφέρουμε και σε ποια μορφή.

Το κλασικό σχήμα είναι ότι οι πελάτες στέλνουν δεδομένα ή ενέργειες στον διακομιστή και ο διακομιστής στέλνει την τρέχουσα κατάσταση του παιχνιδιού στους πελάτες.

Ο διακομιστής στέλνει όχι την πλήρη, αλλά την φιλτραρισμένη κατάσταση με οντότητες που βρίσκονται κοντά στη συσκευή αναπαραγωγής. Αυτό το κάνει για τρεις λόγους. Πρώτον, η συνολική κατάσταση μπορεί να είναι πολύ μεγάλη για να μεταδοθεί σε υψηλή συχνότητα. Δεύτερον, οι πελάτες ενδιαφέρονται κυρίως για οπτικά και ακουστικά δεδομένα, επειδή το μεγαλύτερο μέρος της λογικής του παιχνιδιού προσομοιώνεται στον διακομιστή του παιχνιδιού. Τρίτον, σε ορισμένα παιχνίδια ο παίκτης δεν χρειάζεται να γνωρίζει ορισμένα δεδομένα, όπως τη θέση του εχθρού στην άλλη πλευρά του χάρτη, γιατί διαφορετικά μπορεί να μυρίσει πακέτα και να ξέρει ακριβώς πού να κινηθεί για να τον σκοτώσει.

Σειριοποίηση

Το πρώτο βήμα είναι να μετατρέψουμε τα δεδομένα που θέλουμε να στείλουμε (εισαγωγή ή κατάσταση παιχνιδιού) σε μορφή κατάλληλη για μετάδοση. Αυτή η διαδικασία ονομάζεται σειριοποίηση.

Αμέσως έρχεται στο μυαλό η ιδέα να χρησιμοποιήσετε μια μορφή αναγνώσιμη από τον άνθρωπο, όπως JSON ή XML. Αλλά αυτό θα είναι εντελώς αναποτελεσματικό και θα καταλαμβάνει το μεγαλύτερο μέρος του καναλιού για τίποτα.

Αντίθετα, συνιστάται η χρήση της δυαδικής μορφής, η οποία είναι πολύ πιο συμπαγής. Δηλαδή, τα πακέτα θα περιέχουν μόνο μερικά byte. Εδώ πρέπει να λάβουμε υπόψη το πρόβλημα σειρά byte, το οποίο μπορεί να διαφέρει σε διαφορετικούς υπολογιστές.

Για σειριοποίηση δεδομένων, μπορείτε να χρησιμοποιήσετε μια βιβλιοθήκη, για παράδειγμα:

• FlatBuffers Google
• Cap'n Proto Αμμοθύελλα
• δημητριακών Shane Grant και Randolph Voorhees

Απλώς βεβαιωθείτε ότι η βιβλιοθήκη δημιουργεί φορητά αρχεία και φροντίζει για το endianness.

Μια εναλλακτική λύση θα ήταν να την εφαρμόσετε μόνοι σας, δεν είναι τόσο δύσκολο, ειδικά αν χρησιμοποιείτε μια προσέγγιση με επίκεντρο τα δεδομένα στον κώδικά σας. Επιπλέον, θα σας επιτρέψει να πραγματοποιήσετε βελτιστοποιήσεις που δεν είναι πάντα δυνατές όταν χρησιμοποιείτε τη βιβλιοθήκη.

Ο Glenn Fiedler έχει γράψει δύο άρθρα σχετικά με τη σειριοποίηση: Πακέτα ανάγνωσης και γραφής и Στρατηγικές σειριοποίησης.

Συμπίεση

Ο όγκος των δεδομένων που μεταφέρονται μεταξύ των πελατών και του διακομιστή περιορίζεται από το εύρος ζώνης του καναλιού. Η συμπίεση δεδομένων θα σας επιτρέψει να μεταφέρετε περισσότερα δεδομένα σε κάθε στιγμιότυπο, να αυξήσετε τον ρυθμό ανανέωσης ή απλώς να μειώσετε τις απαιτήσεις εύρους ζώνης.

Συσκευασία κομματιών

Η πρώτη τεχνική είναι το bit packing. Συνίσταται στη χρήση ακριβώς του αριθμού των bit που είναι απαραίτητος για την περιγραφή της επιθυμητής τιμής. Για παράδειγμα, εάν έχετε ένα enum που μπορεί να έχει 16 διαφορετικές τιμές, τότε αντί για ένα ολόκληρο byte (8 bit), μπορείτε να χρησιμοποιήσετε μόνο 4 bit.

Ο Glenn Fiedler εξηγεί πώς να το εφαρμόσετε στο δεύτερο μέρος του άρθρου. Πακέτα ανάγνωσης και γραφής.

Η συσκευασία bit λειτουργεί ιδιαίτερα καλά με τη διακριτοποίηση, η οποία θα είναι το θέμα της επόμενης ενότητας.

Δειγματοληψία

Δειγματοληψία είναι μια τεχνική συμπίεσης με απώλειες που χρησιμοποιεί μόνο ένα υποσύνολο πιθανών τιμών για την κωδικοποίηση μιας τιμής. Ο ευκολότερος τρόπος εφαρμογής της διακριτοποίησης είναι με στρογγυλοποίηση αριθμών κινητής υποδιαστολής.

Ο Glenn Fiedler (και πάλι!) δείχνει πώς να εφαρμόσετε τη διακριτοποίηση στην πράξη στο άρθρο του Συμπίεση στιγμιότυπου.

Αλγόριθμοι συμπίεσης

Η επόμενη τεχνική θα είναι οι αλγόριθμοι συμπίεσης χωρίς απώλειες.

Εδώ, κατά τη γνώμη μου, είναι οι τρεις πιο ενδιαφέροντες αλγόριθμοι που πρέπει να γνωρίζετε:

• Κωδικοποίηση Huffman με προυπολογισμένο κώδικα, ο οποίος είναι εξαιρετικά γρήγορος και μπορεί να παράγει καλά αποτελέσματα. Χρησιμοποιήθηκε για τη συμπίεση πακέτων στη μηχανή δικτύου Quake3.
• zlib είναι ένας γενικός αλγόριθμος συμπίεσης που δεν αυξάνει ποτέ τον όγκο των δεδομένων. Πώς μπορείτε να δείτε εδώ, έχει χρησιμοποιηθεί σε ποικίλες εφαρμογές. Για την ενημέρωση των καταστάσεων, μπορεί να είναι περιττή. Αλλά μπορεί να είναι χρήσιμο εάν πρέπει να στείλετε στοιχεία, μεγάλα κείμενα ή έδαφος σε πελάτες από τον διακομιστή.
• Μήκη εκτέλεσης αντιγραφής είναι ίσως ο απλούστερος αλγόριθμος συμπίεσης, αλλά είναι πολύ αποτελεσματικός για ορισμένους τύπους δεδομένων και μπορεί να χρησιμοποιηθεί ως βήμα προεπεξεργασίας πριν από το zlib. Είναι ιδιαίτερα κατάλληλο για συμπίεση εδάφους που αποτελείται από πλακίδια ή voxels στα οποία επαναλαμβάνονται πολλά γειτονικά στοιχεία.

συμπίεση δέλτα

Η τελική τεχνική συμπίεσης είναι η συμπίεση δέλτα. Βρίσκεται στο γεγονός ότι μεταδίδονται μόνο οι διαφορές μεταξύ της τρέχουσας κατάστασης του παιχνιδιού και της τελευταίας κατάστασης που έλαβε ο πελάτης.

Χρησιμοποιήθηκε για πρώτη φορά στη μηχανή δικτύου Quake3. Ακολουθούν δύο άρθρα που εξηγούν πώς να το χρησιμοποιήσετε:

• Το μοντέλο δικτύωσης Quake3 Μπράιαν Χουκ
• Quake 3 Review Source Code: Network Model Fabien Sanglars [μετάφραση άρθρα στο Habré, βλέπε ενότητα "Μοντέλο δικτύου"]

Ο Glenn Fiedler το χρησιμοποίησε και στο δεύτερο μέρος του άρθρου του. Συμπίεση στιγμιότυπου.

Κρυπτογράφηση

Επιπλέον, μπορεί να χρειαστεί να κρυπτογραφήσετε τη μετάδοση πληροφοριών μεταξύ των πελατών και του διακομιστή. Υπάρχουν διάφοροι λόγοι για αυτό:

• Απόρρητο/Εμπιστευτικότητα: Τα μηνύματα μπορούν να διαβαστούν μόνο από τον παραλήπτη και κανένας άλλος ανιχνευτής δικτύου δεν θα μπορεί να τα διαβάσει.
• έλεγχος ταυτότητας: ένα άτομο που θέλει να παίξει το ρόλο ενός παίκτη πρέπει να γνωρίζει το κλειδί του.
• αποτροπή cheat: θα είναι πολύ πιο δύσκολο για τους κακόβουλους παίκτες να δημιουργήσουν τα δικά τους πακέτα εξαπάτησης, θα πρέπει να αναπαράγουν το σχήμα κρυπτογράφησης και να βρουν το κλειδί (το οποίο αλλάζει σε κάθε σύνδεση).

Συνιστώ ανεπιφύλακτα να χρησιμοποιήσετε μια βιβλιοθήκη για αυτό. Προτείνω τη χρήση λιπνάτριο, γιατί είναι ιδιαίτερα απλό και έχει εξαιρετικά μαθήματα. Ιδιαίτερα ενδιαφέρον είναι το σεμινάριο για ανταλλαγή κλειδιών, το οποίο σας επιτρέπει να δημιουργείτε νέα κλειδιά σε κάθε νέα σύνδεση.

Πρωτόκολλο εφαρμογής: Συμπέρασμα

Αυτό ολοκληρώνει το πρωτόκολλο εφαρμογής. Πιστεύω ότι η συμπίεση είναι εντελώς προαιρετική και η απόφαση χρήσης εξαρτάται μόνο από το παιχνίδι και το απαιτούμενο εύρος ζώνης. Η κρυπτογράφηση, κατά τη γνώμη μου, είναι υποχρεωτική, αλλά στο πρώτο πρωτότυπο μπορείτε να το κάνετε χωρίς αυτό.

Λογική Εφαρμογής

Μπορούμε πλέον να ενημερώσουμε την κατάσταση στον υπολογιστή-πελάτη, αλλά ενδέχεται να αντιμετωπίσουμε προβλήματα λανθάνουσας κατάστασης. Ο παίκτης, μετά την είσοδο, πρέπει να περιμένει μια ενημέρωση κατάστασης παιχνιδιού από τον διακομιστή για να δει τι αντίκτυπο είχε στον κόσμο.

Επιπλέον, μεταξύ δύο ενημερώσεων κατάστασης, ο κόσμος είναι εντελώς στατικός. Εάν ο ρυθμός ενημέρωσης κατάστασης είναι χαμηλός, τότε οι κινήσεις θα είναι πολύ σπασμωδικές.

Υπάρχουν διάφορες τεχνικές για τον μετριασμό των επιπτώσεων αυτού του προβλήματος και θα τις συζητήσω στην επόμενη ενότητα.

Τεχνικές Καθυστέρησης Εξομάλυνσης

Όλες οι τεχνικές που περιγράφονται σε αυτήν την ενότητα αναλύονται λεπτομερώς στη σειρά. Γρήγορο παιχνίδι για πολλούς παίκτες Gabriel Gambetta. Συνιστώ ανεπιφύλακτα να διαβάσετε αυτήν την εξαιρετική σειρά άρθρων. Περιλαμβάνει επίσης μια διαδραστική επίδειξη για να δείτε πώς λειτουργούν αυτές οι τεχνικές στην πράξη.

Η πρώτη τεχνική είναι να εφαρμόσετε το αποτέλεσμα εισόδου απευθείας χωρίς να περιμένετε απάντηση από τον διακομιστή. Ονομάζεται πρόβλεψη από την πλευρά του πελάτη. Ωστόσο, όταν ο πελάτης λαμβάνει μια ενημέρωση από τον διακομιστή, πρέπει να επαληθεύσει ότι η πρόβλεψή του ήταν σωστή. Εάν αυτό δεν ισχύει, τότε απλά πρέπει να αλλάξει την κατάστασή του σύμφωνα με αυτό που έλαβε από τον διακομιστή, επειδή ο διακομιστής είναι αυταρχικός. Αυτή η τεχνική χρησιμοποιήθηκε για πρώτη φορά στο Quake. Μπορείτε να διαβάσετε περισσότερα για αυτό στο άρθρο. Ανασκόπηση κωδικού Quake Engine Fabien Sanglars [μετάφραση στο Habré].

Το δεύτερο σύνολο τεχνικών χρησιμοποιείται για την εξομάλυνση της κίνησης άλλων οντοτήτων μεταξύ δύο ενημερώσεων κατάστασης. Υπάρχουν δύο τρόποι για να λυθεί αυτό το πρόβλημα: παρεμβολή και παρέκταση. Στην περίπτωση της παρεμβολής λαμβάνονται οι δύο τελευταίες καταστάσεις και εμφανίζεται η μετάβαση από τη μία στην άλλη. Το μειονέκτημά του είναι ότι προκαλεί ένα μικρό κλάσμα της καθυστέρησης, επειδή ο πελάτης βλέπει πάντα τι συνέβη στο παρελθόν. Η παρέκταση αφορά την πρόβλεψη που πρέπει να βρίσκονται τώρα οι οντότητες με βάση την τελευταία κατάσταση που έλαβε ο πελάτης. Το μειονέκτημά του είναι ότι εάν η οντότητα αλλάξει εντελώς την κατεύθυνση κίνησης, τότε θα υπάρξει μεγάλο σφάλμα μεταξύ της πρόβλεψης και της πραγματικής θέσης.

Η τελευταία, πιο προηγμένη τεχνική, χρήσιμη μόνο σε FPS, είναι αντιστάθμιση υστέρησης. Όταν χρησιμοποιείται αντιστάθμιση καθυστέρησης, ο διακομιστής λαμβάνει υπόψη τις καθυστερήσεις του πελάτη όταν πυροβολεί στον στόχο. Για παράδειγμα, εάν ένας παίκτης έκανε ένα headshot στην οθόνη του, αλλά στην πραγματικότητα ο στόχος του βρισκόταν σε διαφορετική τοποθεσία λόγω της καθυστέρησης, τότε θα ήταν άδικο να αρνηθούμε στον παίκτη το δικαίωμα να σκοτώσει λόγω της καθυστέρησης. Έτσι, ο διακομιστής επαναφέρει το χρόνο πίσω στο χρόνο που ο παίκτης πυροβόλησε για να προσομοιώσει αυτό που είδε ο παίκτης στην οθόνη του και να ελέγξει για σύγκρουση μεταξύ της βολής του και του στόχου.

Ο Glenn Fiedler (όπως πάντα!) έγραψε ένα άρθρο το 2004 Φυσική Δικτύων (2004), στο οποίο έθεσε τα θεμέλια για τον συγχρονισμό των προσομοιώσεων φυσικής μεταξύ του διακομιστή και του πελάτη. Το 2014 έγραψε μια νέα σειρά άρθρων φυσική δικτύωσης, στο οποίο περιέγραψε άλλες τεχνικές για το συγχρονισμό των προσομοιώσεων φυσικής.

Υπάρχουν επίσης δύο άρθρα στο wiki της Valve, Πηγή Multiplayer Networking и Μέθοδοι αντιστάθμισης καθυστέρησης στη σχεδίαση και βελτιστοποίηση πρωτοκόλλου εντός παιχνιδιού πελάτη/διακομιστή αντιμετώπιση της αποζημίωσης καθυστέρησης.

Πρόληψη απάτης

Υπάρχουν δύο κύριες τεχνικές πρόληψης της εξαπάτησης.

Πρώτον, καθιστώντας δυσκολότερο για τους απατεώνες να στέλνουν κακόβουλα πακέτα. Όπως αναφέρθηκε παραπάνω, ένας καλός τρόπος για να το εφαρμόσετε είναι η κρυπτογράφηση.

Δεύτερον, ο έγκυρος διακομιστής πρέπει να λαμβάνει μόνο εντολές/εισόδου/ενέργειες. Ο υπολογιστής-πελάτης δεν θα πρέπει να μπορεί να αλλάξει την κατάσταση στον διακομιστή εκτός από την αποστολή εισόδου. Στη συνέχεια, ο διακομιστής, κάθε φορά που λαμβάνει είσοδο, πρέπει να το ελέγχει για εγκυρότητα πριν το εφαρμόσει.

Λογική Εφαρμογής: Συμπέρασμα

Συνιστώ να εφαρμόσετε έναν τρόπο προσομοίωσης υψηλής καθυστέρησης και χαμηλών ρυθμών ανανέωσης, ώστε να μπορείτε να δοκιμάσετε τη συμπεριφορά του παιχνιδιού σας σε κακές συνθήκες, ακόμη και όταν ο πελάτης και ο διακομιστής εκτελούνται στον ίδιο υπολογιστή. Αυτό απλοποιεί σημαντικά την εφαρμογή των τεχνικών εξομάλυνσης καθυστερήσεων.

Άλλοι Χρήσιμοι Πόροι

Εάν θέλετε να εξερευνήσετε άλλους πόρους μοντέλων δικτύου, μπορείτε να τους βρείτε εδώ:

• Το ιστολόγιο του Glenn Fiedler — αξίζει να διαβάσετε ολόκληρο το blog του, υπάρχουν πολλά εξαιρετικά άρθρα σε αυτό. Εδώ συλλέγονται όλα τα άρθρα σχετικά με τις τεχνολογίες δικτύου.
• Φοβερό παιχνίδι δικτύωσης by M. Fatih MAR είναι μια ολοκληρωμένη λίστα άρθρων και βίντεο σχετικά με μηχανές δικτύωσης βιντεοπαιχνιδιών.
• В wiki subreddit r/gamedev Υπάρχουν επίσης πολλοί χρήσιμοι σύνδεσμοι.

Πηγή: www.habr.com