Desarrollar un juego de bolos para Android obliga a convertir un movimiento físico conocido en una interacción táctil breve. El gesto, la física y el marcador deben sentirse como una única acción.
Lo sabemos por Bowling Stryke, nuestro juego de bolos para Android, que hoy se llama Bolos – Bowling Stryke 3D en Google Play y supera el millón de descargas. Aquí contamos cómo se hizo y por qué la versión 5, que estamos preparando en Unity 6, empezó por arreglar la física. Qué es el juego y cómo se juega lo cuenta la página de Bowling Stryke, y el resumen del proyecto está en su ficha.
Un juego sencillo que gustó durante años.
Bowling Stryke es un juego de bolos en 3D de Androtiyas y OverFuture. Se juega sin conexión, en partidas rápidas para uno o dos jugadores que se pasan el móvil por turnos. Tiene reseñas desde 2014, y su última versión publicada es la 4.0.1.
Esa sencillez es lo que había que conservar. La versión 5 se rehace en Unity 6 con retos, progreso y cinco idiomas.
La partida sigue siendo la misma. Coges el móvil, lanzas y miras cómo caen los bolos.
El día que los bolos se caían solos.
Cuando retomamos el proyecto para la versión 5, el juego compilaba y las pruebas pasaban. Pero cualquier lanzamiento contaba como pleno, porque los bolos se caían solos en cuanto se soltaban, incluso sin bola.
Había dos causas que se sumaban. El centro de masas de cada bolo quedaba fuera del propio bolo, y la base de su colisionador era semiesférica, así que no se sostenía en pie. Corregir solo una no bastaba.
Por el mismo motivo, los bolos no dejaban de moverse y cada tirada se cerraba por tiempo, a los 20 segundos. En una prueba, una partida perfecta acumuló más de cinco minutos de espera.
Resolver el impacto como una secuencia.
El contacto inicial no cierra la jugada. El sistema debe dejar que terminen las colisiones, identificar qué bolos siguen en pie y actualizar el marcador cuando el estado ya es estable.
Un cierre demasiado rápido recoge los bolos antes de que la reacción sea visible, y uno demasiado lento rompe el ritmo. La transición necesita condiciones, no solo un temporizador fijo.
Eso es lo que hace el nuevo resolutor. Solo vigila los bolos que siguen en pie y cierra la jugada cuando pasan 0,45 segundos sin impactos y llevan 0,3 segundos quietos. Nunca espera más de 4 segundos tras el último impacto. Cuenta cada bolo por su posición y su orientación, y recoloca rectos los que quedan inclinados, como hace la máquina de una bolera.
En las pruebas, del lanzamiento al recuento pasan ahora entre 3,1 y 4 segundos.
Prueba útil. Repite exactamente el mismo lanzamiento y comprueba si el resultado, el tiempo de espera y la lectura del marcador mantienen una relación coherente.
Una pista a escala real.
La física de un juego de bolos depende de que todo tenga el mismo tamaño relativo que en una bolera. Medimos la pista sobre la malla del modelo y la dejamos en 18,29 metros de la línea de falta al primer bolo.
La bola mide 21,83 centímetros de diámetro y los bolos, 38,1 centímetros de alto. Bola, bolos y pista están en la misma escala, sin deformaciones en ninguna pieza de la escena.
Empezar por el gesto, no por el efecto.
El lanzamiento necesita traducir la posición, la distancia y la velocidad del dedo a parámetros comprensibles. Si pequeñas variaciones producen resultados extremos, el jugador no puede aprender de un intento al siguiente.
Antes de añadir efectos conviene visualizar la dirección calculada y probar rangos de fuerza. Esa instrumentación ayuda a detectar si el problema está en la entrada o en la simulación posterior.
Separar la trayectoria de la presentación.
La lógica que mueve la bola no debería depender del marcador ni de una animación de la interfaz. Mantener estas responsabilidades separadas permite ajustar la física sin romper el flujo de la ronda.
También facilita probar casos concretos, como un lanzamiento centrado, una entrada lateral o el contacto con el canal.
Modelar ronda, tirada y jugador activo.
Las reglas funcionan mejor cuando cada estado tiene una responsabilidad clara. La tirada registra el resultado, la ronda decide si continúa y la partida cambia de jugador o avanza hacia el final.
Esta estructura evita que un botón o una animación cambien varias reglas a la vez y hace viable un segundo jugador en el mismo móvil. Las reglas de puntuación eran lo que mejor funcionaba del proyecto. El 300, el décimo frame y la alternancia entre dos jugadores ya daban el resultado correcto.
Ese mismo marcador es el que usa nuestra calculadora de puntuación de bolos. Puedes meter tus tiradas y ver cómo suman los plenos y los semiplenos.
Pruebas que lanzan la bola.
El proyecto que retomamos tenía más de 400 pruebas automáticas y todas pasaban. El problema es que comprobaban la configuración, no el comportamiento, y ninguna detectó que los bolos se caían solos.
Las pruebas nuevas juegan de verdad. Colocan los bolos sin bola y comprueban que siguen en pie. Después hacen 12 lanzamientos variados, alternan dos jugadores y juegan una partida completa. La última encadena 12 plenos y espera un 300.
Una partida que se oye.
Una de las quejas que más se repetía en las reseñas era que no se oía nada. La causa era fácil de encontrar en cuanto alguien la buscó. La escena de la partida no tenía AudioListener, el componente que escucha el sonido en Unity.
Lo añadimos y los volúmenes de los ajustes vuelven a funcionar. Es un buen ejemplo de lo que aporta mirar el juego con los ojos del jugador y no solo el código.
Diseñar una interfaz que no tape la pista.
En el móvil, cada capa de información compite con el espacio jugable. El marcador debe poder consultarse sin ocultar la dirección del lanzamiento ni la posición de los bolos.
Las elecciones previas se agrupan antes de entrar en la pista. Durante la partida, la pantalla conserva solo el turno, la puntuación y las acciones imprescindibles.
En la versión 5, la interfaz vive en prefabs y escenas guardados, con uGUI y TextMeshPro, sin generadores de código que la rehagan.
Retos y progreso como datos.
La versión 5 añade retos, niveles y un selector de bolas. Las bolas se canjean con la experiencia que da el juego, sin dinero real. La lista completa está en la página de Bowling Stryke.
Las bolas, los niveles y los retos se definen como datos con ScriptableObjects. Nunca están en el código ni en la interfaz.
Así se pueden ajustar sin tocar la partida. El récord de la versión 4.0.1 pasa al perfil nuevo.
Un control correcto en un teléfono puede sentirse distinto en una tableta. Conviene probar densidades, relaciones de aspecto y frecuencias de refresco diferentes, además de dispositivos con recursos limitados.
La validación incluye el tiempo de carga, la respuesta del gesto y la legibilidad del marcador.
Y sigue cuando Android, Unity o las dependencias de publicación evolucionan.
Si vas a encargar un juego con física, pide pruebas automáticas que jueguen de verdad, no solo que revisen la configuración. Y pide ver el tiempo que tarda cada jugada en resolverse.
Lo que aprendimos.
Un juego puede compilar, pasar sus pruebas y estar roto. La física se comprueba lanzando la bola, y el sonido, escuchando la partida.
También aprendimos a medir antes de ajustar. La escala de la pista, los tiempos de espera y el recuento de bolos salieron de medidas, no de impresiones.
Es la forma de trabajar que aplicamos en cada encargo de desarrollo de videojuegos desde Zaragoza.
