La clé de la conception de l'architecture d'un jeu est de prendre en compte l'efficacité dès le début. Se concentrer trop tôt sur les mesures, la journalisation, la télémétrie et la monétisation peut entraîner un gonflement excessif de l'architecture du jeu. Intégrer tout cela dans votre serveur de jeu au moment de l'exécution peut en fait réduire le retour sur investissement (ROI) et augmenter le coût total de possession.

Commencez plutôt par un produit minimum viable (MVP) le plus tôt possible. Faites fonctionner le serveur, le client, le netcode et le système de matchmaker, puis construisez à partir de là. Vous devriez également envisager de choisir votre fournisseur d'hébergement dès le départ - il peut fournir des solutions et une infrastructure préétablies qui peuvent vous faire gagner du temps en matière de développement.

Lorsqu'il s'agit de la conception de votre jeu, à quoi ressemble la simplicité ? L'image ci-dessus montre une conception complexe avec non seulement une instance de serveur de jeu, mais aussi de nombreux processus auxiliaires sur la même machine, y compris des exécutables de matchmakers, de journalisation et de métrologie.

Cette complexité n'apparaît pas nécessairement avant que vous ne commenciez à effectuer des tests d'échelle, et c'est alors que vous commencez à vous rendre compte que ces éléments ne fonctionnent pas bien ensemble lorsqu'il y a des milliers de joueurs. En outre, les services auxiliaires peuvent ne pas être protégés par des clôtures de ressources, de sorte qu'ils peuvent commencer à cannibaliser les ressources de la machine et avoir un impact sur les performances du joueur. La simplicité peut contribuer à atténuer ces problèmes.

En termes de conception de serveur de jeu, la simplicité consiste à regrouper les choses dans une seule instance de serveur, comme un seul exécutable, et un matchmaker résilient (peut-être hébergé sur un service dorsal plutôt que sur une machine). Ainsi, lorsque l'un des serveurs de jeu est perdu, il n'entraîne pas les autres joueurs avec lui et la zone affectée reste réduite. À l'échelle, si un serveur de jeu de cette conception présente des dysfonctionnements, cela n'aura pas d'incidence sur l'expérience des joueurs.

Pour minimiser les risques liés aux coûts, ne conservez pas sur la même machine des processus auxiliaires tels que le débogage, les observateurs et l'appariement. Si un serveur de jeu meurt et que vous avez des machines en nuage sur lesquelles il est dimensionné, vous laissez les processus auxiliaires "zombifiés". Ils consomment toujours des ressources, ce qui coûte de l'argent à votre studio, et vous n'avez aucun moyen de les arrêter.

Envisagez plutôt de faire des processus auxiliaires, tels que le matchmaking et le débogage, des sous-processus du serveur de jeu - restez simple. Ainsi, si vous perdez le serveur de jeu, il emporte les sous-processus avec lui, au lieu de les laisser tourner en arrière-plan. Dans ce cas, si le serveur cesse de fonctionner, vous pouvez en créer un autre sans avoir à supporter les ressources et les coûts supplémentaires associés aux processus "zombifiés".

Dans les jeux multijoueurs avec des sessions de longue durée, il peut y avoir des problèmes tels que des fuites de mémoire, une utilisation croissante de la RAM, et plus encore, qui peuvent ne pas apparaître jusqu'à ce que vous exécutiez votre jeu à grande échelle.

Voici quelques risques associés aux sessions de jeu de longue durée :

• Attaques DDoS : Étant donné que l'IP de l'instance de jeu ne change pas avec un modèle de session de jeu persistant, il existe une possibilité d'attaques DDos.
• Coûts élevés de l'informatique en nuage : Il faut beaucoup de ressources coûteuses pour maintenir un jeu qui est toujours, ou presque, actif, même si les joueurs ne jouent pas.
• Interruptions dues à l'application de correctifs : Les correctifs peuvent être difficiles à gérer, car il peut y avoir des matchs actifs qui doivent être interrompus afin de corriger le jeu, ce qui entraîne une mauvaise expérience pour les joueurs.

Il existe toujours des risques et des considérations liées à l'expérience du joueur pour les sessions de jeu courtes. Même si votre jeu à deux joueurs ne dure que deux minutes, faciliter des centaines de milliers (ou plus) de ces matchs simultanés peut être coûteux et présenter des risques.

Voici quelques éléments à prendre en compte pour les sessions de jeu courtes :

• Chargement élevé du backend : Les appels constants d'API à votre backend pour faciliter les sessions de jeu courtes peuvent représenter une charge énorme, c'est pourquoi il doit être résilient.
• Les infrastructures sont durement touchées : Lorsque le serveur redémarre entre deux sessions courtes, il se peut que l'unité centrale et la mémoire vive augmentent au début du chargement des processus, ce qui peut s'avérer coûteux.
• Nécessite un solide entremetteur : Avec des sessions courtes, vous avez besoin d'un entremetteur efficace pour gérer les billets d'appariement pour les nouvelles sessions, les reconnexions, et plus encore.
• Qualité de service (QOS) : Vous aurez besoin d'un fournisseur qui vous permettra d'envoyer à votre client de jeu une liste d'adresses IP en temps réel afin de déterminer la région du serveur sur la base de télémétrie et de données réelles, plutôt que sur la base de l'emplacement physique.
• Besoin de données métriques et télémétriques : Si quelque chose ne va pas, un joueur est plus susceptible d'abandonner et de commencer une autre session plutôt que de signaler une erreur. Si vous n'obtenez pas de mesures et de télémétrie à partir de ces courtes sessions, vous risquez de ne pas voir ce qui ne va pas dans le jeu.

Voici les avantages et les inconvénients des jeux de courte durée :.

Pour:

• Il n'est pas nécessaire de stabiliser pour les longues durées d'utilisation
• Permet d'accélérer la mise en place des correctifs
• Facilité de réduction d'échelle
• Pas d'état d'inactivité
• Les fichiers journaux de chaque session facilitent le dépannage.

Cons:

• Plus de callbacks, ce qui signifie plus de charge à l'échelle
• Le coût de l'informatique en nuage pour les redémarrages n'est pas trivial à grande échelle
• Conditions de course
• Pointes de MEM/CPU au démarrage
• Plus de complexité pour le matchmaking
• Les problèmes de performance des machines peuvent être cachés

Dans les jeux multijoueurs persistants (comme les MMO), il peut y avoir certains problèmes et risques. Par exemple, la prise en charge de situations telles que les migrations de joueurs entre serveurs signifie que vous avez besoin d'un système dorsal plus robuste - y compris des serveurs coûteux et des disques durs puissants.

Voici quelques éléments à prendre en compte pour la conception de sessions de jeu persistantes :

• L'établissement d'un budget peut poser problème : Des systèmes dorsaux plus robustes sont nécessaires pour que les sessions persistantes fonctionnent. Vous devrez donc calculer les coûts de maintenance en fonction du nombre d'utilisateurs pour déterminer s'il s'agit de la bonne conception de session pour vous.
• L'informatique en nuage n'est peut-être pas réalisable : En raison des exigences élevées d'une session de jeu persistante, le cloud peut s'avérer trop coûteux pour votre projet.
• La qualité du réseau est extrêmement importante : La latence et la gestion de la latence feront de votre session de jeu persistant un succès ou un échec pour les joueurs, c'est pourquoi il est essentiel de tester votre réseau dès le début et de manière rigoureuse pour garantir une bonne expérience aux joueurs.
• L'application de correctifs est difficile et risquée : Les temps d'arrêt liés à la maintenance ne sont jamais très agréables pour les joueurs, même s'ils sont nécessaires pour améliorer l'expérience globale. Il est essentiel de communiquer avec votre communauté au sujet des heures d'entretien. Vous pouvez également envisager de faire tourner plusieurs versions du jeu en même temps et d'appliquer des correctifs au fil du temps.

Voici les avantages et les inconvénients des jeux à sessions persistantes :

Pour:

• Les serveurs sont toujours opérationnels
• Possibilité de raccourcir la boucle de jeu
• Moins de charge sur votre backend

Cons:

• Plus difficile à concevoir
• Instabilité dans le temps
• Nettoyage des sessions
• La conception de l'état de repos est nécessaire
• Nécessité d'être conscient du rôle d'entremetteur
• Les correctifs A/B peuvent prendre plus de temps

C'est une bonne idée de se préparer à d'éventuels problèmes d'expérience des joueurs à grande échelle. Le lancement, l'exécution et la mise à jour d'un jeu multijoueur peuvent être chaotiques. Il est donc important d'effectuer des tests situationnels de "résistance au chaos" et de s'assurer que le backend de votre jeu est configuré pour gérer ce chaos.

Par exemple, que se passe-t-il si tout le monde quitte votre jeu et tente de revenir dans le matchmaking en même temps ? Le fait de comprendre la réponse du backend à cette situation et de le configurer pour gérer ce problème peut vous épargner des maux de tête (et contribuer à protéger votre réputation) à long terme.

Il est probable que vous devrez patcher votre jeu lors du lancement. C'est pourquoi il est important de construire votre infrastructure avec la possibilité de mettre en place des correctifs pendant la production et le lancement. Cela permet d'accélérer et de faciliter le chaos du jour du lancement et des mises à jour à la volée, et l'impact sur les joueurs peut être limité.

L'une des façons d'aborder cette question est d'exécuter plusieurs versions de votre jeu simultanément. Cependant, vous devrez également vous assurer que votre infrastructure est en mesure de gérer plusieurs versions. En outre, vous devrez disposer d'un bac à sable contenant toutes les différentes versions.

Si vous avez déjà intégré la possibilité de faire fonctionner plusieurs versions simultanément, il n'y a pas de temps d'arrêt ni de perturbation pour les joueurs lorsque vous effectuez une mise à jour.

Il est essentiel de procéder à des tests fréquents sur les balances, c'est pourquoi la recherche d'un fournisseur capable de vous aider dans ce domaine doit être une considération majeure lors de la sélection de vos services.

La tessellation et la défragmentation du serveur sont des éléments importants à tester. La tessellation des serveurs est un facteur de coût important. Il s'agit essentiellement d'utiliser des machines métalliques bon marché pour l'hébergement dans un premier temps. Au fur et à mesure que votre base de joueurs fluctue, vous voudrez également retirer rapidement les machines cloud les plus coûteuses, ce qui est plus rentable.

L'hébergement de serveurs de jeux (Multiplay) évite l'allocation à des machines plus coûteuses, ce qui permet de les supprimer plus rapidement lorsque le nombre de joueurs diminue.

La capacité de notre système à le faire dépend de la durée de vie de votre correspondance. Des durées de match plus courtes nous permettent de mettre fin plus rapidement aux attributions sur des machines coûteuses. Les matchs plus longs signifient que nous ne pouvons pas éteindre les machines avant la fin du match.