Unreal Engine - Premiers pas
Apprenez en pratiquant et déployez votre premier serveur dédié sur Edgegap. À la fin de ce guide, vous aurez déployé un serveur dédié avec Edgegap sans frais.
La méthode la plus rapide, la plus simple et la plus fiable pour commencer consiste à utiliser Docker Desktop.
✔️ Préparation
Avant de commencer, assurez-vous de créer un compte gratuit avec Edgegap (aucune carte de crédit requise). Vous pouvez inviter les membres de votre équipe ensuite, même s’ils n’ont pas encore de compte Edgegap.
Configurez quelques éléments essentiels sur votre machine de développement :
Installez l’extension Docker Edgegap Quickstart
Installez depuis Docker Desktop / Extensions / Parcourir ou en utilisant le lien.
⚙️ 1. Configurer le projet
Que vous utilisiez une machine Windows, Mac ou Linux, vous allez devez construire votre serveur pour l'exécution sous Linux, car la plupart des fournisseurs cloud aujourd'hui (y compris Edgegap) fonctionnent sous Linux. Ne vous inquiétez pas, aucune connaissance en Linux n'est requise.
☑️ Commencez par vérifier votre version d’Unreal Engine - prérempli avec la valeur issue des fichiers de votre projet.
☑️ Saisissez le nom d’utilisateur GitHub et PAT de ✔️ Préparation, pour télécharger les dépendances depuis GitHub.
☑️ Désactiver la vérification de compatibilité de la version d'Unreal Engine pour les serveurs dédiés et définir IpNetDriver comme le pilote par défaut ou le pilote de secours pour le réseau de réplication :
Assurez-vous de saisir votre DefaultServerTarget à la fin de cet extrait!
☑️ Redémarrer Unreal Engine pour recharger les derniers changements.
☑️ Créer un script de cible pour serveur dédié en copiant votre <PROJECT>Editor.Target.cs fichier dans le dossier racine du projet et en renommant la copie en <PROJECT>Server.Target.cs.
☑️ Remplacez toutes les références à mot Editor par Server dans votre script de cible serveur.
☑️ Modifier les paramètres par défaut de la build serveur en éditant votre script de cible serveur :
✅ Vous pouvez maintenant passer à l'étape suivante.
🔧 2. Construire le serveur de jeu
Nous allons maintenant compiler et cuisiner votre projet, puis le empaqueter dans une image Docker facilement réutilisable.
Travailler en équipe de développeurs signifie partager votre code. Quand les choses tournent mal, la dernière chose que vous voulez entendre est « ça marche sur ma machine ». Les serveurs de jeu doivent fonctionner de manière fiable sur n'importe quelle machine, car les serveurs d'un jeu à succès tourneront sur des milliers de machines serveur à travers le monde.
Pour aider à rendre votre serveur fiable, nous utilisons Docker - un logiciel de virtualisation garantissant que toutes les dépendances de votre code serveur jusqu'au niveau du système d'exploitation seront toujours exactement les mêmes, peu importe comment ou où le serveur est lancé.
☑️ Vous pouvez configurer les options suivantes (ou conserver les valeurs par défaut) :
Nom de l'image est un identifiant unique de votre choix, permettant d'étiqueter votre build de serveur avant la livraison.
En général, cela inclut le nom de votre jeu - par exemple « my-game-server ».
Tag de l'image est un identifiant pointant vers une version spécifique de votre image.
Le terme « artefact de build » est parfois utilisé pour désigner une version spécifique de votre image.
Les horodatages sont une excellente option par défaut pour les tags, par ex.
2024.01.30-16.23.00-UTC.
☑️ Compiler le projet une fois que vous êtes satisfait de votre configuration. L’achèvement de cette étape ajoutera une nouvelle image avec l’exécutable de votre serveur de jeu Linux dans votre client Docker local.
✅ Vous pouvez maintenant passer à l'étape suivante.
🧪 3. Tester le serveur localement
Essayons de déployer localement (sur votre machine) et de connecter un client de jeu, pour nous assurer que l'image du serveur fonctionne correctement avant de l'uploader et de la déployer (ce qui peut prendre un certain temps).
☑️ Sélectionnez le tag d’image que vous souhaitez exécuter localement (les images distantes seront téléchargées). En option, d’autres arguments docker run peuvent être fournis pour personnaliser votre test local :
-p 7777:7777/udp- il s’agit du mappage de port de votre conteneur local,-e ARBITRIUM_PORT_GAMEPORT_INTERNAL=7777est une variable d’environnement qui simule un déploiement Edgegap réel, en indiquant à votre serveur de jeu le port interne sur lequel écouter les connexions des joueurs.
☑️ Une fois que vous êtes satisfait de votre configuration, cliquez sur Démarrer le serveur local. L’achèvement de cette étape entraînera un nouveau conteneur démarré sur votre machine de développement.
☑️ Il est maintenant temps de connecter votre client de jeu de l’éditeur Unreal Engine (PIE) à votre conteneur de serveur local. Ouvrez la console Unreal PIE avec ~ (accent grave) et connectez-vous avec open <ip>:<port>:
ip=localhostou127.0.0.1(équivalent dans la plupart des cas),port= valeur de port externe aléatoire du conteneur dans l’interface Docker.
☑️ Une fois que vous avez vérifié que vous pouvez vous connecter à votre conteneur de serveur local et jouer sans problème, vous pouvez supprimer le conteneur 🗑️ pour libérer des ressources sur votre machine pour d’autres programmes.
✅ Vous pouvez maintenant passer à l'étape suivante.
☁️ 4. Publier sur Edgegap
Il est temps de mettre votre serveur en ligne ! Maintenant que votre image peut héberger des joueurs avec succès, nous pouvons la téléverser sur Edgegap et commencer à l’exécuter n’importe où dans le monde. Dans ce guide, nous utiliserons le registre de conteneurs d’Edgegap (stockage pour les images).
☑️ Choisissez un nom d’application pour étiqueter et regrouper des images similaires sur Edgegap.
☑️ Sélectionnez le tag d’image que vous souhaitez publier et Téléverser l’image. L’achèvement de cette étape entraînera le téléversement de l’image de votre serveur vers le registre Edgeap et la création d’une nouvelle version d’application créée dans votre navigateur web. Assurez-vous de créer votre de port de votre conteneur local lorsqu’on vous y invite, avec les valeurs par défaut.
Vous avez trouvé un bug et devez reconstruire/publier à nouveau ? Utilisez Reconstruire à partir des sources pour Unreal Engine et Unreal Engine avec les valeurs d’entrée actuelles de l’extension rapidement.
✅ Vous pouvez maintenant passer à l'étape suivante.
🚀 5. Déployer dans le cloud
Ceci est l'étape finale de ce guide, après laquelle vous disposerez d'un serveur déployé sur le cloud Edgegap, auquel des joueurs du monde entier pourront se connecter.
☑️ Choisissez une application et une version de l'étape précédente à déployer.
☑️ Une fois prêt, cliquez sur Déployer sur le Cloud, attendez d'atteindre Déploiements. L'achèvement de cette étape entraînera le démarrage d'un nouveau déploiement sur votre compte Edgegap.
☑️ Vérifiez qu'il n'y a pas de nouvelles erreurs dans la sortie de la console. Assurez-vous également que vos Déploiements n'affichent aucune erreur et que vos Déploiements n'indiquent pas une utilisation des ressources à 100 % (vCPU ou mémoire), sinon de nouvelles connexions de joueurs peuvent être rejetées, ou votre serveur bloqué dans une boucle de redémarrage. Consultez les étapes de dépannage ci-dessous pour résoudre tout problème.
☑️ Nous allons maintenant effectuer le test final et connectez votre éditeur Unreal Engine à votre déploiement cloud. Récupérez le hôte du déploiement à la place de l'adresse IP du serveur et le port externe, ouvrez la console Unreal dans le client de jeu (accent grave ~) et tapez open {host}:{port} .
Désactiver le VPN lors des tests pour des conditions plus réalistes et recevoir un déploiement à faible latence.
☑️ Une fois que vous avez vérifié que vous pouvez vous connecter à votre déploiement sans problème et que vous avez fini les tests, Arrêtez votre déploiement pour libérer de la capacité dans votre compte pour la prochaine build.
En cas de problème, inspectez les journaux du tableau de bord de votre déploiement.
Si vous ne parvenez pas à identifier le problème, nous traînons dans notre Discord Communautaire et heureux de vous aider.
🙌 Félicitations pour votre premier déploiement sur Edgegap ! Si vous souhaitez en savoir plus, continuez à lire.
👉 Étapes suivantes
Une fois que vous disposez d'une configuration client/serveur fonctionnelle, assurez-vous de sauvegarder une copie de votre projet (en utilisant un logiciel de contrôle de version comme git) afin de toujours pouvoir retracer vos étapes en cas de problème.
Continuez à lire pour en savoir plus sur les sujets liés au cycle de vie des serveurs et à leur découvrabilité.
Arrêter les déploiements
Une fois la partie terminée (ou les joueurs partis), votre déploiement peut être arrêté pour économiser des coûts. L’exécution de déploiements vides ou seulement partiellement remplis peut augmenter inutilement vos coûts !
Si vous avez suivi ce guide et construit avec notre extension Docker, vous pouvez simplement appeler la méthode FGenericPlatformMisc::RequestExit . Nous avons ajouté un script qui gère le processus de votre serveur dans l’image empaquetée, ce qui effectuera automatiquement une fermeture propre du déploiement.
Pour personnaliser la gestion du cycle de vie du serveur, modifiez notre exemple script StartServer.sh .
Connectez votre Stockage des points de terminaison pour enregistrer les journaux de déploiement, sinon ils seront supprimés !
Variables injectées
Lisez des informations utiles comme l'ID du déploiement, l'adresse IP du serveur, l'emplacement du serveur, et plus encore, en accédant aux variables d'environnement injectées. Chaque déploiement inclut automatiquement :
Variables de déploiement - fournies automatiquement par Edgegap,
Variables de matchmaking - fournies automatiquement par Edgegap lors de l'utilisation de Appariement,
Variables de version d'application - paires clé-valeur personnalisées configurables par vous.
Importez notre Outils de développement pour lisez facilement les variables typées à l’aide des Blueprints.
Profilage des serveurs
Pour comprendre et optimiser les problèmes de performances des serveurs sur Edgegap, explorez Déploiements, Déploiements, et plus encore Déploiements outils à votre disposition.
Vous pouvez également utiliser les outils de profilage Unreal Engine existants avec Edgegap :
Configurez le traçage dans votre serveur Unreal Engine (événements intégrés et personnalisés) :
enregistrez la trace sur le disque du serveur avec
-tracefile, téléversez-la dans un stockage tiers et analysez-la hors ligne,ou diffusez les données de trace avec Déploiements pour le port interne
1981via le protocole UDP.
Analyser Memory Insights et Networking Insights et Unreal Engine.
Automatisation des sessions
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
Optimiser les builds
Configurez le découpage des assets pour isoler les assets réservés au client des assets serveur.
Explorez les techniques et recommandations de découpage des assets par Epic.
Excluez les assets et plugins réservés au client, et non requis pour l’exécution du serveur.
En savoir plus sur l’exclusion des assets et des plugins au moment de la compilation.
Revoyez votre stratégie de cuisson du contenu.
Envisagez Cooking on the Fly (COTF) pour retarder la cuisson des assets client et accélérer les builds du serveur.
Mettez en œuvre le Level Streaming pour réduire la charge mémoire à l’exécution.
Si votre conception maintient les joueurs principalement ensemble dans la même zone de carte, le level streaming peut réduire l’utilisation de la mémoire de votre serveur de plus de 60 % et améliorer les performances du client !
N’incluez que ce qui est absolument nécessaire au fonctionnement de votre serveur.
Copier des fichiers inutilisés dans vos images entraîne une inflation de l’image, des téléversements plus longs, des vitesses de cache plus lentes et un démarrage global du serveur plus lent. Consultez les सुझाव d’optimisation des images Docker.
Envisagez d’utiliser des builds Docker multi-étapes (lien).
Séparez les grandes dépendances du serveur dans une image distincte afin de les réutiliser dans les builds multi-étapes. Docker mettra en cache chaque couche et réutilisera simplement la version précédente, en ignorant le téléversement de cette partie sauf instruction contraire explicite, ce qui vous fera économiser de la bande passante et du temps d’attente à la fin du téléversement.
Si vous ne savez pas pourquoi l’une des commandes de votre Dockerfile renvoie une erreur, essayez de déboguer localement. Créez une nouvelle étape juste avant que le problème ne se produise (ajoutez une deuxième
FROMcommande), utilisez--targetpour indiquer au processus de build de s’arrêter à l’étape problématique, puisdocker exec -it {container} /bin/bashpour entrer dans un terminal interactif à l’intérieur de votre conteneur. Ensuite, vous pouvez utiliser des commandes shell dans votre image de base pour approfondir l’analyse (par ex.topsur Ubuntu).
Personnaliser l'image
Nous prenons également en charge l’ajout de votre propre Dockerfile pour les utilisateurs qui ont besoin de plus de contrôle sur leurs images en raison de l’optimisation de la taille des builds, de dépendances superflues ou d’un processus de démarrage plus complexe. Nous allons maintenant partager quelques conseils et bonnes pratiques « à faire soi-même ».
Assurez-vous toujours de travailler avec une version de serveur fonctionnelle.
Avant de supposer qu’un problème est lié au Dockerfile personnalisé, assurez-vous que votre build de serveur peut être démarré, et que le processus de build dans votre moteur de jeu n’a déclenché aucune exception ni erreur.
Testez toujours en local avant de téléverser.
Tester votre image localement vous fera gagner beaucoup de temps pendant que vous attendez la fin du téléversement. C’est aussi entièrement gratuit ✨ car cela ne nécessite aucune ressource Edgegap.
Lors des tests en local, assurez-vous de définir correctement votre port interne :
Assurez-vous de maîtriser les bases. Chaque Dockerfile a besoin de quelques commandes essentielles :
FROM {image}est votre image de base ; nous utilisons généralement un Linux pris en charge à long terme, mais toute image de base basée sur Linux fera l’affaire. Il s’agit généralement d’images publiques stockées sur Docker Hub. Référence Dockerfile ici. Référence Dockerfile ici.COPY {source} {destination}pour copier votre build de serveur Linux depuis votre machine hôte dans l’image, afin de pouvoir le démarrer plus tard. Référence Dockerfile ici.USER {user}doit suivre un commande useradd (Ubuntu) ou équivalent ; il vaut mieux ne pas tout exécuter en tant querootpour plus de sécurité. Référence Dockerfile ici.CMD {command}sera la dernière ligne, appelant très probablement unStartServer.shou un script de démarrage de quelque sorte afin de vous assurer que votre serveur s’initialise correctement une fois que tout est configuré. Référence Dockerfile ici.N’utilisez PAS
VOLUME- vous ne pourrez pas monter de stockage local de cette façon sur Edgegap ; envisagez plutôt notre fonctionnalité de stockage de point de terminaison et utilisez un bucket S3, voir Stockage de point de terminaison,EXPOSE 7777/UDPn’est pas requis ! Cela ne rendra pas réellement le port interne du serveur disponible depuis l’extérieur du conteneur ; ce n’est qu’une indication pour le développeur et le port doit êtrepublié lors des tests en local avec
docker run <image> -p 7777/udp,ou mappé dans le mappage de ports Edgegap.
Retardez la déclaration des paramètres jusqu’au dernier moment possible. La configurabilité > la composabilité en raison des longs temps de build du serveur. Appliquez cette approche aux commandes du Dockerfile afin de construire et téléverser plus rapidement.
Scénario : vous devez définir des paramètres comme le stade de déploiement, la version, le mode de jeu, la carte, le nombre de joueurs par serveur, la fréquence de sauvegarde, ou similaires.
Mauvaise solution : créer une image séparée pour chaque combinaison de vos paramètres. Vous passerez tout votre temps à reconstruire les images pour très peu d’avantages avec cette approche.
Meilleure solution - remplacez les paramètres de configuration juste à temps :
paramètres de déploiement - fournis juste avant le déploiement - sélecteurs de matchmaking transmis sous forme de variables d’environnement, ou votre système personnalisé de gestion de session transmettant des variables d’environnement au moment du déploiement,
paramètres de version - partagés pour tous les déploiements d’une version d’application - stade de déploiement, tag de l’artefact, secrets et points de terminaison tiers, et similaires ; puis
une seule image - contient et charge toutes les options de configuration au lancement.
N’exécutez PAS de bases de données sur les déploiements Edgegap.
Les déploiements Edgegap ne sont pas destinés à des processus de longue durée et peuvent être arrêtés après une longue période d’exécution sans préavis. Une base de données (même distribuée) fonctionnant de cette manière peut être arrêtée et entraîner une perte irréversible de données. Si vous avez besoin d’une base de données, veuillez envisager un DBaaS tiers.
Envisagez d’utiliser nos Clusters gérés pour héberger des bases de données et des services de longue durée.
Mis à jour
Ce contenu vous a-t-il été utile ?