Cet article est un aperçu de la technologie de synchronisation, principalement pour la sélection de l'architecture et du framework.
Les utilisateurs ont de fortes interactions les uns avec les autres et les exigences en temps réel sont élevées, de sorte que le serveur doit activement envoyer des messages. Nous choisissons des protocoles tels que tcp/ws comme charge réseau de base.
Fondamentalement, tous les types de jeux peuvent choisir cette architecture.
Avantage:
Poussée active, faible latence. Forte interaction. (décision commerciale)
Désavantages:
La communauté est relativement inactive. La pile technologique stable prête à l'emploi est essentiellement C/C++. Selon la particularité du métier, il est également difficile d'avoir un cadre général.
Les méthodes de synchronisation de jeu spécifiques peuvent être divisées en synchronisation de trame et synchronisation d'état.
Selon le type de jeu spécifique, nous choisissons différents modèles de synchronisation :
Synchronisation des images :
Exigences de sécurité relativement faibles (plug-in, triche, etc.). Les exigences de stabilité du réseau sont relativement élevées et la capacité anti-retard est relativement faible. Le moteur physique est moins utilisé, voire pas du tout. Le nombre d'utilisateurs monoposte est faible (peu de messages synchronisés)
Tels que King of Glory, Snake, jeux de combat, StarCraft, etc.
Pour les modèles simples, vous pouvez choisir le verrouillage (une personne gèle la carte complète de tout le monde).
À l'heure actuelle, les cadres optimistes sont plus couramment utilisés. Le serveur exécute des cadres et la commande client prend effet dans le cadre qu'elle peut suivre.
Synchronisation d'état :
Généralement, la position, la direction et la vitesse du joueur sont synchronisées, et le serveur calcule l'état du joueur et l'envoie au client pour la lecture.
Comme les fesses, manger du poulet, lol, WOW et ainsi de suite.
L'architecture spécifique du serveur de jeu peut être simplement divisée en type de salle et type de grande carte.
Service de type de chambre :
Étape 1 : Des dizaines de milliers d'utilisateurs actifs quotidiens, peu de gameplays et relativement simples. Une seule structure de serveur de jeu peut être utilisée.
La proposition de connexion est fractionnée. Il peut y avoir différents canaux permettant aux joueurs de se connecter, tels que wx, qq, appleid, etc.
Phase 2 : Le gameplay est stable, le DAU est plus élevé et de nouveaux gameplays sont constamment itérés.
À ce stade, le serveur proxy peut être utilisé comme couche intermédiaire pour enregistrer l'état du lecteur.
Étape 3 : Le DAU est plus élevé et ne peut être transporté par un seul service.
Attribuez différents agents via un passeport pour effectuer l'équilibrage de charge.
Le gamemanager assigne différents jeux pour faire le chargement.
complet:
Plus le journal requis, la base de données, etc.
Châssis de base en option :
https://github.com/name5566/leaf