Guide de construction du serveur dédié Unreal et de déploiement sous Linux

Points clés : Guide de construction du serveur dédié Unreal et de déploiement sur Linux

• Créez une cible de serveur, générez avec une chaîne d'outils Unreal capable de gérer les sources, préparez le contenu pour la plateforme du serveur, et empaquetez un artefact tête-bêche versionné avec la configuration, les cartes et les bibliothèques d'exécution nécessaires. Démarrez-le avec un paramètre de carte explicite, de port, de chemin de journalisation et d'indicateurs non interactivés ; exposez séparément l'état du processus et de la session ; préservez la sortie standard ou les journaux de fichiers ; et déployez l'artefact testé exactement via un service, un conteneur ou un orchestrateur avec une mise hors service douce et un retour en arrière.

Réponse directe

Créez une cible de serveur, générez avec une chaîne d'outils Unreal capable de gérer les sources, préparez le contenu pour la plateforme du serveur, et empaquetez un artefact tête-bêche versionné avec la configuration, les cartes et les bibliothèques d'exécution nécessaires. Démarrez-le avec un paramètre de carte explicite, de port, de chemin de journalisation et d'indicateurs non interactivés ; exposez séparément l'état du processus et de la session ; préservez la sortie standard ou les journaux de fichiers ; et déployez l'artefact testé exactement via un service, un conteneur ou un orchestrateur avec une mise hors service douce et un retour en arrière.

Cette page traite de la livraison de la construction à l'exécution sur Linux. Elle ne répète pas la conception de la réplication, le matchmaking, le choix du fournisseur cloud ou l'intégration anti-triche. L'objectif pratique est une tranche de construction de jeu qu'un autre développeur peut reproduire à partir d'une vérification propre. Gardez séparés le comportement du moteur, la politique du projet et les 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 test nommé prouve le résultat local.

Ce que ce guide fournit

• Un modèle de propriété concret pour unreal dedicated server build deploy linux.
• Un flux de travail de mise en œuvre en six étapes en Blueprint/C++ avec un exemple d'API ou de commande réel.
• Trois scénarios de production, y compris le comportement normal, les cas limites et la transmission de responsabilité.
• Des critères de récupération en cas de défaillance et de validation pour les builds de l'éditeur et les builds empaquetés.
• Une transmission SEELE bornée qui conduit au créateur Unreal sans modifier l'intention technique de cette page.

Architecture du système et propriété

Cible de construction

Un fichier Target.cs sélectionne TargetType.Server, les modules, les paramètres de construction et les plateformes prises en charge. La construction du serveur supprime le rendu et les besoins locaux du joueur, mais nécessite toujours les modules de jeu et les actifs préparés utilisés par la logique autoritaire.

Revue de la cible de construction : capturer les hachages du moteur, du projet, de la cible et de l'artefact et montrer comment l'artefact préparé reçoit ou observe le résultat accepté sans devenir un deuxième propriétaire.

Artefact préparé

Automatiser BuildCookRun ou BuildGraph avec une version de moteur et de projet fixée. Enregistrer la commande, le code de sortie, le manifeste, le hachage de l'archive, la liste des cartes, la configuration et si les versions du contenu client et serveur correspondent.

Revue de l'artefact préparé : capturer le manifeste de cuisson et la présence des cartes requises et montrer comment le contrat d'exécution reçoit ou observe le résultat accepté sans devenir un deuxième propriétaire.

Contrat d'exécution

Commencer avec une carte explicite, un port, un journal, des indicateurs non surveillés, des paramètres de plantage et une politique stdout. L'environnement ou la configuration injecte les secrets ; ne jamais intégrer des identifiants actifs dans DefaultEngine.ini ou l'archive empaquetée.

Revue du contrat d'exécution : capturer la liaison du port et le démarrage du pilote réseau et montrer comment le cycle de vie des opérations reçoit ou observe le résultat accepté sans devenir un deuxième propriétaire.

Cycle de vie des opérations

La santé du processus indique que l'exécutable est en vie ; la disponibilité indique que le monde et la couche en ligne/session peuvent accepter les joueurs. Gérer SIGTERM ou l'arrêt du service, refuser les nouvelles tâches, vider l'état, fermer les sessions et quitter dans un délai imparti.

Revue du cycle de vie des opérations : capturer la connexion client, le voyage et la déconnexion et montrer comment la cible de construction reçoit ou observe le résultat accepté sans devenir un deuxième propriétaire.

Flux de travail de mise en œuvre

1. Étape 1 : Ajouter ProjectServer.Target.cs avec TargetType.Server et le générer dans un agent propre en utilisant le workflow de source Unreal requis ou le workflow de build installé pour la version cible.
2. Étape 2 : Exécuter une commande BuildCookRun reproductible pour LinuxServer, les cartes nommées et la configuration Development ou Shipping souhaitée. Archiver les symboles et les manifestes séparément de l'artefact public.
3. Étape 3 : Tester le serveur localement avec une carte fixe et un port, inspecter le démarrage du journal jusqu'à la disponibilité du monde, puis connecter un client de version correspondante et exercer le voyage et la déconnexion.
4. Étape 4 : Empaqueter l'archive dans un répertoire de service ou une image de conteneur minimale, exécuter en tant qu'utilisateur non-root si possible, monter les journaux et les sorties de plantage accessibles en écriture, et injecter la configuration à l'exécution.
5. Étape 5 : Définir la liveness, la readiness, les limites de ressources, l'exposition des ports, la terminaison gracieuse, le délai de démarrage et les étiquettes de version d'artefact. Ne pas utiliser le nombre de joueurs seul comme indicateur de santé du processus.
6. Étape 6 : Déployer un canari, se connecter et terminer une session représentative, l'arrêter gracieusement, vérifier les journaux et le vidage d'état, puis déployer ou revenir par identifiant d'artefact immuable.

Exemple d'API ou de commande concret

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

Installer une seule archive immuable, injecter l'environnement à partir d'un fichier de service protégé, définir Restart=on-failure, rediriger les journaux et utiliser ExecStop avec un chemin d'arrêt gracieux en jeu avant le délai d'expiration du service.

Les preuves pour l'hôte systemd devraient inclure les hachages du moteur, du projet, de la cible et de l'artefact, l'identité de la build propriétaire, et la condition qui ramène ce scénario à son dernier état connu bon.

Exemple 2 : Canari de conteneur

Exposer explicitement les ports de jeu UDP et les ports de requête, monter les sorties de crash, étiqueter l'image avec les commits du moteur et du projet, et conditionner la readiness à la carte plus l'initialisation de la session.

Les preuves pour le canari de conteneur devraient inclure le manifeste de cook et la présence de carte requise, l'identité de la build propriétaire, et la condition qui ramène ce scénario à son dernier état connu bon.

Exemple 3 : Rejet de non-concordance 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 d'échouer plus tard lors de la réplication.

Les preuves pour le rejet de non-concordance de version devraient inclure la liaison de port et le démarrage du pilote réseau, l'identité de la build propriétaire, et la condition qui ramène ce scénario à son dernier état connu bon.

Modes de défaillance et récupération

L'exécutable du serveur se construit mais la carte est manquante

Auditer l'inclusion de la carte de cuisson, les règles du gestionnaire d'actifs, les références douces et le manifeste d'archive. La disponibilité de l'éditeur n'est pas une preuve de contenu préparé.

Avant de fermer l'exécutable du serveur se construit mais la carte est manquante, relancer l'hôte systemd et prouver que la liaison de port et le démarrage du pilote réseau reviennent à la limite attendue sans étape de réparation non documentée.

Le processus est vivant mais ne peut pas accepter de joueurs

Séparer la liveness de la readiness et journaliser les étapes de carte, de pilote réseau, de liaison de port, de service en ligne et de création de session. Redémarrer aveuglément masque le premier échec.

Avant de fermer le processus est vivant mais ne peut pas accepter de joueurs, relancer le canari de conteneur et prouver 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 sur une bibliothèque ou une permission

Exécuter dans l'image finale ou la classe d'hôte, inspecter les dépendances dynamiques, le bit d'exécution, les chemins sensibles à la casse, les répertoires inscriptibles et la propriété non-root.

Avant de fermer le démarrage Linux échoue sur une bibliothèque ou une permission, relancer le rejet de non-concordance de version et prouver que la readiness, la terminaison, les journaux, les sorties de crash et le retour en arrière reviennent à la limite attendue sans étape de réparation non documentée.

Le déploiement tue les sessions actives brutalement

Gérer la terminaison, retirer la readiness, arrêter d'accepter les connexions, sauvegarder ou fermer le travail autoritaire, puis quitter avant le délai de l'orchestrateur.

Avant de fermer le déploiement tue les sessions actives brutalement, relancer l'hôte systemd et prouver que les hachages du moteur, du projet, de la cible et de l'artefact reviennent à la limite attendue sans étape de réparation non documentée.

Matrice de validation

• moteur, projet, cible et hachages d'artefact : l'inspecter à côté de la cible de build ; réussir uniquement lorsque l'exécutable du serveur se construit mais la carte est manquante ne se reproduit pas pendant l'hôte systemd et que les preuves nomment la build exacte.
• manifeste de cuisson et présence de carte requise : inspectez-le à côté de l'artefact préparé ; passe uniquement lorsque le processus est vivant mais ne peut pas accepter les joueurs ne se produit pas pendant le canary du conteneur et que les preuves nomment la bonne version de construction.
• liaison de port et démarrage du pilote réseau : l'inspecter à côté du contrat d'exécution ; réussir uniquement lorsque le démarrage Linux échoue sur une bibliothèque ou une permission ne se reproduit pas pendant le rejet de non-concordance de version et que les preuves nomment la build exacte.
• connexion client, voyage et déconnexion : inspectez-le à côté du cycle de vie des opérations ; passez uniquement lorsque la fermeture brutale des sessions actives par le déploiement ne se reproduit pas pendant l'hôte systemd et que les preuves nomment la version exacte.
• prêt, terminaison, journaux, sortie d'erreur et retour en arrière : inspectez-le à côté de la cible de construction ; passez uniquement lorsque la construction de l'exécutable du serveur réussit mais que la carte est absente ne se reproduit pas pendant le canari de conteneur et que les preuves nomment la version exacte.

Limites de version et de source

Ces étapes ciblent la surface de documentation actuelle d'Unreal Engine 5 au 26 juillet 2026. Les paramètres par défaut du moteur, le statut expérimental, l'emballage des plugins, les signatures d'API et le support des plateformes peuvent changer. Sélectionnez la version de documentation correspondant au projet, testez la mise à jour exacte et la cible, et conservez une révision de retour en arrière. La documentation publique ne remplace pas les exigences de NDA, les revues de magasin, la certification de console ou les preuves de performance spécifiques au projet.

Sources officielles

• Setting Up Dedicated Servers — preuve de source pour la cible de construction dans ce workflow de déploiement de serveur dédié Unreal ; vérifiez la version de la documentation par rapport à la branche de distribution.
• Opérations de construction : Cuisson, Paquet, Déploiement, Exécution — preuve de source pour l'artefact préparé dans ce workflow de déploiement de serveur dédié Unreal ; vérifiez la version de la documentation par rapport à la branche de distribution.
• Command-Line Arguments — preuve de source pour le contrat d'exécution dans ce workflow de déploiement de serveur dédié Unreal ; vérifiez la version de la documentation par rapport à la branche de distribution.

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

Du plan technique à un jeu SEELE Unreal

Utilisez cette page pour définir le système, les tests d'acceptation et les limites de défaillance ; puis portez ce brief précis dans [le créateur de jeux Unreal de SEELE](/features/create/unreal-game). SEELE peut générer un jeu Unreal 5 natif, fournir une prévisualisation en navigateur, soutenir l'optimisation et l'emballage dans SEELE, et vous permettre de télécharger le projet ou la sortie emballé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 le respect des plateformes ne sont pas garantis. Gardez le jeu Unreal source, les journaux de construction, les preuves de test et les décisions de publication externe sous le contrôle de votre équipe.

FAQ

Quelle est l'architecture correcte pour unreal dedicated server build deploy linux ?

Créez une cible de serveur, générez avec une chaîne d'outils Unreal capable de gérer les sources, préparez le contenu pour la plateforme du serveur, et empaquetez un artefact headless versionné avec la configuration, les cartes et les bibliothèques d'exécution nécessaires. Démarrez-le avec une carte explicite, un port, un chemin de journalisation et des indicateurs non interactivés ; exposez séparément la santé du processus et de la session ; préservez stdout ou les journaux de fichiers ; et déployez l'artefact testé exactement via un service, un conteneur ou un orchestrateur avec arrêt doux et retour en arrière. Commencez par la cible de génération et l'artefact préparé, puis maintenez la présentation comme observateur de l'état de jeu confirmé.

Unreal dedicated server build deploy linux doit-il être construit en Blueprint ou en C++ ?

Les deux peuvent fonctionner. Le Blueprint est efficace pour la logique de jeu rapide et l'itération du concepteur ; le C++ est utile pour les contrats réutilisables, la gestion de la durée de vie complexe, les boucles sensibles aux performances et les tests automatisés. Préservez les mêmes limites de propriétaire, de validation, d'échec et de récupération dans les deux.

Comment unreal dedicated server build deploy linux doit-il être testé ?

Testez un cas normal, une entrée invalide, une interruption ou une désactivation, un redémarrage propre et une parité de build empaqueté. Capturez les hachages du moteur, du projet, de la cible et de l'artefact, le manifeste de cuisson et la présence de carte requise, la liaison de port et le démarrage du pilote réseau avec un identifiant de build et des critères de passage explicites.

Quelle est la défaillance la plus dangereuse dans unreal dedicated server build deploy linux ?

La build de l'exécutable du serveur mais la carte manquante est un avertissement précoce : Auditez l'inclusion des cartes dans la cuisson, les règles du gestionnaire d'actifs, les références douces et le manifeste d'archive. La disponibilité de l'éditeur n'est pas une preuve de contenu préparé. Vérifiez également la suppression et la réessaie afin que la solution apparente ne laisse pas un état obsolète.

Quelle version d'Unreal ce guide unreal dedicated server build deploy linux cible-t-il ?

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

Que peut faire SEELE après que ce plan unreal dedicated server build deploy linux soit prêt ?

SEELE peut générer un jeu natif Unreal 5, fournir un aperçu dans le navigateur, prendre en charge l'optimisation et l'emballage, et fournir des téléchargements de projet ou d'application emballée pour une publication externe ou une version gratuite ou payante de SEELE. Il ne garantit pas l'approbation des magasins tiers, la compatibilité, les ventes ou les revenus.