Imagina que estás desarrollando un videojuego para unas gafas de realidad virtual. El documento de diseño lo expone todo; después de derrocar a la Reina Zombie, el jugador se dirigirá a la casa segura, donde una simple puerta en el interior es el único obstáculo entre la tranquilidad y un zombi que se come un trozo de su mente. Tu trabajo es sencillo: hacer una puerta que el jugador pueda abrir y cerrar.
Esta interacción aparentemente sencilla tiene una sorprendente profundidad. ¿Debe ser una puerta que se empuje o que se tire? ¿Debe haber una manilla o un pomo? ¿Puede el jugador interactuar con la puerta? ¿Es divertido interactuar con una puerta? Kerry Davis, de Valve, tiene una charla de casi una hora sobre este tema, y con razón; el desarrollo de la VR es una intersección única entre la interacción persona-ordenador y el diseño de juegos, y requiere una cuidadosa consideración para equilibrar ambos aspectos.
Si vienes de un entorno de desarrollo en otro ámbito, como el desarrollo de aplicaciones, ya conoces la melodía: cosas que parecen sencillas pueden ser muy complejas de implementar. Esto no es menos cierto en el desarrollo de la VR. En este artículo, hablaremos de las consideraciones esenciales que afectarán al alcance de tu juego de VR desde el principio, en qué se diferencian del desarrollo de juegos tradicionales y cómo afrontarlas de la mejor manera posible.
1. Diseña según las especificaciones técnicas de tu plataforma
El rendimiento de tu plataforma es una de las primeras cosas que debes tener en cuenta al diseñar un juego de VR. En el desarrollo de juegos, es habitual dejar la optimización para el final, pero esto puede ser una trampa en la VR. Lo último que quieres es llegar al final de tu ciclo de desarrollo y darte cuenta de que, debido a tu elección de plataforma, muchas de las ideas de juego que has tenido son extremadamente difíciles o imposibles de ejecutar a un nivel de rendimiento aceptable. Los peligros del bajo rendimiento son demasiado fuertes para ignorarlos. Por ejemplo, si tu juego sufre frecuentes caídas de fotogramas, puedes hacer que tus usuarios se sientan físicamente mal: una experiencia de juego poco divertida.
Sin embargo, las ligeras variaciones en la potencia de las plataformas no importan demasiado para el diseño de tu juego. Lo que importa es que las plataformas de VR se presentan ahora en dos tipos que tienen una diferencia bastante grande en cuanto a la potencia de cálculo, lo que repercutirá en el diseño de tu juego; son las llamadas plataformas con y sin ataduras.
En las plataformas «tethered» (por ejemplo, Valve Index y Oculus Rift), el procesamiento se realiza en un ordenador dedicado y el vídeo se envía al casco a través de un cable. Esto ofrece un rendimiento al nivel de un ordenador dedicado a los juegos o de una videoconsola de gama alta. Por otro lado, las plataformas sin ataduras tienen el hardware informático en el propio casco (por ejemplo, Oculus Quest). Este hardware suele ser tan potente como un buen smartphone o una consola de juegos.
Esencialmente, esta elección es la misma que cuando decides si apuntar a los teléfonos móviles para tu juego. La diferencia de potencia entre un ordenador de juegos y una plataforma móvil puede ser amplia; esto puede afectar a la fidelidad de tus imágenes, al número de objetos que pueden aparecer en pantalla, a la riqueza de tus simulaciones físicas, etc. Por ejemplo, si nuestro juego de zombis requiere miles de zombis que tienen una IA compleja y pueden chocar entre sí, puede que no sea factible realizarlo en una plataforma móvil. Haz un prototipo desde el principio para evaluar si el diseño de tu juego se ajusta a tu plataforma objetivo. Y si quieres desplegarlo en varias plataformas, recuerda esto: es mucho más fácil escalar un juego de una plataforma de baja potencia a una de alta potencia que al revés.
Una vez tomada esta decisión, ten en cuenta la tasa de refresco de las pantallas de tus plataformas objetivo y asegúrate de que te ajustas a esta cifra lo máximo posible. Como referencia, la Oculus Quest 2 admite intervalos de 72/80/90 Hz, mientras que la Valve Index admite 90/120/144 Hz. Para reiterar, debes cumplir con esta tasa de refresco sin caídas frecuentes de fotogramas, o harás que tus usuarios se enfermen físicamente. Los fabricantes de plataformas lo saben, y por ello algunas plataformas de distribución tienen un objetivo mínimo de framerate que tienes que cumplir para poder utilizarlas. Por ejemplo, Oculus exige un mínimo de 45 FPS para vender un juego en su tienda. Sin embargo, un juego de VR que funcione a este nivel suele considerarse un juego de bajo rendimiento. Esfuérzate siempre por cumplir con la tasa de refresco mínima soportada por la plataforma en todo momento.
2. Diseña para el volumen de seguimiento de tu plataforma
A continuación, deberás tener en cuenta cómo se moverá el jugador por el mundo digital que has creado. Para ello, fíjate en el sistema de seguimiento que utiliza tu plataforma. Esto es lo que permite al casco saber cómo se mueve en el espacio del mundo real. Hay dos tipos de sistemas de seguimiento: outside-in y inside-out.
Las plataformas como HTC Vive y Valve Index utilizan un sistema de seguimiento externo, en el que el usuario coloca sensores en la habitación que rastrean cómo se mueven los auriculares y los controladores. Esto ofrece un volumen de seguimiento limitado, es decir, el área dentro de la cual los jugadores pueden moverse físicamente y seguir siendo captados por los sensores. Este tipo de sistema de seguimiento suele encontrarse en las plataformas de VR ancladas, en las que se dispone de grandes cantidades de recursos informáticos para que el juego los utilice.
Plataformas como la Oculus Quest utilizan el seguimiento de dentro a fuera. Estos dispositivos tienen los sensores para el seguimiento del movimiento dentro del propio casco, normalmente mediante una serie de cámaras. La falta de sensores externos significa que el volumen de seguimiento de dentro a fuera es teóricamente ilimitado, lo que permite experiencias de VR que pueden llenar grandes espacios. Dado que no hay sensores externos que montar o calibrar, las plataformas «inside-out» son más adecuadas para aplicaciones de alta portabilidad, como demostraciones in situ o ferias comerciales.
Sin embargo, si estás diseñando una experiencia vinculada a un lugar físico, tendrás que asegurarte de que el espacio está bien iluminado y lleno de detalles para que las cámaras lo capten y lo rastreen; este tipo de sistema de seguimiento no funciona bien en una sala con paredes desnudas y un suelo sencillo. También hay que tener en cuenta que el seguimiento desde dentro hacia fuera suele ser una característica de las plataformas sin ataduras, lo que significa que tendrás que prestar mucha atención al rendimiento a cambio de la portabilidad.
En función del volumen de seguimiento de tu plataforma, la siguiente decisión es si se trata de una experiencia «de pie» o «a escala de sala». En la primera, el jugador se mueve utilizando medios abstractos, como un joystick o unos clics de un puntero, en lugar de mover físicamente su cuerpo (lo que se conoce como locomoción artificial). Esta opción funciona mejor en sistemas que no ofrecen un gran volumen de seguimiento, como Oculus Rift o PlayStation VR. Sin embargo, con un volumen de seguimiento lo suficientemente grande, se pueden ofrecer experiencias a escala de sala en las que el jugador puede caminar físicamente por el volumen de seguimiento (lo que se conoce como «locomoción natural»).
Hasta cierto punto, esta decisión se ha tomado por ti: Diseña siempre primero una experiencia de pie con locomoción artificial. Es imposible saber lo grande que será el espacio de juego de un jugador -a no ser que compruebes su lista de Zillow-, así que considera que la capacidad del jugador para caminar es un buen complemento si tiene los medios. Obviamente, ignora esto si el diseño de tu juego se basa en la locomoción natural a escala de la habitación, pero recuerda que estás perdiendo una gran audiencia al hacerlo.
3. Considera las interacciones
Si todos los juegos de VR requirieran simplemente que los jugadores anduvieran por ahí, el trabajo estaría hecho. Pero ahora hay que tener en cuenta cómo van a interactuar los jugadores con el juego utilizando sus mandos. Por ejemplo, en un juego en el que el jugador pinta sobre un lienzo, ¿qué constituye realmente la acción de pintar? Estas consideraciones son más fáciles de hacer si puedes decidir desde el principio si quieres que los mandos actúen como las manos del jugador o como herramientas.
Como manos, modelarás en gran medida las interacciones de los controladores según los mecanismos del mundo real. En nuestro ejemplo de pintura, el jugador cogería un pincel y «simplemente pintaría». Esta es una forma muy natural de modelar las interacciones, pero conlleva un montón de pasos adicionales. Por ejemplo, si un jugador puede coger un pincel, luego puede dejarlo, dejarlo caer o incluso perderlo. ¿Y entonces qué? Hay algo que se llama demasiado realista: ¿le va a parecer divertido al usuario dejar caer el pincel? Asegúrate de considerar a fondo las implicaciones de este modelo de interacción para tu juego.
Si tratas los mandos como herramientas, no tienes por qué ceñirte a las convenciones de la vida real. Por ejemplo, el mando podría ser una especie de multiherramienta con una interfaz de usuario para cambiar los ajustes del pincel, como es el caso del Tilt Brush de Google. También se podría tratar el mando como una especie de ratón, en el que el jugador apunta con un láser al lienzo y pulsa un botón para aplicar la pintura. Esta funcionalidad es más fácil de desarrollar, pero debido a su naturaleza abstracta, requerirá una mayor carga de información al usuario antes de que empiece a pintar.
