Scars of Honor: Beast Burst Entertainment construye el...

Scars of Honor en desarrollo: Así están construyendo el sistema de duelos en vivo

Venelin, CEO de Beast Burst Entertainment y Director Creativo de Scars of Honor, realizó una nueva transmisión en vivo dedicada íntegramente al desarrollo en tiempo real del sistema de duelos del juego. A pesar de haber pasado la semana enfermo y de haber enfrentado varios problemas técnicos antes de poder conectarse, Vanalin cumplió con su promesa a la comunidad y estuvo presente para compartir el proceso de creación de una de las mecánicas más esperadas del MMORPG.

Un sistema de duelos pensado para la comunidad

La sesión comenzó con una revisión del Documento de Diseño del Juego (GDD) correspondiente al sistema de duelos. El diseño original contempla dos modalidades: práctica y duelo a muerte. Este último incluye la posibilidad de apostar objetos y oro entre los participantes, aunque se aclaró que esta opción sería completamente voluntaria. Durante el stream, Venelin también propuso una extensión del sistema que permitiría desafíos entre grupos, abriendo la puerta a enfrentamientos de 2 contra 3, 5 contra 5 e incluso batallas masivas de 40 contra 40 en el mundo abierto, una idea que generó un gran entusiasmo en el chat.

Para conocer la opinión de la audiencia, se realizó una encuesta en vivo sobre la posibilidad de apostar objetos y oro. Los resultados mostraron una división de opiniones: una parte de la comunidad apoya la idea tal como está planteada, mientras que otra prefiere que solo se puedan apostar materiales. El debate quedó abierto para futuras decisiones de diseño.

El desarrollo paso a paso: del objeto visual al prefab

Con el entorno de desarrollo listo, Unity iniciado y el servidor local activo, Venelin comenzó a construir el sistema desde cero. El primer paso fue crear un objeto visual temporal en Unity al que llamó "duelo flag", una especie de marcador o estandarte que indicará visualmente dónde se lleva a cabo un duelo. Este objeto, formado por dos cubos ajustados en escala, rotación y posición, es un placeholder que el equipo artístico reemplazará con un modelo definitivo más adelante. Una vez configurado, se creó un prefab del objeto para su uso en el juego.

A continuación, se procedió a registrar el nuevo objeto en la base de datos de GameObjects del juego mediante una migración. Para lograrlo, fue necesario identificar cómo el sistema carga los prefabs en tiempo de ejecución, lo que llevó a Venelin a revisar el código en Rider. Allí descubrió que el juego utiliza el sistema de Addressables de Unity para gestionar la carga de prefabs, por lo que el "duelo flag" debía marcarse como Addressable y reconstruirse para que los cambios quedaran sincronizados con el servidor.

Problemas técnicos y depuración en vivo

La transmisión no estuvo exenta de complicaciones. Tras reiniciar el servidor, al verificar si el nuevo objeto se había sincronizado correctamente, este no aparecía en la base de datos, lo que indicó un posible problema con la carga de Addressables. Al intentar depurar el código con Rider, surgieron dificultades para conectar el depurador con Unity. A esto se sumó que Unity comenzó a mostrar un alto consumo de memoria, incluso sin estar en uso activo, lo que apuntó a posibles fugas de memoria. Finalmente, Unity se cerró de forma inesperada, lo que en ese contexto resultó ser una interrupción que permitió reiniciar el proceso con mejores condiciones.

Tras reiniciar Unity, el consumo de memoria volvió a niveles más razonables. Se configuraron nuevamente los presets de Addressables para que el sistema reconociera los prefabs. Sin embargo, el prefab del "duelo flag" seguía sin cargarse correctamente en el juego. Fue entonces cuando Venelin identificó la causa raíz del problema: el nombre del prefab en el código no coincidía con el nombre real del archivo. Al corregir ese detalle y reiniciar el servidor, el "duelo flag" apareció correctamente en el mundo del juego. Posteriormente se ajustó el punto de pivote del objeto para que su posición fuera la adecuada.

Pruebas multijugador y problemas de autenticación

Para probar el sistema de duelos con dos personajes al mismo tiempo, Venelin utilizó Parallel Sync junto con el Clones Manager, herramientas que permiten ejecutar varias instancias del cliente simultáneamente. Sin embargo, al intentar iniciar sesión con las cuentas de prueba, aparecieron errores de autenticación que obligaron a ajustar la configuración del servidor. Una vez resuelto ese inconveniente, la conexión fue exitosa y el terreno quedó listo para continuar con las pruebas del sistema.

Más allá del código: conversaciones sobre el juego

Entre las sesiones de depuración, la comunidad aprovechó para hacer preguntas sobre diferentes aspectos del juego. Se confirmó que habrá más clases con mascotas además del Nigromante, incluyendo al Druida en su diseño. Se discutió el uso de asistentes de inteligencia artificial para programar, y Venelin aclaró que no los utiliza activamente en el desarrollo; prefiere identificar funcionalidades en código previo y adaptarlas al contexto actual. Solo los emplea ocasionalmente para investigar enfoques alternativos.

También se habló sobre la localización del juego. Se reconoció la importancia de traducir a idiomas como el portugués o el turco para acceder a mercados clave, aunque no hay planes inmediatos de traducción al polaco, a pesar de que hay miembros polacos en el equipo de desarrollo. En cuanto a las animaciones, se aclaró que las que se ven en materiales antiguos ya están siendo reemplazadas por animaciones únicas para cada raza y género.

El sistema de duelos toma forma: RPCs y lógica de red

Con el objeto visual funcionando, Venelin avanzó hacia la lógica de red del sistema de duelos. Se identificaron y crearon varios Remote Procedure Calls (RPCs) necesarios para que el sistema funcione de manera correcta entre cliente y servidor: request duel, response duel, start duel y end duel. Estos RPCs son los encargados de gestionar el flujo completo de un duelo, desde el momento en que un jugador desafía a otro hasta que el enfrentamiento concluye.

Se buscó también la parte de la interfaz de usuario (UI) correspondiente a la ventana de solicitud de duelo, con el objetivo de integrarla al flujo del sistema. Se encontró que el componente "Duo" no se estaba mapeando correctamente en el código, lo que generó más rondas de depuración antes de dar con la solución.

Preguntas de la comunidad: raids, gremios, PvP y más

La sesión también incluyó una extensa ronda de preguntas en la que se tocaron temas importantes sobre el diseño del juego:

En cuanto a las raids, se confirmó que el tamaño planificado es de 40 jugadores, aunque actualmente las mazmorras se perciben demasiado grandes y se planea probar versiones más pequeñas. El sistema tendrá puntos de control para facilitar los reintentos.

Sobre los gremios, se indicó que son un elemento central de la comunidad, pero que el contenido adicional como las guerras de gremios podría no estar disponible desde el lanzamiento. El sistema de duelos podría servir como una forma de simular esos enfrentamientos de manera informal.

Respecto al PvP, se confirmó que existirán servidores separados para PvP y PvE. El PvP en mundo abierto no tendrá recompensas directas en una primera etapa para evitar comportamientos tóxicos. La velocidad del combate se comparó más con el PvP de World of Warcraft retail que con el clásico.

En cuanto al inventario y la economía, se confirmó que los bancos serán compartidos entre ciudades. La aleatorización de estadísticas de los objetos se comparó con el sistema de Path of Exile, aunque siempre garantizando que los ítems tengan estadísticas apropiadas para su clase.

Sobre las clases y los sanadores, se confirmó que habrá varias opciones: Paladín, Sacerdote, Místico y Druida. Las clases que no pueden sanar, como el Guerrero, el Mago, el Nigromante, el Asesino, el Pirata y el Explorador, contarán con habilidades de reducción de curación, silencios, aturdimientos y daño para compensar en los enfrentamientos.

En relación al contenido de mazmorras, se mencionó un sistema de niveles similar al Mythic Plus de World of Warcraft, con "augmentations" que permitirán modificar la experiencia de juego dentro de las mazmorras.

Sobre los biomas, se confirmó la existencia de pantanos y zonas de fantasía cargadas de magia. Las áreas nevadas presentan mayor dificultad de creación, mientras que los desiertos son más sencillos de desarrollar.

Producción interna y optimización

Venelin confirmó que todos los activos del juego, incluyendo efectos visuales, modelos y entornos, son producidos íntegramente por el equipo interno de Beast Burst Entertainment. La única limitación real en este proceso es el tiempo disponible. El objetivo es que el juego funcione correctamente en equipos de gama baja, y la optimización se describe como un proceso continuo a lo largo del desarrollo. La mayoría del equipo trabaja de forma remota, con dos oficinas activas.

Cierre del stream

Venelin cerró la transmisión agradeciendo a todos los espectadores por su participación y su apoyo. Invitó a la comunidad a compartir sus opiniones en el servidor de Discord, a agregar Scars of Honor a su lista de deseos y a apoyar el proyecto en YouTube. Anunció que el próximo stream tendrá contenido interesante y se despidió con un mensaje cargado de entusiasmo y dedicación hacia el proyecto.