[0%] 
Saludos guerreros de Calradia!
El desarrollo de juegos puede ser un asunto delicado. A veces una tecnología o herramienta existente no hace exactamente lo que uno quiere que haga o no es tan eficiente como uno espera. Esto te deja con una decisión difícil de tomar: cambiar el diseño o crear tu propia solución a medida.
Esto es algo que nos dimos cuenta mientras trabajábamos en la Interfaz de Usuario (UI) para Bannerlord. Anteriormente, usábamos una combinación de Flash y Scaleform para crear nuestra interfaz de usuario, que en realidad es un método bastante común en la industria de los juegos. Empezaríamos por crear la interfaz de usuario en Flash, antes de usar Scaleform para hacer que la interfaz de usuario funcione en el juego. Técnicamente, tanto Scaleform como Flash funcionaron perfectamente y nos proporcionaron la capacidad de implementar la interfaz de usuario de la forma que queríamos. Sin embargo, no pasó mucho tiempo antes de que nos dimos cuenta de algunos problemas con el proceso general de creación e implementación de la interfaz de usuario que creímos que necesitábamos abordar.
Para empezar, el proceso fue bastante lento. Cualquier cambio en la interfaz de usuario tenía que hacerse en Flash, antes de ser implementado en el juego a probar. A medida que las pantallas crecían en complejidad, la generación del archivo.swf tomaba más tiempo. Y con cada cambio que hacíamos, el juego tenía que ser recargado para ver el resultado. Incluso un pequeño cambio, como mover un elemento 5 píxeles a la izquierda, requeriría pasar por todo este proceso.
Además, Scaleform y Flash son frameworks de terceros sobre los que teníamos un control limitado. La dificultad de cambiar y modificar estos sistemas, en función de nuestras necesidades, nos hizo cuestionar el esfuerzo que estábamos haciendo para que funcionara.
Finalmente, nos dimos cuenta de que el tiempo y la energía que gastábamos en la interfaz de usuario realmente nos estaba frenando, y la única forma de tener una interfaz de usuario que se ajustara a nuestra visión del juego sería crear nuestra propia biblioteca de interfaz de usuario. Después de todo, algunos problemas son sólo oportunidades disfrazadas.
Ahora, esa era una perspectiva realmente aterradora porque ya habíamos invertido miles de horas-hombre en la interfaz de usuario existente. Afortunadamente, al principio del proceso de desarrollo, habíamos decidido utilizar un paradigma llamado MVVM para crear la interfaz de usuario. Esto significaba que parte de nuestro código estaba en clases C# ordenadas que no dependían de ninguna biblioteca específica de la interfaz de usuario, y podríamos reutilizar esta parte de nuestro trabajo incluso si tuviéramos que rehacer el resto. Yay!
Luego, tuvimos que decidir cómo sería nuestra nueva biblioteca de UI. Se nos ocurrió una lista de requisitos:
*La nueva biblioteca tenía que ser rápida y rápida. Nuestro equipo de motores trabajó muy duro para eliminar un solo milisegundo de nuestro ciclo de renderizado y no apreciarían que la interfaz de usuario malgastara sus ahorros con un rendimiento deficiente.
*La nueva biblioteca también tenía que ser muy fácil de trabajar y hacer cambios sobre la marcha. Preferiblemente usaría un formato de archivo de especificaciones basado en texto, como XML, ya que los archivos basados en texto hacen que la colaboración entre múltiples desarrolladores sea mucho más fácil.
*El sistema tenía que facilitar la creación de interfaces de usuario altamente interactivas.
*El diseño de la interfaz de usuario tenía que ser independiente de cómo se vería visualmente. Esto permitiría al diseñador de la interfaz de usuario trabajar independientemente del artista.
Decidimos llamar a nuestro nuevo marco de trabajo de interfaz de usuario Gauntlet (¡por la única razón de que nos pareció genial!). Con Gauntlet, podemos hacer cambios sobre la marcha. Esto significa que podemos editar una pantalla sin cerrar el juego una sola vez, sin necesidad de generar archivos ni pasos adicionales. Cuando hacemos cambios en el archivo.xml de una pantalla, vemos los resultados tan pronto como guardamos ese archivo. Y debido a que tenemos control total sobre el sistema, podemos hacer cambios en el sistema a medida que nuestras necesidades lo requieran.
Entonces, ¿cómo funciona? Bueno, el sistema es bastante simple. Acoplamos un archivo.xml a una pantalla del juego, que el juego carga cuando se abre la pantalla. Toda la información de disposición de la pantalla se especifica en este fichero. También podemos hacer referencia a otros archivos.xml en cada .xml, lo que significa que si creamos un elemento de la interfaz de usuario que sabemos que vamos a usar más de una vez (es decir, en otras pantallas) podemos simplemente referirnos a ese elemento. Esto nos permite hacer cambios en el archivo y hacer que estos cambios ocurran en cualquier lugar donde hagamos referencia a este.xml.
También tenemos un conjunto de archivos XML separados que especifican cómo se verán los distintos elementos, de forma muy parecida a los archivos CSS que se utilizan para las páginas HTML. Este sistema de despellejar es muy potente y el artista puede especificar fácilmente cada detalle sobre cómo se verá y comportará un elemento de interfaz de usuario. Por ejemplo, un botón puede cambiar de color cuando el usuario mueve el ratón sobre él y puede pasar por una animación cuando el usuario hace clic sobre él.
Pantalla inventario.xml
Inventario ingame
Esperamos que Gauntlet sea una adición bienvenida para nuestra comunidad de modding. En Warband, la edición de la interfaz de usuario siempre fue un dolor de cabeza y había algunas limitaciones que no se podían superar. Con Gauntlet, los modders tendrán control total sobre cada pantalla, con la única limitación de su imaginación.
En el blog de la próxima semana, hablaremos con el Asistente de Diseño, Cihan Şekercioğlu. Si tienes alguna pregunta que te gustaría hacerle, por favor, deja una en la replicas y de todas ellas elegiremos una para que responda.
