El Encounter Manager de Hytale ya está disponible en el pre-release. Permite a cualquier administrador diseñar boss fights multi-fase sin tocar código de motor: Fases, oleadas, condiciones de victoria y cambios de arena se configuran como contenido. Esta guía muestra cómo crear tu primer encounter personalizado paso a paso.
- Coordina fases, oleadas y transiciones de arena en un solo archivo.
- Los designers oficiales lo usan para el primer dungeon hecho a mano (Cap. 1).
- El pre-release ya trae la documentación base y un encounter de ejemplo para clonar.
Por qué el Encounter Manager cambia cómo se diseña un boss en Hytale
Antes del Encounter Manager, un boss fight en un juego tipo sandbox requería tocar código de motor o contratar a un programador que recompilase el binario. En Hytale, ese ciclo se acabó. Simon, el Game Director, lo dijo con claridad en el blog de Chapter 1: La tecnología detrás del primer boss multi-fase ya está disponible al público, y los encounters se escriben como contenido, no como código de motor.
En la práctica esto significa que tu primer boss personalizado sale en horas, no en semanas. Si sabes escribir un archivo JSON, ya tienes lo principal. Si no, el pre-release trae un encounter de ejemplo que puedes clonar y modificar para entender la lógica. En el resto de esta guía verás los cuatro componentes que controlan cualquier encounter: Fases, triggers, condiciones de victoria y cambios de arena. Y un flujo de trabajo que aplica tanto al Feastmaster de los Goblins como a un dragón de lava que inventes el viernes por la noche.
Antes de tocar nada, asegúrate de tener el pre-release de Hytale instalado y un servidor local levantado. Los pasos siguientes asumen que ya arrancas HytaleServer.jar y entras al mundo.
Qué es un Encounter en Hytale (y qué no es)
Un encounter es un archivo de datos que describe una pelea: Dónde ocurre, qué oleadas se activan, qué condiciones disparan cada fase y qué pasa cuando ganas. El Encounter Manager lee ese archivo y coordina los sistemas del juego: Spawns, música, HUD, colisiones, condiciones. Para que la pelea funcione como una unidad. Tú solo escribes el guión.
Lo que el encounter no controla:
- El modelo 3D del boss. Eso vive en los assets del juego o en tu mod de assets.
- La inteligencia artificial base de los mobs. El encounter dispara comportamientos, no los reescribe.
- El balance numérico final. Tú defines el daño, la vida y el cooldown; El motor los aplica.
El alcance importa porque te ayuda a decidir qué puedes resolver como encounter y qué tiene que ir a otro sistema (asset pack, plugin, script). Si quieres un boss con tres cabezas que cambian de estrategia, el encounter lo coordina. Si quieres una cabeza con un mesh nuevo, eso va por el lado de assets.
Las cuatro piezas de cualquier encounter
Cuando abras un archivo de encounter verás casi siempre las mismas cuatro secciones. Entenderlas bien te evita reescribir el archivo cada vez que algo falla.
- Fases. Una fase es un bloque con un nombre y un estado. El Encounter Manager mueve al boss de fase A a fase B cuando se cumple un trigger. Las fases son estados puros: No ejecutan lógica por sí solas, solo esperan a que algo cambie.
- Triggers. Son condiciones que arrancan una transición. Las más usadas: Vida del boss por debajo de un umbral, tiempo transcurrido, número de mobs aliados muertos, jugador en una zona del mapa. El pre-release ya trae una librería con 12 triggers documentados.
- Oleadas y spawns. Cada fase puede invocar oleadas de mobs. Los spawns aceptan coordenadas, tipos, número y delay. El Encuentro manager no spawnea más allá de los límites que le pongas: Si defines 6 goblins de una vez y la arena tiene 4 huecos libres, los 2 restantes se quedan en cola.
- Condiciones de victoria y derrota. El encounter termina cuando se cumple una de dos rutas: El boss muere, o los jugadores mueren. Puedes anadir condiciones extra: Si el boss llega a una zona del mapa con vida, la fase se reinicia, o si un NPC aliado cae, se activa un miniboss de respaldo.
Esa separación entre fases (qué estado) y triggers (qué dispara) es la que hace que el sistema sea mantenible. Un encounter con 8 fases y 14 triggers sigue siendo legible si cada fase declara solo lo que cambia respecto a la anterior.
Crear tu primer boss personalizado: Flujo completo
El flujo está pensado para que lo completes en una tarde, desde cero, sobre un servidor local. Si ya tienes el pre-release y el binario corriendo, sáltate el paso 1.
Paso 1. Clona el encounter de ejemplo. El pre-release incluye un encounter llamado goblin_feastmaster_demo dentro de la carpeta encounters/ del proyecto. Cópialo con otro nombre en la misma carpeta, por ejemplo mi_boss_personalizado.json. El archivo es texto plano, lo editas con cualquier editor.
Paso 2. Cambia tres campos clave. El archivo clonado trae los datos del Feastmaster. Para tu propio boss modifica solo estos al inicio:
id: identificador único del encounter. Usa snake_case, sin espacios.arena.center: coordenadas X, Y, Z del centro de la arena.arena.radius: radio de la zona, en bloques. Define dónde se activan los triggers espaciales.
Mantén el resto del archivo intacto por ahora. Así confirmas que tu copia carga sin errores antes de añadir complejidad.
Paso 3. Define las fases. El Feastmaster de ejemplo tiene tres fases. Empieza con dos: Una de apertura y una de furia. La apertura dura hasta que el boss pierde el 70% de la vida; La furia, hasta que muere o el encounter expira.
Paso 4. Asigna los triggers. Los dos primeros triggers que necesitas son los de cambio de fase:
health_below: a 70% de vida, salta a la fase 2.elapsed_time: a 5 minutos, fuerza la fase 2 aunque la vida no haya bajado.
El segundo trigger es importante: Evita que un encounter se quede colgado si los jugadores no hacen suficiente daño. Es un seguro de tiempo, no un requisito.
Paso 5. Añade una oleada a la fase 2. En la fase 2 declara un spawn_wave con tres goblins arqueros en los bordes de la arena. Usa coordenadas relativas al centro o nombres de zonas predefinidas (north_balcony, east_pillar). El manager se encarga del resto.
Paso 6. Declara la condición de victoria. El default del motor es “boss muere”. Para algo más rico añade: Si el boss muere y al menos un jugador sigue dentro de la arena, se activa un evento de loot. Si todos los jugadores mueren, el encounter se considera derrota y se reinicia después de 30 segundos.
Paso 7. Carga y prueba. Entra al juego, teleporta a tu personaje a las coordenadas de la arena, y abre la consola de admin con /encounter start mi_boss_personalizado. El manager levanta el encounter. Si algo no carga, los logs del servidor te dicen qué campo está mal escrito.
Este flujo de siete pasos lo cubre todo: Clonar, identificar, configurar, probar. La mayoría de errores vienen de saltarse el paso 7 con prisa. Si pruebas cada cambio en local antes de subirlo al servidor público, evitas que tu comunidad vea un boss invisible o una oleada infinita.
Errores típicos al empezar con el Encounter Manager
Después de hacer docenas de encounters con la comunidad de Hytale, los tropiezos más comunes son siempre los mismos.
Definir la arena demasiado pequeña. Un radio de 12 bloques parece mucho en el editor, pero con tres oleadas simultáneas se llena. Empieza con 20 y ajusta después. Si los jugadores chocan contra los bordes y no pueden esquivar, la pelea se siente injusta aunque esté bien balanceada.
Reutilizar IDs de triggers entre fases. Cada trigger necesita un nombre único. Si dos fases usan el mismo health_below, el manager entra en conflicto y prioriza la primera que cargó. La pelea se queda en la fase 1.
Olvidar la condición de derrota. El motor asume una derrota por defecto, pero los mods externos a veces la sobrescriben. Declara siempre defeat_on.all_players_dead = true en el encounter. Así te aseguras de que el encounter termina pase lo que pase.
Hardcodear paths en lugar de usar zonas. Es tentador escribir spawn at 128, 64, -256. Funciona, pero rompe en cuanto alguien mueve la arena. Define zonas con nombre (west_summon, center_altar) y úsalas en los spawns. Si después mueves la arena 20 bloques al norte, solo cambias el centro y el resto se reajusta.
No probar con jugadores de prueba. Un encounter puede parecer balanceado en papel y romperse con tres personas. Antes de publicarlo, invita a tres amigos y mide cuánto dura la pelea real. La diferencia entre 4 minutos y 7 minutos cambia la dificultad por completo.
Encounter Manager vs plugins tradicionales: Cuándo usar cada uno
El Encounter Manager no reemplaza a los plugins ni a los mods de scripting. Son herramientas distintas que se complementan. La regla práctica:
- Si lo que quieres es coordinar mobs, oleadas y fases de una pelea, usa el Encounter Manager.
- Si lo que quieres es extender la lógica del juego fuera de las peleas (economía, comandos, UI, teletransporte), usa un plugin.
- Si lo que quieres es cambiar el aspecto de un mob o añadir uno nuevo, usa un mod de assets.
Los tres sistemas se llaman entre sí. Un encuentro puede invocar un comando de un plugin al cambiar de fase. Un plugin puede comprobar si hay un encounter activo antes de teletransportar a un jugador. El límite real lo defines tú según lo que quieras mantener en un solo archivo y lo que prefieras delegar a un sistema especializado.
En el blog oficial de Chapter 1 los propios developers dicen que cada nuevo encounter que crean expande el toolbox para el siguiente. Lo mismo te pasa a ti: Tu primer encounter te obliga a pensar en fases y triggers. El segundo sale en la mitad de tiempo. El tercero ya lo haces de memoria.
Dónde alojar tu servidor de Hytale para probar encounters
Para diseñar encounters en serio necesitas un servidor que no se caiga cuando spawnees 30 mobs a la vez. Si trabajas con un alojamiento de juegos con pre-release de Hytale preinstalado, el binario y los assets ya están donde deben estar, y tú te concentras en el diseño. Las pruebas pesadas (20 oleadas, 8 fases, 4 jugadores) se soportan mejor en una máquina dedicada que en un PC local con el IDE abierto y Discord corriendo de fondo.
Si tu comunidad va a probar el encounter en cuanto lo publiques, conviene un VPS con la build de pre-release de Hytale instalada. Así cada admin del equipo puede clonar el encounter, probarlo en un servidor paralelo, y subir la versión final sin que la comunidad sufra las pruebas. La mayoría de errores de encounter se descubren en los primeros 10 minutos de prueba con jugadores reales.
Para iterar más rápido, ten siempre dos entornos: Un servidor local para prototipar y un servidor público para validar con jugadores. Cuando ambos pasan el encounter en menos de 6 minutos con tres jugadores, sabes que está listo para producción.
Preguntas frecuentes sobre el Encounter Manager de Hytale
¿Necesito saber programar para usar el Encounter Manager?
No. El encounter se escribe en un archivo declarativo. Si sabes editar un JSON y entiendes qué hace cada campo, ya tienes lo principal. El pre-release trae documentación con los 12 triggers disponibles y un encounter de ejemplo que puedes clonar y modificar campo por campo.
¿Los encounters se pueden compartir entre servidores?
Sí, siempre que compartan la misma versión de pre-release. El archivo es portable: Lo subes a la carpeta encounters/ del servidor destino, reinicias el servicio y el manager lo carga. Si el servidor tiene una versión distinta, algunos campos pueden no reconocerse y el encounter falla al activarse.
¿Puedo usar un encounter dentro de un plugin?
Sí. Los plugins pueden invocar un encounter por id con un comando de admin, o escuchar cuándo un encounter termina para ejecutar lógica propia. Lo normal es que la pelea la controle el manager y los efectos colaterales (recompensas, teletransporte, notificaciones) los gestione el plugin.
¿Cuántas fases aguanta un encounter antes de saturarse?
El manager no impone un límite duro, pero a partir de 6 fases el archivo se vuelve difícil de mantener. Si necesitas más complejidad, divide en dos encounters encadenados: El primero termina en una condición que dispara el segundo. Así cada archivo queda legible.
¿Qué pasa si dos jugadores activan el mismo encounter a la vez?
El manager serializa las activaciones. El segundo encounter se queda en cola y arranca cuando el primero termina. Si quieres que ambos ocurran en paralelo, declara el encounter con allow_concurrent: true en el archivo. Úsalo solo si tu servidor soporta la carga de dos peleas simultáneas.
¿Los encounters afectan al rendimiento del servidor?
Depende de las oleadas y los triggers, no del sistema en sí. Un encounter con 30 spawns simultáneos y 5 triggers activos pesa más que uno con 4 spawns y 1 trigger. La recomendación es probar siempre con el doble de jugadores que los esperados y medir el TPS antes de publicarlo.
¿Se pueden hacer encounters cooperativos para grupos grandes?
Sí, los encounters escalan con el número de jugadores sin tocar el archivo. Lo que sí conviene ajustar es el daño y la vida del boss si esperas grupos de más de 6. La curva de dificultad del Feastmaster oficial está pensada para grupos medianos; Para raids de 12, multiplica vida por 1.8 y daño por 1.4.
¿Hypixel Studios va a publicar más documentación oficial?
El equipo confirmó que cada nuevo dungeon amplía el toolbox, lo que en la práctica significa que la documentación oficial crecerá con cada release. Mientras tanto, la comunidad en Discord documenta encounters propios y comparte archivos de ejemplo que sirven como base.
¿Puedo monetizar un encounter que diseñe?
Sí, el Mod Browser de Hytale acepta encounters y el sistema de pagos de la plataforma reparte los ingresos. Si tu encounter se vuelve popular en el marketplace, queda como contenido de autor con tu nombre. Los términos finales del reparto se confirman con el lanzamiento de Chapter 1.
Tu primer boss personalizado, en una tarde
El Encounter Manager de Hytale cierra la distancia entre diseñador y jugador. Cualquiera con un pre-release instalado y un archivo JSON puede publicar una pelea multi-fase en su servidor. El sistema está pensado para iterar rápido: Clonas un ejemplo, cambias tres campos, defines dos fases, y ya tienes algo jugable.
Los bosses más recordados de los RPG sandbox no salieron del primer intento. Salieron de designers que probaron, rompieron, ajustaron, y volvieron a probar. Tu primer encounter no va a ser perfecto. El segundo va a ser mejor. El tercero, con la toolbox que el propio manager te da, ya va a empezar a parecerse a algo que tu comunidad quiera compartir.
El 12 de octubre, con el lanzamiento de Chapter 1, el primer dungeon oficial hecho a mano abre el camino. Lo que viene después depende de lo que la comunidad construya encima. Si tu primer encounter sale esta semana, vas a tener tiempo de sobra para iterarlo antes de que la doc oficial amplíe el sistema.
¿Quieres seguir explorando el modding de Hytale? Estas guías te pueden servir:
- ¿Qué trae exactamente el Capítulo 1? Te lo resumimos con las funciones confirmadas y las que faltan por anunciar.
- Cómo preparar tu servidor de Hytale antes del 12 de octubre sin perder el estado actual de tu mundo.
- Los Goblin Gadgets (rocket boots, mechanical hookshot, glider) explicados uno por uno y sus usos en combate.
Si todavía no tienes claro dónde correr tus encounters, rdsnode.com ya tiene pre-release de Hytale preinstalado en sus planes de alojamiento. Entras, clonas el encounter, y empiezas a iterar el mismo día. La pieza que faltaba para que un servidor de Hytale no dependa de mods externos para tener contenido serio. Úsala. Comparte lo que aprendas. El 12 de octubre hay dungeon oficial esperándote, y un toolbox abierto para que el siguiente lo hagas tú.
¿Ya probaste el Encounter Manager o todavía no arrancas el pre-release? Déjamelo en los comentarios y vemos qué encounter puede salir esta semana.