Guía de servidor dedicado Dragonhold

Dragonhold no es always-online. Exis Games provee archivos de servidor dedicado en Steam para que jugadores hosteen sesiones co-op persistentes sin mantener cliente completo abierto como listen host — más servidores oficiales y comunitarios a los que puedes unirte libremente. Esta guía recorre conceptos de hosting, flujo de instalación Steam, checks de conectividad y defaults de red reportados por comunidad. Está escrita para admins PC Early Access; verifica ajustes contra config local porque puertos y argumentos de lanzamiento pueden cambiar entre parches.

Combina con Checklist de puertos del servidor por checks pre-vuelo imprimibles y Guía co-op por etiqueta de party in-mission una vez amigos conecten.

Por qué correr servidor dedicado

Beneficios sobre listen hosting ad-hoc:

• Persistencia de sesión — Amigos se unen a dirección estable mientras admins mantienen proceso por separado.
• Margen de rendimiento — Máquina dedicada (o VM) evita correr gráficos de cliente más simulación de servidor en un rig pesado en GPU.
• Grupos co-op amigables con horarios — Parties Boundless Order a largo plazo mantienen mismo mundo entre noches de juego.

Tradeoffs incluyen configuración de router, reglas Windows firewall e inestabilidad Early Access cuando builds de servidor van detrás de hotfixes de cliente — observa Actualizaciones tras parches.

Archivos de servidor dedicado Steam

Steam lista herramientas de servidor dedicado para Dragonhold junto a app principal del juego (1510330 en store). Flujo admin típico:

1. Instala SteamCMD o usa app ID de servidor dedicado si figura en documentación de servidor.
2. Descarga/actualiza archivos de servidor dedicado Dragonhold a carpeta dedicada (no mezclada con desorden de save personal).
3. Configura ajustes de servidor vía archivos Config incluidos — plugins comunitarios WindowsGSM referencian rutas Dragonhold/Config pero notan comportamiento de consola experimental en Early Access.
4. Lanza binario de servidor con logging habilitado para primeras pruebas (-log aparece en plantillas host comunitarias).
5. Confirma listen local en puertos esperados antes de invitar amigos externos.

Nombres exactos de ejecutables y app IDs deben confirmarse desde sección Dedicated Server de Steam al instalar — Early Access baraja layout de archivos ocasionalmente.

Puertos reportados por comunidad (verifica localmente)

Docs de hosting comunitarios — incluyendo plugins WindowsGSM Dragonhold de terceros — citan comúnmente:

Puerto	Protocolo	Uso reportado
7777	UDP	Puerto de juego por defecto
27015	UDP	Puerto query por defecto

Importante: Estos valores están reportados por comunidad, no copiados aquí como constantes oficiales garantizadas. Autores de plugins dicen explícitamente “No idea if those are correct” y apuntan admins a archivos config locales. Siempre lee config generada tras updates.

Reenvía ambos puertos UDP en router a IP LAN del PC host cuando amigos conecten desde internet. Usa Checklist de puertos del servidor paso a paso.

Firewall y NAT

En hosting Windows:

• Permite inbound UDP para puertos de juego y query en Windows Defender Firewall.
• Desactiva escenarios double-NAT (módem + router ambos NATeando) o coloca PC servidor en DMZ solo como último recurso — entiende tradeoffs de seguridad.
• Prueba conectividad externa con amigos o checkers UDP de terceros — abierto localmente no significa abierto a internet.

Alternativas LAN y VPN

Cuando port forwarding falla:

• Juego LAN — Amigos en misma red conectan vía IP local (patrón 192.168.x.x:7777 en guías comunitarias).
• Herramientas VPN mesh — Redes ZeroTier-style crean LANs virtuales; hosts comunitarios reportan éxito apuntando clientes a IPs virtuales (patrón ejemplo 10.x.x.x:7777). Ver página checklist por pasos high-level sin endorsar vendor específico.

Flujo de conexión del cliente

Jugadores se unen vía browser de servidores Steam o IP:puerto directo según UI Early Access — confirma etiquetas de menú actuales tras parches. Si clientes timeout:

1. Verifica proceso servidor corriendo y puertos escuchando.
2. Re-chequea forwards UDP y firewall.
3. Confirma builds cliente y servidor coinciden post-parche.
4. Reintenta LAN antes WAN para aislar issues de router.

Saves y administración

Mundos dedicados generan saves server-side distintos de islas hub solo en muchos despliegues estilo Unreal — localiza rutas de save en config tras primer boot y respaldar antes de parches. Admins deben documentar:

• Ruta de directorio de save.
• Política auto-update (updates SteamCMD programados vs noches de parche manual).
• Contraseña admin / ajustes whitelist si config lo soporta.

Expectativas de hardware para hosts

Hostear más jugar en una máquina estresa CPU, RAM y GPU. Requisitos del sistema listan specs de cliente (~GTX 1080 min, RTX 2070 rec, 73 GB almacenamiento). Hosts solo-dedicados importan más rendimiento single-thread CPU y RAM que GPU — pero rigs host+jugador necesitan ambos.

Steam Deck no está soportado oficialmente para cliente según declaraciones del desarrollador; no asumas que Deck puede hostear fiablemente.

Servidores oficiales vs comunitarios

Texto Steam store menciona servidores oficiales provistos libremente junto a self-hosting. Guía admin dedicada se enfoca en self-hosting; jugadores que no quieren dolor de router pueden unirse a listados oficiales/comunitarios cuando estén poblados — población fluctúa en Early Access.

Guías relacionadas

• Cómo alojar un servidor — walkthrough host primera vez narrativo.
• Guía co-op — roles de party tras conectar.
• Hub multijugador — overview enlazando todos los temas online.

Self-hosting co-op Dragonhold es absolutamente posible en Early Access — éxito es mayormente higiene de red, coincidencia de versión y tratar números de puerto comunitarios como hipótesis que confirmas en tus propios archivos config.