Guide de build de serveur dédié Unreal et de déploiement Linux

Réponse directe

Créez une Server target, build avec une chaîne Unreal source-capable, compilez les contenus pour la plateforme serveur et packagez un artefact headless versionné avec configuration, maps et bibliothèques d’exécution requises. Démarrez-le avec une map explicite, un port, un chemin de log et des flags non supervisés ; exposez séparément la santé du processus et celle de la session ; conservez les logs stdout ou fichier ; et déployez l’artefact testé exact via un service, un conteneur ou un orchestrateur avec arrêt propre et rollback.

Cette page couvre le passage du build à l’exécution sur Linux. Elle ne répète pas la conception de la réplication, le matchmaking, le choix d’un fournisseur cloud ni l’intégration anti-triche. L’objectif concret est une tranche de construction de jeu que tout autre développeur peut reproduire depuis un checkout propre. Gardez séparés comportement du moteur, politique de projet et preuves mesurées : la documentation d'Epic établit les concepts pris en charge, le projet définit la propriété et les budgets, et seul un run de test nommé prouve le résultat local.

Ce que ce guide apporte

• Un modèle de propriété concret pour déploiement de build serveur dédié Unreal sous Linux.
• Un flux de travail de mise en œuvre Blueprint/C++ en six étapes avec un exemple réel d’API ou de commande.
• Trois scénarios de production, incluant comportement normal, limites, et comportement de passation.
• Critères de récupération d’échec et de validation pour les builds éditeur et packagés.
• Un passage de relais SEELE borné qui mène au créateur Unreal sans modifier l’intention technique de cette page.

Architecture système et propriété

Build target

Un fichier Target.cs définit TargetType.Server, les modules, les paramètres de build et les plateformes prises en charge. Le build serveur supprime le rendu et les besoins de joueur local, mais conserve les modules de jeu et les assets cookés utilisés par la logique d'autorité.

Revue du build target : capturez les hachages du moteur, du projet, du target et de l’artefact, et montrez comment l’artefact cooké reçoit ou observe le résultat accepté sans devenir un second propriétaire.

Artefact cuit

Automatisez BuildCookRun ou BuildGraph avec un moteur et une révision de projet épinglés. Enregistrez la commande, le code de sortie, le manifeste, le hachage d’archive, la liste des maps, la configuration et si les versions de contenu client et serveur correspondent.

Revue de l’artefact cooké : capturez le manifest de cook et la présence de la map requise, et montrez comment le contrat d’exécution reçoit ou observe le résultat accepté sans devenir un second propriétaire.

Contrat d’exécution

Commencez par définir explicitement la carte, le port, la journalisation, le mode unattended, le comportement de crash et la politique stdout. Les secrets proviennent de l'environnement ou de la configuration ; n'insérez jamais d'identifiants actifs dans DefaultEngine.ini ou dans l'archive empaquetée.

Revue du contrat d’exécution : capturez la liaison de port et le démarrage du net-driver et montrez comment le cycle de vie des opérations reçoit ou observe le résultat accepté sans devenir un second propriétaire.

Cycle de vie des opérations

La santé du processus indique que l’exécutable est vivant ; la readiness indique que le monde et la couche online/session peuvent accepter des joueurs. Gérez SIGTERM ou l’arrêt du service, rejetez toute nouvelle requête, videz l’état, fermez les sessions et quittez dans un délai imparti.

Revue du cycle de vie des opérations : capturer la connexion, le travel et la déconnexion client, et montrer comment le build target reçoit ou observe le résultat accepté sans devenir un second propriétaire.

Workflow de mise en œuvre

1. Étape 1 : Ajoutez ProjectServer.Target.cs avec TargetType.Server et compilez-le sur un agent propre en utilisant le workflow source Unreal requis ou un build installé pour la version cible.
2. Étape 2 : Exécutez une commande BuildCookRun reproductible pour LinuxServer, avec des maps nommées, et la configuration Development ou Shipping visée. Archivez séparément les symboles et les manifests de l'artefact public.
3. Étape 3 : Effectuez un smoke test local du serveur avec une carte et un port fixes, vérifiez le démarrage via les logs jusqu'à la préparation du monde, puis connectez un client en version correspondante et testez le travel et la déconnexion.
4. Étape 4 : Mettez en paquet l’archive dans un répertoire de service ou une image conteneur minimale, exécutez en tant qu’utilisateur non root si possible, montez les logs et les sorties de crash en écriture, et injectez la configuration au moment de l’exécution.
5. Étape 5 : Définissez la liveness, la readiness, les limites de ressources, l’exposition des ports, l’arrêt propre, le délai de démarrage et les labels de version des artefacts. Ne utilisez pas le nombre de joueurs seul comme indicateur d’état du processus.
6. Étape 6 : Déployez un canary, connectez-vous et terminez une session représentative, arrêtez-la proprement, vérifiez les journaux et le flush d’état, puis déployez ou revenez en arrière via l’identifiant d’artefact immuable.

Exemple concret d’API ou de commande

RunUAT.bat BuildCookRun -project="D:\Games\Arena\Arena.uproject" -noP4 -server -noclient -serverplatform=Linux -serverconfig=Shipping -cook -build -stage -pak -archive -archivedirectory="D:\Artifacts\ArenaServer"
./ArenaServer.sh ArenaMap?listen -port=7777 -unattended -stdout -FullStdOutLogOutput

Trois scénarios de production

Exemple 1 : hôte Systemd

Installez une archive immuable, injectez l’environnement depuis un fichier de service protégé, définissez Restart=on-failure, transférez les logs, et utilisez ExecStop avec un chemin d’arrêt en jeu propre avant le timeout du service.

Les preuves pour l’hôte systemd doivent inclure les hachages du moteur, du projet, du target et de l’artefact, l’identité de build propriétaire, et la condition qui remet ce scénario dans son dernier état connu comme valide.

Exemple 2 : Canary de conteneur

Exposez explicitement les ports de gameplay UDP et de query, montez la sortie de crash, étiquetez l’image avec les commits du moteur et du projet, et bloquez la readiness sur l’initialisation de la carte et de la session.

La preuve du canary conteneur doit inclure le manifest de cuisson et la présence de la carte requise, l’identité du build propriétaire et la condition qui ramène ce scénario à son dernier état connu bon.

Exemple 3 : Rejet de non-correspondance de version

Le client et le serveur échangent une version de contenu ou de protocole compatible. Le serveur rejette un client incompatible avec une raison visible au lieu de l'accepter et de tomber ensuite en erreur pendant la réplication.

Les preuves de rejet de non-correspondance de version doivent inclure la liaison de port et le démarrage du net-driver, l'identité de build propriétaire, et la condition qui remet ce scénario dans son dernier état connu comme valide.

Modes de défaillance et reprise

Le serveur executable se build mais la carte est manquante

Contrôlez l’inclusion des maps dans le cook, les règles de l’Asset Manager, les soft references et le manifest d’archive. La disponibilité dans l’éditeur ne constitue pas une preuve de contenu cooké.

Avant la fermeture, le serveur executable builds mais la map est manquante : relancez l’hôte systemd et prouvez que la liaison de port et le démarrage du net-driver reviennent à la limite attendue sans étape de réparation non documentée.

Le processus est actif mais ne peut pas accepter de joueurs

Séparez la liveness de la readiness et journalisez les étapes de carte, net driver, bind du port, service online et création de session. Un redémarrage aveugle masque la première panne.

Avant la fermeture, le processus est en cours d’exécution mais ne peut pas accepter de joueurs : relancez le canary du conteneur et prouvez que la connexion client, le travel et la déconnexion reviennent à la limite attendue sans étape de réparation non documentée.

Le démarrage Linux échoue à cause d’une bibliothèque ou d’une permission

Exécutez dans l’image finale ou la classe d’hôte, inspectez les dépendances dynamiques, exécutez des tests de bits, paths sensibles à la casse, répertoires inscriptibles et propriété non-root.

Avant de fermer, si le démarrage Linux échoue sur une bibliothèque ou une permission, relancez le rejet de non-correspondance de version et prouvez que la readiness, l’arrêt, les logs, la sortie de crash et le rollback reviennent à la borne attendue sans étape de réparation non documentée.

Le déploiement coupe brusquement les sessions actives

Traitez la terminaison, retirez la readiness, cessez d’accepter les rejoins, enregistrez ou fermez le travail faisant autorité, puis quittez avant le délai de l’orchestrateur.

Avant de fermer, les déploiements qui terminent brutalement les sessions actives doivent relancer l’hôte systemd et prouver que les hachages moteur, projet, target et artefact reviennent à la borne attendue sans étape de réparation non documentée.

Matrice de validation

• empreintes du moteur, du projet, du target et de l’artefact : inspectez-le à côté du build target ; validez uniquement lorsque le build server executable fonctionne mais la map est manquante ne se reproduit plus sur l’hôte systemd et que la preuve indique le build exact.
• manifest de cuisson et présence de la carte requise : inspectez-le à côté de l’artefact cuit ; validez uniquement lorsque le processus reste actif mais ne peut pas accepter de joueurs ne se reproduit plus lors du canary conteneur et que la preuve indique le build exact.
• liaison de port et démarrage du net-driver : analysez-la à côté du contrat d’exécution ; validez uniquement lorsque l’échec de démarrage Linux dû à une bibliothèque manquante ou une permission refusée ne se reproduit plus lors du rejet de non-correspondance de version et que les preuves identifient exactement le build.
• connexion client, travel et déconnexion : inspectez-le à côté du cycle de vie des opérations ; validez uniquement lorsque le déploiement coupe brusquement les sessions actives ne se reproduit plus sur l’hôte systemd et que la preuve indique le build exact.
• readiness, arrêt, logs, sortie de crash et rollback : analysez-la à côté du build target ; validez uniquement lorsque la compilation de l'exécutable serveur, sans carte associée, ne se reproduit plus lors du canary de conteneur et que les preuves identifient exactement le build.

Inspectez-le à côté de la présentation et de l’autorité ; validez uniquement lorsque plusieurs interactions déclenchées par une pression ne se reproduisent pas lors d’une porte avec état de verrouillage et que les preuves mentionnent le build exact.

Ces étapes ciblent la surface de documentation Unreal Engine 5 actuelle au 2026-07-26. Les valeurs par défaut du moteur, le statut expérimental, le packaging des plugins, les signatures API et la prise en charge des plateformes peuvent changer. Sélectionnez la version de la documentation qui correspond au projet, testez le patch exact et la cible, et conservez une révision de rollback. La documentation publique ne remplace pas les exigences NDA de plateforme, la revue en store, la certification console ou les preuves de performance spécifiques au projet.

Sources officielles

• Configuration des serveurs dédiés — preuve source du build target dans ce flux de build de serveur dédié Unreal et déploiement Linux ; vérifiez que la version de la documentation correspond à la branche shipping.
• Opérations de build : Cook, Package, Deploy, Run — preuve source pour l’artefact cooké dans ce workflow unreal dedicated server build deploy linux ; vérifiez la version de la documentation avec la branche shipping.
• Arguments de ligne de commande — preuve source pour le contrat d’exécution dans ce workflow de build de serveur dédié Unreal et déploiement Linux ; vérifiez la version de la documentation par rapport à la branche shipping.

Unreal Engine est une marque déposée d'Epic Games. SEELE AI est indépendant et cet article n'implique pas l'approbation d'Epic Games ou de Valve.

Du plan technique au jeu Unreal de SEELE

Utilisez cette page pour définir le système, les tests d'acceptation et les limites de défaillance ; puis transmettez ce cahier des charges précis dans [le créateur de jeu Unreal de SEELE](/features/create/unreal-game). SEELE peut générer un jeu natif Unreal 5, fournir un aperçu dans le navigateur, prendre en charge l'optimisation et le packaging dans SEELE, et vous permettre de télécharger le projet ou la sortie packagée pour une publication externe ou de le publier en tant que jeu SEELE gratuit ou payant.

Ce transfert ne modifie pas la responsabilité de production native décrite ci-dessus. L'approbation du magasin, les ventes, les revenus, la certification, la compatibilité des plugins tiers et la conformité de la plateforme ne sont pas garanties. Gardez le jeu Unreal source, les journaux de compilation, les preuves de test et les décisions de publication externes sous le contrôle de votre équipe.

FAQ

Quelle est la bonne architecture pour unreal dedicated server build deploy linux ?

Créez une Server target, build avec une chaîne Unreal source-capable, compilez les contenus pour la plateforme serveur et packagez un artefact headless versionné avec configuration, maps et bibliothèques d’exécution requises. Démarrez-le avec une map explicite, un port, un chemin de log et des flags non supervisés ; exposez séparément la santé du processus et celle de la session ; conservez les logs stdout ou fichier ; et déployez l’artefact testé exact via un service, un conteneur ou un orchestrateur avec arrêt propre et rollback. Commencez par le build target et l’artefact cuit, puis restez en observateur de l’état de jeu engagé.

Le build de serveur dédié Unreal et le déploiement Linux doit-il être réalisé en Blueprint ou en C++ ?

Les deux sont possibles. Blueprint est efficace pour une logique de jeu rapide et l’itération des designers ; C++ est utile pour des contrats réutilisables, des durées de vie complexes, des boucles sensibles aux performances et des tests automatisés. Conservez les mêmes limites de propriété, de validation, d’échec et de récupération dans les deux cas.

Comment tester le build de serveur dédié Unreal et le déploiement Linux ?

Testez un cas nominal, une entrée invalide, une interruption ou une teardown, un redémarrage propre et la parité du build empaqueté. Capturez les hachages du moteur, du projet, du target et de l’artefact, le manifest de cook et la présence de la map requise, la liaison de port et le démarrage du net-driver avec un identifiant de build et des critères de validation explicites.

Quel est l’échec le plus dangereux dans le build de serveur dédié Unreal et le déploiement Linux ?

Un exécutable serveur qui compile mais dont la map est absente est un signal précoce : vérifiez l’inclusion des maps dans le cook, les règles de l’Asset Manager, les soft references et le manifest d’archive. La disponibilité dans l’éditeur ne constitue pas une preuve de contenu cooké. Vérifiez également le nettoyage et le retry pour que la correction apparente ne laisse pas d’état résiduel.

Quelle version d’Unreal Engine est visée par ce guide de déploiement de build de serveur dédié sur Linux ?

Il utilise la surface de documentation Unreal Engine 5 disponible le 2026-07-26. Vérifiez le sélecteur de version, la signature API, l’état du plugin, la chaîne d’outils de plateforme et le comportement packagé dans le patch moteur exact qui sera livré.

Que peut faire SEELE après que ce plan de build de serveur dédié Unreal et déploiement Linux soit prêt ?

SEELE peut générer un jeu natif Unreal 5, fournir une prévisualisation navigateur, prendre en charge l'optimisation et l'empaquetage, et fournir des téléchargements de projet ou d'application empaquetée pour une publication externe ou une sortie SEELE gratuite ou payante. Il ne garantit pas l'approbation par des magasins tiers, la compatibilité, les ventes ou les revenus.