Guía de compilación de servidor dedicado de Unreal y despliegue en Linux

Respuesta directa

Crea un objetivo de servidor, compila con una toolchain de Unreal con soporte de source, realiza cook del contenido para la plataforma del servidor y empaqueta un artefacto headless versionado con configuración, mapas y bibliotecas en tiempo de ejecución necesarias. Inícialo con un mapa explícito, puerto, ruta de logs y banderas unattended; expón por separado la salud del proceso y de sesión; conserva logs de stdout o de archivo; y despliega el artefacto exacto y probado mediante un servicio, contenedor u orquestador con apagado gradual y reversión.

Esta página trata la entrega build-to-runtime en Linux. No repite el diseño de replicación, el matchmaking, la selección de proveedor cloud ni la integración antitrampas. El objetivo práctico es un recorte de construcción de juego que otro desarrollador pueda reproducir desde un checkout limpio. Mantén separados el comportamiento del motor, la política del proyecto y la evidencia medida: la documentación de Epic establece conceptos compatibles, el proyecto define propiedad y presupuestos, y solo una ejecución de prueba con nombre propio valida el resultado local.

Lo que ofrece esta guía

• Un modelo de propiedad concreto para despliegue y compilación de servidor dedicado en Unreal para Linux.
• Un flujo de trabajo de implementación en seis etapas en Blueprint/C++ con un ejemplo real de API o comando.
• Tres escenarios de producción, incluyendo comportamiento normal, de borde y de transferencia.
• Criterios de recuperación de fallos y validación para builds de editor y empaquetadas.
• Una entrega de SEELE acotada que conduce al creador de Unreal sin cambiar la intención técnica de esta página.

Arquitectura del sistema y propiedad

Objetivo de compilación

Un archivo Target.cs selecciona TargetType.Server, módulos, configuración de compilación y plataformas compatibles. La compilación del servidor elimina necesidades de renderizado y jugador local, pero aún requiere módulos del juego y assets cocinados usados por la lógica autoritativa.

Revisión del objetivo de compilación: captura hashes de motor, proyecto, objetivo y artefacto y muestra cómo el artefacto cocinado recibe u observa el resultado aceptado sin convertirse en un segundo propietario.

Artefacto cocido

Automatiza BuildCookRun o BuildGraph con un motor y revisión de proyecto fijados. Registra el comando, el código de salida, el manifiesto, el hash de archivo archivado, la lista de mapas, la configuración y si las versiones de contenido de cliente y servidor coinciden.

Revisión del artefacto cocinado: captura el manifiesto de cook y la presencia del mapa requerido y muestra cómo el contrato de runtime recibe u observa el resultado aceptado sin convertirse en un segundo propietario.

Contrato de tiempo de ejecución

Comienza con mapas explícitos, puerto, registro, modo desatendido, caída y directiva de stdout. El entorno o la configuración inyectan secretos; nunca incrustes credenciales en vivo en DefaultEngine.ini ni en el archivo empaquetado.

Revisión del contrato de ejecución: captura la asignación de puerto y el inicio del controlador de red y muestra cómo el ciclo de vida operativo recibe u observa el resultado aceptado sin convertirse en un segundo propietario.

Ciclo de vida operativo

La salud del proceso indica que el ejecutable está vivo; la readiness indica que el mundo y la capa online/session pueden aceptar jugadores. Gestiona SIGTERM o detención del servicio, rechaza nuevo trabajo, descarga el estado, cierra sesiones y sale dentro de un plazo.

Revisión del ciclo de vida operativo: captura la conexión, travel y desconexión del cliente y muestra cómo el objetivo de compilación recibe u observa el resultado aceptado sin convertirse en un segundo propietario.

Flujo de trabajo de implementación

1. Etapa 1: Añade ProjectServer.Target.cs con TargetType.Server y compílalo en un agente limpio usando el flujo de Unreal source requerido o el flujo de instalación para la versión objetivo.
2. Etapa 2: Ejecuta un comando BuildCookRun reproducible para LinuxServer, mapas nombrados y la configuración de Development o Shipping prevista. Archiva símbolos y manifiestos por separado del artefacto público.
3. Etapa 3: Realiza una prueba de humo local del servidor con un mapa y puerto fijos, revisa el registro de inicio a través de la preparación del mundo y luego conecta un cliente con versión coincidente y ejercita travel y desconexión.
4. Etapa 4: Empaqueta el archivo en un directorio de servicio o imagen de contenedor mínima, ejecuta como usuario no root siempre que sea posible, monta logs y salida de fallos con escritura y configura la inyección de configuración en tiempo de ejecución.
5. Etapa 5: Define liveness, readiness, límites de recursos, exposición de puertos, terminación gradual, tiempo de espera de inicio y etiquetas de versión de artefacto. No uses el conteo de jugadores como único indicador de salud del proceso.
6. Etapa 6: Despliega un canario, conéctate y completa una sesión representativa, ciérrala de forma ordenada, verifica los registros y el vaciado de estado, y luego despliega o revierte mediante un identificador de artefacto inmutable.

Ejemplo concreto de API o comando

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

Tres escenarios de producción

Ejemplo 1: Host de systemd

Instala un archivo inmutable, inyecta el entorno desde un archivo de servicio protegido, configura Restart=on-failure, reenvía logs y usa ExecStop con una ruta de apagado en el juego gradual antes del tiempo de espera del servicio.

La evidencia para systemd debe incluir los hashes de motor, proyecto, objetivo y artefacto, la identidad de compilación propietaria y la condición que devuelve este escenario a su estado conocido como válido.

Ejemplo 2: Canary en contenedor

Expón explícitamente puertos UDP de juego y de consulta, monta la salida de crash, etiqueta la imagen con los commits de motor y proyecto, y condiciona la readiness a la inicialización de mapa y sesión.

La evidencia del canario de contenedor debe incluir el manifiesto de cook y la presencia del mapa requerido, la identidad de compilación propietaria y la condición de que este escenario regresa a su último estado conocido como correcto.

Ejemplo 3: Rechazo por incompatibilidad de versión

Cliente y servidor intercambian una versión de contenido o protocolo compatible. El servidor rechaza a un cliente incompatible con una razón visible en lugar de aceptarlo y fallar luego durante la replicación.

La evidencia de rechazo por incompatibilidad de versión debe incluir la vinculación del puerto y el arranque del net-driver, la identidad de compilación propietaria y la condición que devuelve este escenario a su estado conocido como válido.

Modos de fallo y recuperación

El ejecutable del servidor se construye, pero falta el mapa

Audita la inclusión del mapa en cook, las reglas del asset manager, referencias blandas y el manifiesto de archivo. La disponibilidad del editor no es evidencia de contenido cocinado.

Antes de cerrar "el ejecutable del servidor se construye pero falta el mapa", vuelve a ejecutar el host de systemd y demuestra que la asignación de puertos y el inicio del controlador de red regresan al límite esperado sin un paso de reparación no documentado.

El proceso está vivo pero no puede aceptar jugadores

Separa liveness de readiness y registra los pasos de mapa, net driver, vinculación de puerto, servicio en línea y creación de sesión. Reiniciar a ciegas oculta el primer fallo.

Antes de cerrar, aunque el proceso esté activo pero no pueda aceptar jugadores, vuelve a ejecutar el canario de contenedor y demuestra que la conexión de cliente, el travel y la desconexión regresan al límite esperado sin un paso de reparación no documentado.

El inicio de Linux falla por una biblioteca o un permiso

Ejecuta en la imagen final o clase de host, inspecciona dependencias dinámicas, ejecución de bits, rutas con distinción de mayúsculas/minúsculas, directorios escribibles y propiedad sin privilegios root.

Antes de cerrar, que Linux falle al iniciar por una librería o permiso, vuelve a ejecutar el rechazo por incompatibilidad de versión y demuestra que readiness, terminación, registros, salida de crash y reversión regresan al límite esperado sin un paso de reparación sin documentar.

El despliegue termina sesiones activas bruscamente

Gestiona la terminación, quita la readiness, deja de aceptar uniones, guarda o cierra el trabajo autorizado y luego sale antes del límite de tiempo del orquestador.

Antes de cerrar, la implementación mata sesiones activas bruscamente; vuelve a ejecutar el host systemd y demuestra que los hashes de motor, proyecto, objetivo y artefacto regresan al límite esperado sin un paso de reparación sin documentar.

Matriz de validación

• hashes de motor, proyecto, objetivo y artefacto: revísalo junto al objetivo de compilación; apruébalo solo cuando la construcción del ejecutable del servidor se complete pero el mapa falte no se repita en el host de systemd y la evidencia nombre la compilación exacta.
• manifiesto de cook y presencia del mapa requerido: revísalo junto al artefacto cocido; apruébalo solo cuando el proceso está vivo pero no puede aceptar jugadores no se repita durante el canario de contenedor y la evidencia nombre la compilación exacta.
• asignación de puerto e inicio del controlador de red: Inspección junto al contrato de runtime; aprobar solo cuando el arranque de Linux falle por una librería o permiso y ello no se repita durante el rechazo por incompatibilidad de versión y la evidencia nombre el build exacto.
• conexión de cliente, travel y desconexión: revísalo junto al ciclo de vida operativo; apruébalo solo cuando el despliegue termina sesiones activas bruscamente no se repita en el host de systemd y la evidencia nombre la compilación exacta.
• readiness, terminación, registros, salida de crash y reversión: Inspección junto al objetivo de compilación; aprobar solo cuando no se repita que el ejecutable del servidor se construye pero falta el mapa durante el canario en contenedor y la evidencia nombre el build exacto.

Presentación y autoridad: verifica únicamente que múltiples interacciones por pulsación no se dispare más de una vez durante la puerta con estado de bloqueo y que las evidencias indiquen la build exacta.

Estos pasos apuntan a la superficie de documentación actual de Unreal Engine 5 al 2026-07-26. Los valores predeterminados del motor, el estado experimental, el empaquetado de plugins, las firmas de API y el soporte de plataforma pueden cambiar. Selecciona la versión de documentación que coincida con el proyecto, prueba el parche exacto y destino objetivo, y conserva una revisión de reversión. La documentación pública no sustituye los requisitos de NDA de plataforma, revisión de tienda, certificación de consola o evidencia de rendimiento específica del proyecto.

Fuentes oficiales

• Configuración de servidores dedicados — evidencia fuente del objetivo de compilación en este flujo de trabajo de construcción y despliegue de servidor dedicado de Unreal en Linux; verifica la versión de la documentación con la rama shipping.
• Operaciones de compilación: Cook, Package, Deploy, Run — evidencia fuente del artefacto cocinado en este flujo de unreal dedicated server build deploy linux; verificar la versión de la documentación con la rama de shipping.
• Argumentos de línea de comandos — evidencia fuente del contrato de ejecución en este flujo de trabajo de compilación y despliegue de servidor dedicado de Unreal en Linux; verifica la versión de la documentación con la rama shipping.

Unreal Engine es una marca registrada de Epic Games. SEELE AI es independiente y este artículo no implica respaldo de Epic Games ni de Valve.

Del plan técnico a un juego de Unreal de SEELE

Utiliza esta página para definir el sistema, las pruebas de aceptación y los límites de fallo; luego lleva ese planteamiento preciso al [creador de juegos Unreal de SEELE](/features/create/unreal-game). SEELE puede generar un juego nativo de Unreal 5, proporcionar una vista previa en el navegador, soportar la optimización y empaquetado en SEELE, y permitirte descargar el proyecto o el resultado empaquetado para publicación externa o publicarlo como un juego SEELE gratuito o de pago.

Esa entrega no cambia la responsabilidad de producción nativa descrita anteriormente. La aprobación de la tienda, ventas, ingresos, certificación, compatibilidad con complementos de terceros y cumplimiento de la plataforma no están garantizados. Mantén el juego de Unreal de origen, registros de compilación, evidencia de prueba y decisiones de publicación externa bajo el control de tu equipo.

FAQ

¿Cuál es la arquitectura correcta para unreal dedicated server build deploy linux?

Crea un objetivo de servidor, compila con una toolchain de Unreal con soporte de source, realiza cook del contenido para la plataforma del servidor y empaqueta un artefacto headless versionado con configuración, mapas y bibliotecas en tiempo de ejecución necesarias. Inícialo con un mapa explícito, puerto, ruta de logs y banderas unattended; expón por separado la salud del proceso y de sesión; conserva logs de stdout o de archivo; y despliega el artefacto exacto y probado mediante un servicio, contenedor u orquestador con apagado gradual y reversión. Comienza con objetivo de compilación y artefacto cocido, luego mantén la presentación como observador del estado de juego comprometido.

¿Se debe implementar la compilación y el despliegue de servidor dedicado de Unreal en Blueprint o en C++?

Ambos pueden funcionar. Blueprint es efectivo para lógica de juego rápida y para la iteración de los diseñadores; C++ es útil para contratos reutilizables, ciclos de vida complejos, bucles sensibles al rendimiento y pruebas automatizadas. Mantén los mismos límites de propietario, validación, fallo y recuperación en ambos.

¿Cómo se debe probar la compilación y el despliegue de servidor dedicado de Unreal en Linux?

Prueba un caso normal, una entrada inválida, una interrupción o desmontaje, reinicio limpio y paridad del build empaquetado. Captura los hashes de motor, proyecto, objetivo y artefacto, el manifiesto de cook y la presencia del mapa requerido, la vinculación de puerto y el arranque del net-driver con un identificador de compilación y criterios de aprobación explícitos.

¿Cuál es el fallo más peligroso en la compilación y despliegue de servidor dedicado de Unreal en Linux?

Que el ejecutable del servidor se construya pero falte el mapa es una alerta temprana: audita la inclusión del mapa en cook, las reglas del asset manager, las referencias blandas y el manifiesto de archivo. La disponibilidad del editor no es evidencia de contenido cocinado. También verifica limpieza y reintento para que la solución aparente no deje estado obsoleto.

¿A qué versión de Unreal está dirigida esta guía de unreal dedicated server build deploy linux?

Utiliza la superficie de documentación de Unreal Engine 5 disponible al 2026-07-26. Confirma el selector de versión, la firma de la API, el estado de los plugins, la toolchain de plataforma y el comportamiento empaquetado en el parche exacto del motor que se enviará.

¿Qué puede hacer SEELE después de que este plan de compilación y despliegue de servidor dedicado de Unreal en Linux esté listo?

SEELE puede generar un juego nativo de Unreal 5, proporcionar previsualización en el navegador, soportar optimización y empaquetado, y proporcionar descargas del proyecto o empaquetado para publicación externa o un lanzamiento gratuito o de pago de SEELE. No garantiza la aprobación de tiendas de terceros, compatibilidad, ventas o ingresos.