Persistance
Gérez des mondes persistants avec des déploiements toujours en ligne 24 h/24, 7 j/7 sur Flottes privées.
De nombreux genres (MMO, sandboxes, jeux sociaux) exploitent les mondes persistants pour permettre aux joueurs de :
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 et placé par les joueurs,
participer à des combats de raid épiques durant des heures avec de grands groupes ou des guildes entières.
Explorez des stratégies pour offrir la meilleure expérience joueur possible, maîtriser les coûts et supprimer la frustration des joueurs due aux pannes ou aux rollbacks.
Voir aussi Déploiements l’orchestration cloud afin d’utiliser la tarification fractionnée des vCPU.
✔️ Préparation
Pour permettre des déploiements persistants, ininterrompus et toujours en ligne 24 h/24, 7 j/7 :
Créez une nouvelle version d’application (ou mettez à jour une version existante).
Dans le tableau de bord - choisissez « persistent » au lieu de spécifier une durée max.
Avec l’API - spécifiez
"max_duration": -1dans votre requête de version d’application.
Créez une flotte privée dans le tableau de bord et planifiez les hôtes.
La création de la flotte est gratuite ; faites-le d’abord pour prévisualiser les emplacements et les détails.
Choisissez des spécifications de machines virtuelles (Performance) ou de bare metal (Overdrive).
Il vous sera demandé de confirmer le prix final avant de planifier les hôtes.
Déployez de nouveaux serveurs avec Navigateur de serveurs ou des intégrations personnalisées.
Le navigateur de serveurs démarre les serveurs selon les politiques de mise à l'échelle.
Les intégrations personnalisées doivent démarrer les serveurs à l’aide de l’API de flotte privée.
Testez votre mise à l'échelle des serveurs 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.
Si vous avez besoin d’aide, veuillez nous contacter sur Discord. Pour l’assistance aux jeux en direct, consultez notre système de tickets.
🔑 Propriété des serveurs
Avantages et inconvénients des modèles de propriété modernes par rapport aux modèles traditionnels avec l'edge computing.
Hébergement par le studio
Des serveurs traditionnellement gérés par le studio, les coûts d'hébergement étant récupérés sur les revenus du jeu.
👍 Avantages
Aucun frais supplémentaire pour les joueurs - le coût de l'hébergement est récupéré sur les revenus du studio.
Forte compatibilité client/serveur grâce à un couplage lâche du client/serveur/service.
Plus résistant à la triche et aux abus grâce au code source fermé du jeu.
👎 Inconvénients
Support limité du modding communautaire afin de garantir l'intégrité et l'équité du serveur.
Serveurs communautaires
Permettez à vos joueurs de financer leurs propres serveurs sur Edgegap, et débloquez des revenus d'hébergement qui iraient autrement à des services d'hébergement tiers dépourvus d'expertise sur l'expérience utilisateur.
👍 Avantages
Améliorez le support du modding grâce à des mods et des versions sélectionnés.
Améliorez votre jeu de manière itérative grâce à une collaboration directe avec la communauté.
Renforcez la confiance de la communauté grâce à une meilleure longévité du jeu et à un modèle en libre-service.
👎 Inconvénients
Un investissement de développement est nécessaire pour le support du modding et la compatibilité.
Davantage d'efforts opérationnels pour gérer la communauté et les systèmes de paiement.
Risque accru de rétro-ingénierie en raison de l'exposition des éléments internes du jeu.
🥛 Capacité et mise à l'échelle
Apprenez des techniques avancées pour optimiser le coût des serveurs et la qualité de service.
Lancer vos déploiements manuellement, en collant l’URL et les ports, ne suffira pas pour un jeu en direct.
Automatisez les flux de jeu populaires pour gérer les sessions et la mise à l’échelle à la demande avec l’une ou l’autre des options suivantes :
Manches plus courtes
Parties à la demande
Classement par niveau et/ou Règles personnalisées
Persistant ou en manches
Hubs régionaux sociaux
Affectation automatique et/ou Recherche personnalisée
Backend personnalisé :
Migrer des parties en cours
Capacité
Les déploiements ne suivent ni ne gèrent les connexions actives des joueurs après que vous Déploiements pour vous donner un contrôle absolu et la liberté de mettre en œuvre n'importe quel design.
Mettez en place une gestion de la capacité pour garantir que vos serveurs :
contrôlent le coût de l'hébergement - benchmark et optimisent l'utilisation des ressources du serveur par joueur,
fournissent une expérience cohérente - maintiennent le CCU par serveur dans une plage sûre.
Voir Navigateur de serveurs pour une gestion automatisée de la capacité avec notre service managé.
Conseils : si vous choisissez de développer un orchestrateur de session et de capacité personnalisé.
La procédure doit empêcher la concurrence pour la capacité avec des réservations simultanées.
Envoyez fréquemment un heartbeat à votre orchestrateur pour synchroniser l'état du serveur.
Retirez rapidement du processus de découverte les serveurs obsolètes, en panne ou arrêtés.
Déclenchez un timeout des réservations de capacité si les joueurs ne se connectent pas dans le délai alloué.
Déconnectez les clients et libérez la capacité lorsqu'une inactivité du joueur est détectée.
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 de serveur utilisant des versions d'application nécessitant davantage de ressources CPU ou mémoire.
Montée en charge
Stratégies intelligentes de mise à l'échelle préviennent les temps d'attente en file des joueurs et minimisent le coût des serveurs inactifs.
Nous recommandons de dimensionner les ressources en fonction des joueurs simultanés plutôt que de la charge machine (CPU et RAM), car les fluctuations de charge peuvent entraîner une disponibilité imprévisible.
La mise à l'échelle ne nécessite pas d'« estimation approximative » du trafic régional ou du coût du serveur. Planifiez Flottes privées la capacité pour la marée basse et basculent automatiquement vers le cloud lors de pics de trafic inattendus.
Activer Activer la mise en cache dans la version de votre application pour déployer des serveurs en quelques secondes.
Réduction de charge
Arrêter les serveurs sans précaution peut nuire négativement à l'expérience joueur. Prenez en compte ces facteurs et testez les changements avant de les déployer :
La détection de l'inactivité / déconnexion des joueurs est-elle fiable ?
L'absence d'entrée du joueur est-elle fiable ? Les joueurs utilisent souvent des bots et des macros pour simuler une activité et éviter d'être expulsés, ce qui entraîne un temps d'attente en file lors de la reconnexion.
Existe-t-il d'autres indicateurs d'activité plus difficiles à falsifier ?
Existe-t-il une solution de design de jeu pour atténuer l'impact/la motivation d'utiliser des bots ?
Pouvez-vous redémarrer les serveurs facilement et rapidement, sans rollback majeur ?
Votre serveur peut avoir besoin d'un certain temps pour redémarrer et restaurer l'état. La restauration de l'état entraîne-t-elle des coûts supplémentaires de transfert de données ou de service avec votre backend de jeu ?
Pouvez-vous masquer le chargement du serveur avec un mini-jeu / lobby pour garder les joueurs engagés ?
Les joueurs sont-ils liés à des instances de serveur spécifiques ou peuvent-ils migrer facilement ?
Comment la connexion à un autre serveur affecte-t-elle le compte du joueur, l'historique des achats, l'expérience sociale, la progression, l'inventaire et la rétention globale des joueurs ?
Passez en revue votre Persistance et assurez-vous qu'aucune donnée critique ne soit perdue.
La transparence et la gestion de la communauté font des merveilles en cas d'interruption de service.
💭 Configuration et état
Définissez les paramètres de seed du serveur et gérez de manière fiable l'état des joueurs/serveurs.
Gestion de la configuration
La configuration ou seed désigne les données initiales transmises au serveur lors du déploiement :
variables injectées spécifiques à l'environnement:
par ex. les données de compatibilité des versions client/serveur,
paramètres, clés et secrets d'intégration tierce.
La configuration est immuable. Lue au démarrage du serveur, sans modification pendant l'exécution.
Gestion de l'état
L'état désigne les données d'exécution, résultat des actions précédentes des joueurs et des événements du serveur :
connexion du joueur, changements d'état contrôlés par le joueur (par ex. Pawn),
changements de propriétés contenus dans le niveau/la scène (par ex. Actor, Objet de jeu),
changements liés au mode de jeu, état du jeu, ou scène du jeu informations.
Les données d'état changent fréquemment. La synchronisation se produit de nombreuses fois par seconde (tick rate).
Des sauvegardes fréquentes de l'état aident à prévenir la perte de données en cas de plantages/problèmes inattendus :
mises à jour asynchrones avec une API de backend de jeu tierce, par ex. Nakama de Heroic Labs,
heartbeat périodique du serveur transférant des fichiers d'état sérialisés vers le stockage d'objets cloud.
Les composants avec état ont généralement un propriétaire clairement désigné, soit le serveur, soit un joueur.
Objets appartenant au serveur
Les objets appartenant au serveur ne peuvent être manipulés que par le serveur. Les joueurs connectés ont un accès en lecture limité aux objets appartenant au serveur.
Les objets appartenant au serveur peuvent être restaurés par un serveur de remplacement (migration d'état). Ils ne sont généralement pas partagés entre des serveurs s'exécutant simultanément (req. server meshing).
Objets appartenant au joueur
Les objets appartenant au joueur peuvent être manipulés à la fois par les joueurs et par le serveur. Attribuer la propriété des objets du monde persistant aux joueurs peut faciliter le stockage et la migration d'état.
Sauvegardez les objets appartenant au joueur sur l'appareil du joueur ou dans le backend du jeu entre les sessions. Chiffrez l'état du joueur et/ou téléversez des sommes de contrôle de l'état pour détecter les modifications non autorisées.
Objectifs de reprise
Certaines catégories de données peuvent être plus sensibles à la perte de données et au temps de reprise.
Nous recommandons fortement d'en discuter au sein de votre équipe :
Catégories de données traitées dans vos clients de jeu, serveurs et backend de jeu.
Impact de la perte de données pour chaque catégorie, pour vos joueurs et pour votre entreprise.
Recovery Point Objective - quantité acceptable de perte de données avant un préjudice grave.
Recovery Time Objective - à quelle vitesse le système doit-il se rétablir.
Consultez ci-dessous notre exemple simplifié d'évaluation des objectifs de reprise :
compte, abonnement et achats
🔥 5 min
🔥 30 min
progression, inventaire et niveau de compétence
🔥 5 min
🔥60 min
modération, performances et suivi des erreurs
⚠️ 30 min
⚠️ 8 h
fonctionnalités sociales, historique du chat, analyses comportementales
⏬ 24 h
⏬ 72 h
Préparez à l'avance un plan de reprise après sinistre pour vos catégories les plus critiques.
La gestion des plantages du serveur dépend de votre politique de redémarrage du processus. L'état du serveur peut être perdu.
👀 Observabilité
Les serveurs persistants de longue durée apportent de nouveaux défis d'observabilité, notamment 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 serveur afin de gagner en traçabilité et en supervision supplémentaire du temps de disponibilité.
Connectez votre Stockage des points de terminaison pour enregistrer les journaux de déploiement, sinon ils seront supprimés !
Mis à jour
Ce contenu vous a-t-il été utile ?