La cocina del juego sobre 3 desafíos técnicos para hacer La piedra de la locura
A principios de este año, The Game Kitchen lanzó The Stone of Madness, un RPG táctico donde los jugadores ayudan a cinco reclusos a escapar de una prisión inquisitorial. En este artículo de invitado, tres desarrolladores del estudio comparten cómo abordaron los desafíos de renderizado, interfaz de usuario y pruebas durante el desarrollo.
Somos The Game Kitchen, y recientemente lanzamos The Stone of Madness en PC y consolas. Queremos compartir algunos de los desafíos más urgentes que enfrentamos durante el desarrollo de nuestro último proyecto, abordándolos desde una perspectiva técnica con ejemplos prácticos. En este artículo colaborativo, nuestro equipo de programación desglosa las soluciones clave que implementamos en Unity para optimizar tanto el rendimiento como la eficiencia en el desarrollo.
Primero, Adrián de la Torre (programador de gráficos) explicará cómo diseñamos y renderizamos el pipeline artístico del juego para lograr su estilo visual distintivo.
A continuación, Alberto Martín (programador de UI) detallará cómo aprovechamos Noesis para optimizar el desarrollo de la interfaz de usuario, mejorando el flujo de trabajo con mejoras de UX basadas en la retroalimentación de los usuarios.
Finalmente, Raúl Martón (programador de jugabilidad) mostrará cómo externalizamos y automatizamos pruebas para acciones complejas dentro del juego en un servidor, asegurando que se manejaran múltiples casos extremos sin interrumpir la integración.
Haciendo que la locura se vea bien: Una mirada al pipeline de renderizado personalizado
Adrián de la Torre, Programador Gráfico, The Game Kitchen
La Piedra de la Locura combina visuales en 2D con mecánicas de juego en 3D, lo que presenta un desafío técnico único. Mientras los jugadores ven un mundo 2D, los sistemas subyacentes del juego operan en un espacio tridimensional, creando una dualidad distintiva en su diseño.
Para abordar este desafío, nuestro equipo de desarrollo creó un pipeline de renderizado personalizado que efectivamente cierra la brecha entre la información de juego en 3D y la representación visual en 2D. Esta solución implementa múltiples pasadas de renderizado y técnicas especializadas para mantener la consistencia visual mientras se preserva la profundidad de juego prevista, permitiendo la traducción fluida de elementos 3D al distintivo estilo artístico 2D del juego.
En La Piedra de la Locura, hay dos escenarios principales que contribuyen a la representación de un marco.
El primer escenario, que llamamos el Escenario Proxy, está compuesto por primitivas geométricas que calculan la iluminación del fotograma final.
El segundo escenario es el Escenario de Lienzo, que consiste en sprites que coinciden con la forma y posición de la geometría del Proxy. El lienzo está organizado en capas para simular el espacio 3D y lograr un correcto ordenamiento en Z con los elementos del juego en movimiento.
La siguiente sección detalla cada paso en nuestra tubería gráfica para el renderizado de fotogramas.
1. Cono de visión
Siempre que se habilite un cono de visión o una habilidad de juego, se inicia el primer paso en el proceso. Colocamos una cámara en el punto de vista (PoV) del NPC para renderizar la profundidad de los proxies dentro de su campo de visión (FoV).
Luego, en otra textura de renderizado, la cámara genera un gradiente de la distancia desde el origen del jugador en el canal B, que se utiliza para los efectos de área de habilidad.
Usando la textura de renderizado en la perspectiva del NPC, la cámara del cono de visión renderiza un cono sobre la textura anterior en los canales R y G con información sobre obstáculos y distancia.
El pase final renderiza ondas sonoras en el canal Alpha.
Esta es la textura final creada en este paso, que se utilizará en el paso de la Cámara del Lienzo para renderizar los sprites de la escena.
2. ID de renderizado de lienzo Cámara
Cada proxy en nuestro proyecto tiene un ID de Render asociado (un valor float). El proxy y su sprite relacionado comparten el mismo ID de Render. En este paso, renderizamos el valor float del ID de renderizado en una textura de renderizado.
En el siguiente paso, utilizamos esta textura para hacer coincidir la información de iluminación calculada en el escenario proxy con los sprites en el escenario Canvas.
3. Ilumin
La iluminación en nuestro juego consiste en:
- Iluminación horneada Luces naturales que permanecen activas de forma permanente, como la iluminación exterior.
- Iluminación mixta Luces estáticas en la escena que se pueden encender y apagar, como velas.
- Iluminación en tiempo real Luz que se mueve a través de la escena y se puede encender y apagar (implementamos esto en solo una instancia, la lámpara de aceite de Alfredo)
Usando la textura RenderID, creamos una textura de renderizado que contiene la información de iluminación de la escena proxy.
4. Cámara de lienzo
Después de crear todas las texturas de renderizado, una cámara comienza a renderizar los sprites con información sobre iluminación, áreas de efecto de habilidades, conos de visión y ondas de ruido.
5. Post-procesamiento
La corrección de color, el viñeteado y otros efectos se aplican en un pase de post-procesamiento.
6. UI
Finalmente, la interfaz de usuario está superpuesta.
Locura en el HUD: Acelerando los procesos de la interfaz de usuario
Alberto Martín, Programador de UI, The Game Kitchen
La versión final de lanzamiento de La Piedra de la Locura cuenta con más de 50 interfaces de usuario. La razón detrás de ese número es que este juego tiene muchos datos para mostrar al usuario. Nuestro trabajo de UI fue muy laborioso, especialmente por lo pequeño que era el equipo al principio, por lo que estábamos continuamente optimizando nuestros procesos para asegurarnos de que estábamos logrando buenos resultados en el menor tiempo posible.
Nuestro trabajo de UI abarcó todo el proyecto, por lo que era importante que nuestros diseñadores de UI/UX entendieran claramente todas las características que necesitábamos implementar. Para asegurar que nuestro juego proporcionara una buena experiencia de usuario y fuera divertido de jugar, tuvimos cuidado de mantener una línea de comunicación abierta entre los equipos de programación y diseño.
Para crear las mejores versiones de todos nuestros componentes de interfaz de usuario, necesitábamos eliminar los silos entre nuestros equipos técnicos y nuestros equipos creativos/de investigación para que todos estuvieran activamente involucrados en el desarrollo del juego. Así es como abordamos este flujo de trabajo en dos partes.
El papel de la investigación y la creatividad en el diseño de UI
Nuestros diseñadores de UI/UX son responsables de definir cómo se verán los elementos de la interfaz de usuario en el juego final y de garantizar que ofrezcamos una experiencia de usuario satisfactoria. Con esto en mente, comenzaron creando cada elemento con una carga técnica mínima y validándolo con usuarios potenciales. Ese proceso se veía así:
- Requisitos: Entender las necesidades del jugador y crear una lista de las necesidades del juego y los objetivos del usuario
- Investigación Mirando otros juegos para ver cómo manejaron problemas similares
- Esquemas Trabajando en los esquemas y la estructura (sin arte final en este momento)
- Maqueta: En este punto, montamos la interfaz casi completamente diseñada con elementos previamente creados (botones, desplazamientos, marcos, etc.), lo que nos permite iterar sin mucho esfuerzo.
- Prototipo: Construimos un prototipo en Figma utilizando nuestro modelo, simulando interacciones con gamepads y teclado/rato para mostrar cómo funcionará en un entorno real.
- Prueba de usuario: Usando nuestro prototipo previamente creado, iniciamos una prueba de usuario, validando las necesidades y objetivos que identificamos en el Paso 1.
- Fase de iteración: Si la prueba de usuario cumple con las expectativas, se pasa a los procesos de la parte técnica, se hacen más iteraciones o se realizan más pruebas si es conveniente.
Implementación técnica de la interfaz de usuario
Como se mencionó anteriormente, el número de elementos de la interfaz de usuario en La Piedra de la Locura es enorme. Desarrollar un motor de interfaz de usuario es costoso, por lo que necesitábamos usar un marco que fuera fácil de aprender con herramientas y flujos de trabajo decentes. Después de evaluar una variedad de middleware, elegimos Noesis GUI, que sigue el patrón Modelo-Vista-VistaModelo (MVVM).
Elegimos Noesis porque se basa en WPF (Windows Presentation Framework) y sigue el modelo MVVM de una manera que podemos reutilizar la mayor parte de la documentación, bibliografía, entradas de foros, etc., para solucionar la mayoría de los problemas. Este marco ha estado presente durante un tiempo: ya han pasado 18 años desde su primera versión, y es familiar para un gran número de desarrolladores de UI, lo que le da a nuestro estudio la opción de contratar de un grupo de talento comparativamente más grande para implementar interfaces y herramientas para nuestros proyectos. Otra cosa importante sobre Noesis es que podemos usar las mismas herramientas de WPF.
Con XAML, nuestro equipo creativo de UI estuvo involucrado en el trabajo de diseño y en pulir todos los elementos con una mínima participación técnica. Gracias al enfoque MVVM, nuestros programadores de UI técnicos pudieron centrarse en la funcionalidad y brindar apoyo a los equipos creativos en ciertas áreas cuando fue necesario.
Pruebas (o, cómo no volverse loco creando un juego con un diseño sistémico)
Raul Martón, Gameplay Programmer, Teku Studios
La jugabilidad en La Piedra de la Locura se basa en tres pilares fundamentales: Habilidades del jugador, IA de NPC y interacciones en la escena. Cada uno de estos tres sistemas está fundamentalmente entrelazado, lo que aumenta exponencialmente el número de situaciones que el jugador necesita controlar, y el número de escenarios que necesitamos probar.
Tan pronto como comenzamos el proyecto, nos dimos cuenta de que un sistema de aseguramiento de calidad tradicional iba a ser insuficiente. Simplemente había demasiados escenarios que dependían de varias piezas interactuando entre sí de una manera particular, creando una situación incontrolada. Además, estas situaciones podrían ocurrir en un lapso de tiempo que es simplemente demasiado pequeño para que un equipo de QA pruebe cómodamente.
Para resolver estos problemas, creamos un conjunto de pruebas automáticas. La idea era que todos los posibles escenarios/situaciones que podrían ocurrir a nuestro equipo de desarrollo en relación con un sistema particular, pudieran ser contabilizados y probados automáticamente de manera mucho más eficiente en un entorno de juego simulado.
Para proporcionar un ejemplo, uno de los personajes principales de La Piedra de la Locura, Amelia Exposito, tiene la habilidad de robar carteras. Mientras implementábamos esta habilidad, iniciamos una serie de pruebas para asegurar:
- El funcionamiento básico de la habilidad era correcto: Al robar a un NPC, se abriría el mini-juego de hurto y el juego se pausaría hasta que terminara.
- También se cubren situaciones menos comunes: Si intentas robar a un NPC mientras otro NPC (como un guardia) te está mirando, o si el NPC está corriendo, la acción es imposible.
Creando una prueba de integración
Cada prueba de integración que creamos requirió una configuración basada en los siguientes requisitos:
1. Una escena especialmente preparada para crear esta situación particular
Para probar la habilidad de carterista, creamos una escena con dos guardias y un jugador. Colocamos a cada personaje de manera que miren en la dirección necesaria para que la situación se pruebe con precisión (recuerda, el jugador no puede usar el robo si está dentro del campo de visión de un guardia).
Además, la escena solo debe incluir los componentes mínimos necesarios para probar el escenario, ya que los elementos extranos pueden añadir ruido a la medición. Por eso nuestra escena de ejemplo no tiene HUD, sistema de entrada manual, efectos de sonido, etc.
- Este paso requiere que la estructura del juego esté bien compartimentada, lo que puede requerir un esfuerzo, pero, una vez logrado, ¡vale la pena! 😉
2. Un código de prueba capaz de forzar la situación a ser probada
Muchas de las situaciones que necesitábamos probar pueden ser difíciles y llevar mucho tiempo crear manualmente y necesitan un envío de código para iniciar.
Por ejemplo, si queremos crear un escenario de prueba para asegurarnos de que nuestros NPC nunca pisen trampas para ratones a menos que el NPC esté en movimiento, la cadena de instrucciones sería:
- Lanza la escena
- Espera un segundo
- Genera una trampa para ratones debajo del NPC
- Espera un segundo más
- Ordena al NPC que comience a caminar en cualquier dirección
Esta parte del proyecto es muy sensible a cualquier cambio durante el desarrollo (dependiente de factores como el cambio de especificaciones del juego y varios escenarios inesperados), por lo que es fundamental que tanto el código de prueba como los comentarios resultantes sean lo más claros posible.
No hay nada peor que un examen que falla sin dar ninguna información clara sobre lo que realmente está saliendo mal.
3. Una forma confiable de saber si el escenario está funcionando como se esperaba, o si la prueba ha detectado un error en la lógica.
Las pruebas automatizadas aún requieren supervisión. El aumento en el número de pruebas con mayor especificidad sobre lo que se está probando puede volverse difícil de monitorear, o los escenarios terminan sin ser probados el tiempo suficiente para ser estadísticamente significativos. Para sortear estos problemas, creamos herramientas personalizadas.
Por ejemplo, algunas de nuestras pruebas involucraron interacciones combinadas entre varios NPCs en una escena. Para monitorear estos casos adecuadamente, creamos un sistema para registrar los diferentes estados de IA por los que los NPCs pasan durante la prueba.
También necesitábamos una buena API que nos diera visibilidad sobre el estado actual del juego (¿ha sido un NPC noqueado?) ¿Ha entrado un NPC en un estado de enrutamiento? ¿Cuántas veces? ¿Qué personaje jugador ha sido capturado? Y así sucesivamente).
4. Un sistema para poder lanzar todas estas pruebas rápidamente:
A diferencia de las pruebas unitarias, las pruebas automatizadas deben realizarse con el juego en funcionamiento en tiempo real. Esto puede hacer que la ejecución de estas pruebas sea muy lenta.
En estas circunstancias, podemos aprovechar el hecho de que nuestro juego no utiliza el sistema de actualizaciones estándar de Unity. En su lugar, todos nuestros componentes utilizan una función Tick(), que simula las actualizaciones de Unity pero se lanza de manera controlada por nuestro motor de juego.
Esto nos ayudó a lograr un par de objetivos diferentes con nuestras pruebas:
- Primero, podríamos acelerar su ejecución con una función de forzado que ejecute varios cuadros de código por cada cuadro del juego.
- En segundo lugar, debido a que estas pruebas se realizan en tiempo real, son muy susceptibles a las variaciones causadas por las tasas de fotogramas en la computadora que ejecuta el escenario de prueba. Al convertirlos a una tasa de fotogramas controlada, evitamos esta variación: Si una prueba pasa en una máquina, pasará en todas las máquinas, y viceversa.
Y este sería el resultado.
Cómo las pruebas de seguridad nos ayudan a evitar compilaciones rotas
Con la creación de este conjunto de pruebas, también necesitábamos implementar una salvaguarda que interrumpiera automáticamente la fusión de una rama si contenía errores. Para asegurar esto, creamos un script de fusión automática que se lanza cada vez que se realiza un cambio en la rama principal del proyecto.
Este script se asegura de lanzar todas estas pruebas y monitorear sus resultados. Si alguna prueba falla, devuelve un error de detección e interrumpe la fusión.
Con este sistema, podemos evitar situaciones en las que un cambio en un sistema aparentemente aislado rompa otras mecánicas con las que interactúa.
Gracias a The Game Kitchen por compartir esta mirada detrás de escena del desarrollo de The Stone of Madness. Explora más juegos Hechos con Unity en nuestra página de Curador de Steam y obtén más información de los desarrolladores en la página de Recursos de Unity.
