![Lidia-Rodriguez-Segovia-400×400 Lidia-Rodriguez-Segovia-400x400](https://www.naka.syntphony.com/wp-content/uploads/elementor/thumbs/Lidia-Rodriguez-Segovia-400x400-1-qp4633e8bl79epsay03dw1c3080m1eg48u001nt9x0.png)
Lidia Rodríguez Segovia
Lead XR Designer en NTT DATA
En nuestra búsqueda habitual por optimizar procesos y métodos de trabajo, nos hemos encontrado con el asset “Figma Converter for Unity” una herramienta disponible en el store de Unity que podría ayudarnos a agilizar la aplicación de diseños 2D, realizados por el equipo de diseño, de forma sencilla en los proyectos de Unity. Bajo este escenario hemos decidido analizarlo para ver su utilidad y analizar sus ventajas e inconvenientes.
¿Qué es el asset de Figma converter for unity?
Entendemos por asset cualquier recurso para complementar el desarrollo de un proyecto de Unity. Dentro de los asset nos encontramos varios tipos, estos pueden ser tanto modelos 2D o 3D, como plantillas de SDK o herramientas para acelerar el desarrollo de los proyectos.
En concreto, el asset Figma Converter for Unity, es una herramienta que amplía las funcionalidades de la plataforma de desarrollo. Lo que nos permite importar los diseños realizados en Figma al motor de juego de Unity de una forma sencilla y rápida.
Para facilitar la descarga de estos assets, Unity cuenta con una tienda donde tiene disponibles múltiples recursos tanto gratuitos como de pago. Figma Converter for Unity entra en la lista de los assets de pago y lo podéis encontrar disponible en el siguiente link.
![](https://www.naka.syntphony.com/wp-content/uploads/2024/02/figma-5-1-2048x564-1-300x83.png)
![](https://www.naka.syntphony.com/wp-content/uploads/2024/02/Unity-logo-2048x1152-1-300x169.png)
Que implica usarlo
Para la investigación de este asset hemos estado involucrados miembros tanto del equipo de desarrollo como de diseño.
Para el equipo de diseño, el uso de esta herramienta no implica instalaciones ni el uso de ningún software o herramienta adicional.
Lo que si tenemos que tener en cuenta es que, aunque seguiremos usando las mismas herramientas que hasta ahora, para facilitar la tarea de importación de los diseños de Figma a Unity, tenemos que trabajar de una forma concreta para que se realice correctamente. Este cambio lo desglosaremos más adelante concretando una serie de directrices a seguir.
Esto provoca que para diseño no supone una reducción de tiempo de trabajo y dependiendo de la manera en la que queramos aplicar su uso, supondrá un incremento de diferente dimensión (abordaremos esto más adelante), sin embargo, por la parte de desarrollo, el uso de esta herramienta sí que implica la reducción de los tiempos de implementación del código ya que permite la importación directa de las pantallas pintadas por el equipo de diseño, consiguiendo así que el diseño en Unity sea exactamente igual al de Figma.
Para su uso, evidentemente, requiere de la instalación del asset en la plataforma de desarrollo y la configuración inicial.
Directrices de diseño:
¿Cómo diseñar teniendo en cuenta Figma Converter for Unity?
A continuación, vamos a ver las directrices que hay que seguir a la hora de hacer los diseños en Figma para la correcta importación y visualización de estos en Unity. El incumplir estas indicaciones, acarrearían diferentes problemas, como la visualización incorrecta, una mala importación de los diseños en la plataforma de desarrollo o la falta de estados en las vistas como los diferentes estados de los botones.
Listado de directrices
– Tenemos que desactivar “clip content” en los frames antes de importarlos a Unity.
![](https://www.naka.syntphony.com/wp-content/uploads/2024/02/MicrosoftTeams-image-7-600x438-1-300x219.png)
– Debe usarse “-” o “/” como separadores entre la etiqueta y el resto del nombre de la capa.
![](https://www.naka.syntphony.com/wp-content/uploads/2024/02/2.png)
– Las capas deben nombrarse con etiquetas que permitan a Unity identificar los scripts.
· ‘img’: Para un componente que queremos que se convierta en una sola imagen al importarlo.
· ‘btn’: Para que se añada el script del botón a su GameObject durante la importación.
· ‘cont’: Para conjuntos de vectores que forman una imagen pero que deben importarse por separado.
· ‘field’: Para componentes de campo de texto con los que el usuario podrá interactuar.
· ‘pholder’: Para el texto que aparece dentro de un input y da información o pistas al usuario sobre cómo completar el mismo.
· ‘grid’: Para crear componentes Grid Layout que permitan la colocación precisa de los elementos.
– El texto que se escriba después de la etiqueta no debe constar sólo de caracteres especiales.
![](https://www.naka.syntphony.com/wp-content/uploads/2024/02/3-incorrect-1024x308.png)
– No dar un fill de fondo al frame de la pantalla. Pintar un rectángulo en el frame y aplicarle un color.
– Usar máscaras de recorte para conseguir que el fondo o las ilustraciones que van dentro del frame, no sobresalgan de este.
– El stroke debe ser siempre interior, sino no se verá, además de formar parte del background.
– El background debe ser la última capa de cada frame.
– Las sombras deben ir dentro de la “forma”, por ejemplo, un rectángulo en caso de un botón.
– Aplicar constraints a los diferentes elementos que tengamos en el frame.
– Las variantes de un componente (por ejemplo los botones) no funcionan como en Figma, sino que tenemos que construir el componente de forma que tenga todas las capas variables (distinto texto o distinto fondo para diferentes estados) incluidas en el frame. Pondremos primero todos los textos, definiéndolos por el nombre del estado, y después los backgrounds (formas con relleno de color). Por ejemplo, la estructura del botón sería la siguiente:
![](https://www.naka.syntphony.com/wp-content/uploads/2024/02/5-button-1024x480.png)
– No utilizar líneas. Hacerlas como rectángulo.
– No utilizar ajustes de la tipografía como el ALL CAPS, lowercase o title case. Establecerlo siempre en el setting por defecto As typed (-).
![](https://www.naka.syntphony.com/wp-content/uploads/2024/02/6-basics-300x225.png)
– No utilizar la feature de “secciones” de Figma. Dejar los frames y pantallas directamente sobre el lienzo.
– No utilizar varios pesos de tipografías en un mismo cuadro de texto, ya que solamente reconoce una.
– Si varios elementos de la pantalla salen posicionados incorrectamente en Unity, utilizar frames con autolayout para agruparlos y marcar su padding correcto.
Teniendo en cuenta todas estas directrices, podríamos plantear dos escenarios de trabajo para el equipo de diseño.
El primer escenario podría consistir en usar un archivo de Figma en el que los componentes no se creen de la forma adecuada siguiendo las buenas prácticas de diseño y directamente se diseñe siguiendo las directrices que pide este asset. El inconveniente de este escenario sería que, si nos encontramos ante un proyecto de gran envergadura, si este sufre algún tipo de modificación durante su desarrollo, como algún cambio de estilo en los botones, aplicar los cambios en los diseños que se vean afectados llevará más tiempo y será más complejo.
La razón de esto, al final, es que el uso de las buenas prácticas llevadas a cabo cuando usamos una librería o el uso de componentes bien definidos es poder gestionar de forma unificada e instantánea este tipo de cambios. Practica que estaríamos omitiendo en este escenario.
El segundo escenario sería uno donde tengamos dos archivos de diseño. Uno que esté enlazado a la librería del proyecto y se apliquen en los diseños de pantallas los componentes y sus variants, sus estilos de texto y colores de forma correcta, para tenerlo todo organizado de forma óptima y que si sufre cambios en el futuro puedan abarcarse de forma fácil. Y otro archivo que se comparta con el equipo de desarrollo, donde se trabajarán los diseños mediante la forma permitida por el asset aplicando las directrices vistas anteriormente.
Este fichero adaptado para poder realizar la exportación a Unity tendría que abordarse como paso final una vez tengamos los diseños definitivos y validados por cliente y sepamos que no van a sufrir cambios para evitar retrabajos, puesto que debería servir como un entregable y no como una zona de trabajo viva.
¿Cómo importar las pantallas el equipo de desarrollo a Unity?
Para poder usar el asset por parte de desarrollo, primero habrá que realizar un proceso de configuración del entorno de desarrollo.
Esta configuración consta de una serie de pasos:
– Instalar el asset en Unity y comprobar que está instalado el framework JSON (hay que añadirlo si no está).
– En la ventana Tools de la parte superior, se creará un canvas con la resolución del panel que se vaya a meter importar de Figma.
![](https://www.naka.syntphony.com/wp-content/uploads/2024/02/6-convert-figma.png)
– En el canvas creado, aparecerán todos los parámetros que hay que modificar.
– Hay que añadir el token y la URL del proyecto de Figma.
– En la configuración del texto, debe estar habilitado “best fit“ y los márgenes horizontales y verticales sin desbordamiento.
– Se pueden añadir directamente las fuentes utilizadas en el diseño en la sección de configuración de texto.
![](https://www.naka.syntphony.com/wp-content/uploads/2024/02/7-text-settings-300x284.png)
– En configuraciones adicionales, Json.NET tiene que estar habilitado.
Una vez abordada esta configuración, el proceso de importación es bastante sencillo:
– Pulsando el botón “Download Project”, se cargarán automáticamente todos los elementos que haya en el Figma.
– Una vez cargados, se podrán seleccionar los elementos concretos que queremos importar y una vez seleccionados, se pulsará el botón “Import Frames” para finalizar.
Conclusión Final
Este asset presenta una mejora notoria para el equipo de desarrollo, ya que, de forma rápida y sencilla, podrá disponer de los diseños planteados por el equipo de diseño sin tener que gastar casi tiempo en realizar la programación de este (a excepción de pequeños ajustes que haya que tocar por código.) Además, conseguimos un diseño en Unity ajustado totalmente al diseño propuesto en Figma.
Por otra parte, hay que valorar si el trabajo extra para el equipo de diseño no excede a las ventajas proporcionadas por usar este asset. También hay que profundizar en el escenario idóneo en el que diseño debería trabajar para llevarlo a cabo, teniendo en cuenta si es viable tanto para grandes desarrollos como para pequeños y si el uso de la herramienta se aplicaría solamente para que el equipo de desarrollo pueda hacer una implementación inicial en el que, como punto de partida, importara los diseños mediante el uso del asset pero cualquier tipo de modificación a futuro se realizara mediante desarrollo puro o si cada cambio futuro en el diseño implicaría modificaciones en el fichero de Figma entregable que desarrollo importaría en cada nueva versión de diseño.
![9 9](https://www.naka.syntphony.com/wp-content/uploads/elementor/thumbs/9--qp4633ebz5iuuy8n6inimyd4ypaw705q3ra0ezo3u2.png)
Para la elaboración de este artículo se ha tomado como base la documentación disponible tras la descarga del asset Figma Converter for Unity.