Configurar un servidor 7 Days to Die pour jouer en équipe

El archivo serverconfig.xml 7 Days to Die es la pieza central que decide si una partida cooperativa fluye con un ritmo justo o se convierte en un caos de hordas ingobernables y loot mal repartido. Slots, dificultad, comportamiento zombi y velocidad de progresión del grupo se controlan ahí, parámetro por parámetro, sin necesidad de mods externos.

Dónde está serverconfig.xml en 7 Days to Die y cómo prepararlo

El archivo se encuentra en la carpeta raíz de la instalación, normalmente junto al ejecutable 7DaysToDieServer.exe o, en un entorno Linux, junto al binario del servidor. Si administras desde un panel tipo Pterodactyl, lo verás directamente en el gestor de archivos web, lo que evita tener que conectarte por FTP o SSH cada vez que quieras tocar un valor.

Antes de modificar nada, haz una copia del archivo original. El formato es XML clásico, con pares property name="..." value="...", sensible a mayúsculas y a comillas mal cerradas: un error de sintaxis basta para que el servidor no arranque.

<ServerSettings>
  <property name="ServerName" value="Coop-Supervivientes" />
  <property name="ServerPassword" value="" />
  <property name="ServerMaxPlayerCount" value="6" />
  <property name="ServerVisibility" value="2" />
</ServerSettings>

Guarda siempre una copia antes de aplicar cambios masivos: una sauvegarda reciente del mundo y del archivo de configuración te permite revertir en segundos si una combinación de valores rompe la partida. Si quieres partir de una base ya optimizada para varios jugadores sin montar cada parámetro desde cero, puedes revisar el alojamiento servidor 7 Days to Die de Fly-Serv, que incluye plantillas listas para cooperativo.

Slots, visibilidad y acceso para partidas en grupo

El primer bloque de ajustes de serverconfig.xml 7 Days to Die define cuántos jugadores entran y cómo se descubre el servidor en la red. Para cooperativo pequeño (amigos conocidos) suele bastar con visibilidad limitada y contraseña; para comunidades abiertas conviene exponer el servidor con filtros de acceso más estrictos vía lista blanca.

Parámetros clave de slots y acceso

Propiedad	Función	Recomendación cooperativo
ServerMaxPlayerCount	Número máximo de jugadores simultáneos	4 a 8 para un grupo estable
ServerVisibility	0=privado, 1=amigos, 2=público	1 o 2 según si aceptas invitados externos
ServerPassword	Contraseña de entrada	Siempre activa fuera de grupos cerrados
EnableWhitelist	Lista blanca de cuentas permitidas	True en servidores comunitarios
DropOnDisconnect	Si el inventario cae al desconectar	False para evitar pérdidas accidentales

Un detalle que muchos pasan por alto: ServerMaxPlayerCount también influye en el rendimiento del mundo simulado. Cada jugador activo implica chunks cargados, IA de zombis calculada y entidades físicas en memoria. En un hardware con CPU de frecuencia alta y almacenamiento NVMe, seis u ocho jugadores no suponen un problema; en hardware compartido y saturado, la latencia de cada ciclo de horda se nota rápido.

Dificultad y ritmo de progresión en equipo

La dificultad en serverconfig.xml 7 Days to Die no es un único valor, sino una combinación de parámetros que, mal ajustados, pueden hacer que el grupo avance demasiado rápido (aburrimiento) o se quede atascado en los primeros días (frustración y abandono de la partida).

Loot y economía de recursos para varios jugadores

• LootAbundance: porcentaje de ítems generados en contenedores. En cooperativo con 4+ jugadores, bajarlo entre un 10% y un 25% respecto al valor por defecto evita saturar al grupo de recursos.
• LootRespawnDays: días hasta que un contenedor ya saqueado vuelve a tener loot. Subirlo ligeramente obliga a explorar más lejos en lugar de repetir los mismos puntos.
• AirDropFrequency y AirDropMarker: controlan la frecuencia de suministros aéreos, un buen incentivo para que el grupo coordine desplazamientos.

Experiencia y curva de nivel

<property name="PlayerExperienceMultiplier" value="80" />
<property name="PartySharedKillRange" value="100" />
<property name="BuildCreate" value="false" />
<property name="GameDifficulty" value="2" />

PartySharedKillRange es clave en cooperativo: define el radio en el que la experiencia por matar zombis se reparte entre los miembros del grupo. Un valor demasiado bajo deja fuera a quien no está pegado al objetivo; uno generoso mantiene nivelado a todo el equipo aunque se dispersen por el mapa.

GameDifficulty va de 0 (más fácil) a 5 (pesadilla). Para un grupo de 4-6 jugadores con experiencia media en el juego, un valor de 2 o 3 suele mantener tensión sin volver imposible la supervivencia temprana. Si el grupo es nuevo, empezar en 1 y subir progresivamente mantiene la motivación.

Zombies: hordas, luna de sangre y comportamiento multijugador

El comportamiento zombi es, junto a la dificultad, el ajuste que más define el ritmo de una partida cooperativa. serverconfig.xml 7 Days to Die permite afinar desde la frecuencia de la horda nocturna hasta la sensibilidad de detección de los zombis feroces.

Horda de luna de sangre (Blood Moon)

Propiedad	Descripción	Ajuste sugerido en grupo
BloodMoonFrequency	Cada cuántos días llega la horda	7 por defecto; 10 para dar más margen de preparación
BloodMoonEnemyCount	Cantidad de zombis simultáneos en la horda	Escalar con el número de jugadores (8-12 por jugador activo)
BloodMoonWarning	Horas de aviso antes del evento	Mantener en 8 para coordinar defensas
BloodMoonRange	Distancia de activación respecto a jugadores	Por defecto suele funcionar bien

BloodMoonEnemyCount merece atención especial: es un contador por jugador conectado, no un total fijo. Con un grupo grande y un valor alto, el número real de zombis simulados puede disparar el consumo de CPU durante el evento. Un procesador de frecuencia alta y memoria suficiente marca la diferencia entre una horda fluida y caídas de tasa de tick justo cuando más se necesita estabilidad.

Comportamiento fuera de la luna de sangre

<property name="ZombieMove" value="1" />
<property name="ZombieMoveNight" value="3" />
<property name="ZombieFeralSense" value="1" />
<property name="DayNightLength" value="60" />
<property name="DaysPerMoonCycle" value="7" />

ZombieMoveNight controla la velocidad nocturna de desplazamiento; en cooperativo, dejarlo en correr (valor 3) obliga al grupo a asegurar refugios antes del anochecer en lugar de ignorar el ciclo día-noche. ZombieFeralSense define si los zombis feroces detectan jugadores a mayor distancia, algo que vuelve más tenso cualquier desplazamiento nocturno en grupo disperso.

Un consejo práctico: aplica los cambios de a poco y reinicia el servidor entre cada bloque de ajustes para observar el efecto real antes de combinar varias modificaciones. La consola del panel permite ver en vivo los logs de spawn y detectar si una horda se está disparando por encima de lo previsto.

Para comparar comportamientos con otros juegos de supervivencia cooperativa que también exponen ficheros de configuración similares, puedes revisar todos nuestros servidores de juegos o, si gestionas varias instancias propias, el panel desde un VPS Pterodactyl.

Ajustar serverconfig.xml 7 Days to Die para cooperativo es un trabajo de prueba y ajuste fino: slots acordes al grupo, dificultad progresiva, loot equilibrado y hordas que escalen con el número de jugadores. Documenta cada cambio y mantén copias del archivo antes de tocarlo.

FAQ

¿Por qué el servidor no arranca después de editar serverconfig.xml?

Casi siempre es un error de sintaxis XML: una comilla sin cerrar, una etiqueta mal cerrada o un valor fuera de rango. Revisa el log de arranque en la consola del panel; suele indicar la línea exacta del problema.

¿Cómo evitar que la horda de luna de sangre colapse el rendimiento con muchos jugadores?

Reduce BloodMoonEnemyCount o aumenta BloodMoonFrequency para dar más margen entre eventos. Un hardware con CPU de frecuencia alta y NVMe ayuda a mantener la tasa de tick estable durante picos de zombis.

¿Se puede aplicar un cambio en serverconfig.xml sin perder el progreso del mundo?

Sí, la mayoría de propiedades se aplican al reiniciar el proceso sin afectar el guardado del mundo. Aun así, conviene hacer una sauvegarda previa por si el valor modificado genera un comportamiento inesperado.