Persistance
Apprenez à gérer des mondes persistants avec des déploiements toujours en ligne 24/7 sur Flottes privées.
De nombreux genres (MMO, bac à sable, jeux sociaux) tirent parti des mondes persistants pour permettre aux joueurs :
rencontrer et socialiser avec de nouveaux amis ; nourrir des communautés de joueurs organiques,
explorer un monde ouvert vivant rempli de contenu généré par les utilisateurs placé par les joueurs,
participer à des raids épiques durant des heures avec de grands groupes ou des guildes entières.
Explorez des stratégies pour offrir la meilleure expérience possible aux joueurs, garder les coûts sous contrôle et supprimer la frustration des joueurs due aux pannes ou aux retours en arrière. Améliorez le modèle de serveur traditionnel en apportant les avantages de l'edge computing emballés pour une utilisation facile par les développeurs de jeux.
Alternativement, voir Déploiements orchestration pour utiliser la tarification vCPU fractionnée.
✔️ Préparation
Pour permettre des déploiements persistants et ininterrompus 24/7 toujours en ligne :
créez une nouvelle version d'application (ou mettez à jour une version existante) avec notre API,
spécifiez
"max_duration": -1pour empêcher la terminaison automatisée après 24h,
Utilisez API de déploiement de flotte privée pour démarrer serveurs en veille par Persistance.
Choisissez entre des machines virtuelles (Performance) ou des spécifications Bare Metal (Overdrive).
Testez la mise à l'échelle de votre serveur et le processus d'arrêt pour vérifier la fiabilité de vos contrôles de coûts. L'état du serveur stocké en mémoire sera perdu une fois le déploiement arrêté, voir Persistance.
🔑 Propriété du serveur
Explorez les avantages et les inconvénients des modèles de propriété modernes et traditionnels avec une touche d'edge computing.
Hébergement par le studio
L'hébergement des serveurs est traditionnellement géré par le studio, couvrant le coût de l'hébergement à partir des revenus du jeu.
👍 Avantages
tarification produit transparente - le coût de l'hébergement est couvert par la licence/abonnement du joueur,
forte compatibilité client/serveur avec découplage léger des clients, services et montée en charge,
plus résistant à la triche et au reverse engineering en raison de la nature propriétaire des serveurs.
👎 Inconvénients
le support de modding communautaire est limité pour garantir l'intégrité et la stabilité du serveur.
Serveurs communautaires
Permettez à vos joueurs d'héberger et de financer leurs propres serveurs et supprimez le besoin de services de location tiers. Canalisez les revenus via votre studio plutôt que via des tiers n'ayant pas de visibilité sur la qualité de l'expérience utilisateur finale.
👍 Avantages
support de modding renforcé via une liste organisée de mods Applications et versions,
boucle de retour joueur améliorée grâce à une collaboration plus étroite avec la communauté,
risque financier réduit car les joueurs couvrent le coût de l'hébergement.
👎 Inconvénients
plus d'opérations pour le studio - modération des demandes des joueurs et collecte des paiements,
compatibilité client/serveur affaiblie en raison du nombre accru de versions modifiées,
susceptible aux tricheurs en raison de la base de code distribuée et de la possibilité de reverse engineering.
🥛 Capacité & Mise à l'échelle
Apprenez des techniques avancées pour optimiser la disponibilité des serveurs, le coût d'hébergement et la qualité de service.
Capacité
Les déploiements ne suivent ni ne gèrent les connexions actives des joueurs après vous Déploiements pour vous donner un contrôle absolu et la liberté d'implémenter n'importe quel design.
Mettez en œuvre la gestion de la capacité pour assurer que vos serveurs :
maximisent les économies de coût - mesurez et utilisez efficacement les ressources serveur,
offrent un gameplay fluide - empêchent la surcharge des serveurs par trop de joueurs simultanés,
éviter les mauvaises critiques dues aux plantages - détecter et gérer les exceptions inattendues.
Pour assurer une gestion efficace de la capacité serveur :
libérez les emplacements de joueurs si les joueurs affectés au serveur de jeu ne se connectent pas dans les quelques secondes,
envoyez fréquemment un message de battement minimal des clients vers le serveur pour suivre l'activité,
déconnectez les clients et libérez les emplacements de joueurs si aucune activité n'est détectée pendant plusieurs secondes,
empêchez d'ajouter des joueurs à des serveurs à capacité pleine et sans emplacements disponibles.
Voir Navigateur de serveurs pour la gestion automatisée de la capacité avec notre service géré.
La quantité de ressources de déploiement réservées ne peut pas être modifiée pendant l'exécution. Mise à l'échelle horizontale avec de nouvelles instances serveur utilisant des versions d'application nécessitant plus de ressources CPU ou mémoire.
Monter en charge
La mise à l'échelle des serveurs persistants ne nécessite pas de « deviner » le trafic régional ou le coût serveur. Réservez Flottes privées de la capacité pour la marée basse et basculez automatiquement vers le cloud lors de pics inattendus.
Activer Mise en cache active dans votre version d'application pour déployer des serveurs en quelques secondes.
Mettez en place des stratégies de mise à l'échelle des serveurs pour :
permettre un hébergement à grande échelle tout en protégeant soigneusement contre les abus,
minimiser le gaspillage de coûts serveur dû aux serveurs en veille vides,
éviter de longues files d'attente en répondant rapidement à l'augmentation de la demande des joueurs.

Points clés d'intégration
Les clients intègrent l'Autorité de Mise à l'Échelle - Matchmaking, Navigateur de serveurs, ou une solution personnalisée.
Découvrez d'autres joueurs, réservez de la capacité dans des serveurs en cours d'exécution, ou demandez de nouveaux serveurs si nécessaire.
L'Autorité de Mise à l'Échelle assigne des serveurs en cours d'exécution ou démarre de nouveaux serveurs pour desservir les joueurs.
Le serveur notifie l'Autorité de Mise à l'Échelle en temps réel du démarrage/arrêt du serveur et des changements de connexion des joueurs.
L'Autorité de Mise à l'Échelle supprime (expire) les enregistrements obsolètes des serveurs non réactifs (plantés).
Les clients se connectent et établissent des sessions de jeu avec le serveur directement, puis poursuivent le jeu.
Nous recommandons fortement de dimensionner en fonction du nombre de connexions plutôt que de la charge physique (CPU & RAM), car des fluctuations momentanées de la charge physique peuvent entraîner une disponibilité imprévisible.
La quantité de ressources de déploiement réservées ne peut pas être modifiée pendant l'exécution. Mise à l'échelle horizontale avec de nouvelles instances serveur utilisant des versions d'application nécessitant plus de ressources CPU ou mémoire.
Descendre en charge
Des politiques de réduction efficaces sont essentielles pour optimiser les coûts, mais éteindre des serveurs sans précaution peut impacter négativement l'expérience des joueurs. Considérez ces facteurs et testez les changements avant de les déployer :
Votre détection de l'activité / déconnexion des joueurs est-elle fiable ?
L'absence d'entrée indique-t-elle de manière fiable l'inactivité du joueur ? Les joueurs utilisent souvent des bots, macros et autres techniques pour simuler l'activité et maintenir une connexion active afin d'éviter les temps d'attente.
Y a-t-il des actions fréquemment effectuées par des joueurs actifs qui sont difficiles à simuler ?
L'utilisation de bots ou de macros est-elle un problème ou une fonctionnalité avec Persistance les serveurs ?
L'arrêt des serveurs est-il facilement et rapidement réversible (remonter en charge) ?
Une fois atteint Déploiements, votre serveur peut nécessiter du temps supplémentaire pour effectuer l'initialisation du moteur et Persistance (restauration de l'état). Engagez-vous des coûts supplémentaires pour le calcul ou le transfert de données avec les services de jeu ? Ce temps d'attente affecte-t-il l'expérience des joueurs ?
Pouvez-vous masquer le chargement du serveur avec une scène de chargement, un mini-jeu, un hall ou par d'autres moyens ?
Les joueurs sont-ils liés à des instances de serveur spécifiques ou peuvent-ils migrer facilement ?
Comment la connexion à un serveur différent influence-t-elle le compte du joueur, l'historique des achats, l'expérience sociale, la progression, l'inventaire et d'autres aspects du gameplay ?
Passez en revue votre Persistance et assurez-vous que les données critiques ne sont pas perdues.
Mettez en œuvre des méthodes automatisées ou des outils pour les joueurs afin de restaurer les données critiques.
Fournissez un support humain et communiquez avec votre communauté au sujet des pannes et des problèmes.
🔎 Découvrabilité
Pour trouver des serveurs actifs acceptant de nouveaux joueurs, implémentez une ou plusieurs méthodes de découverte :
Démarrez de nouvelles parties lorsque suffisamment de joueurs se joignent Matchmaking.
Ajoutez des joueurs pour remplacer les départs dans les matchs existants avec du backfill.
Permettez aux joueurs de parcourir les serveurs et de choisir dans une liste avec Navigateur de serveurs.
💭 Configuration & État
Intégrez des services pour définir les exigences initiales du serveur et gérer l'état des joueurs et des serveurs.
Gestion de la configuration
La configuration se réfère aux données initiales passées à votre serveur lors du déploiement :
variables injectées spécifiques à l'environnement:
par ex. données de compatibilité version client/serveur,
paramètres, clés et secrets d'intégration tierce.
Gestion de l'état
L'état se réfère aux données décrivant le résultat d'une série d'actions précédentes des joueurs et d'événements serveur :
connexion du joueur, changements d'état contrôlés par le joueur (par ex. Pawn),
changements liés aux objets contenus dans le niveau/scene (par ex. Actor, Objet de jeu),
changements liés à mode de jeu, état du jeu, ou scène de jeu informations.
Effectuez des sauvegardes d'état fréquentes pour prévenir la perte de données en cas de problèmes inattendus côté client ou serveur :
asynchrones en temps réel en utilisant un service tiers, par ex. Nakama par Heroic Labs,
au démarrage ou à l'arrêt client/serveur, sous forme de fichiers d'état désérialisés dans stockage d'objets cloud.
Les objets de jeu désignent généralement un propriétaire qui les contrôle, cela peut être soit le serveur soit un joueur.
Objets possédés par le serveur
Les objets possédés par le serveur ne peuvent être manipulés que par le serveur. Les joueurs connectés ont un accès en lecture limité aux objets possédés par le serveur. Les objets possédés par le serveur ne sont généralement pas partagés avec d'autres serveurs.
Les objets possédés par le serveur peuvent être chargés par un serveur de remplacement en cas de crash inattendu du serveur. Utilisez ID de déploiement pour identifier votre nouveau fichier de sauvegarde lors du premier lancement, et pour stocker l'état des objets possédés par le serveur.
Objets possédés par les joueurs
Les objets possédés par les joueurs peuvent être manipulés à la fois par les joueurs et par le serveur. Assigner la propriété d'objets persistants aux joueurs facilite la migration vers d'autres serveurs ultérieurement.
Sauvegardez l'état des objets possédés par les joueurs sur l'appareil du joueur ou un backend de jeu entre les sessions de jeu.
Objectifs de récupération
En cas de problèmes, certaines catégories de données peuvent être plus sensibles à la perte de données, par exemple :
données de compte, d'abonnement, d'achat et de microtransaction - critique,
données de progression, de réalisations, de classements et d'inventaire - importantes,
données de détection de triche, modération, performances et suivi des erreurs - importantes,
données de comportement des joueurs, sociales, de chat - peu importantes.
Mettez en œuvre la restauration des achats à partir d'une source d'historique des transactions indépendante pour une meilleure expérience.
Nous recommandons vivement de discuter des points suivants au sein de votre équipe :
catégories de données traitées dans vos clients et serveurs de jeu,
importance et sensibilité de chaque catégorie pour votre entreprise et vos joueurs,
Recovery Point Objective (RPO) - quantité acceptable de perte de données avant qu'un préjudice sérieux ne survienne,
Recovery Time Objective (RTO) - durée acceptable d'indisponibilité avant qu'un préjudice sérieux ne survienne.
Un plantage inattendu du serveur entraînera le redémarrage automatique de votre serveur. L’état du serveur peut être perdu.
👀 Observabilité
Les serveurs persistants de longue durée apportent de nouveaux défis d'observabilité, en particulier la détection d'anomalies dans la surveillance, la journalisation et le suivi des bugs.
Nous recommandons fortement de mettre en place des alertes pour les redémarrages de serveurs pour obtenir plus de visibilité sur les problèmes.
Notre Stockage d'endpoint l'intégration des logs transfère uniquement les logs après Déploiements, ajoutez des logs personnalisés et un suivi des bugs (comme Sentry) pour dépanner les pannes partielles et les bugs.
Envisagez de réserver Flottes privées capacité de réserve pour les jeux ayant des schémas de trafic prévisibles.
Mis à jour
Ce contenu vous a-t-il été utile ?

