Cómo mantener visibles los controles de la mascota y el personaje en una interfaz de juego compacta

Haz una lista de la información y las acciones que el jugador necesita durante el bucle principal de juego. Una primera aproximación útil podría incluir la mascota, una acción principal como alimentarla o jugar, y un indicador compacto que aclare si esa acción está disponible. Mueve los ajustes, las colecciones y las acciones menos frecuentes a un menú secundario o a un breve panel contextual. Este es un método de diseño, no una regla universal: un juego cuya tarea central consista en elegir entre varias acciones puede necesitar más controles visibles al mismo tiempo.

Asigna al personaje un área visual definida antes de encajar los controles. Mantén despejadas las partes esenciales de su silueta y expresión, y evita colocar botones o etiquetas sobre ellas. Si una acción requiere tocar directamente a la mascota, deja esa zona de interacción libre de obstáculos; si los controles se sitúan sobre la escena del juego, asegúrate de que no tapen la parte del personaje que los jugadores necesitan ver. La guía de controles de juego de Apple recomienda reducir los controles virtuales cuando la interacción directa con los objetos del juego pueda cumplir la misma función (Game controls).

Agrupa las acciones frecuentes donde sean fáciles de alcanzar y coloca las acciones secundarias más lejos o detrás de un menú. En una pantalla táctil, evita acumular botones en la misma zona donde la mano del jugador taparía a la mascota. Apple sugiere colocar los controles táctiles frecuentes cerca del pulgar y los secundarios cerca de la parte superior de la pantalla; su guía también indica que se debe tener en cuenta el alcance cómodo y los límites del dispositivo. Toma esto como un punto de partida para hacer pruebas en el dispositivo y la orientación previstos, y no como un diseño fijo para todos los juegos.

Haz que el icono visible sea compacto sin reducir el área táctil real para compensar. Apple recomienda un mínimo de 44 por 44 puntos para los controles de uso frecuente y de 28 por 28 puntos para los controles menos importantes en sus plataformas. Android recomienda al menos 48 por 48 píxeles independientes de la densidad para los objetivos táctiles interactivos. Estas medidas son específicas de cada plataforma, así que utiliza las unidades y directrices correspondientes en lugar de tratar las cifras como equivalentes (Apple game controls, Android accessibility guidance). Deja suficiente separación para evitar toques accidentales, sobre todo cuando dos acciones produzcan resultados diferentes.

Una mascota puede estar técnicamente en pantalla y, aun así, ser difícil de distinguir si los controles, las etiquetas o los paneles decorativos compiten con ella. Utiliza un peso visual discreto para los elementos secundarios de la interfaz: iconos pequeños, etiquetas breves y paneles que ocupen solo el espacio imprescindible. Mantén despejada la cara del personaje y otros detalles importantes durante las acciones más relevantes. Si la escena del juego cambia detrás del texto o los iconos, valora la opción de incluir un fondo sutil o un contorno para que la interfaz siga siendo legible sin necesidad de añadir un panel opaco grande.

Comprueba el texto y los iconos tanto sobre las zonas claras como sobre las oscuras de la escena. Un contraste adecuado sobre un fondo determinado puede perderse cuando la mascota se mueve o el escenario cambia. Para el texto, las directrices de las WCAG del W3C establecen un ratio de contraste de 4.5:1 para el texto de tamaño normal y de 3:1 para el texto grande. Las WCAG son pautas para contenido web y no una norma específica para videojuegos, pero sus umbrales de contraste pueden servir como una referencia útil para verificar el texto de la interfaz sobre fondos variables (W3C contrast guidance). No dependas únicamente del color para comunicar que una acción no está disponible; modifica también su etiqueta, forma o estado de manera visible.

Si los controles permanentes ocupan demasiado espacio, muestra las acciones opcionales cuando el jugador abra un menú o seleccione a la mascota. Oculta las acciones que no estén disponibles en el estado actual y muestra un cambio de estado claro al pulsar un control. Apple recomienda de forma específica adaptar los controles virtuales visibles al contexto de la partida, lo que incluye ocultar los controles no pertinentes y hacer más visibles los activos. Un patrón práctico consiste en mantener disponible la acción principal y desplegar las opciones relacionadas en un menú pequeño que se cierre tras realizar la selección.

Haz que los cambios de estado sean predecibles. Un control que desaparece justo cuando el jugador va a utilizarlo puede generar confusión; por ello, reserva la acción de ocultar o mostrar para funciones cuya disponibilidad resulte evidente según el estado actual. Si un botón pasa a estar inactivo, indica dicho estado y, si es necesario, explica brevemente qué ha cambiado. Evita que un menú desplegable tape la cara de la mascota o la zona donde el jugador debe pulsar a continuación.

Diseña en función del área útil y no solo del rectángulo exterior de la pantalla. Los notches, los orificios para la cámara, las barras del sistema y las áreas de gestos pueden solaparse con controles importantes situados cerca del borde. Las directrices de diseño de Apple definen las zonas seguras como regiones que ayudan a mantener el contenido libre de elementos de la interfaz y características del dispositivo. De igual modo, Android recomienda respetar los márgenes de las barras del sistema, los gestos y los recortes de pantalla, manteniendo los controles críticos alejados de dichos cortes (Apple layout guidance, Android edge-to-edge guidance). Las ilustraciones de fondo pueden extenderse hasta el borde mientras los elementos interactivos se mantienen dentro de los márgenes de seguridad.

No des por sentado que una sola disposición compacta servirá para todas las relaciones de aspecto. Ancla los controles al área útil y permite que el espaciado o la agrupación se adapten cuando cambie el ancho disponible. La guía de juegos de Android para Unity recomienda utilizar la API de safe area y admitir diferentes tamaños de pantalla y relaciones de aspecto. Prueba los diseños en vertical u horizontal únicamente si el juego los admite, y vuelve a comprobarlos tras rotar la pantalla, cambiar el tamaño de la ventana o plegar el dispositivo si esas configuraciones forman parte del alcance del proyecto (Android guidance for Unity games on large screens).

Una maqueta estática no permite ver qué zonas tapan los dedos del jugador durante el uso. Revisa la interfaz en el tamaño físico de pantalla previsto y, a continuación, prueba las acciones principales prestando atención a posibles detalles del personaje tapados, toques fallidos y controles que se solapen con funciones del sistema. Repite la comprobación en la pantalla compatible más pequeña y con una relación de aspecto más ancha o más alta. Si es posible, pide a alguien que no esté familiarizado con el diseño que realice la tarea principal y observa dónde pulsa, duda o pierde de vista a la mascota.

Utiliza una breve lista de verificación de apto/no apto para cada diseño admitido:

• La mascota permanece visible durante la acción principal, incluidos su rostro u otros detalles esenciales.

• La acción principal está al alcance, cuenta con un estado de pulsación claro y no se solapa con ningún otro elemento interactivo.

• Las etiquetas y los avisos de estado importantes siguen siendo legibles frente a los cambios de fondo del escenario.

• Ningún control esencial se sitúa bajo un recorte de pantalla, barra del sistema o zona de gestos.

• La apertura de un control secundario no tapa la parte del personaje o del área de juego necesaria para el paso siguiente.

Si una comprobación no se supera, modifica un solo elemento cada vez: elimina un componente de baja prioridad, desplaza un control hacia el borde del área de juego respetando los márgenes de seguridad o muestra las acciones secundarias solo cuando sea necesario. Vuelve a probar la misma interacción. Esto facilitará determinar si el cambio solucionó el problema de visibilidad o si solo lo trasladó a otro lugar.

• Apple Developer, Game controls

• Apple Developer, Layout

• Android Developers, Make apps more accessible

• Android Developers, Edge-to-edge design

• Android Developers, Make your Unity game great on all form factors

• W3C Web Accessibility Initiative, Understanding Success Criterion 1.4.3: Contrast (Minimum)