Teclas virtuales o virtual keys: ejemplo con botones

En el post anterior, comentamos como añadir un par de botones que podríamos usar en un juego en dispositivos móviles. Por ejemplo, en un juego de plataformas para PC, lo habitual sería que se moviese por el teclado, o en un joystick/gamepad. Si ese mismo juego que estamos desarrollando lo exportamos para un móvil, no hace falta hacer ningún cambio: añadimos los botones para que se visualicen, los relacionamos para que se activen con el teclado y nada más. Pero entonces, si no hay teclado en un móvil o tablet, ¿como se utilizarían estos eventos? Ahora es cuando entramos con las teclas virtuales.

Qué son las teclas virtuales o virtual keys

En Game Maker Studio, no sé si en otros programas o lenguajes también lo hacen de la misma manera, existe un concepto para relacionar un evento de teclado con un trozo de la pantalla (del móbil o tablet). Esto es lo que hace exactamente una virtual key: decimos el área de nuestro dispositivo que cuando se toque reaccione igual que si pulsamos una tecla determinada.
Para los eventos de ratón no es necesario definir nada extra. Si tenemos un evento Left Pressed, se asocia directamente con el tap de la pantalla. Con el botón derecho, Game Maker especifica que lo han relacionado con el doble tap de la pantalla. Con los eventos globales del ratón ocurre lo mismo, no hace falta programar nada para que funcione bien.
En los eventos de teclado, podemos añadir los botones necesarios, y en ellos podemos añadir la tecla virtual. El área que definimos será el mismo que ocupe el botón, así que sabiendo dónde está ubicado sería suficiente, aunque veremos que algún problema nos puede dar.

Funciones GML de virtual keys

Con las acciones que vemos a la derecha, del editor de objetos, no podemos gestionar de ningún modo teclas virtuales, así que toca pasar por escribir código GML (como la mayor parte de cosas avanzadas).
Existen 4 funciones principales para gestionar virtual keys.

virtual_key_add(x, y, w, h, keycode)

Con esta función añadimos una nueva tecla virtual. Vemos que nos piden en los parámetros la posición X/Y, y el tamaño del ancho y alto. El último parámetro es para decir que tecla es la relacionada.

virtual_key_show(index)

Para poder depurar el área y posición de nuestra tecla virtual, podemos usar esta función para que muestre que zona es la afectada. Lo habitual es ver un rectángulo blanco, aunque podemos modificarlo con las funciones de dibujo que tenemos. Para testear nos sirve tal cúal se ve.
En la función nos pide como parámetro index, este parámetro se refiere al índice de la tecla virtual.
Volviendo a nuestros botones creados, si añadimos en nuestro evento Create este código GML

///Virtual Key LEFT

v_left = virtual_key_add(x, y, sprite_width, sprite_height, vk_left);

virtual_key_show(v_left);

podemos ver al compilar (sí, muestra la tecla virtual cuando lo lanzamos para Windows aunque no la podemos usar) que el área ocupa todo el botón. La variable v_left tiene el índice que le pasamos luego para mostrar en virtual_key_show().
Recordemos de quitar o comentar la última línea cuando tenemos nuestro proyecto definitivo, para que pueda verse el botón. Yo suelo mostrarlo cuando compilo en modo debug, y sustituyo la línea por esto
if debug_mode virtual_key_show(v_left);
De esta manera me olvido cuando creo el fichero definitivo a exportar, usando la variable debug_mode, que devuelve true si compilamos con la opción Run in debug mode o pulsamos la tecla <F6>.

virtual_key_hide(index)

Con esta función podemos esconder la tecla virtual mostrada.

virtual_key_delete(index)

Elimina la tecla virtual, eliminando los eventos asociados al área que teníamos adjudicada. Hay un tema importante que hay que tener en cuenta: cuando la room finaliza, se elimina automáticamente la tecla virtual (sin usar la función). Esto es muy útil si tenemos rooms con opciones de menú antes de nuestro juego, ya que Game Maker lo hace automático (y nos olvidamos). Pero tenemos que vigilar en que eventos creamos nuestras virtual keys, ya que si tenemos muchos niveles de un juego en diferentes rooms, debemos crear la virtual key en cada room. Un error común sería hacer que los objetos de botones sean Persistent, para no añadirlos en cada nivel de nuestro juego, pero debemos de cambiar el evento de creación. En el evento Create solo se ejecutaría una sola vez, así que en la siguiente room no funcionaría. Una opción fácil sería cambiarlo al evento Room Start.

Problemas con virtual keys

Parece muy fácil de usar las virtual keys, ¿verdad? Creas un objeto botón sencillo, añades un par de líneas y ya funcionaría en nuestra tablet o móvil. Pero vamos a ver un problema muy común que vamos a tener, dependiendo del juego que hagamos. Es muy posible que estés usando views en tu juego. Y si estás usando views, es probable que estés usando ports, o lo que es lo mismo, estás haciendo zoom en tu juego (la parte de zooms lo abordaremos en próximos posts para reescalar en dispositivos Android). Empezamos con un ejemplo.
Vamos a activar las views en nuestro juego, poniendo el tamaño total de nuestra room, que en nuestro caso es de 800×480, en las opciones de View in room y Port on screen. Os muestro como queda:

Vemos el área de uno de los botones de nuestra virtual key

Ahora cambiamos los valores de port incrementado en un 50%, poniendo en W 1600 y H 240. Vemos el área del virtual key:

He reducido un poco la imagen para que no sea vea tan grande en el blog

¿Qué ha pasado? ¿No estábamos cogiendo los valores del botón? Sí, y coincidían mientras no usemos port en vistas, pero ahora son diferentes. ¿Porqué? Porque los parámetros que se pasan en virtual_key_add() son los parámetros de la pantalla del dispositivo, no los del juego. Para entenderlo, ponemos un ejemplo radical: imagina que hacemos un juego con estética retro, como un tetris, y no necesitamos una room más grande de 320×240. Exportamos nuestro juego en nuestro móvil, que puede tener fácilmente 1920×1080 de resolución. ¿Qué hace Game Maker? Pues lo ampiará hasta el tamaño máximo de pantalla. Si hemos definido una tecla virtual de 64×64 píxeles, eso es lo que hará en el móvil. Así que tenemos un problema para solucionar.

¿Como solucionarlo?

Está claro que debemos definir el tamaño del área de nuestra virtual key, dependiendo de dónde se juegue, y que cambie resultando si estamos usando un iPhone 4S o un iPad 2. Yo he usado una solución estándar que vamos a explicar.
Cuando estamos diseñando nuestra room, podemos crear una grid para ajustar los objetos y que queden alineados. Yo creo los botones ajustándolos en esa grid para que queden bien alineados. En nuestro ejemplo, la grid es de 64 píxeles. Vamos a numerar cada casilla de la grid para ver dónde quedan los botones

Numeramos cada casilla. También vemos el tamaño total en el ancho de la room.

Vemos que el primer botón está en la casilla x=1, y = 6. Así que vamos a modificar el código para que quede así:

///Virtual Key LEFT

/*
    Si creamos juegos en pantalla completa, móvil o tablet,
    mejor utilizar en device_width la función display_get_width();
*/
device_width = window_get_width();

grid_size = device_width / 12.5;

xx = grid_size * 1;
yy = grid_size * 6;

v_left = virtual_key_add(xx, yy, grid_size, grid_size, vk_left);

virtual_key_show(v_left);

En la variable device_width guardamos el ancho de nuestro room con window_get_width(). Usamos esta función porque, tal y como comento en el código, si nuestro juego es una ventana (no está en pantalla completa), o dentro del navegador, si es HTML5, no podríamos usar display_get_width(), ya que esa función se utiliza para saber el tamaño del ancho de la pantalla completa.
La variable grid_size calcula el tamaño de la casilla a utilizar. Si no ampliamos nuestro juego con views, o jugándolo en pantalla completa, el tamaño sería el que vemos en la imagen del editor de rooms, 64 píxeles. Si usamos el port o zoom de la vista, entonces este tamaño cambiará y se adaptará a la perfección.
En las variables xx e yy, almacenamos la posición que quedaría con el cálculo.
Ahora solo falta modificar la función virtual_key_add(), añadiendo la posición calculada. Como el tamaño de los botones coincide con la casilla, podemos usar grid_size para definir el ancho y el alto de nuestra tecla virtual.

Conclusión

Si queréis ver como queda el código, os dejo este proyecto modificado. Un último apunte: los botones se han añadido tal cual en la room, si hacemos una vista que se va moviendo por toda la room, los botones también se desplazarán y pueden ocultarse. Cuando hagamos ejemplos de juegos, ya haremos todas las adaptaciones también para móvil. Queda pendiente para un futuro post como crear un pad de 360 grados para que funcione de una manera similar a un tecla virtual.

¿Que os parece el uso de las virtual keys? ¿Queda suficientemente claro? No dudéis en preguntar en los comentarios.