Métodos de Scripting y Gameplay

Esta sección demuestra maneras que los desarrolladores móviles escriben código y estructuran su juegos para que puedan ser rápidos. La idea principal aquí es que el diseño del juego y la optimización no son procesos separados; las decisiones que usted haga cuando usted esté diseñando su juego pueden ser ambas divertidas y rápidas.

Un ejemplo histórico

Usted puede recordar juegos viejos dónde el jugador solamente estaba disponible a un disparo en la pantalla a la vez, y la velocidad de carga fue controlado por si la bala fallo o no, en vez de un temporizador. Esta técnica es llamada object pooling, y simplifica el manejo de memoria, haciendo que los programas corran más suave.

Los creadores de space invaders solamente tenían una pequeña cantidad de RAM, y tenían que asegurarse que su programa nunca fuera a necesitar asignar más de la disponible. Si dejaban que el jugadora disparará cada segundo, y ofrecieran un powerup que disminuyera el tiempo de carga a medio segundo, ellos hubieran tenido que asegurar que hubiera suficiente memoria en espacia para asignar muchos proyectiles en el caso dónde el jugador dispara tan rápido como sea posible, y todos los disparos viven por el tiempo más largo posible. Esto seguramente sería un problema para ellos, entonces más bien, ellos simplemente solo asignaron un proyectil y lo dejaron ahí. Tan pronto el proyectil muriera, simplemente se desactivaba, y era re-posicionado y luego activado cuando se disparará nuevamente. Pero siempre vive en el mismo espacio de memoria y no tiene que moverse o estar borrándose constantemente y recreado.

Una optimización, o una gema de gameplay?

Esto casi no es realista, pero cuando sucede es divertido. La tensión es soltada en un momento climático cuando los aliens invasores se acercan al suelo, similar al climax en una película o literatura. La proximidad cercana del invasor le dal al jugador adepto casi un tiempo de carga instantáneo, permitiéndole de manera milagrosa defender la tierra al destruir la tecla de disparo en un tiempo perfecto. Un buen diseño del juego vive en un espacio bizarro entre la narrativa interactiva y la tecnología del fondo que acciona todo. Es difícil planear cosas tan buenas, divertidas y eficientes como esta, ya que la logistica del código y la interfaz del usuario son dos cosas amplias diferentes y profundamente melindrosas, y utilizarlas juntas para sintetizar algo fresco y divertido toma mucho pensamiento y experimentación.

Usted probablemente no puede planear todo aspecto de su juego en términos de interacciones y jugar bonito con un hardware móvil simultáneamente. Es más probable que estas “gemas” dónde los dos se encuentra en armonía van a emerger como accidentes mientras usted está experimentando. Pero tener un entendimiento solido de la manera de que su código corre en el hardware que usted intenta desplegar lo va a ayudar. Si usted quiere ver una explicación técnica detallada de por qué el object pooling es mejor, y aprender acerca de la asignación de memoria, ver nuestra página de Scripting Optimizations

Será que X correrá más rápido en móviles?

Digamos que usted está empezando a trabajar en un juego, y quiere impresionar sus jugadores con muchas acciones y cosas llamativas que suceden a la vez. Cómo piensa planear esas cosas? Cómo sabe dónde los limites están, en términos de juego como qué tantas monedas, qué tantos zombies, qué tantos carros de los oponentes, etc? Todo depende en cómo usted programe su juego.

Por lo general, si usted escribe su código del juego de la manera fácil, o en la manera más general y versátil, usted correrá con problemas de rendimiento mucho más pronto. Entre más usted depende en unas estructuras especificas y trucos para correr su juego, habrá más horizontes expandidos, y usted será capaz de meter más cosas en la pantalla.

Fácil y versátil, pero lento

• Rigidbodies limitados a 2 dimensiones en un juego 2D.
• Rigidbodies en proyectiles.
• Utilizar Instantiate y Destroy mucho.
• Muchos objetos 3D individuales para coleccionables o personajes.
• Realizando cálculos cada frame.
• utilizar OnGui para su GUI o HUD.

Complicado y limitado, pero más rápido

• Escribiendo su propio código de física para un juego 2D.
• Manejando la detección de colisiones para sus proyectiles por usted mismo.
• Utilizar Object Pooling en vez de Insantiate y Destroy.
• Utilizar sprites animados en partículas para representar objetos simples.
• Realizar cálculos costosos cada pocos frames y poner en cache los resultados.
• Una solución GUI personalizada.

Ejemplos

Cientos de monedas coleccionables, girando, prendidas dinámicamente en la pantalla a la vez

• No: Cada moneda es un objeto separado con un rigidbody y un script que la gira y le permite ser recogida.
• SÍ: Las monedas son un sistema de partículas con una textura animada, un script hace las pruebas de colisión para todas las monedas y configura su color de acuerdo a la distancia de una luz.
  • Este ejemplo es implementado en la página de Optimización de Sripting.

Su simulación Soft-body construida personalizada

• NO: El mundo tiene almohadas por ahí en todas partes, las cuales usted puede tirar alrededor y hacer pilas de estas.
• SÍ: Su personaje es una almohada, solo hay una de ellas, y las situaciones en la que va a estar serán algo predecibles (Solamente colisiona con las esferas y los cubos alineados a los ejes). Usted puede probablemente programar algo que no es una simulación softbody con todas las características, pero se verá impresionante y correrá rápido.

30 personajes enemigos disparándole al jugador a la vez

• NO: Cada enemigo tiene su propio skinned mesh, un objeto separado para su arma, e instancia un proyectil basado en un rigidbody cada vez que dispara. Cada enemigo toma el estado de todos sus compatriotas en cuenta en un script AI complicado que se ejecuta cada frame.
• SÍ: La mayoría de enemigos están lejos, y son representados por sprites individuales, o, los enemigos están en 2D y están solo un par de sprites lejos. Cada bala del enemigo es dibujado por el mismo sistema de partícula y simulado por un script que solamente hace física rudimentaria. Cada enemigo actualiza su estado AI el doble por segundo, de acuerdo al estado de los otros enemigos en su sector.

El cómo y el por qué de la optmización de script

Ver la página de Optimizar Scripts.