Unity
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.
✔️ Préparation
Avant de commencer, assurez-vous de créer un compte gratuit chez Edgegap (aucune carte de crédit requise).
Configurez quelques éléments essentiels sur votre machine de développement :
⚙️ 1. Connecter le compte
☑️ Connectez-vous et vérifiez qu’il n’y a pas de nouvelles erreurs dans votre console Unity liées au plugin d’Edgegap.
✅ Vous pouvez maintenant passer à l’étape suivante.
🔧 2. Construire le serveur de jeu
Que vous utilisiez une machine Windows, Mac ou Linux, vous allez devoir construire votre serveur pour l’exécution Linux, car la plupart des fournisseurs cloud aujourd’hui (y compris Edgegap) tournent sous Linux. Ne vous inquiétez pas, aucune connaissance Linux n’est requise pour accomplir cela avec notre plugin.
☑️ Vérifiez que vous avez installé les outils de build Unity Linux requis.
☑️ Éditez les paramètres de build pour vous assurer que toutes les scènes de jeu requises sont incluses.
☑️ Optionnel : ajoutez un script spécifique au netcode pour la vérification des ports et l’amorçage de l’environnement à votre scène serveur initiale depuis le menu Edgegap Server Hosting (clic droit / ➕ dans votre fenêtre Hiérarchie).

☑️ Une fois satisfait de votre configuration, cliquez sur Construire le serveur, attendez la fin du processus et vérifiez qu’il n’y a pas de nouvelles erreurs dans votre console Unity. Terminer cette étape entraînera la création d’un nouveau dossier apparaissant à la racine de votre projet - Builds/EdgegapServer/ServerBuild .
✅ Vous pouvez maintenant passer à l’étape suivante.
🐋 3. Conteneuriser le serveur
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 fonctionneront sur des milliers de machines serveur à travers le monde.
Pour aider à rendre votre serveur fiable, nous utilisons Docker — un logiciel de virtualisation permettant de garantir 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é.
☑️ Pour l’instant, commencez par cliquer sur le bouton Valider pour vous assurer que vous avez complété Outils pour développeurs.
☑️ Vous pouvez configurer les options suivantes (ou conserver les valeurs par défaut) :
Chemin du build est le chemin relatif vers votre artefact de build serveur, gardons la valeur par défaut pour l’instant.
Docker n’accepte que les chemins de build relatifs au dossier racine de votre projet, gardez les builds à l’intérieur de votre dossier de projet.
Nom de l’image est un identifiant unique de votre choix, étiquetant votre build serveur avant l’expédition.
Généralement, cela inclura 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 pour l’étiquetage, par ex.
2024.01.30-16.23.00-UTC.
Chemin vers le Dockerfile peut être utilisé pour personnaliser la recette de vos images.
Nous recommandons de conserver le paramètre par défaut pour l’instant, vous pouvez en lire plus plus tard dans la section Unity.
Paramètres facultatifs de build docker peuvent être utilisés pour donner des instructions supplémentaires à Docker sur des nuances plus fines.
Nous recommandons de conserver le paramètre par défaut pour l’instant, vous pouvez en lire plus plus tard dans la documentation Docker.
☑️ Une fois satisfait de votre configuration, cliquez sur Conteneuriser avec Docker, attendez la fin du processus et vérifiez qu’il n’y a pas de nouvelles erreurs dans votre console Unity. Terminer cette étape entraînera la création d’un nouvelle image apparaissant sur votre machine locale. Vous pouvez vérifier cela soit dans Docker Desktop, dans l’onglet Images sous Local (par défaut), soit dans le CLI docker en exécutant docker images .
✅ Vous pouvez maintenant passer à l’étape suivante.
🧪 4. 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 la téléverser et de la déployer (ce qui peut prendre un certain temps).
☑️ Vous pouvez configurer les options suivantes (ou conserver les valeurs par défaut) :
Tag de l’image serveur de l’étape précédente.
Par défaut, utilise le dernier tag que vous avez construit avec le plugin.
Paramètres optionnels de docker run peuvent être fournis pour exposer plusieurs ports, ou exécuter votre image sur des machines macOS.
Vous pouvez publier plusieurs ports pour votre conteneur si nécessaire, ajoutez simplement le paramètre
-p {port interne}/{protocole}pour chacun, par exemple-p 8080/tcp -p 7770/udppour publier et mapper votre port serveur8080à un port externe aléatoire pour la connexion TCP et le port serveur7777à un port externe aléatoire pour la connexion UDP en même temps.Trouvez la configuration du port serveur dans vos paramètres de Transport ou spécifiques au netcode.
Si vous utilisez une machine avec architecture ARM (macOS M1, M2, M3, etc.), vous devriez voir ce paramètre optionnel inclus dans vos paramètres optionnels de build docker :
--platform=linux/amd64.
☑️ Une fois satisfait de votre configuration, cliquez sur Déployer le conteneur local, attendez la fin du processus et vérifiez qu’il n’y a pas de nouvelles erreurs dans votre console Unity. Terminer cette étape provoquera le démarrage d’un nouveau conteneur sur votre machine de développement.
☑️ Il est maintenant temps de connecter votre client de jeu Unity Editor à votre conteneur docker local pour vérifier que votre image serveur fonctionne correctement. Trouvez vos paramètres client netcode et saisissez :
localhostou127.0.0.1(équivalent dans la plupart des cas) à la place de l’IP du serveur,valeur du port externe aléatoire trouvée dans Docker Desktop / Containers / edgegap-server-test.

☑️ 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.
☁️ 5. Télécharger 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).
☑️ Vous pouvez configurer les options suivantes (ou conserver les valeurs par défaut) :
Nom de l’application sur Edgegap peut correspondre au nom de votre image ou être personnalisé.
Nous avons choisi de copier le nom de votre image pour l’instant.
Version de l’application sur Edgegap peut correspondre à votre tag ou être personnalisée.
Les horodatages sont une excellente option pour les noms de version d’application, par ex.
2024.01.30-16.50.20-UTC.Plusieurs versions d’application peuvent pointer vers le même tag d’image, par exemple
v1.1.0etdev.En savoir plus sur Applications et versions plus tard.
Nom de l’image serveur de l’étape Unity.
Tag de l’image serveur de l’étape Unity.
Trouvez tout nom et tag d’image stockés sur votre machine dans Docker Desktop / Images.
☑️ Une fois satisfait de votre configuration, cliquez sur Téléverser l’image et créer une version d’application, attendez la fin du processus et vérifiez qu’il n’y a pas de nouvelles erreurs dans votre console Unity.
☑️ Vous serez redirigé vers notre Tableau de bord, où vous pouvez configurer des paramètres optionnels. Terminer cette étape entraînera la création d’une nouvelle version d’application, et votre artefact de build sera tagué et téléversé dans le registre de conteneurs d’Edgegap.
☑️ Vous serez maintenant invité à définir un port pour votre nouvelle version d’application. Assurez‑vous de définir la même valeur de port serveur que dans l’étape Unity depuis vos paramètres Transport ou spécifiques au netcode.
✅ Vous pouvez maintenant passer à l’étape suivante.
🚀 6. Déployer dans le cloud
Ceci est l'étape finale de ce guide, après laquelle vous aurez 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, appuyez sur Déployer sur le Cloud, attendez d'atteindre Déploiements. L'exécution de cette étape entraînera la nouveau déploiement en cours de démarrage 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 les nouvelles connexions de joueurs peuvent être refusées ou votre serveur bloqué dans une boucle de redémarrage. Voir les étapes de dépannage ci-dessous pour résoudre tout problème.
☑️ Nous allons maintenant effectuer le test final et connecter votre client de jeu Unity Editor à votre déploiement cloud. Saisissez les détails de connexion du client de jeu depuis le déploiement :
Hôte URL pointant vers l’IP du serveur, généralement dans
NetworkManagercomposant.Port externe mappé vers le port d’écoute interne du serveur, généralement dans le composant Transport.

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 terminé les tests, Arrêter votre déploiement pour libérer de la capacité dans votre compte pour la prochaine build.
Au cas où vous rencontreriez des problèmes, inspectez les logs du tableau de bord de votre déploiement.
Si vous ne parvenez pas à résoudre le problème, nous traînons dans notre le Discord de la communauté 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 gestion de versions comme git) afin de toujours pouvoir retracer vos étapes en cas de problème.
Continuez la lecture pour en savoir plus sur des sujets liés au cycle de vie des serveurs et à leur découvrabilité.
Arrêter les déploiements
Découvrez les différentes méthodes pour arrêter les déploiements une fois le match terminé et les joueurs partis.
Variables injectées
Lisez des informations utiles comme l’ID du déploiement, l’adresse IP du serveur, l’emplacement du serveur, et plus ; 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 Matchmaker,
Variables de version d’application - paires clé‑valeur personnalisées configurables par vous.
Vérifier si l’instance actuelle est un client de jeu ou un serveur en vérifiant si la variable Edgegap est définie :
Matchmaking
Lancer vos déploiements manuellement en collant URL et ports ne suffira pas pour un jeu en production.
En savoir plus sur le Matchmaking pour déployer automatiquement, juste à temps, lorsque les joueurs se connectent.
Optimiser les builds serveur
Reconstruire uniquement les assets qui ont changé depuis le dernier build.
Envisagez d’utiliser les builds incrémentiels d’Unity pour accélérer votre temps de build.
Envisagez d’utiliser les builds incrémentiels d’Unity pour accélérer votre temps de build.
N’incluez que ce dont votre serveur a absolument besoin pour fonctionner.
Copier des fichiers inutilisés dans vos images entraîne un gonflement de l’image, des téléversements plus longs, une mise en cache plus lente et un démarrage serveur global plus lent. Consultez les suggestions d’optimisation d’image Docker.
Désactivez le static batching des meshes pour réduire la taille de l’image.
Compressez les meshes pour réduire la taille de l’image.
La compression des vertex n’impacte pas la taille de l’image.
Implémentez le chargement paresseux conditionnel des ressources.
Excluez les assets réservés aux clients en désactivant la lecture/écriture CPU pour les textures et les meshes.
Envisagez d’utiliser Unity Addressables pour vos builds client afin d’accélérer les builds et déploiements en chargeant les assets juste à temps, ou en sautant le chargement de certains assets dans les builds serveur en vérifiant la présence de Variables injectées.
Envisagez d’utiliser builds Docker multi‑étapes (lien).
Séparez les grosses dépendances serveur dans une image séparée à réutiliser dans des builds multi‑étapes. Docker mettra en cache chaque couche et réutilisera simplement la version précédente et évitera de téléverser cette partie sauf indication contraire, vous faisant économiser bande passante et temps d’attente du téléversement.
Si vous n’êtes pas sûr de la raison pour laquelle l’une des commandes de votre Dockerfile génère une erreur, essayez de déboguer localement. Créez une nouvelle étape juste avant que le problème n’arrive (ajoutez une seconde commande
FROM), 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 enquêter plus avant (par ex.topsur ubuntu).
Personnaliser l’image serveur
Nous supportons également 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 de build, de dépendances superflues, ou d’un processus de démarrage plus complexe. Vous pouvez optionnellement fournir un chemin vers votre Dockerfile personnalisé à l’étape Unity. Nous allons maintenant partager quelques conseils et bonnes pratiques “faites‑le vous‑même”.
Des problèmes lors de l’utilisation de Websockets ou de requêtes HTTPS ?
Si vous obtenez
Erreur Curl 35 : échec du handshake du certificat. Erreur fatale. Code d’erreur UnityTls : 7ne désespérez pas, c’est un problème connu avec les anciennes images de base (FROM) incluant un certificat d’autorité racine expiré. Vous pouvez corriger cela en mettant à jour vers une version plus récente de l’image de base (par ex.ubuntu:22.04), et en exécutantupdate-ca-certificates, ajoutez ceci à votre Dockerfile :
Assurez-vous toujours de travailler avec une build serveur fonctionnelle.
Avant de supposer qu’un problème est lié au Dockerfile personnalisé, vérifiez que votre build serveur Unity peut démarrer et que le processus de build dans Unity n’a généré aucune exception ni erreur.
Testez toujours localement avant de téléverser.
Tester votre image localement vous fera gagner beaucoup de temps pendant l’attente du téléversement. C’est aussi entièrement gratuit ✨ car cela ne requiert aucune ressource Edgegap.
Lors des tests locaux, assurez-vous de définir correctement votre port interne :
Assurez-vous d’avoir les bases. Chaque Dockerfile nécessite quelques commandes essentielles :
FROM {image}est votre image de base ; pour les projets Unity nous utilisons généralement une distribution Linux à support à long terme, mais toute image de base basée sur Linux convient. 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 serveur Linux depuis votre machine hôte à l’intérieur de l’image, afin de pouvoir le démarrer plus tard. Référence Dockerfile ici.USER {user}devrait suivre après une commande useradd (ubuntu) ou équivalente ; il est préférable de ne pas tout exécuter en tant querootpour être plus prudent. Référence Dockerfile ici.CMD {command}sera la dernière ligne, appelant très probablement unStartServer.shou un script de démarrage quelconque pour s’assurer que votre serveur s’initialise correctement une fois que tout est configuré. Référence Dockerfile ici.NE PAS utiliser
VOLUME- vous ne pourrez pas monter de stockage local de cette manière sur Edgegap ; envisagez plutôt notre fonctionnalité Endpoint Storage et utilisez un bucket S3, voir Endpoint Storage,EXPOSE 7777/UDPn’est pas requis ! Cela ne rendra pas réellement le port interne du serveur accessible depuis l’extérieur du conteneur, c’est seulement une indication pour le développeur et le port doit êtrepublié lors des tests locaux avec
docker run <image> -p 7777/udp,ou mappé dans Edgegap Port Mapping.
Différez la déclaration des paramètres jusqu’au dernier moment possible. Configurabilité > composabilité en raison des temps de build serveur longs. Appliquez cette approche aux commandes Dockerfile pour 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 similaire.
Mauvaise solution : créer une image distincte pour chaque combinaison de vos paramètres. Vous passerez tout votre temps à reconstruire les images avec très peu d’avantages.
Meilleure solution - substituer les paramètres de configuration au dernier moment :
paramètres de déploiement - fournis juste avant le déploiement - sélecteurs de matchmaking passés comme variables d’environnement, ou votre système de gestion de session personnalisé passant 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 d’artefact, secrets et points de terminaison tiers, et similaire ; puis
une seule image - contient et charge toutes les options de configuration au lancement.
NE PAS exécuter de bases de données sur les déploiements Edgegap.
Les déploiements Edgegap ne sont pas destinés aux processus de longue durée et peuvent être terminé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 de données irréversible. Si vous avez besoin d’une base de données, veuillez envisager un DBaaS tiers.
Envisagez d’utiliser notre Managed Clusters pour héberger des bases de données et des services à longue durée d’exécution.
Mis à jour
Ce contenu vous a-t-il été utile ?



